How do you decide how many features to add so your product is not too broad or too narrow?
I believe that when launching a product on Product Hunt, you should focus on one main feature and two supporting features that help bring the whole idea together.
When I see a new product with too many features and the whole tool feels complex, I start to lose my understanding of what it actually does.
More features make sense only when the product is already established and wants to serve the needs of different types of users [cover a bigger market].
How do you decide how many features your product should have? (Are you a maximalist or a minimalist?)
What helps you decide that a certain feature needs to be “kil*ed”?
164 views
Replies
Count jobs not features is basically how I think about it too. My app has receipts, voice entry, PDF import, and spending insights, four different input methods for one job, which is turning a transaction into a categorized record. None of those individually needed a debate about whether they belonged.
The one I actually killed was a budgeting goals feature I built early on. Worked fine, nobody used it, and I couldn't explain why someone would open it twice in a week. Turned out the job it solved (am I on track) was already answered by the insights screen, just less directly. A different UI for the same job doesn't count as a second feature, it's usually a sign the first one isn't explaining itself well enough.
I’m closer to the “count jobs, not features” camp.
For an early product, I ask whether a feature helps the same user reach the same outcome faster or with more confidence. If it needs separate onboarding, a long explanation, or attracts a different type of user, it is probably a second product rather than a supporting feature.
The difficult part is that early-stage products often do not have enough usage data yet. Until they do, I prefer keeping only what is necessary to complete one real workflow end to end, then letting actual user behavior overrule the original plan.
When you say one main feature plus two supporting features, are you limiting the feature count, or the number of separate ideas a user has to understand in the first session?
10 days post-launch here with a similar feeling. What I've learned: launch day traffic means nothing on its own. The real signal is whether the people who actually try the product come back or tell someone. I'm running a 24-hour free trial to reduce friction — so at least I know who's genuinely interested vs just clicking. As for advertising — I've tried YouTube so far, now moving to Google Ads and Product Hunt forums. Distribution is a completely different skill than building.
I only implement features in products where I already know the market and the users' needs. When you have that deep understanding, the features you need to build are simply the ones that are strictly necessary and expected — nothing more, nothing less. The market and the users decide for you.
Listen to feedback from users... or if you're building a prototype and have no users then do as much research as possible about what bare minimum features users of the product will require to make it viable and build those first. Then move on to the nice to haves that make your product more appealing,
For me the test is simple: does the feature make the one core job faster or clearer? If it serves a different job, it is not a missing feature — it is a different product.
The kill signal I trust most: things people ask for in a demo but never touch once they have them. I learned this the hard way on an earlier AI writing tool I built. We kept adding options to cover more cases, and the tool got harder to understand for the exact people it was for. Fewer options actually helped them finish faster.
So I lean minimalist. One main job done well, and I only add something when I see the same request again and again, not just once.