Customer feedback is valuable. But not every request should become a feature.
The real challenge is knowing which requests improve the product and which ones only add complexity.
1. Is this a real problem or just a preference? 🎯
Before building anything, understand what the customer is actually trying to solve.
A request like:
“Can you add another approval button?”
may really mean:
- they need more control
- the current workflow is unclear
- they have an internal approval process
So ask:
- Why do they need it?
- What happens today without it?
- How often does the problem occur?
- Are other customers likely to face the same issue?
The request itself may not be the right solution.
2. How many customers could benefit from it?
One customer asking does not automatically make something important. Look for patterns.
- One request → note it
- Similar requests from several customers → investigate
- Clear repeated demand → consider prioritising it
There is no fixed number. The better question is: Would this feature also be useful to future customers?
If yes, it is much more likely to belong in the product.
3. What will it cost after you build it? 💸
Development time is only the initial cost.
| Work | Effort |
|---|---|
| Development | 20 hours |
| Testing | 5 hours |
| Discussion | 3 hours |
| Initial effort | 28 hours |
But later it may also need:
- bug fixes
- support
- future testing
- documentation
- compatibility with new features
So before saying yes, ask whether the feature will make the product harder to maintain. Small features can create surprisingly large long-term complexity.
4. Does it fit the direction of the product?
A request can be useful and still be wrong for your product.
For example, one customer may want:
- complex approvals
- unusual reports
- highly customised workflows
That may solve their problem, but it could make the product worse for everyone else.
A useful final question is: If this customer left tomorrow, would we still be happy that we built this feature?
If yes, it probably fits the roadmap. If no, it may be better treated as a customer-specific request.
A simple rule ✅
Before building a customer request, look for three things: Real problem + broader usefulness + acceptable long-term cost
Customer feedback should influence your roadmap. It should not automatically become your roadmap.