The Two Roadmaps
One word — two documents
A roadmap is a product manager’s best friend. We love them, master them and can’t get enough of them. And yet sometimes you look at someone else’s roadmap or a new, fancy template and think, “Wait, is this what a roadmap looks like..?” This happens because there is no single standard for roadmapping, but a whole range of different formats — each with its own advantages. It doesn’t really help to choose the best one, does it?
Let’s look at a roadmap from a slightly different angle — as it was just another product. And we know how to design products — we look for a problem to solve.
Tell me about your pain
Let’s consider the toughest case of a problem statement: you need a roadmap because someone asked for it. Not to worry, we get feature requests in this format every other day. We don’t accept them right away, nor do we turn them down — we offer qualified help which starts with a question: “Tell me what you need it for”. Let’s ponder on the possible answers.
Before managers in general and product managers in particular appropriated the word “roadmap”, it used to carry a simple and practical meaning. Merriam-Websters defines a roadmap as
1: a map showing roads especially for automobile travel
2a: a detailed plan to guide progress toward a goal
b: a detailed explanation
Every definition clearly translates into a value. A roadmap should show:
- Where you are now.
- Where you are going next.
- All the turns and shortcuts that help you get there.
Well, that was rather obvious. Or was it? Here is a much newer and more specific definition by ProductPlan:
A roadmap is a strategic plan that defines a goal or desired outcome and includes the major steps or milestones needed to reach it.
It also serves as a communication tool, a high-level document that helps articulate strategic thinking — the why — behind both the goal and the plan for getting there.
Our itinerary-builder has turned into
- A strategic plan defining the goal and articulating “the why” behind it.
- A communication tool for strategic alignment and reporting.
Let’s imagine we are talking about roads. The Merriam-Webster definition would describe how you plan a roadtrip drawing your route on a map and circling places of interest and hotels. Remember those days when we did that by hand and not by means of computer graphics? No? Bummer. Anyway, I clearly remember drawing my path on the map of Rome with an eye pencil when I visited the Eternal City for the first time.
The second definition suggests a completely different scenario. Imagine you are outlining a grand travel plan listing countries, cities, architectural masterpieces, nature reserves and other highlights of the programme in chronological order. Would you do this if you were planning your own trip? Well, some people would, but most would assume that such a high-level list is easy to remember — and would focus on the details — such as tickets and schedules. However, for a travel agent, such a document would be instrumental in managing customer expectations, ensuring alignment and buy-in, and last but not least — demonstrating the value of the agent’s work.
All the debates around product roadmaps are based on the fact that the same word is used to describe two different documents targeting two different audiences — your stakeholders and yourself. It reflects the dual nature of a product manager’s job:
- Strategic planning and stakeholder management.
- Execution and delivery.
Create two different roadmaps: one external and one internal.
Don’t try to save some time by creating one document and tweaking it for the occasion. At best, you’ll have a document that serves one purpose well and doesn’t help with the other. At worst, you’ll miss both targets.
A roadmap that helps you sell
This is an external roadmap, and as the name suggests, you can show it to anyone and everyone — within your non-disclosure agreement. Don’t forget to present it to your team — everyone likes to work towards a big and shiny goal.
However, you are not building it for everyone. You are serving the pains and interests of very specific groups of people. Let’s list them and the questions they might have for you.
1.Executive management
- Do you know what it is that you and your team are doing? Are things under control? Do you have a plan?
- Do you know how to monetise it?
- Does it make sense? Is it realistic?
- Is it aligned with the company’s mission and overall strategy?
2.Key customers and partners
- What am I going to get for my money now and in the future?
- What should I keep in mind comparing you to your competitors?
- When can I expect the capability I need?
- How should I adjust my own strategy?
3.Marketing
- What are the milestones and key messages for my marketing and communication strategy?
- Do I have any valuable knowledge that will help to validate and polish the product strategy? If not, how can I get it?
4.Investors
- Am I getting a return on my investments? When, approximately?
- Does it look profitable in the long term?
- Should I increase or cut the investments?
Principles of external roadmapping
These pain points help us flesh out the principles of external roadmapping — see the table below. We’ll leave the “Internal Roadmap” column empty for now.
Your stakeholders tend to (and definitely should) see the features from the perspective of customer value. In the external roadmap, make sure to emphasise the value over the functionality that enables it.
Remember that every milestone that appears on the external roadmap turns into a commitment. So be defensive and generous in your estimations or consider dropping the timeline altogether.
The purpose of this document is to obtain approval for the final goal of the product strategy — a shippable value. It is important to convince the stakeholders that you are building a good product and identify any misalignments and misunderstandings. That’s why it’s vital to guide the stakeholders through your thinking process and show them why this product idea is so brilliant.
Once the direction is set, getting from point A to B is largely a responsibility of the team — the tactical plan doesn’t require approval. So there is no need to distract your audience with complicated implementation details.
Use major milestones to reassure the stakeholders that they don’t have to wait the whole time and there will be a way for them to track the progress in-between.
The stakeholders judge the strategy and the results. Everything that happens in-between is your personal magic.
Solution
If you’ve done a good job defining your problems, the solutions will design themselves. We are looking for a way to emphasise the value and resist the temptation to go into the details of your execution masterplan. Visual aesthetics also goes a long way towards making a good impression.
#1 Choose a design tool
Make your roadmap look slick and beautiful. Pay attention to the fonts, the colour and the general design. Gladly, there is an abundance of tools that can solve this for you unless you want to flex your design muscles.
#2 Go easy on templates
Choose free to design tools over rigid templates. Regardless of the type and goal of the roadmap, your content remains unique, primary and guiding. Don’t fall into the trap of building your roadmap to match a template.
#3 Tell the story
To focus on the story and not the deliverables, some roadmap approaches suggest replacing the actual timeline with fuzzy terms “current”, “near term” and “future”. Alternatively, you can drop the timeline altogether and use horizontal axis to display an ordered list of large customer value slices. See an example of a theme-based roadmap below.
In some companies, however, this approach might be interpreted as avoiding commitment. You can only know what format works best for you if you know your audience and anticipate their concerns and worries.
If you choose the date-based format, use large time intervals, like quarters. Here is an example of a date-based external roadmap built using Miro.
A roadmap that helps you build
Take a deep breath. You’ve done a fabulous job aligning with your stakeholders and secured the coveted buy-in. It’s Delivery time! We call on stage our main implementation facilitator — The Internal Roadmap.
If it is not clear why we need another roadmap, let’s repeat our exercise and outline the audiences and their key questions. And let’s start with the main stakeholder — you.
That’s right, the main stakeholder for the internal roadmap, just as for the delivery in general is you — the product manager. The teams execute PM’s tasks and submit them to the PM for review and approval. This doesn’t mean that for the delivery time you can kick back and open a beer. PM is responsible for preparing user stories, acceptance criteria, sprint goals, epics and anything else that helps the team deliver value. The roadmap, however, is purposed to facilitate your own work.
Does it make the internal roadmap less important or challenging than the external one? Of course, not. Remember we said earlier that your performance is judged by results? That’s why you need a handy tool to help you hit those targets.
The internal roadmap is for you. Only you decide how it should look like.
OK, it’s not ONLY for you. Depending on how product management and technology departments are structured in your company, the internal roadmap can have other stakeholders. All of them are directly involved in managing product delivery.
1.Your direct management in product and technology
- How can I track the progress?
- When are my help and feedback needed?
- How to make sure that different teams are aligned?
2.Your peers — other PMs and engineering leads
- How do I align the efforts of my team with those of other teams?
- How do we surface dependencies and avoid blocks and bottle necks?
- How can we not do the same work twice?
3.And, of course, your questions.
- What is my next story about?
- How should I order the tickets?
- How do I choose goals for the sprints?
- How do I align with other teams?
- How do we surface dependencies and avoid blocks and bottlenecks?
- How do I easily adjust priorities and expectations based on dependencies and availability of resources?
- How do I track my own progress?
- When is the right time to validate the MVPs, collect feedback, analyse data and adjust both roadmaps?
Principles of internal roadmapping
Don’t let the visual similarity deceive you. These two documents might look like twins but each of them has a mind of its own.
Use value slices to group the features. They and the milestones serve to align external and internal roadmaps.
Keep in mind that it is the functionality that you need to release for the milestones. It’s wise to make it your delivery focus.
Take your average team velocity, a calendar with public holidays and paid vacations and a deck of tarot cards — and produce your very best and most honest time estimate. You need to be realistic in order to identify dependencies and overlaps between the teams, eliminate bottlenecks, avoid jamming and manage stakeholders’ expectations in a timely manner.
PMs and lead engineers usually have enough experience to take such estimations with a grain of salt and concentrate on the order of the tasks — as they should. Be sure to keep the internal roadmap out of sight of anyone who would take your predictions for commitments.
The internal roadmap is a visual actionable plan of “The How” — key features and implementation steps. Naturally, internal roadmap units are much more granular than those of the external roadmap. “The Why”, as interesting as it is, simply won’t fit the scale and should be communicated via other documents.
Solution
As said before, the internal roadmap is your tool and you know best what form it should take. I’ll merely share what works for me and what key features I find beneficial.
- Show where you are now
Clearly mark your position on the timeline so that you could see the work to be done on one side of the mark and your progress on the other. This helps you maintain a holistic view of the product behind the list of tasks. Comparing actual progress with initial planning helps to fine-tune your time estimates and improve predictions. Apart from all this, who doesn’t like progress bars?
- Outline your steps and manoeuvres
The internal roadmap is like a table of contents for sprints and user stories for months to come — it informs both the content of the tickets and their order. The optimal granularity of the roadmap units and their mapping to epics and stories can vary from team to team. What’s important is that one look at the roadmap should tell you what the next big thing is.
- Use the roadmap to pivot in an organised way
There is an opinion that a time-bound feature plan contradicts the agile methodology and limits the team’s manoeuvrability. That’s not true, Agile doesn’t have anything against planning. However, it does require regular reviews and adjustments of the plan based on the new data. The trick is to be able to change the plan that is already in action — without wasting the work already done. This can be achieved by delivering value in small incremental slices.
Nothing serves this goal better than the internal roadmap. It visualises the value slices, their building blocks and the resources required. You can easily add, remove, replace or re-prioritise the features while keeping the resources constant and simply reallocating them from one task to another. It helps you to see what you gain and what you lose in time and resources if you proceed with the changes — in full compliance with the agile principles.
- Avoid traffic jams
A good internal roadmap should surface interdependent blocks of functionality. Ideally, it should help you to discover the problem and figure out how to minimise the dependencies together with your team. If it cannot be done, you’ll be able to anticipate the bottlenecks and prioritise the tasks in order to avoid them.
- Include technical tasks and maintenance
The internal roadmap shouldn’t disregard so-called technical tasks if these require a considerable amount of resources and, therefore, affect overall capacity. It can also be used as a valuable exercise for the team to define the value of the technical tasks — in simple business terms.
Here is an example of the internal roadmap built using Google Spreadsheets. Each column represents a sprint providing the necessary granularity.
For the external roadmap, we suggested to use horizontal blocks for teams — and cells — the actual roadmap units — for value slices. You can use a similar approach for the internal roadmap and use cells for features. However, I prefer to swap the rows and the cells. In the example above, the features are grouped by value slices, and each feature occupies a separate row. You can read this roadmap in different ways: from top to bottom you see the ordered list of tasks; from left to right — the time and resources needed to deliver them.
And just the last few tips. Use row grouping to collapse the feature rows and keep the larger value slices — it allows you to “zoom out” and get a better overview. Colour-coding of resources is handy when you work with cross-functional teams.
Happy Roadmapping!
