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.
Weeknotes 476
I did:
Out of office
I’m pretty much always out of office because it’s the twenty-first century and I work for an organisation that’s smart enough to value remote and hybrid working, but this week I was also on leave. That means time for thinking about:
- What’s the difference between an internal product team and a platform team?
- What should be in an opportunity space mapping workshop? Or to put it another way, where does opportunity work end – is it with it mapped, on a roadmap for exploration, plus techniques for exploring, annnnd decision-making and reporting?
- How could impact mapping be made easier to work with so the logic of inputs to activities to outputs to outcomes to impact makes sense more quickly?
I read:
Responding to change
Interesting thoughts from Ian on teams being more intentional about the type of change they are using. Tacking is about knowing where you want to get to and course correcting along the way. Exploring is used to figure out your terrain and where you want to go. And following a plan for what and when to change on your way to a predetermined destination is the third approach.
Domain Driven Design
I read a few different things on domain driven design in preparation for some architectural discussions next week. Can’t say I’ve got my head around it yet but I can see how it will be helpful, mostly around how to organize large domains into a network of Bounded Contexts.
Techno-solutionism in education
Why does education keep falling for techno-solutionism, despite the fact that technology does not seem to drastically improve education? If you want my opinion, it’s the money. Big consultancies push technological solutions because they can be seen to have delivered something for their money, big tech companies push technological solutions because that’s how they make their money, leaders technological solutions because it gives them something tangible to ask for money for and stay relevant.
unFIXing Your Organization With LeSS
I can see how there could maybe be a case for organising in this way if there is a large number of teams all working on the same codebase and product. But in organisations that are smart enough to organise teams and products to be independent, the entire premise falls over.
I thought:
Think big, start small, learn fast
Six words to live by. A generally applicable approach to most situations of uncertainty where you have/want an ambitious goal and need to figure out the way forward by trying things. I don’t know if Chunka Mui came up with it or just got associated with/popularised it, but I’m grateful as it has been a guiding constant for many years.
Impact mapping metrics
I like impact mapping. It’s one of my favourite planning techniques but I don’t use it anywhere near enough. I was thinking about how you could add metrics to each of the five levels to understand how they relate to each other. Here’s a really rough example:
- Impact: Increase revenue by £3 million in one year.
- Outcomes: 50% of new users reach their aha moment in less than 2 hours = £1 million | Cohort of 1 to 5 days uses login more than 3 times = £0.5 million | Cohort of 6 to 15 days generate 1 report = £1.5 million.
- Outputs: Smoother onboarding process | Notification emails | Report templates and view-only access.
- Activities: Experiment and redesign changes for the onboarding process | Email trigger logic and new email content | Design templates, develop view-only sharing URLs, implement instrumentation.
- Inputs: £1 million team including designer, developers, product manager, tool licenses, etc.
If this was a diagram you’d see how each of the things on each level connect to other levels, but more importantly, you can see the team’s hypothesis for how they’re going to achieve impact in the outcomes, which helps them to focus on which outputs to deliver, which helps them decide which activities to do when. And, you can easily calculate the ROI of the team, and make adjustments such as investing more or less in the team, increasing or reducing time, etc.
University products
More rambling, connecting thoughts on defining products in universities (although it probably works in other types of orgs). It goes like this… products are the things the university provides, not the things provided to the university by IT or digital services teams (Couzens)… and we figure out what our products are by applying the business thinking of bundling and unbundling (Barksdale)… because universities are a big interconnected bundle of lots of things (it’s part of what makes them so difficult to disrupt from an innovation point of view (Christensen))… so if we were to unbundle it (we’re not, it’s just a conceptual exercise), we’d break off each business capability so that we can invest in it individually to create core competencies (Prahalad and Hamel) and we’d call them products… each would provide significant value to students, would enable the university to differentiate itself, and would have longevity that it means it can change and improve in ways that make it difficult to copy. Those products would include: Prepare to study (onboarding), Help & support, Library, Careers, Community, and many many more.
