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?
Point 4 is the one teams skip most. Loud requests get logged, quiet patterns in support tickets don't, mostly because nobody's tagging tickets consistently.
Yoggi
@ashton_blake Exactly. The loud request is visible by default, while recurring friction often has to be reconstructed manually across dozens of conversations. Consistent tagging is boring operational work, but without it, roadmap decisions can easily become a ranking of who complained most clearly.
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.
"Who else asked" — curious how you track that.
Yoggi
@avery_jordan1 Fair question. I don’t think counting identical feature requests is enough, because users often describe the same problem through completely different solutions.
The useful part is grouping support messages, feedback, cancellations, and interviews by the underlying problem, then noting who mentioned it and how severely it affects them.
So “who else asked?” really means “who else is experiencing the same problem?”, not necessarily “who requested the exact same feature?”
Matches my experience — the features that get unmaintainable are rarely the heavily-used ones. It's the one-off asks nobody revisits.
Yoggi
@brandon_chase That’s a great distinction. Heavy usage usually forces a feature to improve over time, while one-off features can quietly keep generating edge cases, support questions, and compatibility work long after the original request has disappeared.
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.
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.
All five hold up, and I'd add a sixth that's easy to miss: is the reason this got requested still true?
Feels related to what Sadie and Ashton are describing — one enterprise ask, one loud-request-vs-quiet-pattern gap — but from a different angle: even when the signal was real and correctly weighted at the time, it can go stale before the feature ships.
We shipped something once because three customers hit the same wall in the same month, passed every one of your five checks cleanly. By the time it launched eight weeks later, two of them had already worked around the problem a different way, and the third had churned. Fully justified when we decided to build it. Not justified anymore by the time it shipped, and nobody re-checked.
Has anyone built in a re-check before shipping, or is "the ask was real when we said yes" just treated as good enough?
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.