Course table of contents
1. Role of product manager and framework
2. Market segmentation and competitive analysis
3. User personas
4. Hypothesis testing
5. Product positioning
6. Product roadmap <- You are here
7. Drafting requirements for development
8. Business model and Business- Plan
9. Financial Plan and Pricing
- To Be Continued
Having a roadmap is very important for managing product development. However, in order 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 in order to properly build a roadmap.
United Nations motto: “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. Within the framework 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 in accordance with the prepared map, releases become milestones and stages of this movement - the embodiment of specific steps for product development.
What horizon should you swing with planning? It can be different, but for a start it is better to limit yourself to 6 months. If you know exactly where your product is going to move, it could be 3 years or 5 years. There is no limit. For example, in his recent speechAmazon 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 intense space flights. Amazon relied on an already existing courier and mail infrastructure, Bezos said. If they did not exist, Amazon would not have been able to work or become so successful. Today Blue Origin plans to create the infrastructure for future space travel - rockets, spaceports, satellites, orbital stations and so on. Blue Origin's global goals are to build a spaceship by 2025.
Understanding your global goals helps to draw up a roadmap, where we show concrete steps, building a realistic plan to achieve the set goals in the near future. And Blue Origin, as a company with ambitious plans, is trying to fulfill its mission - to organize a worldwide service for the accessible and convenient movement of people and goods.
From heaven to earth ...
Consider a more realistic example. If a construction company is engaged in high-quality construction, the concept of its work may look like this:
● Vision - to build the best residential area in the north of Moscow (SAO).
● Goals - 5000 apartments, modern architecture, class comfort, convenient layouts, a courtyard without cars.
● Roadmap - queues of development and improvement of the territory.
● Release - concrete finished buildings, roads, parks (division is possible at the stage of completion).
● Feature - a component of the release. For example, a playground, planted trees, covered parking, a ramp.
How to create a software product roadmap?
The software roadmap includes releases, each of which must contain certain features. It is very important to schedule a roadmap by dates, taking into account the available capabilities and resources (more on that later). For example, this is what a roadmap for one of the social apps looks like.
Keep in mind that the roadmap must be planned for all departments at once. If the company is large and sales managers have their own roadmap, you need to link it to the development department's roadmap. Otherwise, when the time comes, for example, to promote a product on the Asian market, it may turn out that you do not have ready-made localization ... and indeed support for the Chinese language.
Requests for what should be in a product come from many different quarters. We already talked about this in one of the previous posts.... They need to be carefully organized and planned. It is important to understand that it will not be possible to prepare and release all the features in version 1.0, because in reality there are never enough resources to implement all the ideas (if this is not the case, then you have few 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 with decreasing priority and importance in iterations.
Let's take a look at another software product development framework (Software Product Management Framework) that controls software development:
The maturity matrix of a company that lives under a given framework is determined by the following table. And with formal adherence to the process of preparing the roadmap, the company immediately gets to the second level of maturity:
In general, this framework is a separate branch for any course on product development. We will not dwell on it now. If someone is interested in reading an additional post on this topic, please leave a comment on this post.
Here for ourselves we will only accept that by observing some formal procedures in software development, while building these processes, the company itself improves the culture of delivering better software. Roadmap is part of this culture.
How to collect and process product requirements?
When we receive requirements from different sides, they need to be entered into some kind of system. For example, Acronis uses Jira, which is quite a powerful tool, but for startups you can use simpler ones, including free ones, for example, Redmine or Asana.
The main thing is that all ideas are registered, because there are no bad thoughts. If the idea does not yet deserve implementation, then its priority will remain low. Therefore, it is very important to enter every sentence into the system - even without a detailed description of "how it should work". Only with this approach can you plan the implementation of the demanded features - that is, create a real Roadmap.
All ideas come to the so-called "Incoming backlog", they can be either formalized or "raw", without evaluations and understanding who needs these features. After working out the requests and adding details, some of them can go to the next release. The rest are sent to the Backlog and I can stay there for a long time.
Epic
Agile or Scrum methodology implies a term like "Epic". If to explain its essence as simply as possible, then we are talking about some big feature, the implementation of which requires the involvement of all participants - developers, testers, interface designers, technical writers, and so on.
Typically, when creating an epic, its importance from a business point of view is assessed, labor costs are calculated, and a decision is made whether to include it in the current release or send it to the backlog.
For epics that have already been graded, you can assign a priority in the system. For example, in the same Jira, you can set "high", "medium" or "low". But, for example, in our Acronis backlog there are hundreds and even thousands of features. In this case, simple priorities are indispensable.
Calculating Feature Score
A more complex scoring methodology is called Feature Score. The idea is to bring all factors influencing development into a single rating. Then, based on the normalized rating, make decisions about including the feature in the release or abandoning development at the moment. Thus, positive metrics add points to a feature, while negative ones act with an inverse proportion (more value - less points). Some of the positive metrics include:
1. Urgency.
2. The size of the client who needs it.
3. Increasing market share due to the emergence of new customers.
4. Potential profit or loss from the departure of current clients.
5. Strategic achievements (goals that lead us to the embodiment of Vision).
Negative metrics:
1. The amount of labor costs.
2. Potential risks.
Feature Score must be a number. This is not a qualitative assessment, but some kind of rating, and the method for its calculation must be unified and approved within the framework 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 customer factor. The so-called Customer Factor is defined as the product of urgency and customer size. You can see an example of calculation in the image below.
Market Penetrationis 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 strategy compliance. To evaluate the Strategy, you need to check whether the feature helps you move along strategic development directions. And the more directions it covers, the higher the score will be.
Revenue is the potential profit that a feature's implementation can give. The estimate of this parameter depends on the size of the company, the characteristics of the product, and the revenue you expect to receive. The table shows an example of scoring for this indicator.
But now let's talk about the opposite factors, which give the less points to a feature, the more they are manifested. 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 is the second aspect. The lower your confidence in the assessments, the higher the risks, which means the lower the value of the criterion in the Feature Score formula.
After taking into account all the factors mentioned, the Feature Score formula may look like this:
It is good if the scores are objective, based on specific factors. But if you are just entering the market, still make a Feature Score. Better to be subjective than none at all.
Roadmap on the example of the "Taxi" application
In one of the previous posts, we have already talked about creating an application for calling a taxi. Suppose we need to rank the following features for this product:
A table with priorities might look like this:
Consider the "Order by the right time" feature. 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 priority list. In our application, we obviously need to make a mobile application on Android. The second move is the “Children's” tariff.
A systematic approach allows not to do what is not so important for the business and not to choose a “random feature” for implementation. The return on 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 just priorities
Release planning takes into account the capacity of the development team. Some products have more than one such command. For example, to create a taxi ordering service, at least there should be backend, QA, Android, iOS commands.
But in addition to prioritizing, we must also estimate how many hours developers can allocate 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 allocated 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 for one release cycle:
If you look at the table below, it becomes clear that a mobile application for iOS requires a lot of resources, and not only the iOS development team, but also backend and QA specialists. That is why it is logical for the management to make a decision not to include the mobile application for iOS in the first release, since the team will not have time to make it anyway, but on the other hand, they will finish “Taxi order by the right time”.
Thus, if we go in the order of priority of all sorted features, then the roadmap for the development of the application by ordering a taxi will look like this:
Each subsequent version will include the next priority features that are placed in the capacity of the development team.
Roadmap - as a product development philosophy
Remember that Roadmap is not a commitment, but rather a prediction. I would advise treating the roadmap as a current plan. It is possible that in a month a new client will come and ask for a new feature. And when we add her to the backlog, her priority will probably be higher than anything previously planned. As a general rule, when working on a product, it is important to have a Roadmap for every moment of time, but you should not make it static, because today you need to adapt to changing market conditions.
The proposed work with the roadmap (prioritizing features according to general rules) requires an internal culture. 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 advisable to allocate a different capacity of development teams to things that are not directly related to the development of custom features. For example, a development team leader may tell you: “We need to switch to a new version of Python, otherwise we will have more time ( money) spend on maintaining the existing ecosystem on the old version ”. To solve such problems, you can allocate, for example, 25% of the team's capacity for features related to winning new customers, 45% for retention of current customers, 20% for technical debt and refactoring, and 10% leave as a buffer so that there is room for features. who 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).
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 them in the release scope. But if we have already decided on the next release, it becomes necessary to establish interaction between managers and developers.
To do this, in the next post we will look at the mechanism for creating requirements for a feature that needs to be set by the development department. This is necessary for the feature to be developed, preferably in the form in which you want to see it. We will talk about why the requirements should be clear, how they should be formalized, and what practices exist for working with requirements for developers.
→ Video recording of all lectures of the course is available on YouTube
Lecture on the roadmap and requirements for development: