More features, further from done: the founder's favorite mistake

The most common early-stage illusion isn't "not building" — it's building nothing but additions. One user asks for export, add it; a competitor ships dark mode, copy it; an investor muses "what about a community?" and it lands in next sprint. Three months later the feature list has doubled while core-flow completion hasn't moved. The product isn't closer to done; it's just fatter.

Numbers make it blunt. Across the early projects we've coached, feature usage is almost uniformly 80/20: 20% of features carry 80% of real usage, while tail features are touched by under 2% of monthly actives — yet they eat over half the dev effort and produce most of the bugs and support tickets. Microsoft's internal Office research found the same pattern: users reliably use only a handful of core commands, which is why Office 2007 dared to scrap the decade-old menu bar for a task-oriented Ribbon. Subtracting features didn't hurt usage; usability scores actually went up.

Why the additions never stop

• Saying no to a real face is hard. Behind every request is a paying customer, a friendly user, an investor. Refusing "one more feature" feels like refusing the person, so every request becomes a ticket.
• Additions look like progress. Shipping three small features makes a great weekly update; polishing the same flow for the fourth time looks like nothing happened. But the former spreads the surface thinner — the latter digs the moat.
• Competitive pressure is mostly illusion. Users leave because your core path breaks, not because you lack a rival's edge feature. Building from a competitor's feature list lets them set your priorities.

Before adding anything, ask three questions

• Does the core path get faster or more roundabout? After shipping, does a new user's first successful key action get quicker or slower? Judged on this alone, half the requests eliminate themselves.
• If you deleted it in three months, would it hurt? If not, it was optional all along. The features that hurt are the ones worth investing in.
• Is there a cheaper fix? A manual reply, a spreadsheet template, an @-mention in the group often absorbs the job. Serve the demand by hand first; write code only when the manual route breaks.

Product completeness measures whether the core path works end-to-end on the first try — not feature count. A product with 8 features and a checkout that never fails is far more complete than one with 30 half-finished ones. Users smell "unfinished" instantly; one broken step cancels ten small delights.

At 51Kaifa, every MVP starts by fixing "one core path": before launch, every request passes the three questions above and gets cut until a user can walk the whole loop in one go. Our experience: the harder you cut version one, the more confident your version-two additions — because by then you're holding real data, not guesses.