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

by Josh Seiden

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.

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.

To see if our work is actually making a difference, we need checkpoints that are smaller, measurable, and more closely connected to the work that we’re doing.

we need to ask our teams to work on outcomes—the smaller, more manageable targets that, taken together, will create the impact we want. We do this by asking them to focus on changing customer behavior in a way that drives business results.

measures of customer behavior.

might be small changes in a big system, but they are specific, and they allow our teams the flexibility to figure out the most efficient way to solve the problem, to deliver the behavior change that we seek, and to make a meaningful contribution to the impacts (revenue, profitability) that our executive leaders care about.

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

our highest priority is to satisfy the customer through early and continuous delivery of value.

have clarity about what “value” means.

“what is the customer behavior change that we are looking for?”

how can we be sure that the stuff we’re making is actually going to deliver value?

The simple answer is that you frequently can’t know in advance. This is why, when working with outcomes, you need a companion tool: the experiment.

Combining experiments with outcomes is a really powerful way to work, especially in situations of high uncertainty.

allows your team to be agile: you set a goal, design an experiment, then you test and learn, test and learn, test and learn, until eventually, you figure out the best solution. So you can think of agile projects as a series of hypotheses and experiments, all designed to achieve an outcome.

smallest thing you can do or the smallest thing you can make to learn if your hypothesis is correct.

highest level of a business, leaders are concerned with the overall performance of the organization, and the performance numbers they watch tend to come down to these factors—which, in our language are high-level or “impact” metrics.

revenue, profit, margin, costs, and loyalty.

impacts—the sum of a whole lot of outcomes.

observable and measurable.

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.

An easy first step would be to see if you have the data. And if you don’t, your next step might be to run an experiment to see if you can observe a correlation.

as we start looking at generating the outcomes we’re seeking, it naturally drives us deeper into the dynamics and relationships in the systems we’re designing, building, and operating. If we change this piece of of the system, what happens?

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

Impact: reduce costs Outcome: fewer people calling tech support Output: improved usability of confusing features

should be able to measure and report on the progress of their work

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. If instead teams can demonstrate through these models that their work goes directly towards creating a business impact that leaders care about, conversations become much more grounded, and teams and leaders become much more aligned.

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

reorients it towards value delivery.

Instead of planning for some mythical “feature-complete” future state (remember, software is never complete), they can plan to deliver value early, then enhance that value through continuous, incremental delivery.

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?”

outcomes let you write better OKR by asking you to step back from your work, consider the meaningful business result that you’re trying to achieve, and express all that in easy-to-measure terms of customer behavior.

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?

be clear about your assumptions.

Test your hypotheses continuously by working in small iterations, experimenting, and responding to the data and feedback you collect.

Build an understanding of what behaviors lead to achieving the targets you seek.

we have to be honest with ourselves about what we know and what we don’t know.

then use observations of customer behavior, data about what people do, and experiments to expand the scope of what you actually know.

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

plan around themes of work, problems to solve, or outcomes to deliver.

planning a roadmap around a customer journey.

Impact Mapping,

Outcomes M...

visualize human behaviors,

current state of the service and see what was creating satisfaction today—and conversely, what was creating dissatisfaction.

behaviors of the people and systems that make up the platform.

success factors (or boosters)

failure factors (or blockers)

Create outcomes-based roadmaps that list questions, themes, and outcomes instead of features.

“The way we took work in, the way we prioritized, the way we executed on work and tracked the results.”

teams need to be really clear about the value they are trying to create,