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.

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.

Notice that the outcome—people spend less time carrying water—is a change in behavior that creates positive results.

We want our customers to log onto our site more often, or put an extra item in their shopping cart, or share an interesting article with a friend, or upload a picture, or complete a task in less time. What do all of these things have in common? They’re all measures of customer behavior. They 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,

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.

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

With that high-level impact defined, we can start looking at customer behaviors. We can ask: “what are things that customers do that predict they’ll visit our site?”

You’ll notice something else: because outcomes are things people do, they’re both observable and measurable.

You just need to remember two things: first, that an outcome is a human behavior that drives business results, and second, to figure them out, we just need to understand what our customers are doing that drives the results that we care about.

When we state our goal as an outcome, we’re either proposing some logical relationship between our work and the result we seek, or asking our teams to figure out that relationship—because we’re asking them to figure out how they might create that outcome. And once we’ve proposed that relationship, we capture it in a hypothesis, and test it with an experiment.

These questions are my magic questions for finding 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’ll use to measure our progress.)

Leaders think in high-level terms—appropriate to their level in the organization. Executors think in much more detailed terms—again, reflecting their POV from where they sit in the organization. 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.

a simple logic model would look like this: Impact: reduce costs Outcome: fewer people calling tech support Output: improved usability of confusing features

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. For example, your objective might be to Successfully Launch our New Product. Your key results might be 25 positive reviews in app store in first day. 3 mentions on industry blogs before launch. 1000 new user registrations in first week 25% of new users convert to repeat users All of these are measures of user or customer or stakeholder behavior that result from your product launch effort. Now you’ll notice that none of this is about what features your product has. It leaves open the “how.” That gives you room to experiment with your tactics, but it aligns the team with the business result you’re generating.

Roadmaps fail when they present a picture of the future that is at odds with what we know about the future. If we were setting out to cross an uncharted desert—one that we cannot see from the air, and that was of unknown size—it would be crazy to predict that we could cross it in a few hours. How far are we traveling? What terrain will we encounter? What sources of food and water exist? You get the idea—you’d be reckless to make a prediction. Instead, you’d probably present your journey (if you chose to make it at all!) as an exploration. You’d ask backers for funding based on the tantalizing promise of what you might find as you explored this unknown land. And certainly, if you had a map at all, it would probably showcase how little you knew about the terrain.

you have to identify not just a single outcome (for example, the way a team might identify a problem and work on that one problem for a while) but instead you have to find a set or a system of related outcomes that taken together will create the result that you want. There are a number of ways to do that, but here I’m going to share one method that I’ve used successfully, and that can apply in a large number of contexts: planning a roadmap around 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.

Case Study: Improving NPS Here’s an example from a recent non-profit client. I was working with a team that had been asked to raise the customer satisfaction score of the service they delivered. The score they were using, called Net Promoter Score or NPS, is used to assess the likelihood of a customer recommending your product or service to others. The team I was working with had been given a goal to improve their score in the coming year. They were trying to figure out how to do this. NPS is an impact. It’s the sum of many factors. So we needed to break that impact down into smaller parts: we needed to identify the outcomes that would contribute to increased customer satisfaction. Our first step was to try to understand the current state of the service and see what was creating satisfaction today—and conversely, what was creating dissatisfaction. We did this by creating a customer journey map. My client runs a two-sided marketplace. So we created our map with three swim lanes: seller behaviors, buyer behaviors, and organizations/system behaviors. Then, in each lane, we laid out an end-to-end, step-by-step picture of the things people do as they interact with the service and with each other. This gave us our raw material: the behaviors of the people and systems that make up the platform. Next: Boosters and Blockers With that mapped out (on a big wall, from left to right, with sticky notes), we then went back through the map and asked our magic question: “What behaviors at ...

And as we answered those questions, we started to come up with a list of things we wanted to work on. 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. In this example, the team chose to stop there, and express the roadmap in terms of the questions we were trying to answer. (“How might we encourage buyers and sellers to meet early in the process?”) We could have taken it one step further, and come up with a list of ideas for how we could encourage early meetings, and included those ideas in the roadmap. If you want to do that though, my recommendation is to avoid making a roadmap that’s filled with answers and ideas. Instead, build the roadmap around hypotheses that link question and potential answer together. 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.

One final point here, you can use this method any time you’re handed a target at the impact level. You’re asked to increase sales? Create a customer journey map, and then review it with the magic question: “what are the behaviors in the system that predict higher sales, and how can we go about encouraging those behaviors?” You’re asked to increase revenue? Same process: create a customer journey map, then ask “what are the behaviors that lead to higher revenue and how can we go about encouraging those?”

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. These two outcomes must be linked. 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 we create this outcome for the user, it will deliver this outcome for the business.

This is a critical part of orienting your work around outcomes: 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.

“In the next meeting, I asked them to talk about what they were worried about. It was night and day. They started telling their stories about their business. The head of [one department] was stressed, because [critical metrics] were down year over year. All the other stakeholders heard the concern, and agreed, ‘we have to focus on that.’ It was the first time in the process that everyone was aligned,” Emily said, ”and it felt like a huge win.” In other words, by shifting the focus, the whole company was able to step back from feature conversations and consider the business problems they needed to solve—the outcomes they wanted to create. In doing so, prioritization suddenly became clear.