How do you decide what to build next as a founder?

The decision of what to build next is less about inspiration and more about discipline: you need a clear signal from users, an honest read on your current trajectory, and the habit of completing one thing before chasing the next. Get those three right and the backlog largely sorts itself.

Start with what users are actually blocked on, not what you wish they wanted

The most reliable input for your next build decision is a specific user who cannot do something they need to do right now. Not a survey response, not a roadmap vote, not a competitor's changelog — a real person hitting a real wall. The question to ask is: what does this user see, lose, wait for, or fail to accomplish because of something missing in the product today? That framing forces you to connect every candidate feature to a concrete outcome rather than an abstract capability.

Garry Tan's product philosophy, visible in how he talks about builder judgment, consistently emphasizes tying technical choices to what the real user experiences. A feature that improves an internal metric nobody sees is a lower-priority candidate than a fix that removes a friction point users encounter every session. Before you write a single spec, name the user, name the friction, and name what changes for them on the day you ship. If you cannot do that in two sentences, the idea is not ready to build.

This discipline also filters out 'ocean' projects — rewrites, platform migrations, and multi-quarter architectural investments that absorb enormous time without delivering anything a user can touch. Those projects sometimes need to happen, but they should be scheduled deliberately, not allowed to crowd out the work that drives retention and revenue.

Use your fundraising trajectory as a forcing function on priority

Paul Graham's analysis of how startups move between funding phases has a direct implication for build decisions: whatever you ship next needs to move you toward a provable trajectory, not just fill a sprint. In early stages, the proof is that the experiment works. In later stages, the proof is usually economic. If you cannot explain how the next thing you build contributes to one of those proofs, it is likely displacement activity.

This matters because the failure mode Graham identifies — where companies drift for a year without urgency and then discover they cannot course-correct — is a product failure before it is a financial one. Teams that are not building toward a clear outcome tend to build features that feel productive but do not compound. The question is not 'is this a good idea?' but 'does shipping this make the next fundraise or the next revenue milestone more achievable?'

Practically, this means your backlog should be sorted by impact on the metric that proves your experiment is working, not by engineering interest or stakeholder loudness. If that metric is activation rate, every candidate feature gets evaluated on whether it moves activation. If it is net revenue retention, the filter is retention. Picking one metric per quarter and running your prioritization through it is not a constraint on creativity — it is how you avoid building a graveyard of launched-but-ignored features.

State your approach before you build, not after

One of the most underrated prioritization skills is the brief, written plan you write before starting anything non-trivial — not a full spec, just enough to surface whether the approach is right before you are halfway through execution. The value is that it creates a cheap correction point. If your plan has a flaw, it is far better to discover it in a paragraph than after a week of implementation.

This habit also forces you to answer a question most founders skip: is this feature the right solution, or just the most obvious one? When you write down the approach, you often notice that the user problem could be solved three different ways and you defaulted to the most technically interesting one rather than the fastest or most effective one. The act of writing it out surfaces that choice explicitly so you can make it on purpose.

For complex work — architectural changes, new data models, features that touch many parts of the product — this pre-work should include a completeness estimate: are you building for the happy path only, or are you covering the edge cases and error states that real users will hit? Shipping something that works 80% of the time can be worse than not shipping it, because you now own the support burden for the 20% failure rate. Be honest about what you are actually committing to.

Mark things done one at a time and let incompleteness surface

A practical discipline that changes how teams prioritize is the rule of completing and marking tasks individually rather than in batches. When you batch-close tasks at the end of a project, you obscure which pieces were actually finished, which were skipped, and which were quietly dropped. That obscurity makes it hard to learn from the build cycle and makes future estimates unreliable.

The same principle applies at the roadmap level. Founders who carry a rolling list of half-built things — features launched but not instrumented, integrations built but not documented, onboarding flows shipped but never tested with real users — have a prioritization problem masquerading as a capacity problem. The solution is not to work faster. It is to finish fewer things completely before starting the next one.

When a task turns out to be unnecessary, explicitly marking it skipped with a one-line reason is not bureaucratic overhead — it is institutional memory. Six months later, when someone asks why a certain capability was never built, the answer is available. More importantly, the pattern of what you skip reveals your actual values versus your stated ones, which is useful information for a founder trying to build a coherent product rather than a collection of adjacent features.

High-stakes ambiguity deserves a pause, not a guess

Some build decisions are genuinely hard because the right answer depends on information you do not have: what your users will do with a capability you have never shipped, how a market will respond to a new pricing model, whether an architectural choice will hold at ten times your current scale. In those cases, the discipline is to stop and name the ambiguity explicitly rather than resolve it by defaulting to whatever feels most comfortable.

A useful structure is to write out two or three real options with their tradeoffs before committing. Not theoretical options — real ones you could actually execute. The act of writing the tradeoffs often makes the right answer obvious, but even when it does not, you have at least made the decision consciously rather than by drift. The user — in this case, you as the founder — has context the framework does not: domain knowledge, timing, relationships, and taste. A framework can recommend; you decide.

What this means practically is that the best founders have a short list of things they are genuinely uncertain about and they seek resolution on those items deliberately, through user conversations, small experiments, or direct competitive research. They do not leave that uncertainty unresolved in the background where it silently shapes decisions without being acknowledged. If you are building the wrong thing because you guessed wrong on a key assumption, you want to find out as early as possible — and that requires naming the assumption as an assumption in the first place.

“Usually the proof is profitability. Usually phase 3 fundraising has to be type A fundraising.”

— Paul Graham, source

The one thing to do

Before starting anything non-trivial, write two sentences: who the specific user is and what concretely changes for them the day you ship — if you cannot, the idea is not ready.

Frequently asked questions

How do I choose between fixing bugs and building new features?

Ask what a real user encounters more often: the bug or the absence of the feature. Bugs that affect every session for a significant portion of users almost always outrank new features, because they destroy retention before new capabilities can create it. Quantify the failure rate before making the call.

What if my team disagrees about what to build next?

Disagreement usually means the decision criterion is unclear, not that the people are wrong. Align on the one metric you are optimizing this quarter, then re-run the debate through that lens. Most disagreements dissolve when everyone is evaluating options against the same explicit goal.

How do I avoid building features nobody uses?

Name the specific user and the specific friction before you start. If you cannot describe what changes for a real person on the day you ship, the feature is not grounded in an actual need. Talking to users after launch to check adoption is too late — that check should happen at the idea stage.

How far ahead should a startup plan its roadmap?

Plan in detail for four to six weeks and hold the rest loosely. Beyond six weeks, user feedback and market signals will likely invalidate specific feature plans anyway. What you should keep stable is the outcome you are building toward, not the list of things you plan to ship.

Sources

More playbook answers · Growth Prophet home