By Luke Gallimore, Head of Product Management, Monstarlab EMEA
The discipline of Product Management is built around two core tenets:
- Define a clear, value-based product strategy
- Create and manage a healthy roadmap
This article is focused on the second.
The roadmap and the product strategy are inseparable. In my previous article, I argued that product strategies should be value-based and that roadmaps are the goal-based descriptions of how you intend to deliver on the product strategy.
Good Values = Good Goals = Good Product
Product values need to translate all the way to the user. Therefore they should be at the heart of your roadmap too. But we’ll get to that later. First, I’ll start with the basics. What does a roadmap need to do and what is the most common roadmap mistake?
When is a roadmap, not a roadmap? When it’s a backlog.
In whatever form your roadmap exists, you should be using it to achieve a few key things:
- Communicate your progress towards achieving the product strategy
- Document the ideas which aim to bring the product strategy to life
- Align stakeholders on what’s currently being worked on in the discovery process
Despite these worthwhile aims many roadmaps somehow end up being the enemy of the product, the user and the business. This injustice usually occurs when roadmaps are confused with backlogs.
Backlogs are purely output-focussed. They are concrete, prioritised plans of what needs to be done. Your backlog includes detailed, actionable tasks assigned to the right people. These tasks have already been validated, therefore they are not subject to a great deal of change, though they may shuffle.
In contrast, the roadmap should be a melting pot of ideas. It should be a place where teams test and learn to identify worthwhile (and not-so-worthwhile) ideas. It needs to communicate the discovery process and how ideas evolve as they move through it.
Treating an idea on the roadmap like it’s in a backlog prevents a product team being able to learn, adapt and iterate. The idea is locked-in as soon as it arrives. Your team’s hands are tied, bound by a promise that stakeholders will get feature X in time for the end of year review. It also gives no protection over being able to say no to ideas which turn out, through investigation, not to be the right thing to build.
You wouldn’t commit to getting a puppy before you’d met. So why would you commit to a feature before you know if it’s worthwhile? Wasteful product decisions are for life, not just for Christmas.
So if a roadmap is not the backlog, what is it?
Strategy, roadmap, backlog… what’s the difference?
A product strategy is a description of the world you’re trying to create — why the product should exist. It is abstracted from tangible features or things. It is outcome-focussed. The roadmap sits
The roadmap sits between the product strategy and backlog. Its job is to translate outcome-focussed aims of the product strategy into the granular, output-focussed to-do list of the backlog. The roadmap should also convey technical learnings from delivery to the long-term-focussed product strategy. It’s a two-way street.
The product strategy constantly evolves alongside the competitive and commercial landscape. Meanwhile, backlog items shuffle during re-prioritisation and re-estimation following learnings in delivery. Product Managers, teams and stakeholders have to understand the roadmap as a living thing too. It’s in a constant state of flux.
This state of flux is known as the discovery process.
What is the discovery process?
Product discovery is the process of getting from a problem to a solution. Therefore, the team responsible for product discovery straddles the problem and solution spaces. They blur the line in the pursuit of defining validated high-level solutions. Once defined, the delivery team takes those solutions into the backlog, adding the necessary detail to build them.
The discovery team must represent the key disciplines for product development, hence there are three essential roles:
As a living thing, the roadmap is the description of ideas progressing and evolving through the discovery process. As a communication tool, the roadmap is a snapshot-in-time of this process.
Therefore, at any given time the roadmap should describe:
- Ideas which are currently being investigated and validated as part of the process
- High-level solutions which are validated and ready to be translated into the backlog
The entire discovery process takes part in the context of a value-based product strategy and there are four key steps to producing solution ideas:
- Problem framing — Understand the problem(s) we’re trying to solve including requirements of the solution
- Roadmap planning — Prioritise the problems, begin planning iterations for each based on expected value and complexity
- Ideation & prototyping — Work as a cross-discipline team to generate ideas quickly and bring to life with prototypes
- Solution testing — Validate solution ideas against the initial problem and the product strategy to determine if they are worthwhile
Once you have a set of rough solutions which you think might be workable, they must pass the validation criteria if they are to be passed on to the delivery team and polished up for the backlog:
- Perceived value — will our users think this is valuable; does it seem to solve the problem?
- Solution usability — if users think it is valuable, is the proposed solution usable?
- Technical feasibility — will we be able to build this with the resources and expertise we have?
- Commercial viability — will this solution, if used, provide the right kind of impact on the business?
Ideally, the team is mindful of these criteria throughout the whole process. This preempts issues and can catch wasteful ideas early. However, there must be a final check to ensure only worthwhile ideas make it into the product.
The roadmap needs to capture all of this detail. So how do you start building one?
How to set up a roadmap
Step 1: right structure = right mindset
Before you open the firehose of ideas onto the discovery process, it’s important to make sure your roadmap is structured correctly.
Communicating the discovery process is the primary task of the roadmap. It’s also the most difficult. The challenge lies in knowing how to bridge the cognitive gap between the abstract product strategy and the concrete backlog.
To bridge the gap your roadmap needs to represent:
- Abstract: product values, used to organise opportunities into themes
- Tangible: specific and tangible ideas, which once validated, become product goals
Healthy roadmaps must use product values as their core. Thematic roadmaps are incredibly powerful for communication because they are digestible to all levels of stakeholders. Using product values as ready-made themes provide rules and KPIs to help guide the ideation and validation process. Most importantly, it ties your roadmap to the product strategy and therefore roots backlog items, ultimately your live product in the product strategy.
Good values = good goals = good product
A popular alternative approach to using product values is to use feature-categories as the themes for the roadmap. But this approach is unhealthy. It is leading as it assumes a part of the solution before you have even started to investigate it. Usually, these kinds of themes are based around existing functionality. It may not necessarily be the case that something you’ve already done is a good foundation for achieving the product vision.
Step 2: Are the ideas worthwhile?
A ‘problem’ describes a gap between the world we live in now and the world we want to live in. Opportunities identify goals that — if we can reach — solve the problem.
Items on the roadmap need to get us to the way we want the world to be (the product vision). Therefore, they should be phrased in terms of problems and opportunities. Fundamentally it’s a gap analysis exercise.
However, the way that the problems are framed is critical. Here’s an example of a problem articulated in two very different ways which can result in vastly different solutions.
- Problem A: There isn’t a bridge over the river for me to get to the other side
- Problem B: I can’t cross the river to get to the other side
What’s the difference? With problem A, I’ve already told you what the solution is — build a bridge. So I would outline the goal like this:
- Goal A: How might we build a bridge?
However, in problem B I have articulated my problem far more purely. So I can outline the goal very differently:
- Goal B: How might we get to the other side of the river?
Why is this important? Well, if you have a team of crackpot engineers and designers at the ready, then you want them to innovate to find the best solution themselves. They’re the experts.
Apply this to your roadmap items. You must frame them in terms of problems and you must frame them in their purest form. This empowers the discovery team to outline their goals less rigidly and find the best solution possible. ‘The best solution’ will depend on the product strategy, the capabilities in the team, the interdependencies and constraints around the team and the resources and time you have available.
Maybe the best way to get to the other side of the river is to use the hot air balloon that’s sitting in the hangar gathering dust. It’s already paid for, I’m qualified to fly and it’s a one-way trip. A bridge is a lot of wastage.
Problems should be phrased from the point of view of at least one of the three core product development disciplines. They often overlap with two:
- User: something of value is not present or ineffective, or there is a gap in usability expectations
- Business: there are commercial factors which are being under-supported or not addressed
- Technology: we are in (or soon will be in) a situation which is leading to detrimental technical performance
To illustrate, here’s a user problem:
“As a user, I want to be able to understand my performance over time so that I can make adjustments to my behaviour but I do not currently have visibility to make decisions”
This becomes a roadmap item, phrased as an opportunity:
“How might we increase performance visibility?”
This gives us a concrete goal when ideating and testing potential solutions to the problem.
Sidenote: sources of ideas are important too
The second main consideration for assessing if an idea is worthwhile or not is where it came from. Different sources of ideas should carry different weight, this should be tailored to individual teams and products, but here’s an example of how you might prioritise three common sources of ideas:
- Rigorous user research and testing
- Product team ‘desk’ research
- Stakeholder feedback
There are lots more sources than this, clearly. However, as guiding principles, the most important factors to consider are:
- How much relevant information was inputted to the source to create the idea?
- What is the frequency of this idea being raised and by how many sources?
- What is the track record of the source(s)?
Step 3: Plan you roadmap
So, you have clearly articulated goals organised into your product values. That’s a lot of the legwork done. You know that each goal will contribute to the overall product vision and there are KPIs ready to use as an objective reference point when measuring success.
But you still don’t know which ideas to tackle first — it’s still one big pot of goals. How do you choose? There are two main factors to consider in prioritising goals and planning your roadmap:
- Expected value — a combined measure of expected user value and expected business value. Both are defined in the product strategy.
- Complexity — led with a technical lens however there should be user and commercial considerations too.
First, goals need to be mapped, relative to one another, on an expected user value scale. The Product Designer would lead this with support from the Product Manager and Solution Architect. This gives you your first hierarchy of the roadmap goals.
Next, you add another axis — for expected business value. Again, this is relative prioritisation but this time is led by the Product Manager.
This now gives you a picture of how valuable the goals are expected to be, for two of the three key disciplines. You can now rank the goals by overall value.
The final stage of ranking is to contrast the value with feasibility. This stage should be led by your Solution Architect. It’s like a soft estimation session, though here we are dealing with relative complexity rather than absolute effort required.
With this complete, you now have all of your roadmap goals mapped out with clear relative positions in terms of how valuable they are and how technically feasible they are. From this point you can create categories corresponding to the quadrants from which to direct your effort and attention:
- P1: High value, high feasibility = quick win items, short-term and cheap
- P2: High value, low feasibility = transformational items, long-term and expensive
- P3: Mid value, mid feasibility = incremental evolutions, medium-term and less expensive
- P4: Low value, low feasibility = nice to have, long term and expensive
You can obviously get more granular with this. But these four rough-and-ready categories will suit most purposes. This prioritisation grid is a living document and as you add ideas to the roadmap, you can place them on the grid next to known items to give a relative indication of value and complexity.
Now you have roadmap goals organised by-product values. The abstract outcome-focussed aims of the product strategy are present in your roadmap. You also have these goals prioritised within those values in terms of expected value and complexity. This gives you the ability to translate them into a concrete output-focussed backlog.
The roadmap is set up. Now you just need to solve the problems 👍
Next steps: Ideate, prototype and test solution
These steps are BYOT — bring your own tools. There are myriad different ways to ideate, prototype and test. These should be carefully chosen based on the team, product and resources available. Therefore it would be impossible to outline them usefully here. However, there are some general principles to help guide the right tools to use and get the most out of them:
- Ideation: make sure that all of the relevant disciplines are present and that the problems are framed correctly before you start
- Prototype: represent the essence of the idea minimally, without unnecessary frills to get to the root of the proposed solution
- Test: where possible, use realistic tests so that you can reduce risk and unknowns in your assessment
As you are documenting the proposed solution, you need to capture three things as a minimum:
- Requirements: at least at the epic level, ideally user story level with firm acceptance criteria
- UX: visuals of how this solution will manifest and how it will fit into any existing flows. Ideally, some UI is done too
- Technical specification: the endpoints, integrations and components necessary to make this happen, in context to the existing architecture.
This is the information which is passed onto the delivery team to polish into backlog items by adding the final details. If an idea has got this far, it’s doing pretty well.
All it has to do now is to pass the validation criteria and it’s ready for the backlog.
The tools you use to document your roadmap have to work for you and your team. You can use a ready-made tool or you can build your own. It doesn’t matter. What does matter is that you do the due diligence in setting up the roadmap in the right way, with special attention to the foundational principles. This will make your product awesome.
- Product strategies should be value-based. Roadmaps are the goal-based descriptions of how you intend to deliver on the product strategy
- Many roadmaps actually end up being the enemy of the product and of the product strategy because they are confused with backlogs
- Roadmaps are always in flux and are a two-way street. They need to sit between the product strategy and the delivery backlog
- Product discovery is the process of getting from a problem to a solution. The roadmap is a document describing the progress of ideas through this process
- Framing your problems well is really important. If you don’t do it right, you will inhibit creativity and you won’t find the right solution
- Using product values as the structure for roadmap ideas provides readymade KPIs and rules as well as linking the outcome-focused product strategy to the output-focussed backlog