How to Create a Product Roadmap?

As a Product Manager working in a software company, you need some space to describe the strategic product vision and share it with your collaborators. After all, to build an application successfully, your team and investors should know the plan of action.

The answer to your needs? A product roadmap. It will help you communicate product strategy and secure buy-in from project stakeholders. 

In today's blog post, we're going to share the steps for creating a product roadmap. We'll guide you through the whole process, from analyzing business goals to defining User Stories. Whether you're working on planning a new product or expanding an existing application, you should find this guide applicable. Granted, when your product is already available to the public, you have likely already analyzed user needs and established your business case. Still, it's worth taking another look at them, especially if you're about to introduce completely new features to your product.

Before we jump into the details of the roadmapping process, let's briefly describe the concept of product roadmaps. 

What is a product roadmap?

A product roadmap is a high-level plan of how your product will grow. It communicates what will be built and why, so it may include the primary business goals, Epics, User Stories, and priorities.

Since it's a single source of truth for all project stakeholders regarding the product vision and strategy, it's crucial that you revisit your product roadmap regularly and update it if necessary.

‍

Steps to create a product roadmap

Our approach to building product roadmaps is rooted in agile principles. The priority is to respond to change and treat the roadmap as a living document.

First, you need to take a moment to review your business case and make sure you have an in-depth understanding of your users.

‍

Consider your business case and your users' needs

When thinking about your product roadmap, you might feel that it's natural to focus on your product's features first. To tell the truth, that’s not the best way to go. You should analyze your business goals and user needs before you dive into your product's functionalities.

If your software solves an actual problem, it means that you have a strong business case, which is very important. That's why you need to ensure that your preliminary vision is realistic and viable. Research the market and use hard data to evaluate your business case. Can you confidently say that you understand your users' pain points and needs? Spending some time on solid user research now may save you a lot of time and money in the long run.

‍

Define the critical path of your application

Now that you have an excellent understanding of where your users are now and what they will be able to achieve with your application, you can draft the critical path. What needs to happen after the sign up so that people achieve their desired result?

The benefit of this step is that you will be able to build a product strategy around features that are truly meaningful. Adding bells and whistles to the product won’t help if the real value isn’t there. Instead, focus on the features that solve your users’ pain points.

Have you defined the critical path? It's time to build Epics for your features around this path. If you're not familiar with this term, an Epic is a body of work that could be divided into smaller User Stories—more on them below. An example of an Epic you could include in your product roadmap would be “Payments” with User Stories regarding different payment methods, chargebacks, failed payments, etc.

Remember that you should be able to justify the need for having each of the Epics in your roadmap. Is it aligned with your business case? Does it belong to the critical path?

Prioritize the work

The next step is to prioritize the Epics. There are different prioritization techniques product managers use to organize their work—we usually rely on MoSCoW and ICE. Here's how they work:

• In the MoSCoW technique, you put items into four categories: Must have, Should have, Could have, Won't have right now. The must-have category, for instance, is for Epics that the product wouldn't work without. The should-have items add considerable value, but you can imagine the product without them.  At this point in the process, you're not likely to have Epics on your list that are totally unnecessary, but this technique should help you to identify the essential elements. The recommended proportion of must-haves to should-haves to could-haves is 60/20/20. 

‍

‍

• The ICE method requires you to evaluate each Epic in terms of their Impact on your key metrics, your Confidence that they will have an impact, and their Ease of implementation. Rate each of these three aspects on a scale from 1 to 5 or 1 to 10 and calculate the average score for each Epic.

Once your priorities are set, you can work on identifying technical dependencies between different parts of your system. Perhaps your team can only start working on one of the Epics when another one is complete? Or a delay in one part of the project could significantly affect other Epics? Knowing the dependencies is an important part of product development: it will help you organize the work and manage project risks.

‍

Think about the timeline

When you have a prioritized list of Epics, you can create a general timeline for your product. How much time will it take to deliver the Epics included in your product's critical path? Keep in mind that your timeline is top level and could be modified. The further in the future you plan, the less certainty there usually is. 

While you're working on the timeline, you should also choose a moment in the production cycle when your product will be ready to be shown to bigger audiences and launched. It's not necessarily when all of the Epics from your roadmap are done: the minimum viable/delightful/lovable product may be achieved earlier.

‍

Work on User Stories

Look at the Epics at the top of your prioritized list and create User Stories, short descriptions of a feature written from your user's perspective. As a user, I want to receive email reminders about my upcoming meetings so that I don’t miss them—that's how your User Stories could sound like. Dividing Epics into User Stories will help you to add much more definition regarding the scope of work. Remember that you should also prioritize User Stories within Epics to have a complete product roadmap.

‍

Stay flexible

Your product roadmap is not set in stone, and you shouldn't be afraid to edit it. Changes in your strategy may be caused by different things: user feedback, shifts in your business strategy, technological breakthroughs, or even global phenomena and trends.

Even if you feel there's no particular reason for changing the roadmap, you might schedule to revisit it regularly and make sure that it's up-to-date. Pay attention to priorities, timelines, estimates—are they still accurate?