Building a quality product requires some solid preparation. It’s good to mark the progress and keep all interested parties up-to-date throughout the whole process. Once the product is complete, we can look back and reassess what threats or errors delayed the work. That’s the reason why so many companies rely on a product roadmap – a neat visual aid that highlights the progress of your work.
What is a product roadmap?
Simply put, it’s a diagram that allows you to track your planned work and its progress. As Atlassian describes it – a product roadmap is a shared source of truth that outlines the vision, direction, priorities, and progress of a product over time. It’s a plan of action that aligns the organization around short and long-term goals for the product or project, and how they will be achieved.
Moreover, the roadmap presents why and how all of its elements are linked, connected, and interdependent, and how they influence the strategy. The roadmap should be flexible enough to respond to market, clients, and stakeholders’ needs. It’s popular among product owners, who use it to keep the team members up to date on the work progress.
What different types of product roadmaps do exist?
Naturally, there are many different types of roadmaps, determined mostly by the priorities or preferred indicators. One product owner will look for far-distance outcomes and vision, while the other will be interested in specific metrics that should improve in, say, the next two quarters.
The most popular product roadmaps are:
- Market & Strategy – long term, represents the potential markets you might want to enter in the next few years, and the way you can build products suitable for these markets, either by in-house production or by acquisition.
- The product roadmap for internal and external use – represents the main and a few secondary features of the product. The internal roadmap helps team members, board and stakeholders align with the goals. Meanwhile, the external roadmap can be presented to the press or investors. It should rely on the internal one, but also be vaguer to avoid any reneged promises or features.
- Vision – roadmap based on vision represents the bigger picture – how the company fits into industry and how it will succeed in it.
- Platform – presents the platform and software used in a specific time period and any potential change to them within time.
- Technology – another more broad-type roadmap, it follows the overall trends of used technology in the industry and potential changes in order to better align the company with these trends.
- Based on the outcome – want to please the stakeholders? Prepare a roadmap that presents the outcomes of your team’s work. Stakeholders mostly care about what is done, instead of how it’s done, so your team has freedom in working on this solution.
Why are product roadmaps important?
Based on different types of roadmaps, this is the list of their main advantages:
- Show stakeholders what we want to achieve.
- Keep interested parties up-to-date with progress.
- Allow to plan ahead and pivot in case of circumstances, trends, or vision change.
- Helpful for non-technical users, as they ditch the technical language in favor of more accessible content.
- Unify the communication and can serve as a Single Source of Truth (SSoT).
What happens when you don’t have a roadmap? Well, be prepared to:
- confuse developers
- upset the stakeholders
- confuse the team with a lack of goal and vision
- derail your product and your team’s work from the beginning.
Who are roadmaps for?
It depends on whom you prepare them. You can create one roadmap for all parties (team, developers, stakeholders) that serves as an internal Single Source of Truth. Then you can edit it and use it for external communication too. When creating a roadmap, it’s important to remember that it may be the key to helping people understand what the product is, and what your goals as a Product Owner are.
Who is responsible for the product roadmap?
The driving force behind the roadmap is the Product Manager (PM). He or she coordinates the actions, plans ahead, and moderates the discussion about roadmap items and strategy. Product Owner connects PM’s with developers and team members by breaking down goals and vision into executable chunks of work (like Story Points). Developers and Stakeholders may give necessary insights based on their position (especially from the Developer’s perspective). Meanwhile, the Stakeholders approve the budget, as well as the overall vision.
What should a product roadmap include?
According to the Product Manager, the key elements of every roadmap are:
- Product Vision – what it should look like, its features, and potential. Importantly, it’s not the endgame, but rather a direction in which we want to develop the product.
- Strategy – like with internal and external roadmap, you must explain the goals, stakes, and business value to stakeholders and developers. The strategy allows keeping consistency with the aforementioned vision.
- Requirements – the necessary steps needed to achieve the set goals. Usually preceded with market and customer research, to know what features are necessary, welcomed, or non-important.
- Product Plan – putting specific time periods, items, and workload on a roadmap.
- Markers – to highlight potential milestones and achieve tasks. Doesn’t have to be an exact date, but it will allow stakeholders to know when they can expect a certain feature to be done.
- Metrics – there are many of them, but every party should operate one specific metric. Standardised metric keeps everyone up-to-date and makes communication much easier.
How to create a product roadmap?
Sure, we could describe it step by step, but to spice things up, let’s use some visual aid:
How to add multiple products to your roadmap?
In the management world, it’s not that unusual to put all eggs in one basket. The challenge is to keep them away from sharing a Humpty Dumpty’s fate. The best solution is to keep multiple products under control and up to date with proper management tools. Using Jira to handle task management? Great, then try BigPicture!
BigPicture’s Roadmap will help you set goals for all your undertakings—projects, products, programs, portfolios, PIs, iterations, and others. It comes in handy for classic as well as hybrid approaches and is SAFe®-compliant. Its practical drill-down feature allows you to see an entire undertaking, or zoom in to its specific phase. BigPicture enables you to define your Objectives’ Planned Business Value and select what brings maximum benefit, set big and small objectives for your teams: from low-level initiatives to high-level undertakings and high-level Agile roadmaps with Gantt module. You can also track the progress of your objectives, determine their business value, and monitor how many of your goals have been attained.
How to define success metrics and KPIs for the initiatives in the product roadmap?
All the metrics are data-based. We should remember that before we choose them mostly because some data is more important than others. A number of followers, likes, or views are sometimes described as “vanity metrics”. Meaning they lack any substance, are not nuanced enough, and can be pretty misleading. No wonder they are often used as a PR trick.
- Customer-oriented metrics:
- Net Promoter Score (NPS)
- Retention Rate
- Bounce rate
- Churn Rate
- Customer Lifetime Value
- Average Revenue Per Account (ARPA)
- Business-oriented metrics:
- Sales Revenue
- Customer Acquisition Cost (CAC)
- Monthly Recurring Revenue (MMR)
- Cash Burn Rate (CBR)
- Customer Acquisition Cost (CAC)
- Net Profit Margin
How to prioritize the product roadmap?
Actually, we have prepared a whole article about backlog prioritization. The methods we described there are transferable to the roadmap prioritization too. Also, according to the FullStory, there are four different ways to prioritize your product roadmap:
- User feedback and behavior – asking and learning from customer feedback, its opinion, and behavior.
- Value vs. Complexity – this model is gaining much popularity these days. Its basis is to define the business value of each task/initiative, and the potential amount of work/complexity of these elements. We can compare it to the Impact Effort Matrix, where the high-impact tasks requiring the low-effort are a low-hanging fruit, while the low-effort and the low-impact tasks are described as work for the sake of work.
- MoSCoW Method – the principle is simple, we create four categories and assign tasks to them. The categories are:
- Must-Have – absolutely needed and expected features,
- Should Have – important, but not the vital addition that may create extra value to the product,
- Could Have – good to have, but not necessary, especially if generates extra cost,
- Won’t Have – unimportant, the status of such tasks might change later.
- Story Mapping – used to define tests on new products. This way teams can gain maximum knowledge with the minimum effort. It visualizes product backlog.
How to plan security and technical debt on your roadmap?
All debts, especially the technical ones, must be paid. This specific kind of debt appears when you choose shortcuts. Later, you have to pay with time, money, and resources, typically for choosing speed over quality. How to tackle these sensitive and unavoidable issues? Buyan Thyagarajan, Salesforce MVP specialising in Salesforce CRM and Marketing Automation has three tips:
- If you are an agile team, have a technical debt story to be tackled in a quarter. Now you may not get to all the debt but minimize it to core objects which can be handled in a sprint and slowly level it till it’s done.
- Have technical debts in the fourth quarter, where business winds down, and have them completed at that time.
- Leverage your vendors to do the technical debt instead of your employees. The reason is sometimes your admins and architect can focus on the regular needs of your business and your vendors can do the technical debt independently and get it done with minimal supervision. So the bottom line is cadence on technical debt, resources to tackle them, and go at it in small chunks to solve future leaks.
How to present a product roadmap to get the buy-in?
- Substance over style – it’s important to impress people, but don’t use smoke, mirrors, and fancy buzzwords. Instead, focus on key features, time frames, budgeting, and advantages.
- Keep it real – again, promising the moon sounds fun and all, but it can easily backfire at the end when you’re at the stage of creating paper planes. Make bold, but realistic plans that can be executable or at least extended in time.
- Set the proper context – it’s easy to create a roadmap, put some stuff on it, show it to developers, and make them work. Of course, this is a recipe for a total disaster of a product. Instead, think about why you are making a roadmap – what’s important? What do we want to accomplish? How much time do we have? What are the key features? Context is a crucial thing.
- From zero to hero – set one big, but an approachable goal, and divide it into smaller initiatives. Your team will work on them and one by one get closer to achieving them. Remember, tasks, stories, and initiatives are your friends. Leaping to one big thing can fail.
- Keep it open-minded – roadmap is crucial for your plan, but it’s not Ten Commandments and you are not Moses. Meaning, that it can be edited or verified with your team. Listening is part of a PM or PO job – when team members have doubts or hesitate with some aspects of the roadmap, it’s worth listening to what they have to say.
What are product roadmap examples?
Wonder what your roadmap should look like? Let’s check out some examples:
Product roadmap best practices:
- Have a set vision of what you want to achieve.
- Don’t be afraid to think big, be prepared for small steps.
- Think of outcomes, not features.
- Set realistic periods to achieve milestones.
- Prepare different roadmaps for different parties…
- … But base them on the same data, to keep SSoT intact.
- Communicate with your team.
- Keep the Stakeholders up-to-date.
- Don’t be afraid to edit or change the roadmap – it’s better to remove or postpone some items, than force people to crunch.
- Keep your eyes on industry trends and customers’ needs – obsolete products on arrival are basically dead.
How will your roadmap evolve as your product matures?
As your product is finally out, the roadmap will evolve with it. A roadmap is a sign of your strategy, the direction you and your team want to follow. It can change in time. However, it must be flexible to do that, as at this stage it has evolved and probably contains more than one product. If you’ve kept your hand on a pulse, then every stakeholder and developer knows what and how will be done next and what are the time frames to achieve specific milestones. Mature product means proven, or even best practices.
These are the key aspects of every product roadmap. With that in mind, you can easily create a visual aid that will help you achieve both clarities of your vision, as well as describe steps and means for every interested party, that will help you achieve your goal.
How can BigPicture help you with your product roadmap?
If you’re looking for a tool to help you prepare a visually neat and complex roadmap, search no longer – BigPicture is a great solution for Jira roadmap. It’s a versatile Project Portfolio Management app for short- and long-term planning. Importantly, BigPicture serves both agile and waterfall projects, has a number of proven and modern PM modules, and seamlessly integrates with Jira. Interested? Try BigPicture and talk to our experts about the benefits of our software.