More on this book
Community
Kindle Notes & Highlights
In the old days of engineering, setting project goals wasn’t that hard. If you’re building a bridge, for example, you know you’re done when the bridge is built and people are crossing it safely. If you’re making cars, you’re done when they roll off the assembly line. But when you’re making software products, done is less obvious. When is Microsoft Word done? When is Google done?
The problem with this approach is that features can be finished and delivered and “work perfectly” but stlll not deliver any value.
If you’ve ever used a microwave oven you’ve experienced this problem: how many of those buttons do you use in real life?
In fact, we want to use a planning process that makes it possible to make as little stuff as possible and still achieve the outcome we seek.
Outcomes, or the human behaviors that drive business results, are what happen when you deliver the right features. Ideally, they happen when you’ve delivered as few features as possible.
For our well project, the model might be something like this: we plan our resources (the people, materials, money, and other things we need), we undertake a set of activities (traveling to the village, acquiring and transporting our materials, building a well). If all of this goes according to plan, we create the output—the well. If the well works as planned, we achieve our outcome—people in the village spend less time carrying water. That in turn, becomes an important contributor to the impact we seek: a higher standard of living in the village.
These impact-level targets are too complex to be useful to our teams.
So let’s review: you can manage a team by telling them what to make: that’s called managing outputs. It’s a problem because features don’t always deliver value. You can manage a team by asking them to target some high-level value, like growing revenue. That’s called managing impact. It’s a problem because it’s not specific enough. What you want is to manage with outcomes: ask teams to create a specific customer behavior that drives business results. That allows them to find the right solution, and keeps them focused on delivering value. Early
our highest priority is to satisfy the customer through early and continuous delivery of value.
We might have asked, “what is the outcome that our business seeks?” If an outcome is a change in customer behavior that drives business results, we could have asked, “what is the customer behavior change that we are looking for?”
When you combine outcome-based targets with a process that’s based on running experiments, you really start to unlock the power of agile approaches.
“what could we do to deliver value early?” A day or two of planning would have yielded many ideas, and many of them could have been tested in low-risk, safe-to-fail ways.
outcomes are a great way to set goals because they allow teams to experiment—to try different solutions—until they hit on the one that works.
So you can think of agile projects as a series of hypotheses and experiments, all designed to achieve an outcome.
An MVP is NOT version 1.0 of your product. Instead,
there are only five things executives care about: increasing revenues, decreasing costs, increasing new business and market share, increasing revenue from existing customers, and increasing shareholder value.
an outcome is “a change in human behavior that drives business results.”
In for-profit organizations, we’re interested in things like revenue, profit, margin, costs, and loyalty. Those things are important, but you can see that they’re not outcomes in the sense we’ve defined just now. Instead, they’re impacts—the sum of a whole lot of outcomes.
To find the right outcomes to work on, we start with a simple question: “what are the customer behaviors that drive business results?”
Maybe we know that they visit our site after a friend shares an image of one of our shirts on social media. Could we get people to share images of our shirts more frequently? That’s another possible outcome: sharing t-shirt images more frequently.
because outcomes are things people do, they’re both observable and measurable.
first, that an outcome is a human behavior that drives business results,
In the example above, if we can demonstrate that social sharing of t-shirt images increases return visit rate, then social sharing is a leading indicator.
These indicators have some important properties. First, they are measures of what people are doing—in other words, they measure behavior. Second, they predict the success that we’re seeking. In other words, they’re outcomes: our indicators are the customer behaviors that drive the business results we’re seeking.
The good news is that, thanks to the Lean Startup movement, we have a framework for handling assumptions. We can express our assumptions as part of an hypothesis, and we can run an experiment in order to test our hypothesis and see whether our assumptions are right or wrong.
We believe that if people share pictures of our t-shirts at a greater rate, it will prompt existing customers to return to our site at a greater rate.
Earlier, I talked about the notion of MVP, or Minimum Viable Product. When I say MVP, this is what I mean: it’s the smallest thing we can do or make to see if our hypothesis is true.
If you look back on what we’ve just covered, you’ll see that there are a set of questions that we asked to help us use outcomes.
What are the user and customer behaviors that drive business results? (This is the outcome that we’re trying to create.)
How can we get people to do more of those behaviors? (These are the features, policy changes, promotions, etc that we’ll do to try to create the outcomes.)
How do we know that we’re right? (This uncovers the dynamics of the system, as well as the tests and metrics we’...
This highlight has been truncated due to consecutive passage length restrictions.
Instead, the feature must be in the service of changing something.
One consequence of this vagueness is that it makes it hard to track the progress of work. In my experience, this is because leaders and the folks who execute the work tend to think of value at different levels of specificity. Leaders think in high-level terms—appropriate
In other words, leaders think about impacts, and executors are responsible for outputs and outcomes. The solution to this is to try to communicate in terms of outcomes AND the effect you want them to have on the impact the leader cares about.
For example, a leader may want to reduce cost. That’s an impact. An execution team may understand that support costs are high because customers call tech support at a high rate. That’s the outcome. They think they can reduce tech support calls by fixing confusing product features. That’s the output. So in this case, a simple logic model would look like this:
It’s often the case that teams work on improving features based on an intuitive sense that it’s the right thing to do—but this intuitive sense is hard to communicate, and rarely compelling to leaders.
Instead, they’re much more likely to be planned and tracked in terms of features built, or in terms of how they’re tracking to some promised delivery date or other milestone.
For leaders in this situation, there’s a simple question that they can use to start the conversation about outcomes: “what (user/customer/employee) behaviors has this initiative created that are driving business results?”
This is how we can measure progress by using outcomes: insist that our teams plan in terms of outcomes, then ask repeatedly: “what new behaviors did your work create that are creating value for the business?”
So how do you write better OKRs? One way is to think of Key Results as outcomes. If you express your Key Result as a measurable customer behavior, you almost automatically have a well-written OKR.
OKRs can be improved if you think of the Key Result as an outcome.
different kind of roadmap than we’re used to seeing, an outcome-based roadmap.
The Root of the Problem: Output-based planning
Instead of building plans around the outputs that you’ll make, it often makes more sense to plan around themes of work, problems to solve, or outcomes to deliver.
a customer journey. You can also use methods like Impact Mapping, and Outcomes Mapping, (see Reading List at the end of this book) or any other method that allows you to break down big goals into component parts.
With these insights, we were able to ask questions like “how might we encourage buyers and sellers to meet in person earlier in the process? And, how might we eliminate the problem of location, which is causing buyers and sellers to get stuck?”
Instead of the vague (impact-level) request to increase NPS, instead we had a much more actionable set of things to work on: we want to increase the rate at which buyers and sellers meet early in the process. We want to decrease the rate at which buyers and sellers fail to meet due to problems of location. Both of these goals are outcomes: they are very specific and measurable rates of behavior.
For example, you might say something like: We believe that if we increase the rate at which buyers and sellers meet early in the process, it will lead to more successful transactions (as measured by X) and higher user satisfaction (as measured by NPS.) We think we can increase the rate of early meetings [with this idea] and [with this idea] and [with this idea.] We will work on testing these ideas in Q1 of the coming year. This
Outcomes are a tool for doing exactly this: specifying the value that we want our work to deliver.
What does it mean to define value from the customer’s point of view?
