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 significant projects and multi-team efforts that must be achieved. Along with that, all of them have a deadline. So everyone can grab a task from the roadmap and not worry about what to do next. This means we can define a roadmap as:

The product roadmap is a prioritised list of features and projects with an end date.

Usually, a product roadmap comes from the management team or 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 right 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 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 — Marty Cagan

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:

1. Customers are not that excited as we are about a feature that you are creating.
2. A customer wants to use the feature, but it is too difficult to understand or requires too much time to learn it, so they ignore it.
3. Sometimes the idea is excellent, 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.
4. It may be the financial, business or legal reasons that will not allow us to launch or work on those ideas.
5. And the last but not the least, the idea may be significant 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.

You can embrace these truths and you ride along with them or you can ignore them and experience the effects on yourself.

So I embarked on a mission to find out how weak and strong product teams cope with those truths listed above. What are they doing differently 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 — Marty Cagan

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.

On 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 you even established any business objectives. People make commitments before they even know if this is something they could deliver, and most important, will it solve the customer’s 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 separate the good ideas from bad quickly. 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 an excellent 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 and safe sharing 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 communicate 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 essential for companies to make this kind of commitments from time to time and get comfortable with switching to it entirely. Because this way we can indeed 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.

Next, I would recommend reading: