How to create a product roadmap: 8 step process
In most tech companies, you will hear the term "product roadmap" tossed around regularly. Roadmaps are the holy-grail of strategic documents every product team wants to perfect. This article unpacks what it takes to build an impactful product roadmap by treating it like an investment plan instead of a traditional list of features to build.
What is a product roadmap?
A product roadmap is a strategic plan that seeks to unite various, and most often cross-functional stakeholders towards the shared objective of building a better, user friendly, commercially successful product.
👉 Product roadmaps are the domain of product managers, as they are the ones responsible for the product's success.
Why do we need product roadmaps?
A product roadmap tells the story of where the product is going, typically over the period of a year. A product team may however, choose not to work on some of the things in a roadmap if it doesn't make sense anymore.
When product teams work on product features or new products, they almost always work with cross-functional teams to make it happen. Common stakeholders include:
Its not uncommon to have a product feature that involves sometimes hundreds of people or even the entire business.
👉 Given that product features can have a significant impact to an organisation, it is vital to ensure that stakeholders are aligned so that they can support the roll out of that feature.
Roadmaps most often don't deliver value
A typical product roadmap looks like a bunch of features grouped together by a common theme, such as "Mobile App", "User Onboarding", "Customer Retention", etc. However, there are a few pitfalls of this approach:
❌ Presents a delivery oriented view of what you're trying to achieve: Less product more project management, although ensuring delivery of product features is a key requirement of the product manager's role, it is not the thing product teams are rewarded for.
❌ Commercial value is not obvious: It is hard to understand the commercial value attached to themes such as "Mobile Apps" or "User Onboarding" etc.
❌ Hard to present in senior leadership teams: Discussions tend to become very granular, as commercial upside gets debated.
❌ Not based on strategy: Most importantly, often product roadmaps aren't based on company/product strategy. Product teams get caught in the "feature bloat" trap, and start catering to small segments of customers in order to keep them onboard.
✅ Instead a technique I prefer to use is treating roadmaps as an investment plan.
8 step process for creating a product roadmap ⚙️
At a high level, the 8 steps for creating a product roadmap using this approach are:
- Start with the product strategy by reviewing it if it exists, or create one if it doesn't. A product roadmap without a product strategy is akin to implementing random ideas.
- Set your goals. Set goals that allow you to execute on your product strategy.
- Ensure you have resources. Its great to have goals and a plan, but don't bite off more than you can chew.
- Gather your ideas. Ask yourself, what product features or improvements could help you achieve the goals you have set?
- Pick your winners. Based on the list you came up with, choose the most important ones that create most value.
- Consider the trade offs. Evaluate all angles of your initiatives, including secondary metrics to ensure there is a net commercial gain.
- Put it together by working out any dependencies or prerequisites that can create roadblocks, and then finally visualise your roadmap using your choice of tool (Google Slides work great, and is free! There's also a free template in this resources section of this article.)
- Repeat and revise by incorporating your learnings into your product roadmap as you ship features
Step 1: Start with the product strategy
It's important to have a product strategy, needless to say this should always be driven by company strategy. Your leadership team needs to be aligned on company strategy so you can create an effective product strategy. Product strategy is a topic on its own and I won't discuss much more about it here.
👉 If something doesn't align with your product strategy, it doesn't belong on your product roadmap ➡️ 🗑️.
Step 2: Set your goals
"If you don’t know where you are going, you will probably end up somewhere else." —Lawrence J. Peter
Your company goals are a reflection of your business strategy. Depending on your company's planning process, you would ideally have a number of yearly goals you want to achieve as a business. If one of the business goals is to "grow monthly active users to 20,000" then the product impact of this goal needs to be evaluated and your product team needs to have one or more product goals in order to achieve this.
If you pick apart this goal, you could decide that you need to do two things to achieve this goal:
- Convert more prospects who land on your signup form
- Offer a pay-as-you-go pricing tier
In a nutshell these become your product goals, you could state them in a simpler manner such as: "Convert more prospects" and "Pay-as-you-go pricing".
👉 Repeat this exercise until all your goals are covered by one or more product goals.
Step 3: Ensure you have resources
Part of building an investment plan is to review your investment capacity. Similarly, here you need to review your investment capacity in terms of engineering, product and design resources. A critical mistake is not taking into account what your team can actually deliver before coming up with a roadmap. Unless your roadmap is an exercise to ask for more resources, it is imperative you figure out delivery capacity at least at a high level.
Always factor in BAU, time off and unproductive time when thinking through team capacity. Optimistically speaking, between BAU tasks (including bugs and paying down technical debt), agile ceremonies and other meetings, an engineering team can only spend about 65% of their time delivering new features or products. It's a similar story when it comes to product managers and designers. Your mileage may vary depending on various factors such as tech stack complications, platform age and team maturity.
👉 Ideally you want to be in a position where you know the delivery capacity of your team based on t-shirt sizing.
Quick lesson: T-shirt sizing
Your team could define t-shirt sizes as: Small (1), Medium (2) and Large (3). If your team can deliver a maximum of 3 large features in a year, your team's delivery capacity is 9. This will come in handy when you start thinking through product features.
Step 4: Gather your ideas
Now you need to note down the ideas that will help you achieve your goals. Let's go by the earlier example: "Convert more users". You could decide that in order to achieve this, there's a few things you need to test and one change that is obvious, so you end up with the following product ideas:
- 3 A/B tests to optimise signup form
- Incorporate customer testimonials on the signup page
Do your best to incorporate how much value these features deliver, e.g. 3 A/B tests to optimise signup form, could be worth an additional 3,000 users (going off an increased conversion rate). Secondly you want to note down the t-shirt size (number) of this idea. And finally, you also want to calculate and note the commercial value, where possible, of the metric movement (e.g. 3,000 users could be worth $250,000 per year).
If the outcome you're trying to drive is not commercial, then use the north star metric of your product team (e.g. daily active users). I strongly recommend layering in secondary metrics that could be potentially impacted by a feature, e.g. % of users that repeat, NPS, pages per session etc.
👉 Repeat this exercise until you have covered all your product goals. I recommend doing this exercise in a spreadsheet as it is easy to make edits and filter (and you will be doing a lot of that).
Step 5: Pick your winners
Now that you have a list of potential product investments, it's time to figure out what you can actually achieve. Ideally you did the exercise in a spreadsheet as recommended, and if you did, simply sort your list of investments in descending order of commercial impact. Total up the t-shirt size estimates and see if this number is greater than your team's total capacity as determined earlier.
If your resourcing requirements exceed team capacity, then you need to consider dropping items from your list unless getting more resources is an option. It is unwise to think your team will achieve good results if you just cram something into the roadmap. Not only will that result in poor execution but potentially induce churn in the team.
“The difference between successful people and really successful people is that really successful people say no to almost everything." —Warren Buffet
👉 Pick your battles, it's more than likely 80% of the value you're looking for will be created by 20% of the features in your list.
Step 6: Consider the trade-offs
Going through the list of product investments, you need to consider trade-offs and risks as with any investment strategy. This is where your secondary metrics come in. You could have features that deliver a high ROI but have potential downsides.
Going off the earlier example, to optimise the signup form, lets say you removed a few fields which resulted in an increased conversion rate. However in doing so you didn't collect information that onboarded the user fully into your product. This resulted in a "less personal" first experience with your product, which in turn resulted in a higher churn rate. Although you did achieve the target commercial metric, you increased overall churn rate, taking your net commercial impact backwards. This is obviously a drastic example of a trade-off, however one that is quite possible in the real world.
Another thing to consider is idea alignment with product strategy. Product strategy is essentially a type of "guard rail" that prevents your product features from going off track and keeps you aligned to the company's vision. However, since product strategy is a fluid concept, you may often have ideas that are on the "fringes" of your product strategy, ideally you want to avoid these kind of ideas unless it makes great sense to reconsider product strategy and ultimately company strategy.
👉 After considering the trade-offs, you should whittle down your list and pick the features that are high impact and highly aligned to your product strategy.
Step 7: Put it together
If you're thinking that the above feels a bit like an accounting exercise, its important to highlight that commercials are very much a core part of product management. Ultimately everything you do should deliver commercial impact. And often measuring commercial impact is hard. For instance, if you're trying to improve the UX of a particular feature, you could measure impact on retention. With product features, try to get as close as possible to a commercial impact.
If you're wondering what to do about forward looking initiatives, for instance building platform and future proofing product reliability. This is where you apply resource rationing principles. You ideally want a 60-30-10 (%) split between investing in immediate growth, strategic plays and moon shots. Depending on the life stage of your product, this split may look different. For instance it is not unusual for early stage startups to be heavily geared towards immediate growth (90%). Ultimately the ratio you choose (or is chosen for you) will depend on various things, such as business maturity, company strategy and team size.
7a. Get the sequencing right
Once you're good with your list of initiatives, it's time to put them in order. At this point, you will usually have a few conflicts such as:
- Dependencies between initiatives where there is an order to be followed
- A resourcing bottleneck, where a team member is needed on two projects at the same time
- Business deadlines that you can't move, e.g. a marketing campaign that can't be shifted due to seasonality
👉 As a starting point you should ideally front load your product roadmap with the highest impact things and work with your stakeholders to align the dots.
Now you're ready to visualise your product roadmap in a timeline view that can be shared with your team and stakeholders. I prefer bucketing initiatives around business goals and product goals. Going off our earlier example, you could bring it together like this:
Grow users to 20,000
- Convert more users
- 3 A/B tests
- Incorporate customer testimonials
30% of MAUs on a subscription
- Pay-as-you-go pricing
- Payment gateway integration
- Invoicing system
- Customer on-boarding emails
You can see how the above cascades neatly from your business goals and allows any level of stakeholder to take away the point they're most interested in. For instance, your CEO may be interested in ensuring that you're supporting a key commercial goal whereas your engineers or designers might be more interested in the actual features they are building.
👉 For visualisation there are a few tools you can use that are designed for product roadmaps and general timeline style visualisations, however I find it is easiest to just use Google Slides.
Finally: Repeat and revise
Always remember to treat your product roadmap as a living document. You do not need to stick to a roadmap just because you came up with it. A roadmap is not a list of things you will deliver for certain but instead is an instrument for aligning stakeholders. When you learn new things or markets shift, your roadmap should be updated accordingly.
👉 Incorporate learnings from product features you ship, back into your roadmap.
Best practices for Product Roadmaps
Tailor your roadmap by audience
Remember your roadmap will be consumed by various different types of stakeholders with vastly different expectations. Each one of them will require a different level of detail, consider:
👉 An internal roadmap for executive leadership: This should be high level focused on the strategic initiatives that drive the overall goals and metrics for the business. These roadmaps can be presented in a quarterly view.
👉 An internal roadmap for the engineering team: This would contain a lot more detail, and more importantly show how all the dots connect together between different platforms, e.g. web vs app. Its common for these roadmaps to be more delivery focused, often presented in a monthly view.
👉 An internal roadmap for the sales team: This one is particularly important as it enables your sales team to sell to potentially future customer segments who may be particularly interested in upcoming features. This kind of a roadmap should indicate what customer segments features are targeted at. Its also important to note, that you should avoid communicating hard timelines in these kinds of roadmaps as you don't want to set expectations that may not be met due to unforeseen circumstances.
👉 An external or public roadmap: This kind of roadmap is for your customers so that they can see how the product will evolve. Its commonplace to find this in high-volume SaaS or platform type products where the customers are heavily invested in the product. Quite often these roadmaps can present a problem oriented view of the world so that customers understand how it will benefit them. And once again, avoid hard timelines in these kinds of roadmaps.
Emphasise the connection with strategy
A product roadmap shouldn't be treated like a collection of features and timelines; it's a strategic document that sets the course of the product in alignment with the company's broader vision. Every item on your roadmap should resonate with the overarching goals of the organisation. By emphasising this strategic alignment, you not only ensure that the product stays on course but also foster a deeper understanding and buy-in from all stakeholders, especially your executive leadership. A simple technique you can apply here: Use the same keywords or phrases that you find in your company strategy documents.
Detail vs. Clarity
Striking the right balance between detail and clarity is crucial. While it's tempting to include every minute detail about the product's future, it's essential to remember the audience. Overwhelming them with information can lead to confusion and disengagement. Instead, focus on providing just the right amount of detail that offers context without sacrificing clarity. A well-balanced roadmap is one where stakeholders can quickly grasp the product's direction and understand its key milestones. If you cannot tailor your roadmap by audience, then you need to find a way to strike this balance. Its often easier to create multiple roadmaps. I've found that Atlassian's Jira Product Discovery makes this really easy.
Regularly update your roadmap
I've said it before, but I'll say it once again. Your roadmap is useless without being a true living document. You're better off not creating a roadmap, rather than creating one that collects dust.
Make your roadmap responsive
Your roadmap must responsive to customer research/feedback, market & industry shifts, and also internal stakeholder feedback. While it can be frustrating to update a roadmap frequently, its unavoidable.
An alternative approach to this is to use the vision mapping technique which makes managing uncertainty a lot easier. This is a technique that I came up with when I first became a product leader. Its quite effective in startups where change happens regularly. I teach how to do it with examples in my Product Management Course.
Frequently asked questions about product roadmaps
I've captured some common questions I get from product managers about product roadmaps here.
q. What time period should my product roadmap cover?
Generally anything over a year is not recommended. Simply because we live in times when things change rapidly for most tech (and non-tech) businesses. Even within the span of a year it is not unusual to chop and change roadmaps when you learn new things.
q. Is estimating effort really important for a roadmap?
Yes, you should do this at a high level by applying t-shirt sizing principles.
q. How do I estimate effort when I'm not sure what the scope is?
Be clear about the problem each initiative solves and definitely have an idea of the scope a project would entail. An initiative without some sense of scope is a random idea and doesn't belong on your roadmap.
q. How important are timelines when creating product roadmaps?
Timelines are important. Although you may not necessarily do everything on a roadmap in a given year, a product roadmap without timelines is like a car without wheels, it goes nowhere. Although a product roadmap isn't a project plan, you can't expect to achieve alignment with stakeholders if you are unable to estimate the "shipping date" for a feature. Remember there are stakeholders beyond product and engineering that need to be bought in. Your sales, marketing and customer service teams may need to plan things on their end to support the rollout of a new feature.
q. What kind of initiatives belong on a product roadmap?
Small features and BAU don't belong on your roadmap. Remember, a product roadmap is thematic and is meant to paint the bigger picture. For instance, you wouldn't put something like, "make buttons bigger" on a roadmap, but you could have a theme like "User accessibility" which conveys the story behind what you're trying to achieve. The depth of initiatives for your product roadmap also depend on the level of responsibility you have. For instance, a VP of Product would probably have their own version of a roadmap that summarises the salient points of multiple more detailed product roadmaps that are maintained by individual product managers.
q. What are the characteristics of a good product roadmap?
Besides everything I've already discussed above, other things to keep in mind:
- Keep your roadmap easy to understand and free of jargon.
- Anyone in your business should be able to understand it. Avoid complex or internal names for initiatives, e.g. "Project Death Star" probably means little to anyone outside your team.
- Avoid clutter, if you need to add narrative to explain something, then you aren't conveying the headline properly
- Focus on the bigger picture rather than the feature level detail
- Always convey commercial upside where possible
q. Should I tailor my roadmap for different audiences?
Yes, you should. It's not uncommon to have several versions of a product roadmap depending on who the end user or stakeholder is. For instance your sales team may only be interested in high level directional detail and your engineering team might care deeply about the feature level detail.
q. How do I make an agile product roadmap?
The approach discussed in this article is actually agile. An agile roadmap is focused on the goal you're trying to achieve, and additionally incorporating your learnings from releases back into the roadmap.
q. Whats the difference between a product roadmap and a product backlog?
A product backlog is best described as a collection of ideas, potentially unvalidated, not completely aligned with your product strategy or just not important enough to be considered at the present point in time. A product roadmap on the other hand comes with a degree of commitment towards delivery.
q. How often should a product roadmap be updated?
Product roadmaps should be treated as living documents, don't let them collect dust. Update your roadmap as you learn new things. Put your roadmap at the forefront of your development and planning meetings. Print a copy, email it, share it with stakeholders on a regular basis.
If you have a question about product roadmaps you'd like me to address, get in touch.
Product Management Course
Learn advanced roadmapping with my new course on Product Management.Get the Course
Product Roadmap Template
Download the product roadmap template Google Sheet used in the example for this article.Download
8-step process for creating product roadmaps
Download the infographic from this article on 8 steps for creating a product roadmap.Download
Product Roadmap Tools
A curated list of tools for managing and visualising your product roadmap.View