How to measure progress with outcomes

You’ve heard the phrase Outcomes over Outputs. Now let’s put that idea to work.

This piece is a lightly edited excerpt from my new book Outcomes over Output. If you’d like to read more, you can find the book here.

Good leaders ask their teams to deliver value. They want their teams to go beyond simply delivering stuff. Instead, they want teams to do something that creates value for the organization. But “value” is a tricky word — it’s too vague to really get people aligned.

One consequence of this vagueness is that it makes it hard to track the progress of work. In my experience, this is because leaders and the folks who execute the work tend to think of value at different levels of specificity.

Leaders think in high-level terms — appropriate to their level in the organization. Let’s call those “Impacts.” Executors think in much more detailed terms — again, reflecting their POV from where they sit in the organization.

The Project Logic Model, adapted from Kellogg Foundation

In other words, leaders think about impacts, and execution teams tend to think about resources, activities, and outputs.

Bridging The Gap

The solution to this is to try to communicate in terms of outcomes and the effect those outcomes will have on the impact the leader cares about.

Outcomes are the human behaviors that drive business results.

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

When teams are working with well-defined outcomes, tracking progress becomes simpler — leaders and teams can review the hypotheses the teams are working on, they can review their progress towards the outcomes they’re seeking, and they can look at a concrete measure: are people’s behaviors changing? In this case, a team should be able to measure and report on the progress of their work simply by reporting on the rate of calls to tech support relative to the products that they’re working on.

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.

Getting Started with Outcomes

Leaders who are looking to begin using outcomes to track the progress of major initiatives are often in a difficult situation. In most situations, initiatives are not planned in terms of outcomes. Instead, they’re much more likely to be planned and tracked in terms of features built, or in terms of how they’re tracking to some promised delivery date or other milestone.

For leaders in this situation, there’s a simple question that they can use to start the conversation about outcomes: “what (user/customer/employee) behaviors has this initiative created that are driving business results?”

That question is the key to tracking progress because it moves the conversation away from features and reorients it towards value delivery.

For example, you might have a team working on an email marketing campaign. Email newsletters are an easy example because marketing teams are used to measuring their success in terms of what people do with their emails. Do they open them? Do they act on the calls to action? Are the actions that result valuable to the business?

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?

Technologists sometimes push back — they will make the claim that they can’t cut users over from one system to another until the new system is complete. But this is where the power of outcomes shows up: no digital system is ever really complete, and conversely, even very small slices of a new digital system can start generating value before the rest of the system is ready.

So, if we insist that we measure value in terms of outcomes — how many new users are running through the new system — we can encourage teams to change their plans to deliver the outcomes we seek. 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?”

This piece is a lightly edited excerpt from my new book Outcomes over Output. If you’d like to read more, you can find the book here.