Hi all,
Today's post is about Goals, and partly for my own benefit, attempts to consolidate and summarize what I've learned from personal experiences and from various books. I'll touch on ideas from Christina Wadtke's Radical Focus, John Doerr's Measure What Matters, Josh Seiden's Outcomes Over Outputs, and Bill Carr and Colin Bryar's Working Backwards, and Marty Cagan's Inspired (as well as others).
Implementing effective goals or OKRs (objectives and key results), in my view, is really about building effective feedback driven control loops and establishing those control loops at the proper position in what Seiden refers to as a "results chain". (Inputs --> Activities --> Outputs --> Outcomes --> Impacts)
When people mess up goals, I think it's most often because they fail to set goals at the right point in the chain, or they fail to implement a feedback loop, and never look at the goal again until it's too late.
The short version of all this is that I believe a good product goal (as opposed to an engineering goal) is defined as an outcome that's within a team's control to achieve, and that the goal needs to be reported against every 1 or 2 weeks.
Of course, there's a lot of to unpack in that one sentence, which is what this blog post is about. I'll describe the results chain in more detail, use the results chain as a framework for talking about different types of goals, and then try to tie some ideas together from the various books.
Let's dive in.
Basic Models and a Common Language: The Results Chain
First, we need to start with some common language and mental models, because engineering outcomes, product outcomes, and business outcomes can all be mixed up.
My favorite model, that I learned about in Outcomes Over Outputs, is something referred to as a "results chain", and it's a framework often used for measuring some very challenging, tricky to define, humanitarian problems.
Inputs --> Activities --> Outputs --> Outcomes --> Impact
Here's a great example taken https://winderl.net/result-chain-a-beginners-guide,
The country of Smokistan wants to reduce smoking.
The desired impact is that less people die of smoke-related illnesses within five years.
The planned outcome is that fewer people smoke fewer cigarettes.
Smokistan plans to achieve that by increasing taxes on cigarettes and making smoking more difficult in public spaces – these are the outputs.
This requires several activities: for example drafting and passing a new anti-smoking law or funding and implementing smoke-free public zones, etc.
These activities require additional time and money – the inputs.
Outputs are tangible deliverables generated by projects. Documents, product features, software executables, parts, components, reports, etc... these are all outputs.
Outcomes, in particular, are given a very specific definition. For the purposes of product management, they are defined as "measurable changes in human behavior". (Or, for purposes of engineering teams, an outcome may be a "measurable performance improvement.")
Outcomes in turn, lead to impacts. Impact is usually something valuable or worthwhile, or a proxy measure for those things. The example above counts deaths from smoking related illnesses, but things like revenue, Net Promoter Score (NPS), star rating, and other trailing measures would all be considered "impacts".
Different Styles of Goals and Taking Goals at Different Points in the Chain
Seiden advocates specifically for defining product goals in terms of outcomes. In general, I agree, but it's at odds with some of the advice in the other books. Here's how I make sense of it.
Goals on Activities
It makes sense to set an activity based goal if that activity is hard, and the goals serves as a reminder to keep doing the right thing. For example, "Make 3 outbound sales calls per week" is a reminder that sales can be a numbers game, and that sometimes it takes some hustle.
"Go to the gym twice a week" is another form of activity based goal. In the results chain for this one, we're assuming the activity will lead to a net negative calorie expenditure (the measurable outcome), that will lead to weight loss (the impact).
The caveat with activity based goals, is that they create some lock in and take away some creativity . For example, we could get to a net negative calorie expenditure through diet, and while a dramatic choice, we could also get to the desired weight loss through surgery. Taking a goal on an activity creates focus, which is often a good thing, but understand that setting goals further upstream in the results chain takes away options.
Goals on Outputs
I don't mind output goals when the output is quantifiable, but too often, an output is reduced to building a feature or completing a project, and that's where I object. I'll provide examples of both in a moment.
I'm also of the belief that when goals are quantifiable, it's possible to set a wildly ambitious goal to inspire people, and still realize positive outcomes when the quantifiable output falls short of the target. Many outputs, on the other hand, like features or projects, are binary; they're done or they're not.
In Working Backwards, an output goal was set against the number of product pages on Amazon.com with in-stock items, the idea being that more items (the output), would lead to more customers finding something they like and making a purchase (the human behavior that defines the outcome), which would lead in turn to business impact. Here's a case where falling 10% short of an ambitious output goal (say, 750,000 products in stock) is still pretty awesome.
On the other hand, I see so many teams takes goals like "Launch this new feature." I object to these types of goals because they lock the team into building the feature and they let the team off the hook if the feature doesn't have the intended outcome with customers.
Maybe it's semantics, but I view projects as a things where people work to reduce risk and are expected to predictably execute. Which isn't to say that projects shouldn't be tracked and reported against, they should, its just that calling them goals, is in my view, a disservice.
Perhaps the lone exception to my "project as goal" objection is when achieving the output isn't guaranteed from the get go. This is the canonical moonshot: "...this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth."
Goals on Outcomes
Setting goals on outcomes is the model advocated for in Outcomes over Outputs, where an outcome is specifically defined as a human behavior. Some human behaviors lead others. For example, increasing new user signups is a behavior that might lead returning visits, which may in turn lead more behaviors like making a purchase, which will lead to business impact.
One of the things that I really like about this model is that focusing on human behavior, is I think, at the core of good design, and human behaviors make defining measurements somewhat simpler and less subjective.
Setting a goal on outcomes also creates a feedback loop at an interesting point in the results chain. It's not so far upstream that it locks you into a plan, and it's not so too far downstream to get timely feedback, or where other confounding variables may be getting mixed in the signal.
Setting goals on outcomes gives a product team a lot more creative freedom to figure out how to drive the outcome they want, but with a short enough leash to hold them accountable.
I think the real challenge here is figuring out which product outcomes you think will lead to business impact. It takes time and customer research to make that happen, so you can't necessarily jump to goal setting right away. It might take a quarter of research to figure out what outcome you think will drive the desired impact.
Goals on Impact
Finally, it's possible to set straightforward goals on impact, for example "increase revenue by 10%." These give the most freedom and latitude, sometime too much, because it can be beyond the scope of a single team to control. For example, marketing, sales, and product can all influence revenue together. Holding a single team accountable for goals like this can be tricky.
Creating Feedback Loops: More Thoughts On Implementing Goals
So I mentioned earlier the importance of creating feedback driven control loops, and that I believe that means reporting at a cadence of every 1 to 2 weeks.
The intent here, is to force teams to regularly ask themselves "where are we going, where are we now, and what are we doing to close the gap?" When I've seen teams try grading OKRs on a quarterly or 6 week (half quarterly) cadence, the goals just don't stay top of mind.
On the other hand, I've seen teams asked to report an accuracy target (an example of a performance metric, or an engineering outcome), only to realize in the first reporting sessions that they had no idea how to measure the accuracy. Two weeks later, they came back to it with a hand calculated measurement and we argued over the definition of what accuracy meant, than two weeks later, we had automated the measurement, and then over the course of several months, the metric slowly increased as we improved the product.
There are a few points to take away. First, the initial goal language was not perfect. Second, coming back to the goal every 2 weeks forced us to pay attention to it. We refined our definition of what the goal was, how to measure it, and how to improve it.
So in other words, if you're spending more than 2 weeks defining goals, you're taking away some of the power of feedback loops to correct the goal and your definition of it. Define the goal quickly. It's ok to refine it over time. The point is to come back to it repeatedly. Keep asking "Where are we going, where are we now, and what are we doing to close the gap?""
FAQs, Gotchas, and Other Errata
What if the goal can't be measured until the end of the quarter?
Some goals are hard to measure on a continuous basis, or aren't worth measuring until after a project is completed. In this case, Wodtke suggests reporting a confidence score on achieving the goal. Clearly, a direct measurement would be preferable, but at the very least, the feedback loops and mechanisms to drive focus are in place.
Where do mission and vision fit on the results chain?
This is one where I'm still thinking through things. I think shorter term objectives, the larger vision, and the long term mission all fit within the category of down stream impacts.
What is the overlap between the results chain framework above and Objectives and Key Results?
Well, there's a lot that's been written about OKRs, much of which conflicts. John Doore's book, which I don't recommend, often uses a format that I think is more akin to user stories and acceptance criteria, i.e. "achieve this goal, by which we mean that we agree completing these projects means the goal is met." Again, I don't like projects, because I think they take teams off the hook for projects that don't deliver intended results.
Christina Wodtke's book fits much more closely with the framework above, but doesn't write about it quite as clearly, or as a formally. In her book, it's a more pragmatic "how would we know quantitatively that we've achieved our objective?" with less formal definitions of what each of the steps of the chain means..
What about pragmatic situations when you just need to launch something, like a restaurant?
Wodtke would say to quantify the launch. How would you know a restaurant opening is successful? Is it the number of customers? Yelp reviews? Writeups from restaurant critics? Followers on instagram? Service times and food quality? This is all to help you focus. Why is your confidence score an 8 that we'll have a line of customers out the door on opening night? What are you doing to make that a 10?
Notes on Quantity/Quality pairs
Wodtke and others talk about the importance of balanced goals. For example, balancing goals on quantity with goals on quality. It's great that's there's an engineering performance target to produce 20% more widgets an hour. You can't be spitting out garbage parts though, to get there.
Notes on Trade Spaces:
I've seen some goals that give teams freedom my making tradespaces explicit. For example, engineering performance goals on airplane parts could trade a pound of weight and make their part heavier, but only if it also saved $10,000. This sets a lot of context and gives the team to pursue better choices.