How do you decide which features to add to your product? [building & improvements]
Early-stage founders often try to improve their product as much as possible and tend to take almost any feedback into account.
Sometimes they end up adding every feature users (even non-paying ones) ask for, even when those features are unnecessary. The product then becomes more complicated and harder to use.
And I’m not even talking about the stage when the product is already established. At that point, there are more users, and their expectations start to differ.
So how do you decide which features will, or won’t, be implemented?
The most common approaches I’ve personally seen are: – Whether the request comes from paying vs. non-paying users – Whether the feature aligns with the product vision (and isn’t just fluff) – How demanding the feature will be to build – How many people are asking for it (size of demand)I worked in technical support, and we kept receiving repeated requests for specific features, yet the team still chose to focus on something else. In my opinion, that can be a flawed approach. Users clearly want something, but the final decision is still in the founder’s hands.
So how would you convince the decision-makers in the team that a repeatedly requested feature is worth building?
Replies
The framework I've landed on after a lot of trial and error:
Only build a feature if at least two of these three are true:
1. A paying user asked for it (not a free tier user, not a friend)
2. It directly moves a core metric (retention, activation, revenue)
3. Without it, you lose a deal or a customer churns
If only one of those is true, put it in the backlog. If none are true, kill it.
The trap most early founders fall into is building for the loudest voice, not the most important signal. Non-paying users have no skin in the game. Their feedback is cheap. A paying user who says "I'll cancel if you don't build X" is the most valuable product signal you'll ever get.
One practical thing that helped me: instead of a feature request list, keep a "pain log" of specific problems users described, with their plan type and revenue attached. When you sort by revenue impact, the priority order becomes obvious and you stop arguing about it.
The goal isn't a feature-rich product. It's a product where every feature earns its place.
minimalist phone: creating folders
@kanishk_saraswat TBH, we had such users who cancelled because of missing widgets :D and I repeating myself but no one listens sooo :D
Our framework at Hello Aria: the ICE score + one gut check.
ICE = Impact, Confidence, Effort. Score each 1-10, multiply. Prioritize the highest scores.
But the gut check that actually filters out ICE-approved bad ideas: "Would losing this feature cause someone to cancel?" If yes, build it. If no, question it hard.
The other thing that changed our roadmap: instead of asking users "what do you want?", we ask "what did you try to do in the last week that didn't work?" That question surfaces real friction instead of wishlist features.
Funnel-busting retention issues always beat shiny new feature requests.