Before building a new feature, ask yourself these 5 questions
When was the last time you built a feature because one user expressed a strong frustration?
It happens easily. A detailed complaint feels urgent, the solution seems obvious, and suddenly the feature is on the roadmap.
But a user asking for something does not always mean they would use it, pay for it, or even notice when it ships.
Before adding a feature to the roadmap, I find these five questions useful:
1. What problem is the user actually trying to solve?
Users usually suggest a solution, but your job is to understand the problem behind it.
Understanding the underlying problem gives you the freedom to solve it in a simpler, cheaper, or more effective way than the user originally suggested.
2. How are they solving it today?
A spreadsheet, a manual process, another tool, or simply doing nothing can reveal how painful the problem really is.
The more time, money, or effort they already spend on a workaround, the stronger the signal that the problem is worth solving.
3. How often does the problem happen?
A painful problem that happens once a year may still be less valuable than a smaller frustration that happens every day.
Frequency matters because recurring problems are more likely to affect retention, satisfaction, and willingness to pay.
4. Who else has asked for it?
One detailed request can feel more important than twenty silent users experiencing a different problem.
Look for patterns across support messages, interviews, analytics, cancellations, and user behavior rather than relying on the loudest request.
5. What existing feature will become harder to maintain because of it?
Every new feature adds support, edge cases, onboarding complexity, and future decisions.
The real cost is not only building it once, but maintaining, explaining, testing, and improving it for years.
A request becomes much more convincing when the problem is frequent, the current workaround is painful, and several users are already trying to solve it themselves.
Have you ever built a feature around one user’s frustration and later realized the demand was not really there?
Replies
We shipped a "custom export" feature off one enterprise ask. Six months later, usage: 3 accounts, all belonging to that same customer.
Yoggi
@sadie_charlotte That’s such a good example of why “one enterprise customer asked for it” can be a strong revenue signal but a weak product-wide demand signal. Did that customer’s value justify maintaining it, or would you handle the request differently today?
One thing missing: how do you measure the maintenance cost after the fact, not just estimate it upfront? Predicted cost and actual cost rarely match.
Yoggi
@ayazakram Very good point. I’d probably track actual maintenance cost through engineering time, related bugs, support volume, documentation changes, and how often the feature complicates future releases. Usage alone can be misleading: a rarely used feature that requires almost no attention may be fine, while another with moderate usage can create constant regressions and exceptions.
Dial
the part I struggle with is point 4 when you're still small. "look for patterns across users" assumes you have enough users for a pattern to exist. with a handful of active accounts, one detailed request IS most of your signal whether you like it or not. the framework works great once you have volume, pre-PMF it can talk you out of building things that were actually right, just early.
the workaround point is so important. if people are already using a messy solution that's usually a better sign than just asking for a feature.
The one I would add, and it is the only question that has ever stopped me: what are they doing right now instead? Every real problem already has a workaround, because people do not sit still. If you cannot describe the current hack in specific detail, spreadsheet, Slack message to a colleague, doing it manually on Fridays, then you are not looking at a problem, you are looking at a preference. And when you can describe it, you get the bar for free: your feature has to beat that hack, not beat nothing. Most features that ship and get ignored lost to a workaround the team never bothered to look at.