Product roadmaps can be a graveyard of ideas. They're often static, fixed, and solution-orientated – rather than problem-orientated. Yet, they don’t have to be this way.
For this article, we put together the heads of Arjen Harris, Head of Product at Maze, Stefan Sabev, Director of Product Management at Productboard, and our very own Pulkit Agrawal to de-zombify product roadmaps, bring them to life and guide you in building roadmaps that are as flexible as they are useful.
What is a product roadmap?
A product roadmap is a holistic visual document that outlines your product’s growth path. A stellar product roadmap template includes release features, key dates, product updates, and the product vision. It also sheds light on your product’s business vision and product strategy – giving context to the product life cycle.
The goal of an agile product roadmap is to align all product stakeholders (including customers). Your product roadmap will allow your team to better prepare for the future by accurately enabling you to predict business growth and resource needs.
The traditional product roadmap
Product development teams are beginning to move away from ‘traditional’ product roadmap templates. Ultimately, product teams spend a lot of time building and writing product roadmaps, just for them to turn into a document that’s tucked away and never looked at again. Or, teams go to the other end of the spectrum and stick to roadmaps word for word – stifling product creativity and agile product growth.
The ‘traditional’ product roadmap example we talk about here is also known as a static roadmap. Meaning it doesn’t adapt to changing markets, customer needs, technology, and SaaS competition. For as verse and flexible product people are with remote work, product roadmaps continue to be a struggle for distributed teams.
A remote environment often doesn’t allow the amount of context an internal product roadmap release needs. It means many development teams, and even customers, are often greeted with a list of features and dates and are expected to understand the strategy behind them. In reality, these types of product roadmaps bring next to no value to anyone beyond the teams that created them.
Let’s explore why traditional roadmaps fail before moving on to how you can stop that from happening.
Why traditional roadmaps fail
There are a few reasons why traditional product roadmaps fail; you may recognize a few of these scenarios arising within your product team.
The reason why static product roadmaps fail is that as soon as you create them, they’re already out of date. It takes an enormous amount of overhead for every PM in the organization to keep them up to date, to ensure the content is ready, to answer questions, and basically keep everyone up to date with developments. They’re not suited for the modern age.
1. Product solutions rule
Product solutions become a fixation rather than the problem they are trying to solve. In these cases, product teams lose their way by sticking to one solution and how that solution is going to work, rather than assessing the problem first and the solution technology second.
2. They're too set in stone
Some product roadmap templates are often treated as unchanging documents; a ‘their way is the only way’ mentality. This gets 10x’d when you discover ten more versions of said roadmap floating about the business—which is often the case when building a roadmap offline and not on a shared workspace. Product roadmaps need to be dynamic, flexible, and central to a business knowledge hub.
3. Traditional roadmaps are short-sighted
Product roadmaps fail when they focus on the near-future and immediate business needs—neglecting the big-picture and product growth strategy.
4. They focus on superficial needs
Failed product roadmaps tend to focus on the needs or priorities that internal stakeholders place on the product. For example, product development teams may prioritize shipping multiple features. Leadership may be focussing on activation goals, while everyone forgets about the customers’ needs. Or, the sales team may focus on “trophy” features that are appealing when selling a product but not actually what the customer needs.
With a classic product roadmap, new features are the holy grail; they often determine how successful the map is. But, customers don’t care about how many features you’ve shipped; they care about how many problems you’ve resolved.
When product roadmaps are customer-centric, that’s when they’re a success.
5. Roadmaps are over-ambitious
This is a touchy subject for product roadmaps and can be the downfall of not only a product’s success but an entire team’s success.
Over-ambitious roadmaps are built with great intent but are often unrealistic. They lead to disappointment and relationship breakdown between teams, departments, and external contractors.
6. They don't expect the unexpected
You’re thinking it, we’re thinking it, so we’re going to go ahead and say it; COVID-19. The pandemic brought a huge amount of unpredictability to our product growth climate. We witnessed new features and entire pivots that we never saw coming from some big SaaS brands.
Build product roadmaps with plan Bs through to Zs. No matter what the situation, you should have a way for continual product-led growth.
7. Victims to loud voices
Internal influencers can be hard to argue against when it comes to a product build. Product roadmap failure is no stranger to being built by the loudest people in the room and how they feel something should be, rather than being built by validation and data.
It’s especially a case with remote working – key inputs of those not physically in the room or as comfortable speaking out online get lost.
The lean, feedback-driven product roadmap
Doom, gloom, and zombies aside. Let’s get on to modern road maps and product roadmap templates that are a better fit for product teams of today and tomorrow.
Modern roadmaps are flexible; they are agile, they do yoga. These types of strategic roadmaps have the potential to be so valuable. They start with users; the problems those users face and validate every step along the way.
Flexibility is key. A roadmap can be constraining and lead you to become a feature factory. You want a roadmap to have the flexibility to enable you to change your mind. Changing your mind can be a really good thing. It means you’ve learned something new. When we change our minds, we build better products.
How to validate your user problems
Validate problems first, but remember these are not your problems. Your perspective is very different from the customers’.
Add strategic constraints to validating your problems. Problems are everywhere, and if you try to solve them all at once, you end up building random feature sets that don’t thematically align and drastically hinder your ability to deliver massive customer value. Your answer to this is building a theme-based roadmap, which we’ll discuss a little later.
Validation is about understanding the relative value from the customer perspective. We want to calculate ROI. The top of our equation should be value from a customer perspective. The bottom of our equation should be the cost from a business perspective. In turn, we prioritize depending on ROI.
So, how can you go about validating user problems?
1. Collect baseline effort scores
Use Microsurveys to collect user feedback on features and product flow. Is there a problem with something a customer is currently using? This will help to validate your hypothesis of a problem.
2. Product-market fit assessments
Using the Sean Ellis methodology, ask your users:
“How would you feel if you could no longer use this product?”
If you’re not getting at least 40% of customer feedback saying they would be “very disappointed” to no longer be able to use your product, then you have yet to find your product-market fit – you have yet to find your problem.
Use this methodology on a feature level, too, so you can understand if your solution is accurately solving the problem or if there’s another problem you need to solve at play.
Surveys are a product manager’s secret weapon.
3. Let users request and vote up features
If you have an engaged customer base, letting customers prioritize problems for you is a great way to go.
List everything you think is a problem, and ask customers to upvote them. It’s also a good idea to give customers the option to submit their own problem with this method too, so you cover everything.
Validate your feature ideas with a voting system – like Productboard's Portal
4. Collect in-app passive feedback
Give users an ongoing opportunity to provide in-app feedback and suggest problems with current solutions. Or problems that have emerged along the way.
You can get a little more specific here. If you release a problematic feature or think a particular page needs improving but are unsure where to start, qualitative data can shine some light.
At Productboard, we’ll start with surveys and will effectively work our way with quantitative data to see if a problem is manifesting as much as we think it is. From there, we’ll go into the more qualitative approach of recruiting a few users and speaking with them about the issue they’ve had. We’ll see what they would like a solution to be. Try to work with either prospects or customers to narrow that problem definition down and ensure you’re not taking on something that’s not too big or too ill-defined.
How to validate your product solutions
Once you’ve got your validated problems, it’s time to start creating solutions. A product manager can do this in many ways but often falls victim to Groupthink. Groupthink builds hype behind an idea, which is great, but that’s not the only thing an idea needs.
The trick you’re aiming for with your solution is to ship right, not fast, and Groupthink hype can lead to shipping fast without proper solution validation.
The question you want to answer is: What tangible evidence do we have that the problem is solved if we implement this feature/product/design?
We can hear your cries. ‘But, why is validating solutions so important? We’ve already validated the problem; why do we need to validate the next step? We already know what needs to be done.’
Well, research shows that 50% of developers’ time is spent on rework, and the cost of fixing UX problems post-release is 100X. These aren’t numbers we can afford to contribute to, and pre-code solution validation helps us steer clear of them.
So let’s look at five ways you can validate a potential solution.
1. The confidence wheel
(Source)
The confidence wheel shows you the levels of confidence you can have given the evidence you collect. The wheel includes everything from an external expert or investor (very low) to A/B experiments and launch data (medium-high).
This method allows your team to eradicate those HiPPOs (Highest Paid Person’s Opinion) 🦛. Meaning the highest-paid person in the room can no longer out-trump juniors with ‘feelings’ – they too must abide by the confidence scale.
2. Test, test, test and de-risk
The four risks, inspired by Marty Cagan's book, Inspired, are:
Useable
Valuable
Feasible
Viable
When it comes to pre-code testing, you want to find out if your solution is usable and valuable. A solution survey is a simple and effective way of minimizing your launch risk. Ask users:
“How valuable would it be if you could <input solution idea>?”
Allow for multiple choice answers:
Not so valuable
Relatively valuable
Extremely valuable
This method is low-lift, high reward: exactly what you want to be shooting for at this point in product roadmapping. You can also consider a Likert Scale or the $100 test for similar results💡
3. Fake door or landing page tests
Add a button or a segway into your hypothesized solution within your product. In reality, the feature is not there, but you’ll be able to see the users’ intent for that feature by determining the number of clicks.
You can take this research method a step further with a Microsurvey to get even more data.
Top tip: This is not a simple research method, as you’ll likely need some developer resources to get it done. However, at Chameleon, we’ve got a way around doing this with zero code!
Creating a fake door test with Chameleon
4. Prototype testing
This is the perfect moment to check the usability risk of your solution. However, it will need context and a dedicated audience to run your prototype test with.
Don’t let fidelity stand in the way of prototype testing. Go to low-fidelity first until you’re ready for high-fidelity. We did some cool things with low-fidelity prototypes at N26. We had people come into the office and placed them into teams on different tables. Each team looked at a paper prototype. Each piece of paper was a UI feature, and it led to some really interesting results.
5. Design sprints
Design sprints tend to encompass all of the steps you need to take to validate solutions accurately. However, if poorly planned, they’ll be poorly executed, leading to a frustrated and exhausted product team.
If you want your design sprint to succeed, then plan well, ask yourself the right questions, and set achievable product goals. In retrospect, it’s not much of a sprint at all; think The Tortoise and the Hare.
(Source)
That’s validation in the bag. Hopefully, you’ve gained some resources and insights into how to accurately validate problems and solutions that will save your entire team hours of work post-release.
Next? Product roadmap examples, and which one is best for you.
Want more on validating solutions and ideas?
Grab a coffee and your notepad – this on-demand webinar is full of examples.
Types of flexible product roadmaps
There are different types of product roadmaps out there, and if you start with one of these product roadmap examples in mind, you’re already setting yourself up for a better chance at success with product growth than with a static roadmap.
Status-oriented roadmap
Now, next, later. A status-oriented product roadmap is flexible and doesn’t stick deadlines in concrete. It’s great for aligning internal teams on what everyone is working on, as well as what’s potentially coming up in the future.
One of the key features of a status-oriented roadmap is that ‘next’ and ‘later’ sections can adapt and shift around as your product and data evolve. It means you avoid getting stuck on one map that may no longer be a fit for growth—given unaccounted for catalysts.
A status-oriented roadmap is usually comprised of three columns, you guessed it, now, next, and later; or Backlog, Planned and In Progress. Most project management tools have the capacity for you to create a simple status-oriented roadmap, as Productboard does.
Theme-oriented roadmap
Theme-orientated roadmap templates are fantastic for staying on problem tracks. For example, if you’ve validated a problem for your users like: “unclear analytics tools,” your theme-oriented roadmap will be: “create a better analytics experience.”
Your theme-oriented product roadmap can last for any time. Usually, it runs for a quarter, but it can run for two quarters, perhaps even an entire year.
What’s great about it? Well, number one: it’s flexible. It doesn’t lock you into new features you have to build—becoming a feature factory—it locks you into validated problems. This is a good thing.
Secondly, it ensures you prioritize according to user needs. Your product team doesn’t get side-tracked by the loudest voice in the room.
Outcome-oriented roadmap
External stakeholders tend to favor outcome-orientated roadmaps. They are goal-driven but not solution-orientated—which is a good thing! Outcome-oriented roadmaps tend to focus on a quantitative goal. For example, “improve analytics feature use by 15%.”
By working towards a goal, the product team is flexible and given autonomy to reach that goal. It means they stay on track, prioritize accordingly, and achieve a metric that everyone is happy with by the end of the roadmap.
Now that you’ve locked down the roadmap template that will work best for you and your product team let’s get into some best practices to remember along the way.
Best practices for building a successful product roadmap
Building successful product roadmaps is a skill. It takes patience, experience, and it certainly takes a few bumps in the road along the way. However, we’ve experienced a lot, as have our experts from Maze and Productboard. So, here are our collective seven best practices for building a successful roadmap.
Get buy-in from the beginning
First and foremost, you’re going to need to get people on board with your roadmap. Not only leadership but everyone responsible for product roadmap research inputs – and ultimately your product’s success.
Ensure every team knows the importance of building a product roadmap and what you as a collective can achieve with it. Explain how you’re not building a static doc that will sit on the sidelines; you’re building a flexible set of rules to help guide your product growth.
Define success
What does a successful roadmap look like, and in turn, what will a successful product look like? Here’s how Stefan defines success at Productboard:
Define how every item in your product roadmap relates to your business objectives and business goals, and define how it relates to your customers’ needs.
Once you have that clear base, you should put together a process to understand how those things relate to each other and start gathering input from various stakeholders across the organization.
Ensure you have a good process for collecting feedback so that you don’t end up prioritizing things that are top of mind for people recently (recency bias).
Have a clearly defined prioritization process to align everyone on how decisions are being made.
Empower people to participate, give everyone a place they can be heard.
Bring it all back to the customer to ensure that you’re making things clear and aligning everyone on why they are here and what you’re trying to achieve – avoiding HiPPO take over.
Lastly, iterate quickly to ensure you’re testing your assumptions, getting as much evidence as possible.
Focus on the product roadmap’s outcomes
This step is exemplified best with a theme-oriented or outcome-oriented agile product roadmap. What problems are you trying to fix, and what goals do you need to achieve to fix those problems?
Focusing on the outcomes of the roadmap ensures the roadmapping process stays on track, is quantitative, data-driven, and you can prove your release plan is a success further down the line.
Don’t overcomplicate things
Lean in, let’s KISS. Keep It Simple, Stupid.
Your product roadmap doesn’t need to be, and shouldn’t be, pages and pages long. It’s a practical, working document, and we want our team to read it, reference it, and learn from it. It’s critical to keep our roadmap simple.
‘But what about my research? What do I do with all of these fantastic customer insights?’
This is when you’re mixing a product roadmap with a product backlog. Your product backlog stores all of your research and the nitty-gritty behind customer problems and potential solutions.
Your agile product roadmap is “team-facing” – if someone needs more context, they can click-through to the backlog and dive deeper into the data, but let your roadmap provide a holistic overview.
Know when to say no
It’s easier said than done. Hopefully, this guide has provided you with a few diplomatic ways you can say no. Use problem validation tools like the confidence wheel and various quantitative data inputs to back a hypothesis. If there are any HiPPOs charging in with their own hypothesis, ensure they back it up with data as well.
When it comes to validation, everyone in the company is equal.
Set clear and manageable timelines
A big fail of static roadmaps is deadlines that are too ambitious. They may look great on paper, but are they realistic? Understand the problem you’re trying to fix with the solution you’re trying to build and the resources you need to get there.
Take everything into account, and add a pinch of salt. You’ll manage expectations better and keep everyone happy.
Psst. There’s also no shame in bumping deadlines. They’re great goals to have but release right the first time and save your developers hours of time and your business unnecessary costs post-release.
Don’t treat your roadmap as a static object
We’ll say it louder for the people in the back. Static roadmaps fail.
Don’t treat your roadmap as though it’s set in stone. This doesn’t mean to say you have to constantly be editing your roadmap and updating it with learning manually.
Find ways to automate updates – Productboard can help with that. Plus, the way you build your roadmap can ensure it adapts as your business does: status-oriented, theme-oriented, outcome-oriented roadmaps are all flexible roadmaps. Pick one that works for you.
Tools for roadmapping success
There are some great roadmapping software tools out there to help you get the job done. We’ve mentioned a few of them throughout this article, but here’s a collection of our top tools for roadmapping.
Chameleon: in-product Microsurveys
Chameleon’s in-product surveys can help you validate problems and solutions. Use modal pop-ups and micro-surveys for further questioning on false door tests.
Maze: rapid testing
Got your prototype and ready to test it out with a relevant demographic? Maze is your go-to for all stages of prototype testing.
Productboard: visual roadmapping
Your go-to tool for visual roadmapping examples and total product management system to ensure that you are building better products informed by customer feedback and evidence.
Typeform: deeper surveys
If you’re looking to get more in-depth qualitative data from your customers, Typeform is a great option to send out customer feedback surveys.
Figma: prototyping
Building prototypes doesn’t need to be a chore, especially low-fidelity prototypes. Figma is a collaborative UI tool that’s perfect for remote product teams.
Demio: live usability sessions
There’s a high chance you’ve used video conferences already. But have you considered it for usability sessions? Try Demio out – it's a delight for users!
Amplitude: find problems in the funnel
Turn customer insights into actionable data. Identify drop-offs in the customer funnel and figure out what’s going from a customer’s perspective.
Go build that flexible roadmap
That’s it; we made it, we survived the roadmap apocalypse. Roadmaps don’t need to be zombies that are dragging your product team down. Roadmaps can be a beautiful, flexible, and agile tool that lifts your product team from one level to the next.
Hopefully, this guide has given you everything you need to bring your product roadmap to life and have it prosper not only for your product team but company-wide.
We’d like to extend a special thanks to our contributors for this article: Arjen of Maze, Stefan of Productboard, and Pulkit. We hope their knowledge helps you map many a product road to come, and it’s a road that twists, turns, and builds bridges to help you get to where your customers need you to be.
Share your product roadmap tips!
Use the hashtag #BetterRoadmaps on Twitter – we'll add our favorites to the article
