When Should a Founder Stop Adding Features and Fix the Core Problem?

A feature request is evidence about a problem, not automatically a specification for what the company should build.

The difficult decision is not whether customers matter. It is deciding when another feature is the right response and when the request is exposing a deeper product, positioning, workflow, or reliability problem. A founder who treats every request as a roadmap item can end up with a larger product that solves the wrong problem more completely.

Before accepting a feature request, reconstruct the situation that produced it.

Ask:

• What was the customer trying to accomplish?
• What happened immediately before the request?
• What workaround exists today?
• What does that workaround cost?
• How often does the problem occur?
• Who else has the same problem?
• What would actually change if the feature existed?

Y Combinator's startup guidance emphasizes launching, talking to users, iterating, and finding a useful 90/10 solution rather than waiting for a perfect product.

A requested solution and a customer need are different evidence.

A request for a dashboard may really mean the customer lacks visibility. A request for export may mean they need auditability or handoff. A request for automation may mean the current workflow is simply too repetitive.

Record each request as:

1. Requested change.
2. Underlying job.
3. Evidence of frequency.
4. Cost of the workaround.
5. Customers affected.
6. Business consequence.

This makes the roadmap a record of problems and evidence rather than a list of preferences.

Several different requests can point to one underlying problem.

If one customer asks for alerts, another asks for scheduled reports, and another asks for a dashboard, the shared problem may be visibility. That is a better product question than deciding which requested feature gets built first.

Public founder discussions show the same tension between building functionality and staying close to users. They are useful qualitative evidence, not representative market data.

Use increasing evidence before increasing build size.

Level 1: stated preference. Someone says a feature would help.

Level 2: repeated problem. Relevant customers describe the same underlying issue.

Level 3: costly workaround. People already spend time, money, or attention solving it.

Level 4: commercial consequence. The issue affects conversion, retention, expansion, implementation, or risk.

Level 5: tested solution. A small intervention changes the intended outcome.

A Level 1 request should rarely justify a large build by itself.

Ask:

"What is the smallest intervention that solves most of the important problem?"

Possible answers include:

• better onboarding;
• a default;
• a report;
• a manual service layer;
• a narrow feature;
• an integration;
• a configuration change.

YC explicitly recommends looking for 90/10 solutions because a useful partial solution can be preferable to a complete solution that takes too long to ship.

Do not turn customer focus into feature avoidance.

A larger build may be justified when:

• the problem is repeated across the intended market;
• the workaround has become expensive;
• the capability is necessary for a key workflow;
• the missing capability creates meaningful security, compliance, accessibility, or reliability risk;
• the feature is important to a strategically relevant segment;
• a smaller experiment has already shown useful evidence.

The question is not whether a feature is large. It is whether the evidence supports its cost and complexity.

Founders can make four errors.

First, one large customer silently becomes the product roadmap.

Second, every request is treated as a vote, even though customers have different needs and commercial importance.

Third, a product problem is mistaken for a feature problem.

Fourth, the team measures shipping activity rather than whether the underlying customer outcome improved.

Use this sequence:

Problem: What is actually failing?

Evidence: How often and how costly is it?

Audience: Which intended customers experience it?

Alternative: Can a smaller solution work?

Test: What can be learned before a large build?

Commitment: What evidence would justify making the capability permanent?

If the problem is important, repeated, costly, strategically relevant, and the proposed solution survives a small test, building may be justified.

If the request is isolated or vague, investigate before committing the roadmap.

Connect this with SOE's work on testing demand, customer interviews, product-market fit, and founder focus. Together they form a path from customer problem to evidence to product decision.

This article uses Y Combinator's published startup guidance as the primary source for customer learning and early product iteration, plus public founder discussions as qualitative context. Community posts are not treated as representative evidence. The evidence ladder and decision framework are SOE editorial synthesis, not a validated scientific score.

Stop adding a feature when the evidence points to a different problem, a smaller solution, a different customer, or a more fundamental product failure. Keep building when the underlying problem is important, repeated, costly, strategically relevant, and the proposed capability has survived a meaningful test.

The founder's job is not to say yes or no to every request. It is to understand what the request is evidence of and choose the smallest useful response.