Why Product Roadmaps Suck
What should our product team work on today? The answer is usually on your product roadmap. It contains a list of features, ideas, tasks to do, small and big projects and multi-team efforts that must be achieved. Along that, all of them have a deadline. So everyone can grab a task from the roadmap and not worry on what to do next. This means we can define a roadmap as:
Product roadmap is a prioritised list of features and projects with an end date.
Usually a product roadmap comes from the management team or from the product manager. Both parties, have reasonable answers on why they want one and why you should follow it. The most common reasons are:
They want to be sure you are working on the highest priority first.
They run a business and this means they have to plan stuff. They want to know when things are going to be delivered so they can sell the product, launch a marketing campaign or report to their investors.
These are fair answers to the question why do we need a product roadmap. But we miss one thing that stayed in the darkness for too long:
Roadmaps are the root cause of most waste and failed efforts in product organisations. They are a graveyard for more than half of listed features and ideas that will never succeed.
Can we explore what is the problem?
The harsh truth is that, with all our best intentions, half of our product ideas will not work. More realistic teams expect that number to jump up to 75%. Because we all know that things almost never go as planned when it comes to building a product. If being more specific, some of the reasons are:
Customers are not that excited as we are about a feature that is being built.
A customer wants to use the feature but it is too difficult to understand or requires too much time to learn it so they simply ignore it.
Sometimes the idea is great, but once we start building it, we realise it will take too much time and effort to finish it. So we leave it along the way.
It may be the financial, business or legal reasons that will not allow us to launch or work on those ideas.
And the last but not the least, the idea may be great and bring a lot of value to both business and customers but we all know that it takes many iterations until we achieve the ideal state. So thus we need more time and resources than initially expected.
And these truths can either be embraced or you ride along with them. So I embarked on a mission to find out how strong and weak product teams cope with that. What are they doing different from each other. And I found out that:
1. Weak teams follow blindly the roadmap.
Month after month, they follow all the tasks on the roadmap and make sure that everything is done on time. And once something goes wrong they start blaming the management for poor goal setting. After that, they ask for more time to redesign the “feature” and improve it. And if they had enough time and money, they would eventually solve the problem and achieve the desired solution, but that is rarely the case.
2. Strong product teams understand, embrace and pivot the truths.
The ideal state is not to ignore these truths but work around them and adapt to the ever changing needs from a different perspective. Strong teams do not start putting a list of features on the roadmap, but they start with a product discovery stage first.
The problem with roadmaps is that we put on it features to build, but it should have business problems to solve. What is the underlying problem? And not just deliver a feature.
A product discovery is a stage when the team tackles: 1) what are the business goals? 2) what are the measurable KPI’s? 3) all the risks and problems that are to overcome, 4) and are fast at iterating the ideal and effective solution for the main business problem they have predefined.
The problem with putting a list of features on the roadmap is that once it’s out, people will interpret it as a commitment. No matter how many disclaimers you attach or notes you leave, people will still have a fixed goal in mind — design or build that feature. The team will start developing and delivering the next task on the list, even when it does not solve a problem.
From the other side, yes, we do need a list of features and hard dates to build and deliver stuff. But what I am suggesting is to take a step back. And transition from being a feature building team, to a business problem solving team. So I don’t recommend removing the roadmap, but improving it with an extra step before committing to anything.
How can we have better roadmaps? Add a discovery stage before committing
I would like to make it clear that the problem lies in committing too early to a goal before the real business objectives are established. Commitments are made before we even know if this is something we could deliver, and most important, will it solve the customers problem. Having a list of features to add with a deadline is crucial. But I am speaking of a broader context — product vision.
Product Discovery
Adding a discovery and delivery model in advance is changing everything. Discovery is all about an intense collaboration between product management, UX and engineering. The purpose of discovery is to quickly separate the good ideas from bad. The output of product discovery is a validated product backlog. This means getting answers to these questions:
Are the users going to buy this?
Is it going to solve a problem our customers face?
Is it going to improve the overall experience?
Is it going to highlight our strong parts of the product?
Does this bring closer to our product vision?
Can our stakeholders support this?
Can our engineers build this?
Can a user figure out how to use it?
How Product Discovery can be applied
Let’s suppose that it requires two weeks to onboard a big client. But for the company to scale we need to reduce that amount of time from two weeks to a couple of hours. That’s a good example of a great business goal: “Reduce the amount of time required to onboard new big size customers.” And for a measurable objective it would be: “Onboarding time less than one hour.”
Now imagine having a product roadmap with only business goals on it. This kind of roadmap opens room for creativity and innovation to come in. People feel more open with their ideas. So now we are not limited by a set of features.
Steps to implementing the idea in real life
First, we ask our key stakeholders to give us a little bit more time for product discovery, to investigate the solution and execution plan. We tell them that we need time to understand if this goal resonates with our customer and whether it is going to improve the overall experience. Then we talk with engineers to ensure that it can be built and iterate on the findings and ideas from a technical point of view. After that we talk with our stakeholders or management team to see if the solution found achieves our business goals.
Now once we aligned all three parties - customers, engineers and management team — we can start making the execution plan. This plan includes our business goal, measurable KPI and the rest of the details, together with an end date.
It is important for companies to make these kind of commitments from time to time and get comfortable of switching to it entirely. Because this way we can truly improve our products by listening to customers and committing to things that are critical to our company rather than doing incremental changes without seeing the bigger picture. And even if you do it rarely, it is better than not doing it.
If you would like to know more about the subject, I would highly recommend reading Inspired by Marty Cagan which offers a clear and best explanation, I ever read, on product management and how it works nowadays for companies such as Tesla, Adobe, Apple, Microsoft.