The Inconvenient Truth About Product
Every week I continue to find product teams laboring away on old-style product roadmaps that have been painstakingly negotiated with management and stakeholders, sometimes for several quarters in advance. I have written several times about the problems with this approach and why it so seldom results in the business impact that the organization was hoping for (see The Opportunity Backlog and Product Roadmaps).
In this article I wanted to shine a light on the underlying reason why, even with the best of intentions, these roadmaps typically lead to very poor business results.
I have begun referring to these reasons as “the two inconvenient truths about product.”
The first such truth is that at least half of our ideas are just not going to work. There are many reasons for an idea to not work out. The most common is that the customers just aren’t as excited about this idea as we are. So they choose not to use it. But sometimes they want 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 choose to use it. And sometimes the issue is that the customers would love it but it turns out to be much more involved to build than we thought, and we simply can’t afford the time and money to deliver.
If that’s not bad enough, the second inconvenient truth is that even with the ideas that do prove to be valuable, usable and feasible, it typically takes several iterations to get the implementation of this idea to the point where it actually delivers the expected business value.
In my experience, there simply is no escaping these inconvenient truths. And I’ve had the opportunity to work with many truly exceptional product and technology people. The real difference is how you deal with these truths.
The weak teams just plow through the roadmap month after month, and when something doesn’t work, first they blame it on the stakeholder that demanded the feature, then they try to schedule another iteration on the roadmap, or another redesign, or another set of features that this time they hope will solve the problem. If they have enough time and money, they can eventually get there as long as management doesn’t run out of patience first.
In contrast, the strong teams are very good at quickly determining the good ideas from the bad (no matter where that idea originated), and are very fast at iterating to a strong and effective solution. This is called product discovery. This is why I view product discovery as the most important core competency of a product organization. If we can prototype and validate ideas with customers, engineers and stakeholders in days rather than months, it changes both the dynamics and the results.
If you still think that you or anyone else in your organization can envision this beautifully working solution from the outset, then I encourage you to look deeper. I promise you that behind every successful product there are many iterations and prototypes.
So rather than fight them, embrace these two inconvenient truths. Become great at product discovery.
