building a product roadmap: a guide for business analysts

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:

1. Define the reason for product development

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:

• What is the vision for the product?
• What need do we want to satisfy?
• What added value do we offer?
• How will the product benefit our customers?

2. Define your target audience

Don’t offer your product to everyone. Define the market segment you are targeting and the profile of your potential consumers.

Ask yourself:

• Who would use this product?
• Who would pay for it?
• Why would they choose it?
• What are their motivations, behaviors, frustrations, pains and needs?

3. Define your goals

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. 

4. Identify and prioritize product features

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.

5. Map user stories

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.

6. Create a timeline

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:

7. Update your product roadmap

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.

Timeline roadmap

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.

Undated roadmap

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.

Kanban roadmap

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

• A product roadmap needs to communicate high-level planning, strategy and goals in a comprehensive way to all readers.
• Calendar standards are crucial to understanding the plan.
• Use color-coding and include a key that explains what each color means.
• Build your roadmap so that it shows a natural hierarchy in your plans.
• Avoid using technical terms.

2. Focus on milestones, not due dates

• Highlight major milestones on your roadmap and find a way to show your team the progress they’re making on initiatives.
• Sharing the status of tasks can be tricky and setting specific deadlines can be risky.
• Let the team know the initiatives, the epics that the product is currently on and how much work is still needed.
• Update the percent completed of each initiative on the roadmap. Your team can view the progress at any time.

3. Let each team member view their own responsibilities on the roadmap

• Make your roadmap available online for the team to view.
• Build different views on the roadmap to display effort details so that team leaders can focus on priorities.
• Create items and filters for items that correspond only to the team’s responsibilities, so they know what the priorities are and are aware of changes.
• Allow your team to view the roadmaps with valuable information for everyone, not just for stakeholders.

4. Hold regular roadmap meetings with your team

• These meetings will allow everyone to view the roadmap and discuss the team’s status, strategies and priorities.
• Long product status meetings on a static document can cause a lack of interest.
• Meetings can be especially useful when some or all team members are working in different locations.
• Meetings can be held monthly or quarterly. Just make sure everyone is involved.

5. Define your product timeframe

• Define a general timeframe for your product (quarter, months, years).
• Be specific. If your client or project manager already knows the expected release dates, include them.
• If your epics are already defined and estimated, include sprints so your client is aware of the deadlines.

6. Validate team’s capacity

• Review with your project manager and technical leader your squad’s capacity. Frontend, Backend, Quality Assurance, Shadows?
• This might help you understand how you can estimate sprints, releases, and activities on your roadmap.

7. Meet with your product and tech leaders to review dependencies

• It is important to understand the dependencies of your epics.
• Each functionality can bring a lot of dependencies, and your team can help you make it visible to the client.
• Your roadmap is the best way to let the client know that everyone on your team is on the same page.

8. Share the final structure with your team

• Hold a meeting to present all the work you have done on the roadmap to your entire team.
• Let them know which color they should look at and what the next steps for the product are.
• Even if they only work on a small fraction of the project, it is good to let them know about the upcoming steps.

9. Present your roadmap to your client

• It’s time to present your team’s hard work. Share the link to your roadmap with your client and invite them to look at the updates, structure, color coding, and dependencies.
• If they have a link that you update every week, you will likely receive feedback on your progress sooner.

10. Continue to update your roadmap

• Keep updating your roadmap with more details. This lets your team know that you are on top of it and lets your client know that everything is crystal clear for everyone.
• Update your roadmap after a sprint starts and also once it is over.
• If your technical leader finds a dependency, show it on the roadmap until it is fixed.
• New requirement? Show it and let your client know about the repercussions on your timeframe for delivery.
• Always show a percent completed. This will give your team an idea of how much work is left.

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.

Benefits of a product roadmap

• Easily validate whether your client’s timeframe is real.
• See possible roadblocks and dependencies.
• Your client will know you are on top of it.
• Estimate backlog items more quickly.
• Build and negotiate the second or third product phase more easily.
• Do you need to prioritize epics or user stories? It’s faster than creating artifacts in JIRA and Excel.
• It helps you build your team.

I hope you feel more prepared to build your own product roadmap, even if you have never built one before. Wishing you luck!