How to Create Product Roadmap and How to Prioritize Solutions
Having a roadmap is very important for managing the product lifecycle. However, to correctly draw up a roadmap, it is necessary to approach this issue systematically. It is very important not to confuse a roadmap with a vision, although having a vision is necessary to properly build a roadmap.
You can have a quick look at my previous related articles Connection Between OKRs, Product Roadmap, and PMT KPIs and Product Vision Board.
In this article, we will try to highlight some of the numerical systems that allow you to understand what to build now, what to skip and keep for later. Roadmap size and limits, how to come up with a solution/feature from vision, samples of software roadmaps, how to gather inputs for your product, how to groom and prioritize them, how to calculate the weighing value of the feature, and examples of formulas & calculations.
It may look like a long article, but I think, keeping the main idea in one place is a plus for you.
The motto of the United Nations is “Think Globally, Act Locally”.
Interestingly, it also works when creating a roadmap for a good software product. To do this, you need to have a global vision so that your aspirations do not end “here and now.”
As part of the vision, goals are set — they are also quite global, and it is to these goals that the roadmap should lead. When you move by the prepared map, releases become the milestones and stages of this movement — the embodiment of specific steps to develop the product.
What is the horizon for planning?
It can be different, but for starters, it is better to limit yourself to 6 months. If you know exactly where your product will go, it could be 3 years or 5 years. There is no limit.
For example, in his recent speech, Amazon founder Jeff Bezos announced the Blue Origin space program with a planning horizon of 50–100 years.
That is, a person creates a company that will work most of the time after his life. How is this even possible?
It’s just that in this case, we are talking about a global vision — Blue Origin should provide the possibility of intensive space flights. Bezos said Amazon relied on its existing courier and mail infrastructure. Without them, Amazon would not have been able to work or become so successful. Today, Blue Origin plans to create infrastructure for future space travel — rockets, spaceports, satellites, orbital stations, and so on. The global goal of Blue Origin is to build a spacecraft by 2025.
Understanding our global goals helps to create a roadmap, where we show concrete steps, building a real plan to achieve our goals shortly. And Blue Origin, as a company with ambitious plans, is trying to realize its mission — to organize a worldwide service for the affordable and convenient movement of people and goods.
From heaven to earth… From Sky to the Land…
Let’s consider an example closer to real life. If a construction company is engaged in quality development, the concept of its work may look like this:
● Vision — build the best residential area in the north of Kyiv.
● Goals — 5,000 apartments, modern architecture, comfort class, convenient layouts, car-free yard.
● Roadmap — construction and landscaping queues.
● Release — specific finished buildings, roads, parks (possible division at the stage of readiness).
● Feature — A component of a release. For example, playground, planted trees, covered parking, ramp.
Ok, now let's get near to our business which we know better :)
So, How to make a roadmap of a software product?
The software roadmap includes releases, each of which must contain certain features. It is very important to paint the roadmap by dates, taking into account the available opportunities and resources (more on this later). For example, this is what the roadmap of one of the social applications looks like.
Keep in mind that the roadmap needs to be planned for all departments at once. If the company is large, and sales managers have their roadmap, you need to link it to the roadmap of the development department. Otherwise, when the time comes, for example, to promote a product in the Asian market, it may turn out that you do not have a ready-made localization … and indeed support for the Chinese language. You see again the importance of all company alignment. Roadmaps are the reflection of the vision and the mission.
Requests for what should be in the product come from a variety of quarters. We have already talked about this in one of the previous posts. They need to be carefully organized and planned. It is important to understand that preparing and releasing all the features in version 1.0 will not work, because in reality there are never enough resources to implement all the ideas (if this is not the case, then you don’t have enough ideas and you need to think more).
With the right approach, Roadmap is an opportunity to divide the product development process into stages and roll out functionality in iterations with decreasing priority and importance.
Let’s look at another software product development framework that manages software development:
The maturity matrix of a company that lives by this framework is determined by the following table. I will write about the maturity matrix of a product but till then, you can read about it here.
And by formally following the roadmap preparation process, the company immediately enters the second level of maturity:
Here, for ourselves, we can only bear that if some formal procedures in software development are observed, when building these processes, the company itself improves the culture of delivering better software. The roadmap is part of that culture. Also remember, Roadmap is not a document of promises, it is a communication tool for aligning all stakeholders.
How to collect and process product needs/expectations/ideas?
When we receive requirements from different sides, they need to be entered into some kind of system. For example, Acronis uses Jira — this is a fairly powerful tool, but for startups, you can use simpler ones, including free ones, such as Redmine or Asana.
The main thing is that all ideas are registered because there are no bad thoughts. If an idea is not yet worthy of implementation, then its priority will remain low. Therefore, it is very important to enter every proposal into the system — even without a detailed description of “how it should work.” Only with this approach will you be able to plan the implementation of popular features — that is, create a real Roadmap.
All ideas come to the so-called “Incoming backlog”, they can be both completed and “raw”, without evaluation and understanding who needs these features. After working out requests and adding details, some of them may go into the next release. The rest are sent to the Backlog and it can stay there for a long time.
EPIC
Agile or Scrum methodology implies a term like “Epic”. If we explain its essence as simply as possible, then we are talking about some kind of big feature, the implementation of which requires the involvement of all participants — developers, testers, interface designers, technical writers, and so on.
Usually, when creating an epic, its importance from a business point of view is evaluated, employee costs are calculated, and a decision is made whether to include it in the current release or send it to the backlog.
Epics that have already been rated can be prioritized in the system. For example, in the same Jira, you can set “high”, “medium” or “low”. But, for example, at Acronis, we have hundreds and even thousands of features in the backlog. In this case, simple priorities are not enough.
Calculating Feature Score
A more sophisticated scoring methodology is called Feature Score. The idea is to bring all the factors influencing the development to a single rating. Then, based on the normalized rating, decide whether to include the feature in the release or abandon development at the moment. Thus, positive metrics add feature points, while negative ones act with the inverse proportion (higher value — fewer points). Positive metrics include:
1. Urgency.
2. The size of the customer who needs it.
3. Increasing market share through the emergence of new customers.
4. Potential profit or loss from the exit of current customers.
5. Strategic achievements (the goal that leads us to the embodiment of the Vision).
Negative metrics:
1. The amount of labor.
2. Possible risks.
Feature Score must be a number. This is not a qualitative assessment, but some kind of a rating, and the method of its calculation must be unified and approved as part of the development of a specific product.
Points are determined based on normalized values, the company’s market goals, and other parameters. The first parameter that is taken into account in the Feature Score is the client factor. The so-called Customer Factor is defined as the product of urgency and customer size. You can see an example of the calculation in the image below.
Market Penetration is defined as the likelihood of attracting new customers and depends on your plans to expand your customer base.
For example, for features that will not attract new customers, this parameter can be equal to 0, and for those that can bring you, say, 500 customers, the score will be 20.
The next question is strategic alignment. To evaluate Strategy, you need to check whether the feature helps to move along the strategic directions of development. And the more areas it covers, the higher the score will be.
Revenue is the potential profit that the implementation of a feature can provide. The estimate of this parameter depends on the size of the company, the features of the product, and the revenue that you plan to receive. The table shows an example of scoring for this indicator.
But now let’s talk about the inverse factors, which give the fewer feature points, the stronger they are. For example, development costs can also be fixed for your company at the level of certain estimates, depending on how much you are willing to spend on the development of certain features.
Risks — this is the second aspect. The less confidence you have in the assessments, the higher the risks, and hence the lower the value of the criterion in the Feature Score formula.
After taking into account all the mentioned factors, the Feature Score formula can look like this:
It is good if the estimates are objective, based on specific factors. But if you are just entering the market, make a Feature Score anyway. Better they are subjective than none at all.
Roadmap on the example of the application “Taxi”
Let’s say we want to rank the following features for this product:
The priority table might look like this:
Consider the feature “Order a Taxi on a Scheduled Time”. Summing up all the parameters, we get 56. What does this number mean?
Nothing!
This is a relative rating, and we need to calculate all 9 features, adhering to the same criteria and ratings. The result is a list of priorities. In our application, we need to make a mobile application on Android. The second move is the “Junior+” tariff.
A systematic approach allows you not to do something that is not so important for business and not to choose a “random feature” for implementation. The return from gradual and phased work will be higher. And this is very important because there are always constraining factors for the development of each project: time, cost, volume. The combination of which gives you quality.
Not Only Priorities!!!
When planning releases, the capacity of the development team is taken into account. Some products may have several such commands.
For example, to create a taxi ordering service, at least there should be backend, QA, Android, iOS commands.
But in addition to prioritization, we must also evaluate how many hours developers can devote to work on each next feature. To do this, you need to multiply the number of people in the team by the number of days allotted for its preparation. Understanding what can go into the capacity available for the next release (scope) helps to avoid wasting resources.
The capacity of different teams per release cycle:
If you look at the table below, it becomes clear that a mobile application for iOS needs a lot of resources, not only iOS development teams but also backend and QA specialists. That is why it is logical for management to decide not to include a mobile application for iOS in the first release since the team will still not have time to make it but to complete “Ordering a taxi on a scheduled time”.
Thus, if we go in the order of priorities of all sorted features, then the roadmap for the development of the application for ordering a taxi will look like this:
Each next version will include the next priority features that are placed in the capacity of the development team.
Roadmap — as a philosophy of product development
It must be remembered that the Roadmap is not a commitment, but rather a prediction. I would advise considering the roadmap as the current plan. In a month a new client may come and ask for a new feature. And when we add it to the backlog, perhaps it will be a higher priority than anything previously planned. The general rule is that when working on a product, it is important to have a Roadmap for every moment in time, but you should not make it static, because today you need to adapt to changing market conditions.
For the proposed work with the roadmap (prioritization of features according to general rules), internal culture is needed. All stakeholders must follow the same scoring principles, so the first step is to discuss the calculation formula and then follow this rule. Of course, everything can be changed if there is an understanding of how to improve prioritization, but then it will be necessary to recalculate the priorities for the entire backlog.
For large products, it is also desirable to allocate a different capacity of development teams to things not directly related to the development of custom features. For example, the development team lead may tell you: “We need to move to a new version of Python, otherwise we will spend more time (money) on supporting the existing ecosystem on the old version”. To solve such problems, you can allocate, for example, 25% of the team’s capacity to features related to winning new customers, 45% to retain current ones, 20% to technical debt and refactoring, and leave 10% as a buffer so that there is room for features, which came suddenly or overhead to account for activities not directly related to product development (deployment of a new build system, implementation of CI\CD, and so on). You can read more about technical debts.
Conclusion
To successfully plan development and adjust the roadmap, you need to periodically review your backlog and recalculate the feature score for those features that you plan to develop and want in the scope of the release. But if we have already decided on the next release, it becomes necessary to establish interaction between managers and developers.
In an upcoming article, I will try to gather information for you about KR-based roadmaps, various prioritization methods, Roadmap success metrics.
Also, we will touch on such topics — how to handle changes and its reflection on feature scorings and what do we do if we can not give even relative scoring to the features at all.
Let's finish it up as usual with a quote;
Steve Job Says:
“People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things.”
