Understanding Outcomes

As we look towards planning for Q3, the product teams I work with have started their quarterly product increment (PI) planning. One thing that came up this week was how to understand or find the outcome for a specific goal or problem.

It’s easy to fall into old projects traps such as “we should add this new feature,” or “I’d like to update the design of this page.” These are common outputs that a lot of teams and individuals new to the product model may be drawn to as it feels like a meaningful step towards “doing something,” but unless these features or design updates are tied to a specific business or user outcome they’re a pitfall back into the build trap.

One PM brought up the following question:

I don’t think “User Enjoyment” is an outcome, in the sense that it is not a measurable human behavior. It’s definitely my Goal, but do I still need to come up with a separate measurable Outcome that drives that Goal?

One member of the product management team suggested this might be a good “5 whys” exercise, another pointed out how “enjoyment” is an incredibly subjective metric and as such is difficult to measure.

I love this question, because it showed that the individuals in our product teams are really working to understand how to move to the product model, and digging deep in trying to understand what is important.

Outcomes Defined

My personal preferred definition of an outcome is “A measurable metric of success; often a change in behavior, that is mapped or aligned to a specific business or product objective (OKR).” What this means is practice is that in order to be an outcome, whatever we’re looking at needs to be measurable, and drive towards the success of a stated objective for the business or product.

For the example above, “User Enjoyment” on its own would not qualify as an outcome, what does improving this metric result in? What is the business or product objective?

By forcing alignment with an objective we can begin to understand the framing around how we might build out our outcomes. If our business objective is growth and retention, and our product objective is an increase in the completion rate of a task, what sorts of behaviors can we modify in order to achieve these objectives?

If we increase how engaging or enjoyable the task is we might see an uptick in completion rates, now we’ve got a measurable outcome that ties back to the original question of how to make “User Enjoyment” more concrete.

Outcome-Driven Product Development

When we use the lens of outcomes to examine product decisions we focus more on the why instead of the how and solutions can come from multiple places. No longer is success defined by what or how much we build, but instead by the impact we have on user and business goals. Product teams are empowered to truly understand their users and dig deep into all of the potential avenues that can solve their problems. This collaborative and exploratory process creates the space for novel and robust solutions that often drive companies to greater success and user loyalty.