Outcomes Are the Success Criteria for Your Hypotheses

Ever since we shared the?Lean UX Canvas?teams around the world have used it to kick off initiatives and begin a cross-functional, product discovery journey. Over the years, I’ve clarified various parts of the canvas including?sharing a complete canvas example. Perhaps the most critical box in the entire canvas is Box 2 – Business Outcomes. This is where I’ve shared in previous blog posts:

• Why you should map your outcomes to impact metrics
• The exercise template for mapping outcomes to impact metrics
• How to find both objectives and key results in the canvas (heavy focus on Box 2)

One thing that continues to come up in?Lean UX workshops?as well as?OKR conversations?is how the outcomes created in Box 2 relate to other parts of the canvas and how best to use them.

Outcomes Are the New Definition of Done

Modern software is built on continuous platforms. These tools allow us to deploy software as fast as we want. Today’s continuous deployment tools have made software deployment a non-event. In the past, shipping software was the definition of done. In today’s continuous world, reaching an outcome is the new definition of done.

An outcome is measure of human behavior. It tells us how the feature we shipped has impacted the people that consume it. If we choose the right combination of code, copy and design we should see our users’ behavior change in a positive way. This is our goal. In a world where we can ship and optimise software forever, outcomes tell us when we’re done.

Outcomes Help Us Validate Our Hypotheses

In the context of the?Lean UX Canvas, and specifically Box 2, the outcomes we generate during this exercise serve as the success criteria for the hypotheses we write in Box 6 of the canvas. We determine the validity of a hypothesis by measuring how much human behavior has changed. Often these outcomes are leading indicators to the actual behavior change we are seeking. For example, we may have a goal to increase the completion rate of the checkout process by 65%. However, in order to do that we first have to figure out how to get people to more effectively add items to their shopping cart. So we may have a leading indicator of, “increase number of times a user adds an item to their cart by 50%” as a way to test hypothetical improvements to that part of the checkout process.

Each hypothesis we come up with for solving our user and business problems must have a success metric attached to it in the form of an outcome. In fact, the very first variable in the hypothesis template is where we plug in the outcomes generated in Box 2. “We believe we that?[business outcome]?will be achieved…” is where these metrics belong. Without a clear measure of human behavior we have no clear indication whether our ideas stand a chance for success or not. This is how we know whether we should persevere with our hypothesis, pivot from it or kill it and move on to a new idea. Outcomes provide the objective perspective we need to help us make both prioritisation as well as development and design decisions.