What is a Product Roadmap

A Product Roadmap is the most common, and yet one of the most vaguely defined aspects of Product Management. In theory, a Product Roadmap simply outlines or 'maps', a list of features to a timeline. But in practice, there are many purposes to it, depending upon the stage of your product - from planning, to team alignment, to stakeholder communication. This is an in-depth study of what constitutes a Product Roadmap, how many kinds are there (hint: many), and which one should you pick.
Different Definitions of Product Roadmap
If you searched 'Product Roadmap' on Google, you'd get 10-15 different definitions of Product Roadmap. Here are some of the top ones:
Atlassian : Atlassian: A Product Roadmap is a shared source of truth that outlines the vision, direction, priorities, and progress of a product over time
Roadmunk : We’ve come to rely on a new product roadmap definition: It's a statement of intent. It’s a visualization of where you’re going ..
Aha.io : Your product roadmap lays out the big efforts required to meet your overall business objectives and the timeline ..
Whenever there is a variance on the definition of something, a good method is to segment the market and see if patterns emerge. By the way, this is also one of the most common problems faced by Product Managers - "A feature seems critical to some, and useless to others". In this case, do not average out the value. Instead segment the market.
As we will show you below, for small product teams a Product Roadmap in a PLANNING tool. On the other hand teams in large mature companies (stakeholde).
Why Should I care?
If you are in the business of writing software, you WILL need to create a roadmap. Whether you are a product company, or a Software development agency, it does not matter. You WILL need a roadmap. And if you search online, and pick the wrong thing without, it will lead you astray. In the best case scenario, you might be asked to reduce the detailing in the roadmap. In the more likely scenario, there will be complete chaos when the development starts. Poorly created roadmaps lead to the following results:
Missing software release deadlines:
It is so freakishly common, it's tragic. Most of the time, the reason is nothing but a badly created roadmap.
Building the wrong product
The top reason of startup failure is building something no one wants. A poorly crafted roadmap has poorly crafted features under it with information gaps which fail to point in the right direction.
Now that we have established that if you are in tech, you should care about Roadmaps, and that you should know what you need, when you think "roadmap".
Purposes of Product Roadmap
We segmented the market that uses the term Product Roadmap, and 3 different kinds of problems evolved. People use Product Roadmaps for 3 related, but pretty different things.
PLANNING - Planning feature releases : This is the simplest use case - you create a roadmap to only to organise your development plan. Here the creators of the roadmap are the same as the consumers of it. Typically these tend to be small product teams, startups and Apple (during Jobs), where the top executive team is directly involved with execution.
ALIGNMENT - Aligning different teams on a version of the future : In this case, a Roadmap is used to ensure that Engineering, Support, Sales, Marketing etc are all in sync about a version of the future. Here the product roadmap is about internal communication. Everyone who consumes the roadmap executes something related to it. Sales and Support promise features which are in the roadmap, Marketing plans promotion according to the roadmap and so on.
COMMUNICATION - Communicating to external stakeholders: : In this scenario, a Roadmap is used to communicate product vision and direction to people who just want to stay in the loop. These tend to be customers, top executive team in a large company, investors, the board etc. Here the roadmap is mainly a communication tool.
Depending upon your product stage, the purpose of a Roadmap changes. Therefore, so does the definition and it's attributes. They are all called Product Roadmaps, but they are different things. You may say that your team needs 2 or all 3 kinds at different times, and you'd be right. The point here is to mainly understand that the 3 are different things.
Attributes of a Product Roadmap
The building block of product roadmaps are Features mapped to time. Depending upon what is the purpose of the roadmap, the following attributes get defined. Think about your own use case - what do you need the roadmap for, and decide what should be your choices from the following attributes.
A. Focus - which business objectives are being met
Talked about the least, and probably the most important aspect of a Product Roadmap is Focus.
Focus basically defines which business objectives are being met in the Roadmap, and to what extent. A lot of times, the PM or the founders do not know the answer to this question. Consequently, the roadmaps, unknown to them, could be heavily biased, and even when executed very well, will lead the company nowhere. For example, imagine if all items in the quarterly roadmap are "Experiments". 3 months of experiments, and NEVER doubling down on things that work. This is an extreme, but not very uncommon, example. In that quarter, the company will get a few small wins, but nothing will move the metrics, because nothing was done completely, beyond an experimentation phase.
B. Zoom - How Detailed is the Roadmap
Product Roadmaps which are meant for external consumption give a 10000 foot view. The external stakeholder typically just want to know if the business objectives are being met in a roadmap.
On the other hand, Product Roadmaps which are execution plans tend to be very deep. You should include every little detail, every ticket that has to be fixed, in this roadmap. A great place to execute this roadmap is Project Management (JIRA or Trello).
We have learnt lately that many teams prefer to plan and execute in the same place. Many of LightCat customers like to execute inside LightCat itself, by marking cards as "In Progress" or "Done".
C. Flexibility - how much can it change
This really depends upon the company stage and culture. Typically, pre-Product Market Fit companies tend to build faster, and NEED to be flexible. Every week you uncover insights that will impact what you're building. So the roadmaps tend to be very agile. Larger companies have more stiff roadmaps. The reason typically is that roadmaps are communicated to other teams, and through them, to the external world. Moving away from the promises that have already been made makes roadmap stiffer. If done at the right stage, and for the right reasons, it's a good thing.
Build a Customer Centric Roadmap?
The method outlined below is a proven framework used by some of the top teams across the world. The greatest but of this method is that it starts by forcing you to outline what your customers want in simple terms. This automatically puts the Customer at the center of your roadmap
Value Drivers : This is a list of things that deliver value to your customers (eg saving time, shipping fast) Write them down. We will use these value drivers to score the user stories.
Cost Drivers : These are the items that drive cost for you. Typically, cost is in terms of the hours spent in building and shipping a feature. A lot of times, this will also inclide time to research, design, talk to customers etc. Greater the cost, lesser is the priority score of a User Story or Fearture.
Prioritization : Rate the features on the value drivers (VScore) and cost drivers (CScore). Then create a total score by subtracting the costs from the value. Now sort the features from the highest score (greatest net value) to the smallest.
Knowledge Graph : This is a super important step for future execution. You must keep all relevant information connected to the User Stories. If everything is tied together, it is less chaotic to manage the entire process. These include specs, designs, customer feedback, market research - essentially anything that helps figure out why and how this should be built.
Roadmap Ready : Add the stories to a release plan. And you are done. You have created a super Customer Centric roadmap, well prioritised on the basis of what customers need, and what you can deliver fast.
This is an important juncture to recognise that the work has just started. If you are an experienced PM, you already know that nothing will go according to the plan. Some developers might go on a leave, Sales might want to move something up the list, top management might change their mind about something. In all likelyhood, all of these will happen around the same time, in the same Relase Plan.
When Everything Screws Up
As we just mentioned, in all likelyhood, everything will go wrong at the same time. As a Product Manager, you are the one holding all the threads, and joining them manually. So you will be expected to solve it, and get the product out of this situation.
Fortunately, you are smart. You already knew this is going to happen. And you have planned for each of these casualties. Do note, that it won't be as hunky dory as we are making it sound right now. You may tear some of your hair (or that of your Engineering Lead's, but let's not get there yet.)
Here are some of the things that DO go wrong, and how to plan for them.
Not enough (wo)manpower - people are on leave, or they underestimated the complexity : This is the most common reason for release delays. When developers start implementing, THAT is when they will know the full impact of what they're dealing with. To avoid delayes, a simple thing is to keep a buffer. Better still, keep multiple deadlines. The one committed to the external world is deadline 3. And the team (knowingly), aims at deadline 1.
Priorities Have Shifted. : This is another fairly common situation - more so for startups than established companies. The reason is simple - team now has new information, or something has changed in the external environment. There is no way to predict this - but there is a way to preempt this. While getting stakeholder buy ins, try to keep customers at the center of the conversation. A lot of times, the clearer we are on "why", the more likely we are to stick to the plan. However, it won't always work.
In Conclusion
Creating a Product Roadmap is the most rewarding activity of a product company. It is the roadmap that ties everything together - teams, external communication, tasks, hopes and dreams - the list goes on.
This is exactly why it is super critical, taxing, and tiring part of building a product. Writing a Product Roadmap is first and foremost a planning skill. And like every other planning skill, you need to be aware of the pitfalls, the risks, the benefits and the costs involved.
If you have come till here. we congratulate you. This was a rather long in-depth guide. We hope you go out there, make an amazing roadmap, and if you need to, come back for reference.