What is a Product Road Map?
The product Road Map showcases what you are doing, in what order, and in most case by when you plan to do it.
It is meant for certain use-cases and audiences, largely those who are not a key part of the decision-making process, but who are affected by it and by leadership, who don’t have the time to dive deep into the how and why of products and features.
It is quite literally a navigation map for others to see, a mechanism to get maximum relevant information that a single glance can get. It showcases what just happened, what is happening now and what will happen in the future while hiding all the other complexities.
Should the Product RoadMap have release dates?
Ideally, a product roadmap should not have due dates, but when you are working with stakeholders they will ask you for some sort of timelines. Personally, I stick to having quarterly or monthly dates to showcase to the leadership as it allows for some buffer.
When you are working with dates, it is best to have some sort of release plan where you work with the marketing team to release the product once it is tested.
What the Product Road Map lacks
What it does not showcase is * why the items are on the roadmap * what decided the order of the items - all the things the PM said a NO for and the reasoning
That does not mean that all the missing information needs to be on the roadmap. The Roadmap is a 30,000-foot view of what is happening, for the audience defined above. Before you build a product roadmap, make sure you have the following things in ready
1. Company Mission & Vision document
As a company, there are various products and features that can be built, but the real value comes from the right set of features and products while saying NO to everything else.
The company’s vision statement is what it expects to achieve in the long term, it is aspirational. The mission statement is all the things it will (and will not do) to achieve its vision. You don’t need a grand document, bullet points of the will do and won’t do, who is the customer, who is not.
For Odiocast, the Podcast service Abhishek Nandi & I built, we "wanted to simplify the creation of audio content and bring it to the masses."
Companies Mission & Vision changes in due time, Microsoft is no longer trying to put a computer on every desk, their mission statement now is "Empower every person and every organization on the planet to achieve more." But don't change it too often.
2. Product Strategy Document
This document lays out a high-level strategic vision of how it plans to achieve the company’s mission. Ideally, it should capture all known influencers of the company & its product. Markets & their movements, competition, and their strengths & weaknesses, internal strengths & weaknesses. Large changes in user behavior etc. Once you spend time researching, debating, and writing it all down, you would be more informed for building out your own strategy.
When building Odiocast we knew we had to be a mobile-first product if we needed to bring audio creation to the masses. We also had to figure out how to remove the hurdle of audio editing if we needed to keep creation simple. That encompassed our initial strategy.
To execute the strategy, we took a page from SnapChat, we noticed that rather than edit a selfie, most folks just retook selfies till they got the best shot, and then posted it. We extended it to audio, we allowed people to record 60 seconds of audio at a time, and then joined all the clips. If you made a mistake, you would just re-record the 60-seconds, thus you did not need editing.
This document will also help in structuring the product teams if there are multiple products that work together or just break down products on how they work. It is also useful for each of the individual team to have their own vision and strategy documents.
At Vserv we had divided the teams into developer-focused products (The AppWrapper and SDKs), The RTB products, and the Ad Exchange. Since the products had different goals, we wrote up individual documents for each of the teams. The products were independent in some ways but worked together in other ways. At YourStory I divided the products into individual functions which aligned with the larger company vision but they did not need individual documents. Since the team was lean, the owners were the same.
The Documents described above help in speeding up the Yes/No decision for building the products because they usually already have the why. They are especially useful for smaller teams which are growing at a rapid pace and more frequently hit the wall of “to build or not to build”.
3. User Feedback system
You need to have a mechanism to collect user feedback and weigh them. It can be an excel sheet, tools like Receptive or Canny.io or others will do
4. Historic decision log
It is always important to track why you picked something up or reject it with all the information so that you can use it for reference for the future
5. A prioritization mechanism
Scores
- ICE
— ICE standards for Impact, Confidence & ease of development
— ICEM (M for maintenance) — For lean teams, you want to avoid features that need a lot of maintenance/updates from the development team. We used this in YourStory as the team was lean.
- RICE (R for Reach)
Matrix
- Risk-Value Matrix — Divide your items into high/low risk vs value matrix
- Effort-Impact Matrix — Divide your items into high/low effort vs value matrix
Scores by Product RoadMap tools
- Many tools have their own scoring tools, which you can use out of the box
There are more, but the idea is to keep it simple and not complicate it. Feel free to modify the mechanism to suit you need
Now you are ready
Once you have all this in place and you can answer why you are building Product or Feature X, instead of Product or Feature Y, start prioritizing it and then showcase the output as a Product Road Map. The Road Map is both an output of all your work, and an input for the rest of the teams in the organization.
