Outcomes Over Output: Why customer behavior is the key metric for business success

by Josh Seiden

an outcome is a change in human behavior that drives business results.

We should have been focused on something else: creating outcomes by changing customer behavior.

The problem with this approach is that features can be finished and delivered and “work perfectly” but stlll not deliver any value.

We do this by asking them to focus on changing customer behavior in a way that drives business results.

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.

What you want is to manage with outcomes: ask teams to create a specific customer behavior that drives business results.

To figure out if your outputs create the outcomes you seek, you need to test and run experiments. MVP is just a buzzword that means “experiment.”

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.

What are the customer and user behaviors that drive business results?

What’s powerful about this question is that it changes the focus of your planning—instead of focusing on what you intend to make, you’re setting your focus on the people you’re trying to serve.

What are our customers trying to do? How do they do that today? How can we make it easier for them to do that?

How can we get people to do more of these behaviors?

What’s powerful about this question is that it orients your planning process away from features ...

This question opens up our solution space to a much broader range of possibilities.

How do we know we’re right?

Good leaders know to ask their teams to deliver value—in other words, don’t just deliver stuff, instead, do something that creates value for the organization.

leaders think about impacts, and executors are responsible for outputs and outcomes.

“what (user/customer/employee) behaviors has this initiative created that are driving business results?”

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.

Use the magic questions to define outcomes: what are the human behaviors that drive business results? How can we get people to do more of these things? How will we know we’re right?

When you’re planning work, be clear about your assumptions. Be prepared to test your assumptions by expressing work as hypotheses. Test your hypotheses continuously by working in small iterations, experimenting, and responding to the data and feedback you collect.

The problem is that most of the time, the answers that make it to the roadmap are guesses, fiction, or lies. One solution to this problem: outcomes-based roadmaps.

Roadmaps fail when they present a picture of the future that is at odds with what we know about the future.

planning a roadmap around a customer journey.

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.

“He had a great thought—that instead of the project being called “IDP redesign” it could have been “Boost sales by 10% from IDP.”

The team decided to try this new approach on their next big project. They wanted to reduce what they called “the subscription funnel bounce rate." This is the rate of people who click on the subscribe button but don't complete the purchase. Notice already the new framing: they weren’t talking about features, but instead about generating business results.

In outcome-based work, teams need to be really clear about the value they are trying to create, and they do this by specifying two critical outcomes of the work: the outcome they are seeking for the customer or user, and the outcome they are seeking for the business.

In other words, you have to have theory that if you create a certain outcome for the customer, this will result in a specific outcome for the business:

if you’re trying to figure out what is going to work for users, you need their early feedback in order to steer your progress, which in turn requires early collaboration across the whole team.

there’s a big difference between a finished feature and value delivery.

“For us it’s about establishing hypotheses and measures of success before we start on an effort,”

They wanted to work on the most important things first, and they knew that to do this, they’d need a way to align their work to business goals. That, in turn, meant clearly articulating these goals, both the longer-term strategic goals and the more urgent, near-term goals. To do that they broke the year into quarters, and began holding goal-setting meetings with the executive leadership. The idea was to understand and agree on the top three outcomes executives wanted to get to in the next quarter. “We have annual goals,” Hellweg said, “but we look at them each quarter to find the top three near-term goals.”

It’s hard for everyone to shift their thinking from the concrete world of features to the abstract world of outcomes.

“it’s a big fundamental shift, and it’s giving up control.

“that’s my one piece of advice: you have to be open to failing and learning and be open to talking about it.”

Your colleagues are your customers. Everything is an outcome. Everything is an experiment.