When I worked as a product management consultant, clients often mentioned: “The product roadmap is desperately needed, the sooner the better. ” Therefore, I have also done some in-depth research in this area, trying to dig out what their real needs are, and the end result has always returned to the most important value proposition and business model.
So, in fact, the need for a product roadmap is essentially saying, “Please help me with strategic planning.”
Product roadmaps are important to product managers, but at the same time, they are a source of uncertainty.
Currently, I lead a team of 40 product managers focusing on public-side software, employee-side software, core technology, and agile management consulting: the product roadmap has been supporting our specialization for the past two years development theme. For better or worse, product roadmaps have always been the most closely watched and scrutinized piece of business for our company.
The above examples mainly illustrate my two assumptions about the product roadmap:
- For lay partners, product roadmaps are synonymous with “product management,” so they can make demands, leaving us ample opportunity to explain the core concepts of product management.
- And we (product managers) have a lot of concerns when creating product roadmaps because they have high expectations for our team, our colleagues, and even our self-worth. We do need a safe space to recognize reality, share problems, and learn from each other.
I created a diagram to help answer the question of what a good product roadmap should look like for a government agency, but I think the same applies to any other scenario.
At the same time, this can also serve as a starting point for us to discuss the core concepts of product management with our partners.
Let’s look at this diagram from the top down – the five elements of a good product roadmap.
1. Environment
It is very important to set the appropriate application environment for your product. Things to consider are the product life cycle, organizational needs, and audience needs. My product roadmap typically considers the following:
Strategic environment:
For a product roadmap to really work, it first has to be clear about what your product is worth today and what you expect it to be worth in the future—and your product roadmap is the link that combines these two values, and also A strategic tool that can help you better plan how to evolve from your current business model, step by step, prioritized, step by step, to an anticipated future model.
Product Lifecycle Environment:
- During the product development and introduction phase, you may focus on completing the development of the core functions of the product according to priorities;
- In the growth period, you need to ensure the matching of products and markets while considering sales, marketing, user guidance, and scalability;
- In the mature stage, you need to give full play to the value of the business model and improve the return on investment;
- In a recession, you need to find a balance between exiting the market and retaining user demand.
Team environment:
The product roadmap is one of the tools you and your team use to define long-term strategies, and it is also an important tool for team communication and mutual motivation. I once led a basic platform-building project that required six to nine months of technical input, and I can tell you the truth: watching those goals complete over time is what keeps us going through the worst days. power.
Organizational Environment:
You and your team will use the product roadmap as a tool for communicating with partners or customers. Sometimes, you even need to show a version with some hidden strategic points to the customer, instead of giving it what they want. What, directly “sell” the team’s work results. You may also need a special version of the product roadmap that focuses specifically on product functionality – as long as it’s not your only product roadmap, that’s fine – treat this as a product PR requirement.
In order to do a detailed environmental analysis of your product, you may need to add at least a few more aspects, such as your vision, business goals, product name, trademark, etc. But the most important point is: the environment is very important, but It is also fickle, so there is no one-size-fits-all model of analysis. I’ve shared a diagram, but it’s not a standard template, you’ll need to figure out the best analysis mode for your production environment.
2. Value
The product management process is a commitment to a customer to solve a problem, but not necessarily a specific solution. We tend to figure out how to get something done, rather than just getting the desired result; we orient ourselves by identifying exactly what needs to be done, rather than figuring out how to get there. Product managers often don’t know the solution explicitly — instead, they help the customer team, prioritizing the most deserving problems to solve, and helping them choose the least expensive but most rewarding solution — in the process if they can find a better solution. A good, simple solution is what we are most happy about.
Value (usually demonstrated in the results achieved for our customers and our organization) is where a good product roadmap is born and is at the heart of product management. Your product roadmap must be driven by the following assumptions that improve product value:
- We believe that for “this set of initiatives” and “this input” by [such persons],
- will obtain [such results],
- We know that [when we see this “signal”, we succeed].
3. Product delivery
Focusing solely on product features, cost components, and delivery dates is one of the most prominent negative examples of product roadmaps. A document laying out solutions by the deadline cannot be called a product roadmap, at best a product delivery schedule, or a project plan — these are very useful in high-certainty, slow-moving situations, but Not suitable for most products development teams. Such an approach is a classic product delivery misunderstanding: focusing on delivering product functionality without focusing on creating value for our customers and the organization.
But then again, product delivery is indeed a very important part of the overall strategy, so there is a strong need to take it into account in the construction of our product roadmap:
- If you are dealing with an expiring contract and most of the team is on vacation or having difficulty researching the user side, you may need to adjust your value strategy based on the actual situation.
- If you don’t want your product roadmap to only reflect the functionality that will be implemented, consider using “use cases” in your product roadmap to illustrate some specific technical details. For example, a few years ago, my team used this approach to find the critical path to implementing a foundational tool for selective analysis, while allowing us to limit the timing of the analysis. Also, using product roadmaps can help us understand the various scenarios we might encounter and the possible subsequent impacts.
Giving product details in a product roadmap has a deeper meaning: that such a product roadmap serves as a strategic shared resource that can be used by all departments (not just product managers). For example, in the basic tool development case I mentioned earlier, the users of the product roadmap include me (product/value), delivery manager (workflow), and web-side developers (technical solutions). As a shared strategic space, the product roadmap can integrate resources from all aspects around the overall strategy.
4. Confidence
The measure of confidence is a powerful tool for discussing options and determining management expectations. Any product roadmap, and any team, should be mature enough to recognize and discuss deadlines, financial constraints, and outcomes —and any management team should be mature enough to understand and discuss the confidence element in the plan, as well as our Understand the need to deepen transformation.
Confidence can also help answer: “How far should I set my product roadmap?” If you set a confidence threshold well below the value you plan to create, then once that threshold is reached and exceeded, your product roadmap no longer creates value.
Confidence can be affected by many factors, especially related to a specific environment, but we can present it in a simple way – as shown in this concise diagram below, but I have also noticed recently that some colleagues also use standardized red, Amber, green, etc. rating methods to help manage expectations.
5. Stage
After reading Product Roadmaps Relaunched, I made one of the simplest and most useful additions to my product roadmap, the “latest update” section, which revisits as we need its Frequency of strategy (and product roadmap, of course), reset expectations. If after three months, your product roadmap shows only 20% of your confidence, and you haven’t revisited and updated it for more than four months, then it’s likely that the product roadmap is useless.
Personally, I tend to revisit my product roadmap every month (although sometimes just to make sure everything is working well to gain confidence), and a more deliberate review every quarter.
