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
Early on for me, I didn't build my product for users - I built it because I faced a problem and I didn't have a desktop solution. Once successful in solving the problem, I figured other users could benefit. Whether or not I am correct will ultimately be determined by 1. Good marketing (for which I need help ... did I say HELP), and 2. User adoption.
There's also a Users "needs vs wants" dimension - not easily parsed unless you're emersed in the software's subject and issues. On one hand you're playing to users ego vs providing solutions - in my world in any case.
minimalist phone: creating folders
@robert_vassov But when you grow and want to market it to broader audiences, you need to take into account other people's suggestions. Who has the priority then? (I know, you have a final word, but anyway, how did you decide?)
@busmark_w_nika I haven't experienced this position but imagine an objective decision based on benefits to the majority users. MVP in my experience is the right starting path - provides you the baseline measurement for all other options on the table.
We used these plus: Is there a strategic partner willing to pay for prioritizing the build? And Is it a competitive differentiator (product vision)?
minimalist phone: creating folders
@felicitemoorman But what if you implement that suggested feature by a non-paying user and he is not subscribing anyway after that? :)
@busmark_w_nika I've spent most of my tech time in IoT & enterprise. Yet to have someone ask me for something they didn't really need and subsequently adopt. I'm in a brave new world now at @BOSS.Tech Beta where any entrepreneur, founder, or even enterprise can adopt BOSS.Tech, so I'll keep this front of mind in our feedback loop!
@busmark_w_nika This is actually one of the hardest parts of building. Sometimes feedback from just one user can sound incredibly convincing – especially if it resonates with you personally, it’s tempting to jump on it immediately. 🙂 And then someone suggests something that doesn’t resonate at all… and you instinctively push back, only to later realize that many users actually wanted that.
What helped us is separating signals from stories. A single request can be interesting, but we usually wait to see patterns:
Is the problem recurring across users?
Does it align with the direction we want the product to go?
And most importantly: does it remove friction in the core workflow, or just add optional complexity?
Not every request becomes a feature, but repeated problems usually deserve attention. Still feels more like art than science most days. 😀
minimalist phone: creating folders
@tereza_hurtova Sometimes it is better to leave the product as simple as possible XD
@busmark_w_nika Can’t agree more! :D
One thing we learned while building Flexlore,
Feature requests are useful, but watching where users struggle in real workflows is often more important.
If a feature makes a task easier for users, we build it. If it only makes the product more complex, we usually skip it.
minimalist phone: creating folders
@ata_han_bayram How do you get that data? Heatmaps? Or from calls?
This is a topic I've been wrestling with for PostGod tbh. Mainly because I have SO MANY ideas for how to improve the product, which extra features would complement the current features best, and so on.
But I realized I was just making the MVP too complicated. While trying to see if the idea makes sense, the product should stay as simple as possible. Then, through user interviews, feedback, and data analysis of users' behaviour should guide the roadmap.
minimalist phone: creating folders
@ruxandra_mazilu And how do you decide which feature will survive? Which will be added? And which needs to be removed? 😆
vibecoder.date
User needs which are representative of the largest growing cohort of users are probably the priority.
But features also build loyalty, and loyalty creates evangelists.
minimalist phone: creating folders
@build_with_aj Well, I think that when there is a huge surge of requests for that specific feature, somehwere is true, and the feature should be built :)
vibecoder.date
@busmark_w_nika absolutely, especially if the group requesting it are given access and thanks. You get evangelists
Kafkai
We use our own products so the main motivator and barometer is if we find it useful. Based on that we then find customer stories which mentions something similar.
This is the hard part: Customers nearly all the time aren't specific or sure what is the "itch" that they will like taken away the most. I've noticed that when we talk to customer, they'll say something like: "well yeah it's not such an issue because it only takes a few minutes to manually edit" BUT when you add that minutes up that's where customers really notice.
minimalist phone: creating folders
@iqbalabd You do not have to say (I experience those added minutes quite often) :D
The volume of requests can be a misleading signal — 100 people saying "that would be nice" is weaker evidence than one churned user who says "I left because this was missing." The question I've found more useful than "how many are asking?" is "how many left because they didn't get it?" That shifts from feature voting to churn attribution, which is a much harder data problem but the right one.
For convincing decision-makers: if you can point to even two or three churned users who specifically named this gap and document what they were trying to do, that's usually more persuasive than a tally of +1s.
minimalist phone: creating folders
@giammbo This is a strong argument. I have never looked at it like this. Churned users probably feel more pain than ad hoc suggestions.
@busmark_w_nika The pain gap is real — a churned user has already decided the missing feature wasn't worth staying for. Much stronger signal than a request from someone who's been around for 3 years and manages fine either way. The tricky part: most churned users just disappear without explaining why. Do you have a way to catch that signal before they leave — while they're still frustrated but around?
minimalist phone: creating folders
@giammbo We incorporated a short form, when they wanna uninstall the app, but it is a free choice to fill it up.
An exit form right at uninstall is exactly the right moment — the friction has already been paid, so anyone who takes the time to fill it is telling you something real. The 'free choice' constraint is honest: you'll miss the silent majority, but the ones who bother are often the highest-signal users — the ones who cared enough to explain. That's the data that actually moves product decisions. Really well-built feedback loop.
UXDesigner.top
As a founder and CPO (With design background), I learnt to transition from being a "pixel-pusher" to a "designer of decisions." To avoid product bloat and unnecessary complexity, you need a strategic filter to decide what truly belongs on your roadmap.
Here is the framework I use to prioritize features and stay lean:
Prioritize with the "Attractiveness vs. Effort" Matrix: Map requests based on user value and technical cost. Focus on "Quick Wins" (high value/low effort) and strategically choose "Big Bets" (high value/high effort) that align with your long-term vision.
Focus on Problems, Not Requested Solutions: Users often ask for specific buttons, but that is their personal solution to a problem. Your job is to uncover the underlying pain point and design the simplest possible fix.
Align with your "North Star" Metric: Every feature should move your primary goal, such as user retention or lead conversion. If a request doesn't push this specific KPI, it should be deprioritized.
Use "Fake Doors" for Rapid Validation: Before building a complex feature, add a button or indicator for it to see if users actually interact with it. If the interest isn't there, discard the idea before writing any code.
Simplify to Increase Conversion: We found that users often don't use 80% of existing features. Removing noise and simplifying your offering can actually lead to higher engagement and better conversion rates.
Reserve a 20-30% Buffer: Always keep a portion of your development time for technical debt, bugs, and unexpected crashes. This ensures your roadmap remains flexible when critical issues arise.
minimalist phone: creating folders
@david_martin_suarez This is a cool guide (if you have some case studies where is also some analysis of psychological aspect how users react with the components, layouts, features), feel free to share :)
UXDesigner.top
@busmark_w_nika From my experience building Velada, LovablePrompts.app and most recently BenchCanvas.app, product psychology is often about making things feel easier, clearer, and more natural for users. I’ve seen better results when reducing choice overload, using familiar interaction patterns, and being transparent about effort in flows. Small UX decisions like these can have a huge impact on conversion, engagement, and trust.
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