Need someone to lead product management at your software company? I build high-craft software and the teams that build it. I'm looking for my next opportunity. Check out my resume and get in touch.

This is the blog of Adam Kalsey. Unusual depth and complexity. Rich, full body with a hint of nutty earthiness.

Product Management

Roadmap Outcomes, not Features

Roadmaps should be outcomes, not features. What customer or business problem do you want to solve, and what does it look like when you’ve solved it? An outcome roadmap isn’t full of things you’ll do. It’s full of the things that happened because of the things you did.

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.

Board game illustration

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.

Recently Written

Lighten Your Process Burden
Dec 7: Everyone hates oppressive processes, but somehow we keep managing to create them.
Product Add-Ons Are An Expansion Myth
Dec 1: Add-ons can enhance your product’s appeal but won’t drive significant market growth. To expand your customer base, focus on developing standalone products.
Protecting your Product Soul when the Same Product meets New People.
Nov 23: Expand into new markets while preserving your product’s core value. Discover how to adapt and grow without losing your product’s soul.
Building the Next Big Thing: A Framework for Your Second Product
Nov 19: You need a first product sooner than you think. Here's a framework for helping you identify a winner.
A Framework for Scaling product teams
Oct 9: The people, processes, and systems that make up a product organization change radically as you go through the stages of a company. This framework will guide that scaling.
My Networked Webcam Setup
Sep 25: A writeup of my network-powered conference call camera setup.
Roadmap Outcomes, not Features
Sep 4: Drive success by roadmapping the outcomes you'll create instead of the features you'll deliver.
Different roadmaps for different folks
Sep 2: The key to effective roadmapping? Different views for different needs.

Older...

What I'm Reading