What made you stop building a feature users kept requesting?
by•
I'm trying to get better at separating a useful request from a loud one. A feature can sound urgent in a conversation, but that doesn't tell me how many people need it or whether they'll use it after it ships.
My current approach is to look for the problem behind the request and wait until the same problem appears more than once before it reaches the roadmap. I still worry that this can make a small team too slow to notice a good idea.
What made you decide not to build a feature people kept asking for? Did the data show weak demand, or would the feature have pulled your product away from its main job?
72 views
Replies
I usually wait until i hear tha same request from diffrent users before building it because one laud request does't always mean everyone needs it
@shivam_kushwaha16 Agreed—one loud request is a signal, not a roadmap item. I’m trying to combine repeated problem statements with lightweight evidence like workarounds, usage, and retention so a quieter but important need doesn’t get missed. What kind of evidence do you trust most before committing?
waiting until the same problem shows up from a few different people seems right, slow beats maintaining something only one person uses. do you tell the person who asked why it didn't get built?
@neerajnathany Yes—I try to close the loop rather than leave people guessing. I’ll explain what we heard, why it isn’t the right fit yet, and what evidence would change the decision. Sometimes I’ll suggest a workaround or a narrower version that keeps the core product focused. What wording has worked well for you when delivering that kind of “not yet”?
@yashpanpaliya i'd keep it honest, something like "not on the roadmap right now, here's why, and we'll revisit if more people ask". people usually take a straight no better than a vague maybe
Your approach of looking for the problem behind the request matches what the numbers taught me. In my app people kept running out of credits and landing on the credit packs screen, so the obvious move was more and cheaper packs. Analytics showed 19 people reaching that screen about 100 times in total and nobody buying. The problem behind it was simply "I want a second song", and a pack was the wrong answer to it. So instead of building more packs, an empty balance now opens the weekly subscription with the packs one link below. On the speed worry: I would not wait for the problem to repeat if you can measure it. One funnel event is often enough to tell a loud request from a common one.
@gbasovv That’s a really useful example of the funnel correcting the initial assumption. Repeatedly hitting the credit-pack screen looked like demand for packs, but “I want a second song” points to a different job entirely. I like your rule of measuring before waiting for repetition—one strong event can be enough to test a hypothesis. Did the subscription link change the number of second-song attempts?
Usually it was neither of those. The request named a solution, and that solution would have made things worse for the people asking.
A flashcard tool I build makes decks for 4 different apps. The obvious ask is "one button, export to all of them". I built a picker instead: you choose the app, and your text and settings carry over if you switch. Each app wants a slightly different card shape, so one export for all four would be average in every one of them.
So, where I would push back on this rule: "wait until it comes up twice" only counts people who talk to you. Most users never write. They just do the workaround and stay quiet, or leave. So when a request repeats, I look for who's doing the workaround, not who's asking again.
@hamanovich That’s a great distinction. “Export everywhere” sounds like a feature request, but the real need is preserving the work while respecting each app’s format. The quiet workarounders point is important too—I’m going to look for those behaviors in usage data, not just count who speaks up. How do you usually spot a workaround before someone churns?
Users kept asking for auto-merge on agent PRs. Mistakes are fine, but the feature was killed the day an agent cleared a failing build by deleting the test assertions and reporting that everything was fine.
I treat a feature request as a description of a problem, not a spec. Owners of service businesses ask us for custom reports all the time. Dig in and nearly every one wants the same answer: which leads came in and what each one cost. A report builder would hand them a blank page and a weekend of setup. Putting that answer on the first screen did the job. If the fix pulls you away from the question people hire you to answer, say no.