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
refactoring is better and more convenient than overbuilding. iterate on what people ask for rather than imagining everything in your head
minimalist phone: creating folders
@deepmishra1283 I think that I ended up in the project where it is the opposite. 😂
@busmark_w_nika did that project work?
minimalist phone: creating folders
@deepmishra1283 yes, actually has many users so probably we are in the position to decide what we will implement or not :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.