Success state roadmaps
I’ve been thinking about how roadmaps align with product strategy. Often, the relationship relies on a lot of implicit knowledge to see how the two relate and so I wondered if there might be a way to make it clearer.
Before we get into that, first a few words on definitions and what we mean when we say “roadmap” and “strategy”. This is a few years old but I mostly still agree with it. A roadmap is not a delivery plan. It’s about goals, intention, and uncertainty, it doesn’t specify the work or when it will be delivered. And this is more recent thinking on product strategy. A strategy should express worthwhile problem to solves, hypotheses about how to solve them, and a way to know if the problem has been solved.
How strategy connects with different types of roadmap
The Now/Next/Later roadmaps fit nicely with the first part of the strategy; worthwhile problems. Janna Barstow, inventor of the Now/Next/Later roadmap, says it is focused on discovery and staying aware of customer needs and business opportunities. Product teams should use NNL when they need
Gannt chart-type roadmaps often show which feature is expected when, but because we’re product managers and not project managers we use them to express our hypotheses about how to solve the problem. We aren’t satisfied with merely getting features shipped, we know shipping features is how we run experiments and validate customer adoption. Product teams should use this type of roadmap when they need to communicate when they are making strategic bets.
But we don’t have a type of roadmap that expresses the third part of the strategy, how we’ll know if we’ve solved the problem. Or, using a different approach to strategy, Roger Martin’s ‘Where to play, how to win’, we don’t have a way to express what winning looks like and how we’ll know if we’re getting there.
Success state roadmaps
Success state roadmaps (I need a catchier name) attempt to express what we’ll see if we’re on the right track to success. The more specific each success state, the easier it is to know if the team is on track at each measurement point in time.
The roadmap reads left to right to imply a sequence – things on the right happen after things to the left – but it doesn’t explicitly mention dates.
Lets look at an example.
PKM
We’re working on a personal knowledge management product, and because it’s 2025 it has to use GenAI. Our (very simple for the purposes of this example) strategy looks like this:
- Our worthwhile problem to solve is that users have information in multiple systems and no way to join it together so they can improve their recall spot patterns in their thinking.
- Our hypothesis about how to solve the problem is that if they make all their information available to our AI, and add their own comments about that information, then we can analyse, organise and summarise information for them, and so make the information more available and useful.
- We’ll know the problem has been solved when 75% of our users give our product access to 3 sources of information (e.g., email, notes, podcasts), and use our product to add their thoughts about that information, and access summaries at least once a week.
How does that look on a success state roadmap?
We can add our final success state to the end of the roadmap and then work backwards to define states of success that tell us we’re on track to achieve our final success. Because our final solved state mentions three different user behaviours we can break our definition of success into three outcomes to make it easier to see where the value is.
| Outcome (user behaviour we’re trying to change) | State 1 | State 2 | State 3 | State 4 | State 5 | Final success state |
|---|---|---|---|---|---|---|
| Give access to source information | 20% of users give access to their podcasts when onboarding. | 30% of users give access to their podcasts when onboarding. | 40% of users give access to their podcasts when onboarding and notes app later. | 50% of users give access to their podcasts and notes app when onboarding. | 60% of users give access to podcasts and notes when onboarding and emails later. | 75% of users give access to 3 sources when onboarding. |
| Add thoughts | 10% of users add voice notes about podcasts they listened to. | 20% of users add voice notes about podcasts they listened to. | 30% of users add voice notes about podcasts or about information in their notes app. | 45% of users add voice notes about podcasts or about information in their notes app. | 60% of users add voice notes about podcasts, notes or email. | 75% of users add voice notes about podcasts, notes or email. |
| View summaries | 10% of users interacted with summaries of the podcasts each week. | 20% of users interacted with summaries of the podcasts and voice notes each week. | 30% of users interacted with summaries of either podcasts or notes, with or without their added thoughts each week. | 45% of users interacted with summaries of either podcasts or notes, with or without their added thoughts each week. | 60% of users interacted with summaries of any source or pattern analysis each week. | 75% of users have interacted with summaries, either for information sources or for pattern analysis across all sources, each week. |
How we define out success states shows things like we need to build trust with users so they’ll give us access to increasingly personal information sources, and implies the experiments the team could run, e.g., making onboarding quicker by only asking to access one source and then adding other sources later.
Breaking out success into three outcomes also helps us see where each reinforces the other. For example, we wouldn’t define the second step of ‘Add thoughts’ as having 40% of users adding voice notes because only 30% of users have given access to podcasts.
Where are we now and where do we want to get next
Having used our success state roadmap to define the steps to success, we also want to use it to show our current level of success and
Lets imagine it’s the end of quarter 1 and the product team is presenting their roadmap to senior leaders.
Green shows the success state we have reached. Getting users to give access to their information is going well, but getting them to view summaries of their information
Orange shows the success state we want to get in the next quarter. The team believes that the real value to users comes from viewing the AI generated summaries, so this is where they are going to focus most, but they’ll also try to increase the number of users adding voice notes.
| Outcome (user behaviour we’re trying to change) | State 1 | State 2 | State 3 | State 4 | State 5 | Final success state |
|---|---|---|---|---|---|---|
| Give access to source information | 20% of users give access to their podcasts when onboarding. | 30% of users give access to their podcasts when onboarding. | 40% of users give access to their podcasts when onboarding and notes app later. | 50% of users give access to their podcasts and notes app when onboarding. | 60% of users give access to podcasts and notes when onboarding and emails later. | 75% of users give access to 3 sources when onboarding. |
| Add thoughts | 10% of users add voice notes about podcasts they listened to. | 20% of users add voice notes about podcasts they listened to. | 30% of users add voice notes about podcasts or about information in their notes app. | 45% of users add voice notes about podcasts or about information in their notes app. | 60% of users add voice notes about podcasts, notes or email. | 75% of users add voice notes about podcasts, notes or email. |
| View summaries | 10% of users interacted with summaries of the podcasts each week. | 20% of users interacted with summaries of the podcasts and voice notes each week. | 30% of users interacted with summaries of either podcasts or notes, with or without their added thoughts each week. | 45% of users interacted with summaries of either podcasts or notes, with or without their added thoughts each week. | 60% of users interacted with summaries of any source or pattern analysis each week. | 75% of users have interacted with summaries, either for information sources or for pattern analysis across all sources, each week. |
By the end of quarter 2, the updated roadmap looks like this:
| Outcome (user behaviour we’re trying to change) | State 1 | State 2 | State 3 | State 4 | State 5 | Final success state |
|---|---|---|---|---|---|---|
| Give access to source information | 20% of users give access to their podcasts when onboarding. | 30% of users give access to their podcasts when onboarding. | 40% of users give access to their podcasts when onboarding and notes app later. | 50% of users give access to their podcasts and notes app when onboarding. | 60% of users give access to podcasts and notes when onboarding and emails later. | 75% of users give access to 3 sources when onboarding. |
| Add thoughts | 10% of users add voice notes about podcasts they listened to. | 20% of users add voice notes about podcasts they listened to. | 30% of users add voice notes about podcasts or about information in their notes app. | 45% of users add voice notes about podcasts or about information in their notes app. | 60% of users add voice notes about podcasts, notes or email. | 75% of users add voice notes about podcasts, notes or email. |
| View summaries | 10% of users interacted with summaries of the podcasts each week. | 20% of users interacted with summaries of the podcasts and voice notes each week. | 30% of users interacted with summaries of either podcasts or notes, with or without their added thoughts each week. | 45% of users interacted with summaries of either podcasts or notes, with or without their added thoughts each week. | 60% of users interacted with summaries of any source or pattern analysis each week. | 75% of users have interacted with summaries, either for information sources or for pattern analysis across all sources, each week. |
The team have succeeded in increasing the percentage of users viewing summaries but getting users to add voice notes is proving to be a much harder problem. They have to make a choice about whether to spend their time next quarter on that or to focus on doing more of the things that are succeeding, and using a success state roadmap shows where they are succeeding and helps them choose more rationally.
If they were following a feature-specific, time-bound delivery plan they wouldn’t know whether they are succeeding or not and would continue to ship features.
Summary
Success state roadmaps show us whether our strategy leading to a successful product.
By defining what we mean by success (part three of our strategy), and breaking down the states we expect to see (on the roadmap), we’ll have a clear connection between strategy and roadmap, and a clear view of which outcomes the team are most able to affect. We create a feedback mechanism from user behaviour to strategy which tells if our strategy is working or not.
Product teams can use their success state roadmap to communicate success and make agile, focusing choices about which success state to go after next.
Leaders can use success state roadmaps to review and adapt strategy and anticipate the final success state.