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.

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

Think about all those website pop ups that try to get you to subscribe to a company’s mailing list. Do they work? Technically, they function as specified. But do they deliver value? Turns out that on the whole, they don’t—people simply get annoyed and just abandon the web site instead.

Setting goals as outcomes sounds simple, but it can be hard to do in practice. One thing that makes it hard is that we often set goals that are too high level—we tell a team to make our business more profitable, or to reduce risk, or something else that’s really a factor of many variables. These impact-level targets are too complex to be useful to our teams. Instead, 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. 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 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.

To find the right outcomes to work on, we start with a simple question: “what are the customer behaviors that drive business results?”

In our example above, we started to try to improve customer return rate by asking a question: “what are things that customers do that predict they’ll visit our site?” The word predict is really important here, so let’s talk about it for a moment.

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.)

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: Impact: reduce costs Outcome: fewer people calling tech support Output: improved usability of confusing features

But other initiatives tend not to have this culture of measurement. Internal technology initiatives are particularly bad. When teams are re-writing internal systems, for example, they often report progress in terms of how many system features they’ve completed. It would be better to instead measure progress in terms of new organizational behaviors created by their work. For example, what is the ratio of users of the new system vs the old system? How many of those users are able to use a new business process as a result of the initiative? Are the new business processes unlocked by this initiative ones that in turn generate positive outcomes?

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.

Don’t mistake impact—high-level aspirational goals—for outcomes. Impact is important, but it’s too big for any one group to target.

Roadmaps are supposed to help organizations manage uncertainty—they promise to answer questions like, “what are we going to be working on? What are we going to deliver? When can we expect this new capability / feature / product?” These are all reasonable questions. 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.

To do that, 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.

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.

In large organizations, coordination is always going to be hard—there’s no perfect organization of course, you’re always optimizing for one factor over another—but so often, our organizations are set up around product or channel vs behavior or customer journey. And when we do that, we’re implicitly de-prioritizing outcomes and prioritizing outputs.

Rather than discussing a desired set of features to implement, they talked about business impact of reducing the bounce rate. Instead of getting opinions on what should be done, the team dove into the data to see where the bounces were happening, and then commissioned a number of user interviews with people who had bounced.

In the resource-constrained environment at HBR, stakeholders had to wait a long time for their requests to make it to the front of the work queue. As a result, stakeholders sometimes loaded up their requests for work, trying to get everything they needed into each request. This is an understandable approach when you have a limited window in which to get your requests serviced, but it means that the team doing the work has to service larger and larger requests. This creates a paradoxical effect: as the scope of each request grows, it takes teams longer and longer to finish each request. When this happens, the other stakeholders suffer even longer wait times. And so when their turn comes, they stuff their requests full to the brim too. This negative feedback loop will make delays longer and longer unless organizations can find a way to break the cycle.

At HBR.org, the team was seeing the real impact of this negative feedback loop: they had a huge backlog of work that they had previously agreed to, and every stakeholder in the business had his or her own backlog of work that they’d not yet been able to get into the queue. A review of the queue showed that there was more than two years of work backed up—it was 2016, and there were tickets waiting in the queue that had been submitted in 2014! They needed to break the cycle.

They started by wiping the slate clean. They threw away their backlog of work. The whole thing. Eric said, “We had been managing this huge queue of old work. We had all these old tickets. Hundreds of them. We got rid of all of them.” One stakeholder, Jeff Levy, Head of Consumer Marketing, recalls, “frankly, it wasn’t going to g...

“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.

Changing behavior inside an organization is a hard problem, and not one that is easily solved by planning on paper. Instead, it benefits from an action-oriented approach. You try something, see if it works, and if it does, you invest in the approach. This experimental approach to achieving behavior change creates a deeply agile way to approach transformation inside organizations.