5 common mistakes in product planning
Product planning, or more specifically creating a product roadmap, is an exercise that all R&D organizations will undertake. Some will do that on a rolling basis, perhaps annually or more frequently. I’ve certainly gone through many iterations of this exercise. Below are some of the pitfalls and anti-patterns that I have observed.
No product vision
A product vision is your north star. It should outline the longer-term objectives (2+ years) of your product. I’ve encountered products that lacked a vision, they almost always end up being “flat”, lacking cohesion or unity. They don’t “feel” like they were well thought of, because they weren’t and it shows. Products that lack a vision become undifferentiated. They aren’t holistic and lack cohesion: they are just a list of features. All the investments you make on your product need to be in support of your vision. Start with the vision then solve for features, not the other way round.
A product vision is not only necessary for proper product planning, it is also an invaluable tool for recruiting and selling your product. Talented engineers and product managers will want to know what your vision is for the product they might work on. These talented and highly skilled individuals want to work for companies that have a bold and exciting product vision. Similarly, customers will want to know what vision you have for the product they might buy. How will your product evolve over time? Is your vision aligned with how they think and see the world and their business? A product vision future-proofs customers and employees that invest their money and time with you.
Your cost and value estimates will be off
One of the more critical components of planning your product roadmap is engineering cost. Your PM team might have a list of features that they want to prioritize and one of the prioritization criteria will be cost. Your cost estimates will be wrong, they will be conservative. I’ve attempted numerous tactics to try and reduce this bias. No matter what tactics I used, they almost inevitably result in the same outcome: your estimates will be off. Probably about 50% off.
There are two sides to the product prioritization exercise: cost and value. The value is the utility that you project you will be able to extract from a feature. That could be in the form of more product usage, more revenue, lower customer churn and so on. Your projected value will also be off. Much like costing, this exercise is fraught with biases and you will probably be 50% off as well.
Not only will you be off 50% of the time, but sometimes features you thought would be a game changer will deliver absolutely no incremental value. Hence, on average you might realize 50% of your projected value, but you will also witness features that fail to deliver on any expected value → 0
Your planning will be off
Try as we might, humans aren’t particularly great at predicting the future. And a product roadmap is exactly that: trying to predict what customers need and by when. We’ve already covered how off you will be both in terms of under-estimating costs and over-estimating value. Not only will you be off with these two parameters, but you will fail to take into consideration unforeseen events (not that you could anyways). Those are obviously surprises that you hope won’t happen. The thing is, they always do, especially in the fast moving and evolving space of startups.
Some of the more common surprises, meaning they will happen at least once a year, include:
A (unplanned) feature request from a highly strategic and disgruntled customer
A (unplanned) feature request from a prospective large customer
Legacy code that finally comes to rear its very ugly head in the form of support cases and customer escalations
These surprise do not include the largest force of unexpected surprises: life. People changing jobs, people going on medical or parental leaves, burning out and more are all unforeseen events that could have significant impact on your plans.
Happy ears
“I just had an excellent conversation with customer X on feature Y. I asked if they would buy it when released and they said yes”
I can’t remember how many times I have heard that, enough to be rich if I collected $1 every time I did. The sad truth is, most won’t buy, even those that said they would. There are many reasons why this particular phenomena occurs.
The first is confirmation bias, or our tendency to seek out or interpret information that supports our pre-existing beliefs, expectations, or hypotheses. And nothing is as exciting as hearing that an idea we have excites customers and prospects. The second is most people don’t like saying “no”. It’s far easier to say “yes” to the question and later on change your mind. Why disappoint a fellow human that is clearly excited about her idea? Just say “yes” to avoid the potential conflict and you can always change your mind later on.
This phenomena compounded with being over-optimistic on value can have significant negative consequences on your product and how it performs in the market. Your approach should be premised on validation and hypothesis testing not confirmation.
“I’ve never heard a customer want this feature”
Some of the product organizations I worked with were “spoon fed”. These product teams would shop around a list of features with customers, sales, prospects in an attempt to prioritize them, with demand being the main prioritization function. Putting aside the “happy ears” bias, this method suffers from a few fatal flaws.
The first is, customers shouldn’t care about features per se, and consequently nor should the product team. Both should care about identifying problems that the customer wants solved. Features are meant to solve problems, ideally hard problems that customers will pay for. By focusing on the problems first, versus the features, you can unlock novel ways of solving these problems. Thinking in terms of problems first will allow you to apply your creativity to find novel ways to solve those problems. First problems, then features.
The second concern I have with this approach is it assumes that customers know best. They don’t, especially if you ask them about features. They know their problems, not necessarily how to solve them (hint: if they did, they don’t need your product). The canonical example is Henry Ford deciding not to build an automobile with an internal combustion engine because “I’ve never heard a customer want that feature”
Surface the problems that matter the most and apply your creativity to solve them.
My next post will outline some of the tactics I have applied, alongside my Product Management peers to address these anti-patterns. While there isn’t a silver-bullet or singular activity that will solve for all these challenges, there are a few actions that can reduce your error rate and inherent biases that this exercise is fraught with.
Things of interest that I recently read
I work with Evan. He’s an amazing human being, a wonderfully talented engineer, and, now I discovered a new side to him as well: an exceptional writer. Evan writes about his experience as an Indie game developer here. A wonderful and very personal read.
- outlines the challenges facing many startups, especially late stage startups that raised at ludicrous valuations. Sobering.
Carta published their June edition of First Cut of Carta data on valuations. The chart shows valuations rebounding relative to 2021. I’d take this with a big grain of salt: small sample size and most of the rebound is in the very early stages. Witness how depressed series-D is too.
