Granted, its a basic question. But it's not trivial.
A Product Roadmap is the most common, and yet one of the most vaguely defined aspects of Product Management. From a "high level visual" to "list of tasks", you can find literally everything being called a roadmap.
As an example, look at the following definitions from the top search results on Google when searched for "Product Roadmap".
Different Definitions of Product Roadmap
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 ..
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.
So How Do I Make My Roadmap?
Making your roadmap depends upon your requirement. Let us assume that you need a real Planning roadmap - something that you and your team will use to develop your product.
You already have a list of ideas. What you need is this:
- Write down Value Drivers that are relevant to your customers. Eg saving money
- Write down the cost drivers.
- Rate the feature on the value and cost drivers. Pick the top ones.
- Keep all relevant information connected to the chosen stories. These include specs, designs, customer feedback, market research - essentially anything that helps figure out why this should be built and how.
- Add the stories to a release plan. And you are done.