Product managers often face a common struggle in the search for the ideal way to prioritize their ever-growing list of feature requests. Trying to reach a single, prioritized product roadmap is usually the goal but, to do so, many factors are weighed in, increasing the complexity of a task that should be simple.
Prioritizing is not an end and shouldn’t take you any more time than strictly necessary. Learning to prioritize is not your goal; it’s ultimately a means to reach your goal of delivering a product that has concrete value and use for your customers (after all, who wants to pay for a product/service that doesn’t come with aggregated value?).
Having a single, unified, and non-prioritized feature request list goes against the goal of delivering value; not knowing what’s important to your customer and focusing on that may cause you to bloat your products with features that don’t add any actual value. Your customer is the one giving you actual money for what you sell; if you end up making your product more complex than it needs to be and less usable, you’ll be doing nothing more than wasting precious development resources.
So, what is a product roadmap?
A product roadmap is no more than a plan to make your short and long-term business goals match, using specific tech solutions to help you meet those goals. This plan can be applied to the products/services you already offer, as well as to new ones. Building a product roadmap is often referred to as “road mapping”.
A roadmap is a common request from the sales force as well as other areas in all types of companies: it details the features for future releases over the upcoming weeks, months, and even years. Your product roadmap, therefore, contains your future plans for what you sell and is an easy way to let everyone knows what features will be delivered and when you’re planning on delivering them (remember that the roadmap is a plan, not a commitment to delivering).
Think of your roadmap as a plan for a backpacking trip through Europe: you have a general idea of which cities you want to visit and how you’re getting there – you’ll plan your routes, but these won’t necessarily be followed precisely.
You may fall in love with Paris or London and end up deviating from your route and spending a few days more than planned on one or two cities. You may hear about a lovely little restaurant in a city you didn’t plan on visiting and make a detour to get there. Your plan is broad and isn’t written in stone – you can make corrections and change it while still reaching the pre-determined goals.
Why should I have a product roadmap?
Now you already know what a roadmap is and what it’ll help you achieve, let’s go over the major uses for it. Ultimately, a product roadmap has these four major uses (not ordered by importance and/or priority):
- Customer/Market feedback: Roadmapping is a low cost/low-risk alternative for your company to capture feedback from your stakeholders on the future of your products/services;
- Development effort: A product roadmap is a mechanism that’ll allow you to determine what’ll be the level of development effort/investment you’ll need in order to deliver the functionalities and features specified;
- Consensus and support: Having a product roadmap is a simple way to have everyone in your business reach consensus and support towards the future of what you sell;
- Plan for the future: Finally, this tool is also a framework that’ll allow your entire organization to make concrete plans for the future (for example, Marketing and Sales can think about strategic ways of selling the new features even before they’re even being developed).
Who’s responsible for the product roadmap?
Product managers are the ones typically leading the road mapping process but they’ll often seek input from all areas involved – development, engineering, marketing, sales, and the executive team – in order to make sure the plan is correctly directed towards the ultimate business goals.
Seeing that a product roadmap is, therefore, a plan that determines how your product/service is going to meet your overall business objectives, it demands more than just the involvement of the tech experts and the product managers.
What should be in a product roadmap?
Your road mapping process has to start with a clear vision of your product/service and the ways customer and market forces will shape the future development direction. Developing your overall product strategy demands that you assess a few key components, such as customer’s needs, market size, your company strengths, your sales channels, market positioning, partners, competition, etc.
More often than not, a product roadmap will contain the release names and approximate delivery dates. You’ll also have to consider a couple of major features when road mapping, such as impacts to the final customer and on your platforms, markets you’ll serve, etc.
Market forces have a clear impact on all levels of your product roadmap: new platforms or OS, key industry events, new competitors entering the market – all of these should be considered when road mapping, since changes in the market will usually result in changed priorities on your map.
Your product roadmap should be as down to earth as possible, assessing first the items that are virtually certain. The more you know about the features on your map, the more information you’ll have to guide future developments. Mandatory features, for example, are the ones you’ll assign a release schedule for. Those “hoped for”, idealistic features shouldn’t be included.
Always remember, as soon as the features are on a product roadmap, all other involved channels – and ultimately your final customer – will assume they’ll be delivered so you should only publish what is guaranteed.
In order to make a roadmap officially public, your organization must be able to hit the scheduled dates on it. Reducing the size of the features and breaking down big features in more than one release is the best way to achieve realistic delivery dates. Smaller releases will also mean your product will come out more often – those essential deal-closer features may come out this year instead of more than a year away.
Having a well-defined marketing segmentation strategy is also a must to avoid confusing customers and products: knowing who you’re selling to avoids pitching for people your product wasn’t defined for (and we all know how trying to sell to the wrong customer ends up). Salespeople may use future necessary features for solving specific customers’ needs will be on the next product releases, ending up having to campaign to get those features on a release, ending up with the cost of building an entirely new feature just to please one customer.
Even though having a product roadmap is very useful for showing your sales channels and major customers what features they should expect in future releases, it also makes that public to your competition. The downside of letting everyone know what to expect is, of course, the risk that competitor players in your market may ace those new features before your product is out.
Once your product roadmap is made public, it’s not that easy to change it – what was supposed to be a plan, ends up as a commitment to some customers. Many companies solve this “problem” by having two roadmaps – one for internal use only and another for publishing. This may be necessary for the reasons stated above but can also be avoided by setting a rule of not printing your product roadmap: only the product manager should be allowed to talk about the future of the product and, even though he/she may use the roadmap on presentations, it shouldn’t be printed or distributed.
Free Product Roadmap Template!
Normally, all of these factors and things to consider listed above would be columns on one or more spreadsheets but, if you’re looking for a more practical way to do so, you should try Pipefy’s Product Roadmap Template.
Our product roadmap template was developed to help you learn how to prioritize your features by following the best practices of product management – from defining the type of improvement to the advanced measurement of impact on your goals.