More on this book
Community
Kindle Notes & Highlights
an outcome is a change in human behavior that drives business results. Outcomes have nothing to do with making stuff—though they sometimes are created by making the right stuff. Instead, outcomes are the changes in customer, user, employee behavior that lead to good things for your company, your organization, or whomever is the focus of your work.
It’s common to get caught in this kind of confusion—mistaking “making stuff” for making progress, and mistaking shipping features for being done. It’s a legacy of a time when we mostly made physical goods, and making stuff well was the primary challenge.
Why not just make an endless list of features and ask our teams to work on that list—forever? In fact, a lot of contemporary project management turns out to work exactly this way. The problem with this approach is that features can be finished and delivered and “work perfectly” but stlll not deliver any value.
So if features don’t automatically create value, then it follows that we shouldn’t use them as the center of our planning process. 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.
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.
The first Agile Principle says, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” As agile is applied to problems bigger than software development, many people who believe in agile principles have restated this principle. Today, it’s fair to say: our highest priority is to satisfy the customer through early and continuous delivery of value.
When you start thinking critically about value delivery instead of features, you very quickly run into a problem: how can we be sure that the stuff we’re making is actually going to deliver value?
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.
An MVP is NOT version 1.0 of your product. Instead, think of MVP as the the smallest thing you can do or the smallest thing you can make to learn if your hypothesis is correct.
The design guru Jared Spool asserts that 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.
The phrase “human behavior” can apply to users’ behavior, customers’ behavior, or staff and employee behavior—anyone who is part of the system can be the focus of this statement.
To find the right outcomes to work on, we start with a simple question: “what are the customer behaviors that drive business results?”
because outcomes are things people do, they’re both observable and measurable. This is an incredibly important part of outcomes because it lets us use them as a management tool.
our indicators are the customer behaviors that drive the business results we’re seeking.
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’ll use to measure our progress.)
