Even with the best of intentions, product roadmaps typically lead to very poor business results. I refer to the reasons for this as the two inconvenient truths about product.
The first inconvenient truth is that at least half of our product ideas are just not going to work. There are many reasons for a product idea to not pan out.
Sometimes customers just aren't as excited about this idea as we are, so they choose not to use it or buy it (the value isn't there). This is the most common situation.
Sometimes they do want to use it, and they try to use it, but it's so complicated that it's simply more trouble than it's worth, which yields the same result—the users don't use it (the usability isn't there).
Sometimes the issue is that the customers might have loved it, but it turns out to be much more involved to build than we first thought, and we simply can't afford the time and cost to deliver (the feasibility isn't there).
The issue is that anytime you put a list of ideas on a document entitled “roadmap,” no matter how many disclaimers you put on it, people across the company will interpret the items as a commitment.
And, sometimes the issue is that we encounter serious legal, financial, or business constraints that block the solution from launch (the business viability isn't there).
If that's not bad enough, the second inconvenient truth is that, even with the ideas that do prove to be valuable, usable, feasible, and viable, it typically takes several iterations to get the execution of this idea to the point where it delivers the expected business value that management was hoping for. This is often referred to as time to money.
In my experience, there simply is no escaping these inconvenient truths. And I've had the opportunity to work with many truly exceptional product teams. The difference is how product teams deal with these truths.
Weak teams just plod through the roadmap they've been assigned, month after month. And, when something doesn't work—which is often—first they blame it on the stakeholder that requested/demanded the feature and then they try to schedule another iteration on the roadmap, or they suggest a redesign or a different set of features that this time they hope will solve the problem.
If they have enough time and money, they can eventually get there so long as management doesn't run out of patience first (a big if).
In contrast, strong product teams understand these truths and embrace them rather than deny them. They are very good at quickly tackling the risks (no matter where that idea originated) and are fast at iterating to an effective solution. This is what product discovery is all about, and it is why I view product discovery as the most important core competency of a product organization.
If we can prototype and test ideas with users, customers, engineers, and business stakeholders in hours and days—rather than in weeks and months—it changes the dynamics, and most important, the results.
It's worth pointing out that it isn't the list of ideas on the roadmap that's the problem. If it was just ideas, there's not much harm in that. The issue is that anytime you put a list of ideas on a document entitled “roadmap,” no matter how many disclaimers you put on it, people across the company will interpret the items as a commitment. And that's the crux of the problem, because now you're committed to building and delivering this thing, even when it doesn't solve the underlying problem.
Don't misinterpret this. Sometimes, we do need to commit to a delivery on a date. We try to minimize those cases, but there are always some. But we need to make what is called a high‐integrity commitment. This will be discussed in detail later, but the key takeaway here is that we need to solve the underlying problem, not just deliver a feature.