How do you decide how many features to add so your product is not too broad or too narrow?

I usually like to launch a product with just the “main feature,” enough for users to start using the tool. Then, I look at session replays (using tools like Posthog) and talk to users to decide what to implement next.

Also, for early-stage products or private alphas/betas, I like to add a "roadmap" feature where users can vote for existing features and suggest new ones. It’s a great way to help prioritize what to build next. I did this in my last project, and it’s working really well :)

Great question, Nika.

I think this is one of the most important skills in product building: knowing what you actually need and what you don’t.

For me, there are two types of features: must-haves and nice-to-haves.

Start with the must-haves, then build an easy way for users to suggest ideas. You can gamify feedback with credits, add a button inside the product, collect ideas through email, or use Discord. The important thing is to keep collecting real feedback.

(A big disclaimer: I would also avoid building every feature users ask for. Look for repeated problems, not isolated requests. A feature should stay only if people actually use it, it improves retention or revenue, and it does not make the core product harder to understand.)

Then test new features for a defined period (sometimes weeks, sometimes months). After that decide whether the feature deserves to stay. Keep the ones users love and that help the business make money. Remove the ones that create complexity without real value. At the end of the day, the product has to sustain itself.

I count jobs, not features. My screenshot tool has maybe twenty features but one job, get what is on your screen into a coding agent in a form it can act on. Everything serving that job stays, so the count never comes up. The kill signal for me is explaining. If a feature needs a paragraph to justify why it is there, it is a second product pretending to be a feature.

building a voice agent adds a wrinkle to this. for us a feature isn't a menu item a user clicks, it's a new thing the agent might say unprompted, live, with no undo. so the question isn't just "does this serve the job" (agree that's the right filter for most products), it's how many new live decision points it adds. two features that are simple on their own can collide mid-call, where the agent has to decide in real time which one applies, and that decision surface grows faster than the feature count does. the kill test we use is close to the explaining test above, except scored on whether we can say what the agent should NOT do with it in one sentence. if we can't, it's not ready to ship.

I feel people don't actually read everything that's explained about the product. So, going by that logic, if the product's core features are explained precisely, then it goes through. Whether there are more features or less features, everything depends on how well the builder explained what was built. If people know that the feature exists, they will use it. Usability should be the deciding factor for killing a feature.

I'm the wrong person to ask, I'm building the maximalist version, six studios and 111 one click apps, so by your rule I already failed. But I don't think count is what confuses people, a missing spine is. Nobody calls Photoshop broad. The signal I watch is the first session: if someone can't finish one real piece of work without opening a second tab, the surface is too narrow, and if they land on ours and can't tell which of the six doors to walk through, the surface is fine and the entrance is broken. Two different fixes, and feature count tells you nothing about which one you've got.

From my experience working for startups, they usually start by trying to do everything that comes their way. Then, eventually, they get to a point where they decide what to focus on and what the product should actually look like - this is a hard part where features get killed and some customer relations have to end.

I’m more of a minimalist. A feature earns its place when it makes the main user outcome faster, easier, or more valuable. If I have to explain why a feature exists instead of users immediately feeling the benefit, it’s usually a sign it should be removed or delayed. The hardest features to kill are often the ones that are impressive but don’t actually change user behavior.

Reading the replies, most people here describe a method they chose. Honestly, we did not decide it up front. We start from a principle and let real behaviour correct us, and the corrections have gone in directions I would not have guessed.

One concrete example. We took advice from a conference talk to simplify and remove friction, and moved registration to after the free module so people could try before signing up. It looked obviously right. Our registrations dropped, so we rolled it back and changed how we position the product instead.

That is why I am wary of deciding breadth by principle alone, minimalist or maximalist. The reasonable-looking simplification was the one the data killed.

Something else I have not seen raised here: we also check what competitors include, less to copy than to tell our deliberate gaps from our accidental ones. A feature you chose to leave out and one you forgot look identical until you compare.

Two things that changed how I think about this.

First, the data answer most of these replies assume is usually not available yet. Session replays, feature votes and retention deltas all need traffic before they mean anything. I work in data and analytics for a living, and at early stage the honest position is that you do not have the sample size to separate a real preference from noise. Deciding by data on forty users a week is still a judgement call, just one wearing a chart. Better to own the judgement than to launder it.

Second, breadth and coverage get treated as one question when they are two. One thing I build generates state specific legal documents in the US. Going from fifteen states to fifty adds no features, no new concepts and nothing for a user to learn, and it roughly triples who it is useful to. A second document type would have been a feature. More states is depth on the same job. Most products I see accused of being too broad actually have shallow coverage of several jobs rather than too many features.

My kill test is whether the feature has its own audience. If the people who want it are not the people the product is for, it is not a feature to keep or cut, it is a different product asking to be built. I have moved two things out that way rather than killing them.

Nika, is your one plus two rule about the count, or about how many separate ideas a user has to hold at once? Those come apart quickly, and I suspect the second is what you are actually measuring.