How to create a product roadmap? 4 basic steps | Business strategies #8

Creating new products is a process. It takes vision, time, and preparation. And to avoid getting lost along the way, it’s worth preparing a document called a product roadmap. What is it and how to create it? Let’s dig right in!

Product roadmap – table of contents:

What is a product roadmap?

The product roadmap is a document that contains information about the vision of the emerging product, the plan for working on it, performance metrics, and anything else that allows the team to determine where they actually are and whether they are making progress. It is most often presented in the form of a chart.

But presenting the product roadmap in this way is not a rule carved in stone. You can present it any way you like. The most important thing is that it is understandable and clear to the audience. Speaking of which, one thing is worth mentioning. You can have more than one roadmap. That is, the content should always be the same. However, the form in which the information is presented can vary depending on who the recipient is.

Product roadmap and its recipients

That’s because different team members play different roles in the product life cycle, and to better understand their roles, managers should speak their language. How does this apply in practice? Let’s take an example and put it on the roadmap. Let’s call it “verify a business hypothesis” and make it our goal for Q1.

Perhaps the project manager is clear about the goal, but what about the rest of the team? Not necessarily. For each department, that goal may mean something different because each department has different tasks to perform within that goal. For example, developers need to build an MVP (a product with minimal usability), and the marketing team needs to collect email addresses.

And this leads us to the next question.

What should a product roadmap include?

Except for you, no one can really say because every product is different. Each one has different specifications, and each one requires a different strategy. So every time, you have to tailor your roadmap to the goals and resources you have. What we can do, however, is identify areas that are worth considering. However, it is important to look at them as potential opportunities, not as a set of ready-made elements.

Things to include in a product roadmap:

Product vision – what and whose problem our product solves, and how does it do it?
Business objectives – what business goals will we achieve by launching the product?
Deadlines and milestones – what stages do we have to go through and when to bring a product to market?
Features – what features must our product have to appeal to our audience? Which of them are essential?
Teams – who is involved in the implementation of the product? Who is responsible for what?
Feedback and iterations – what information we have obtained from our audience will we take into account in future product iterations?
Resources – what resources, including technology, do we need to bring to market a valuable product that meets our audience’s expectations and achieves our business goals?
Success factors – what indicators will help us determine product progress?

How to create a product roadmap? First, a certain assumption.

In contact with the market and potential customers, the product will change. So the product roadmap can’t “stand still.” Also, it must change and keep up with feedback. It is a “living” document. Remember about it.

And how to create it? The following four steps can help you do that.

Step 1. Product vision and audience’s needs

The first step in creating the product roadmap is to identify business goals and hypotheses, as well as the audience’s needs for a given project. What do we mean by that?

Business objectives. The product roadmap has to answer two questions. What are we doing – “What product are we going to build?” and why are we doing what we are doing – “Why do we want to build this product? And management is responsible for defining that. Except that the vision and the goals must be known to product developers. So the most important thing in the first step is the dialog between one party and the other.
Business hypotheses. It is safer to hypothesize than to assume that our product vision will definitely address the needs and problems of our audience. This approach removes the burden of responsibility for potential market failures from the team, encourages experimentation, and opens it up to changes in the roadmap.
Recipients’ needs. Understanding your audience’s needs determines the shape of your future product. That’s why market analysis, user research, and gathering feedback are essential in the early stages of product development. And remember that the roadmap is just one part of a larger whole. We don’t create the roadmap for the sake of the roadmap.

Step 2.Product concept and selecting features

After defining the business goals and understanding your audience’s needs, the next important step is to think about the product concept. This is the stage where we define what the product will look like and what functions it will have. It is important to focus on the value that the product will bring to the recipient.

For example, if we determine that our customers’ most critical need is “the ability to store files,” then we can ask ourselves what solution will best address that specific need and whether we have the resources to bring such a solution to market.

The answer to this question will be, in fact, a business hypothesis. Until we confront it with the market, we can’t be 100% sure that the product idea will actually meet the needs of potential customers. It’s worth testing.

And a minimum viable product (MVP), which is the simplest version of the product that contains a minimum set of features, can be useful for conducting the test.

With an idea for an MVP or even a finished product, we will learn the list of functions we will need to implement, and so put them on the roadmap. But before we do that, let’s think about resources.

Step 3. Identifying resources

The third step in building the product roadmap is to identify resources. What do we really need to make the product work? Capital, people, time, tools? What is it? It’s important to know this up front because the choice of resources determines how the goal will be achieved, and therefore affects the plan and the product roadmap itself.

For example, if you decide to build an MVP in the form of a simple mobile app, two developers may not be able to do it in two months. What then? You can hire more people, outsource the work, or change the deadline. Changing resources affects the path to your goal.

Knowing what kind of product we want to build and how we intend to do it, we can move forward and divide the work into stages. Depending on business experience and market knowledge, defining the stages can be more or less detailed. Sometimes, however, it is difficult to predict what will happen in three or four months.

Therefore, it is safer to assume that we know what we are going to do in the first iteration and then adjust the plan based on the feedback we get from the market. In any case, an indispensable part of dividing the work into phases is assigning deadlines for their completion. In general, we can assume that the more specific the deadline, the better, because we have more control over what happens to the product – “Where are we?”

At the same time, Jeff Lash, global product manager at Forrester, recommends timing your deadlines to your capabilities. Seems obvious. But it takes experience. It’s easy to be tempted to overestimate and break a big goal into four quarters, thinking, “This is what you have to do because this is what you do.”

Jeff Lash takes a slightly different approach. The more predictable the work on a product, the more we should break it down into monthly milestones and assign specific KPIs. But if we don’t have that certainty, and the project is less predictable, then let’s put the milestones and KPIs on a less granular schedule. For example, quarterly (Q1, Q2, etc.) or even “now, soon, later”.

Finally, remember that a roadmap is not a product. It will change as you work. So it pays to keep an open mind and be willing to update this document.

If you like our content, join our busy bees community on Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest, TikTok.

Author: Adam Sawicki
Owner and Editor-in-Chief of Rebiznes.pl, a website with news, interviews, and guides for solo entrepreneurs and online creators. In media since 2014.
View all posts