Roadmap Outcomes, not Features

I’ve long been a fan of problem roadmaps instead of feature roadmaps. In a problem roadmap, you don’t list features and ship dates. It gives you a lot more flexibility in how to solve a problem. It doesn’t tie you to specific things you’ll ship on specific dates so that you can respond better to changing conditions. Customers like this format because they can better understand where you’re going. It’s easier to understand whether a problem applies to them than to recognize if a simple feature description does.

As I’ve gotten more into outcome-based thinking, I’ve realized there’s a shortcoming with problem roadmaps. They don’t tell you why you’re doing something. They don’t provide any guidance toward knowing if you’ve solved the problem. And worse, they discourage iteration. Roadmapping a problem can lead to binary thinking. You’ve either solved the problem and delivered the roadmap item or you haven’t.

An outcome roadmap shows you what you’re building towards and gives a scorecard you can use to see how close you’ve come toward the goal. You can then make decisions about if you’re close enough for now. Take a user activation goal for example. Maybe you didn’t create the activation outcome you were looking for, but you’ve gotten closer to it than you’ve been in the past. You could stop working on this outcome for now and move on to something else.

You can be explicit about this iterative approach in your roadmap. You could put "boost activation to 15% of all registered users" and "boost activation to 30%" as two different roadmap items.

What does an outcome roadmap look like? I like each outcome to have the problem we think we need to solve to create that outcome. And I like to include some example bets we’ll try to solve that problem. These example bets can help people better understand the problem by illustrating some possible solutions. Here’s an example of a roadmap item.

Increase European customer accounts to 8% of our total customers. Make it easier for people outside the US to buy and use our product.

• Datacenter in Europe for speed and data protection
• Offer payments in Euros and Pounds
• Translate product into German and French

This has the outcome you’re creating (a specific percentage of customers come from Europe), the problem that’s keeping you from getting there, and some examples of how you might solve that problem.

I initially started putting the outcome under the problem. I’d list the problem we’re going to solve, then show the outcome that we’d create by solving it. However, I found that didn’t create the iterative benefits I was hoping to create. It didn’t create outcome-based thinking. Teams saw the outcome as simply a way to measure the solution to the problem. But in fact, the outcome is the thing we’re trying to create. We’re only solving the problem so that we can create the outcome.

It’s important to remember that not everyone needs the same level of detail in your roadmaps. Depending on the audience, you might choose to present only the problems to customers, while keeping business outcomes for internal teams. Flexibility is key in determining what to include and for whom.

This style of outcome roadmap can be applied across various formats, whether in a date-driven Gantt chart or a Now/Next/Later structure.