Recently, I spoke with a Director of Product about new features her company is gearing up to release as enhancements to an existing product whose growth has slowed.
We discussed the current roadmap and the product backlog. I probed on a particular feature and asked what I thought were simple questions:
- How pervasive is the problem to customers, and to the market?
- What is the revenue opportunity (current customers; current market potential)?
Her response left me wondering if enough discovery had been done.
Clarify Why
When features are added to a product, there can be different desired outcomes. Many features are designed to generate revenue; others reduce expenses. Some features are developed to simplify a product’s use. Still others are created to address a legal issue – think about updates to HIPAA policy for products and services within the healthcare industry.
So, when simple questions fail to clarify the reason why time, money and resources are being spent, that’s a warning sign.
- Is there a problem that a customer (or the market) cares about?
- How significant is this problem?
- Does the size (or the impact) justify the effort?
Teams should look to solve the problems that reduce pain for customers. Clearly articulate the problem. Identify the size of the problem and the impact of a solution. Determine how to solve the problem, profitably.
The Reality-Check Questions
Once a feature gets put on a roadmap, the feature takes on a life of its own. Momentum is a powerful thing. Teams may start building a feature simply because it’s the next ticket in line, perhaps assuming that someone in the organization validated that a customer (or the market) wants or needs it.
In addition to the above, here are several other questions that should be considered:
- How is the customer solving this problem right now?
- How are non-customers addressing this same issue?
- Is what you’re proposing significantly better than the current solution?
Your Guardrail
“We can….but should we?” should be your guardrail.
Every feature added to a roadmap takes time and money away from the core business. If it doesn’t solve a real, verified market pain – and if internal teams aren’t totally aligned on it – it belongs in the archives.
To pressure-test your roadmap even further, ask two more things:
- What happens if we choose NOT to build this? (If the answer is ‘not much,’ cut it.)
- Is the customer actually willing to pay for this?
