At least once a week a new product is launched somewhere in the world. This trend is mainly due to the following factors: 1) there are more startups taking risks with innovative ideas and testing their MVPs, and 2) organizations are looking for new strategies to improve customer retention and increase profit margins.
Is building a product (physical or digital) easy? That question is relative, and depends on the product roadmap definition. Below, I share the steps for building a product roadmap as well as tools, examples and suggestions that have been useful to me throughout my experience working in product roles.
The product roadmap is a planning artifact that represents the development cycle of a product. Also known as a "roadmap," it visually lays out the product's objectives and the steps for achieving them.
The main role of a product roadmap is to communicate the product strategy. It can present the product’s vision and objectives and show how they support the company's overall strategy.
A product roadmap helps all parties involved in the product’s development maintain alignment, since it makes it easier to visualize what stage the product is in, where it is going and how you will get there. It is a great tool for discussing the different aspects of development as a team.
Product roadmaps are useful for planning delivery deadlines and anticipating surprises you may encounter along the way. However, it doesn’t contain only static actions and deadlines. It is a “living” document. That means the product roadmap must be flexible and adaptable.
In these times of remote work, visualizing the strategy and steps to follow can be a great work ally. But who needs to develop a product roadmap? Find out below.
Creating a product roadmap is a strategic process that starts long before you draw up your roadmap. A product roadmap will only be as good as the information it is based on, so gathering insights, market research and feedback is a must before you even open an application.
How do I start building a roadmap? These steps will guide you in your objective:
The actions and deadlines you map out in the roadmap will be meaningless if you don't know the reason behind it all. Get your entire product development team together and discuss the following questions:
Don’t offer your product to everyone. Define the market segment you are targeting and the profile of your potential consumers.
Ask yourself:
On the one hand, the product's goals should be aligned with the company's business and development goals. How can the product help achieve those goals?
On the other hand, the goals you set for your product roadmap will vary depending on whether it is a new product or an update of an existing product. In the case of a new product, start by defining the Minimum Viable Product (MVP).
The objectives you set should be SMART (Specific, Measurable, Achievable, Realistic, Timely). To do this, identify which metrics will allow you to analyze the product's development, progress, successes and possible drawbacks.
To develop your product roadmap you must identify and analyze all the features and functionalities the product can offer. Consider its attributes and prioritize those that are indispensable for satisfying the customer's needs.
Knowing which features are important will be useful when diagramming your roadmap and development times. The essential features should be ready first, while non-priority features can be refined along the way.
Once you have established your product’s goal and identified and prioritized its features, you can start mapping user stories.
It can be difficult to decide where to start and what to focus on. Mapping the user connects you to the consumer, and all stakeholders should be involved in creating the product stack (it’s much better than writing a 100+ page requirements document).
Mapping starts from the most general aspects and moves towards the most particular aspects of these requirements, and the information is displayed as a tree. It is led by either a product manager or a product owner with all stakeholders, designers, developers, and those responsible for allocating the budget for a product.
The next step is to determine the timeline and break the tasks down into small, achievable steps. Assembling the final roadmap into a single document integrates all the epics into a defined timeline.
Below is an example of a product roadmap placed on a timeline which includes other areas related to the product:
There's a good chance that your product roadmap will be imperfect, and that's okay. Your team will face unexpected challenges, and you will need to encourage them to meet deadlines. It's all part of the job. You can still safeguard your roadmap by reviewing it whenever there is a problem. Check your roadmap and ask yourself: Did we anticipate this? What are the short- and long-term solutions? What resources will I need to solve this problem?
Your roadmap may not be perfect, but you can tweak it to make sure your product comes out exactly as you envisioned. To create an agile roadmap, you have to leave room to adapt to any unexpected changes that come your way.
Previously, Excel and PowerPoint were the most common tools for templating and building a product roadmap. With them it was easy to create and communicate plans. They saved a lot of time and made an excellent starting point. They offered a wide range of templates which you could tailor for a specific roadmap.
Now there are many other tools available to create these roadmaps, including ProdPad, Trello, Roadmunk, Asana, ProductPlan, Aha, and Venngage. Feel free to try any of these tools or another tool you find on the internet.
Below, I will briefly explain three types of product roadmaps and share my experience with them. Each roadmap is designed for particular teams, and there can be more than one roadmap type adopted by a single team.
The timeline roadmap is the most common product roadmap used by product design teams. It is usually for internal use and is not shown to anyone outside the team.
It serves to inform the members of the product design team of which phase they are in, which phases are pending, and which tasks must be completed by what time. Tasks are usually divided by the sub-teams that make up the product development.
In the example below, you can see the user interface tasks, API development tasks, storage administrators tasks, and service integration tasks, each in a different timeline with its own subtasks.
The undated roadmap is an adaptation of the timeline roadmap. It is good for showing to people outside the product design team, such as members of the marketing or administration teams, so they can add their tasks. As you can see, tasks are simplified and management tasks are added.
This type of roadmap is mostly used in kick-off meetings, where the CEO is presented with plans for the entire design of a new product, both from the product team's point of view and from the management team's point of view. It is also an excellent tool for introducing a new hire or an outsider to the team, as it will give them an idea of the product planning before they learn the details.
Unlike the above roadmaps, which are future-oriented, the Kanban roadmap is about the present. This model is ideal for the team that works closely on a day-to-day basis, as it focuses on daily tasks rather than displaying a long-term view.
One of the keys to an effective Kanban roadmap is to limit the flow of work in progress, because by setting limits, you can anticipate the team's shortcomings before they occur and fix them. The Kanban roadmap helps the team learn what is going right and what is not.
The Kanban work philosophy is on the rise, especially in development teams, so you will likely use a Kanban roadmap if you work with the developers team.
My personal advice for your product design team is to know at least the first two roadmaps: the timeline roadmap and the undated roadmap. Roadmaps help to regulate the workflows of the product design team's tasks, which is extremely important in the development of a project.
Product design teams that include developers may benefit from using a Kanban roadmap that allows them to focus on day-to-day tasks rather than the long term. My recommendation in these cases is to avoid losing sight of the long-term product development that a timeline roadmap offers.
Throughout my professional experience, I have participated in the construction of many product roadmaps. Here are some tips for building a successful product roadmap:
1. Create visual roadmaps
2. Focus on milestones, not due dates
3. Let each team member view their own responsibilities on the roadmap
4. Hold regular roadmap meetings with your team
5. Define your product timeframe
6. Validate team’s capacity
7. Meet with your product and tech leaders to review dependencies
8. Share the final structure with your team
9. Present your roadmap to your client
10. Continue to update your roadmap
One extra tip: Once you start defining your product in your backlog and product sessions, you can start adding specific topics in your epics. This exercise will help you confirm whether your understanding of the product is the same as your tech lead’s and product team’s. Same with your client — use your roadmap to let them know how each epic is growing in detail.
I hope you feel more prepared to build your own product roadmap, even if you have never built one before. Wishing you luck!