How to Combine OKRs and User Story Mapping

When you look at most companies’ goals, you find a lot of them focus on output. They put the products and features they’re making at the center of their work and define success as getting those products and features shipped. Some companies, however, have figured out that simply shipping output doesn’t solve their business problems. Instead, they have to focus on their customers, and more specifically the behavior of their customers—which we call outcomes—and what they do with the products. To be successful, they must meet customers’ needs, which will lead to behaviors that drive business results.

There are frameworks to help teams focus their work on their customers. One is my bread and butter: OKRs. Another one popular in the product world is user story mapping. They don’t necessarily get used together—but as story mapping creator Jeff Patton and I advocate, they should.

OKRs help companies and teams identify and prioritize their business needs, formulate goals to align everyone’s work, and identify potential solutions to achieve their goals. User story mapping helps product teams outline customers’ experiences with different products and features from start to finish, and plan optimal release strategies for those products and features. Put them together and you have perfect complimentary processes:

• OKRs tell you the direction your work needs to go and helps you identify potential solutions.

• User story mapping helps you map out those solutions to find the best option and determine the best way to bring it to market.

As I mentioned above, Jeff and I have a new workshop where we teach people how organizations (with a special focus on product teams) can use the two frameworks together. Here’s how we plot out that process in the workshop, from one stage to the next.

1. Identify business needs and write high-level OKRs.

The executive team identifies the most important business problem facing the company and determines the high-level business objective and key results to focus and align all teams’ work.

These key results are impact-level metrics—a.k.a. what the company cares about, but not what the customers care about. For those of us on product teams, the high-level business OKRs help direct our thinking, but to better understand and further refine our build efforts, we need to get a good sense of what our customers care about. That’s the next stage.

2. Identify current customer needs.

Product teams identify the customers’ needs. That first requires identifying the different customers you have. Let’s say your company is B2B, and your customer is another business. Your real customers are the people who work for that business and engage with your product. In that situation, you need to figure out both what their business needs from your product and what the team members who work for that business need.

When you have your customer needs mapped, then you need to figure out your OKRs at the product level.

3. Write product OKRs.

Which one of your customers’ needs most heavily influences the goals stated in your company’s high-level OKRs? At the team level, your objective and key results should focus on that. (If you’re unsure how to write OKRs at the team level, I’ve got you covered.)

Heads up, teams: When you select your key results, make sure to reconcile them with the objective. Teams often write their objective statement on its own and then pick metrics for their key results that may or may not go with the objective. Be sure to double-check. If your customers’ behavior changes in the way stated in your key results, will that lead to your objective? If not, one of the pieces needs to change. You can change either the objective or the key results, but in the end they need to make sense when put together.

4. Identify and prioritize potential solutions.

The next phase of the process is to figure out what you’re going to work on. Looking at your OKRs, your team needs to come up with a list of potential solutions to the customer (and business) problem that you’re trying to solve. These are the products or features you could build. As you write your list, include both what the solution is and the purpose it serves.

When you’ve figured out a handful of good options, start prioritizing them based on two axes: high vs. low perceived value and perceived risk. Something like this…

(Some of you may also be familiar with the Lean UX Canvas used for prioritization.)

The key to always keep in mind as you place your solutions on the matrix is how the value and risk of each solution relate to your OKR. Is it high-value relative to the specific OKR you’re trying to hit, or just generally high-value? For example, if your objective is to create a collaboration tool that cross-functional teams will rely on every day, a potential solution is only high-value if it would positively affect daily usage, not overall usage or usage in another category.

As you assess risk, it’s important to look at it from a variety of angles.

• Value Risk: Do your customers want it? Will they try it once? Will they keep using it?

• Design Risk: Can you create a usable design of the solution reasonably well?

• Technical Risk: Can you build it predictably at scale? Do you have the internal technological expertise to be able to build the solution you’re proposing?

• Brand Risk: Does the solution make sense for the company’s brand? Is it something that aligns with the company’s current offerings and market scope?

When you’ve plotted all potential solutions on the axes, look at the options that have the highest perceived value and a reasonable level of risk—a.k.a. not too high of a risk that it would be too great of an investment for the company to pursue right away.

When you’ve selected the solution you think will best serve your OKRs, then you’re ready for some story mapping.

5. Story map your solutions.

If you’re going to decide to build or work on something, you need to think through what people will do when they use the new product or feature. This is where story mapping comes in very handy. It’s not just for building backlogs, folks; story mapping is for thinking things through.

There are three important steps to story mapping:

1. Frame the story. This means naming your hypothesis. What outcomes and impact do you believe your solution will have, on whom, and why do you believe that?
   

2. Tell the high-level story. Walk through the key points of your customers’ journeys using your proposed product or feature (remember, you may have a few different individual customer personas to account for).
   
   It’s important that the high-level story stays zoomed out. Identify a beginning and an end and the big moments in between, but don’t get lost in the details or “what abouts”.
   

3. Explore details and options. Once you’ve plotted out the high-level stops on the journey, start sketching the things going on in the user interface at each point and ask some questions:

   1. What’s good enough?

   2. What would be a better way to do this?

   3. What would happen if things went wrong, and what could the product do to help the users if something went wrong?

Here’s how Jeff’s and my story map looked in our workshop.

In the workshop, we used the example of a company that provided an online, team collaboration, whiteboard-type workspace (something like Miro or Mural). The product team of this fake company in our workshop had decided to create what we called a “team start board,” a digital space where every team member started their day. In the story map you see above, we have the beginning: Team coach Christine sets up the team board. And we have the end: Team member Mark does some productive things in the board. The green boxes tell the high-level story—the key points along the customer’s journey; and the yellow boxes fill in the details.

But the solution map isn’t at all set in stone. Rather, it’s supposed to be a map full of possibilities and ideas.

6. Plot your solution release strategy.

From there, you cut up all those possibilities to find what we call the smallest successful release. Analogous to the “lowest common denominator,” the idea behind the smallest successful release is to find what would be the least amount of software you could build that would still provide a successful, valuable release for your customers.

Why is this important to do? Because you want your business and users to see a benefit as soon as possible. You can build big things to provide big benefits, but big things take lots of time and money. If you can build something smaller and faster and still achieve the same (or nearly the same) benefit, everyone wins.

Plotting your solution release strategy is where story mapping really shines.

How it works: Break down your big solution into a series of small releases that each result in a positive outcome and impact for your customers and the business.

Here’s the release strategy from our workshop, based on the team start board solution:

When plotted onto the story map, here’s what the solution breakdown looked like:

While the specifics might be hard to read, you can see that the larger solution story map is now divided into release blocks. The top bar of actions is blocked into the Early Adopter Release, which would happen first. The middle bar of actions is blocked into the General Release for Tech Teams, which would happen second. And the bottom bar would be blocked into the third release to Support Other Team Types.

The point of breaking it down is, again, to maximize value and minimize risk. Figuring out your release strategy in advance will help ensure you deliver the highest value and lowest risk at every point in the process.

Keep in mind, your OKRs should still be front and center. Every release you plan should help make progress on your product-level OKRs.

How can you ensure you’re on the right track?

• Focus each release on specific target users and specific target outcomes.

• Identify specific metrics that will tell you if your users have used what you’ve built.

• Thin each item in the release. What’s the least amount of work you can do to achieve your target outcome? What can be deferred to a future release?

• Minimize the risk of your release not by nixing features from the plan but by focusing on fewer people and fewer outcomes.

Essentially, keep your work specific and narrow in scope until you release enough to learn whether or not your hypothesis was correct.

***

If you found this overview useful, join us for the full workshop and Q&A and bring your colleagues. We’d love to have you.