How do you decide which feedback to turn into features?
by•
Since sharing Prodshort here on @producthunt , we’ve received a lot of early feedback. Ideas, feature requests, small improvements, UX feedback… sometimes things we didn’t even think about.
How do you decide what to actually build from all that feedback?
Some feedback looks useful at first, but once you test it, you realize it adds complexity without real value. Other times, a small suggestion turns into something essential for the product.
Would love to hear from your experience:
How do you handle early feedback without going in too many directions?
77 views
Replies
minimalist phone: creating folders
When people cancel the subscription because of the particular features, it is a significant sign.
ProdShort
@busmark_w_nika In cases where the free plan is quite generous at launch, many people may just stay on free and not really need the paid version yet. So in this case they don’t necessarily cancel subscription, and most feedback comes from free users. How do you usually handle feedback in those cases?
The filter that works for me: does the person describe a problem or a solution?
"I want to filter by severity" is a solution. "I can't tell which recalls matter for my family" is a problem, and the answer might not be a filter at all.
The other signal is clustering. One person asking is an opinion. Three strangers
independently describing the same friction is data.
@amraniyasser Such a timely question! My rule of thumb: if a piece of feedback solves a real pain but complicates the core workflow, I table it. If it solves the pain and simplifies the experience, I build it.
The hardest ones are features that users ask for loudly but would actually hurt retention if built — because they're solving a symptom, not the root problem. Have you found a way to distinguish between the two?