How do I decide what to build first?

It’s the question we hear most often from founders who come to us after months of building, and it’s almost never asked by someone who’s had an easy time answering it.

Usually, there’s a long list, a stretched team, a budget that’s already smaller than it was, and a creeping suspicion that the product has grown into something nobody fully understands anymore.

The honest answer is that there isn’t a framework that works cleanly for every product. But there is a way of thinking about it that keeps founders from the most expensive mistake in early builds: treating scope as a planning problem instead of a learning problem.

Start with the problem, not the list

We never start with the backlog. We start with the founder, usually mid-explanation, trying to articulate who this product is actually for and what goes wrong in their life without it.

When that explanation slides into pitch language (“category-defining,” “end-to-end,” “democratizing X”) it’s usually a sign that the features have gotten ahead of the problem. Building has become a way to feel productive while avoiding the harder question of what, precisely, hurts and for whom.

So we stay with the problem longer than feels comfortable. We ask for an example: one specific person, one specific moment, what they tried before this, and why it didn’t work. We keep going until the problem sounds like something someone would actually say to a friend, not something you’d put on a pitch deck.

Only then does it make sense to talk about what to build.

Figure out what absolutely has to work

For a first version, we’re not trying to cover every possible path through the product. We’re trying to make one path, from “I have this problem” to “this helped”, actually work.

That means mapping a simple journey: how someone finds the product, what they do to get started, what they do inside it, and how they know it worked. Once that path is on the table, we look for the places where, if this step fails, nothing else matters. Those become non-negotiable.

Everything else is negotiable, and we use the word “everything” quite intentionally. Configurable settings, multiple views of the same data, sophisticated filters, and polished edge cases all feel important because other products have them, but in a first version, the only question worth asking is whether a feature changes what you learn from this release.

If the answer is no, it moves down.

This is usually the moment when the list shrinks faster than anyone expected, and tends to be the first sign you’re actually prioritizing rather than just documenting.

Protect the value moment

Every product has a moment when a user decides whether it’s worth their time. Sometimes it’s obvious: a report that finally shows the right numbers, a payment that clears, an introduction that actually happens. Sometimes it’s smaller: a nudge that arrives before someone forgets, a piece of friction that quietly disappears.

Either way, there is a moment where the promise stops being theoretical, and your user goes, “Aha!”

That moment is where we concentrate most of the early effort. We want to know what needs to load, calculate, connect, or display so that this moment feels solid. A slightly awkward onboarding is survivable. A bare-bones account page is survivable.

A value moment that feels brittle or unreliable is not.

Users leave before they experience what the product is supposed to do, which means you never learn anything useful from the release. Protecting that moment, keeping it clear, dependable, and easy to reach, is usually more important than shipping every feature that felt essential in the planning session.

Keep it manual until you know what you’re automating

A lot of overbuilt products come from discomfort rather than ambition. Founders feel uneasy charging money when parts of the product are still held together by human effort. Teams relax when the system looks polished, even when the underlying business is still unproven.

The problem is that automation freezes decisions. Once a workflow is baked into code, changing it becomes expensive, and you stop touching it even when you can see it’s not quite right.

So we sometimes have to draw a line: if a step doesn’t have to be instant or self-serve for the user to feel the value, it can be manual for a while. Approve early accounts by hand. Run reports for the first few customers. Stitch together data behind the scenes instead of building a full integration.

It’s not glamorous, but it keeps you close to the work. You see where people stumble. You avoid spending months engineering a process you might end up discarding.

Ask what job each feature is doing right now

By the time a feature shows up on a roadmap, it usually has a story and a champion. That’s not a reason to build it.

The question is what job it does at this specific stage of the product, and whether you’re willing to be wrong about it. Some things have to be right from the start: the core outcome you’re promising, anything involving money or compliance, the moment where a user decides whether to trust you. Everything else is a place where being imperfect for now is a reasonable trade.

When we evaluate a feature, we ask: Does it change whether a user can complete the core workflow? Does it change whether we trust the outcome we’re showing them? Could early users get the same value if we handled it manually?

If none of those answers is yes, it doesn’t belong in the first version.

This tends to surface the features that exist to make the team feel better, like extra analytics, auxiliary dashboards, elegant but non-essential flows. Not bad ideas. Just not doing real work in the experiment you’re running with version one.

Define “enough” before you build anything

If you don’t define what “done” looks like before you start, you will always feel one feature away from being ready.

So before the build begins, we ask founders to write down a few plain markers of success. They don’t need to be elaborate: ten people complete the core workflow within a month; a couple of customers say they’d be annoyed to lose access; the team can deliver the promised outcome within a reasonable timeframe, even when some of the work is still manual.

These are boring on purpose. They exist so that after launch, you can look at real behavior and answer one question: did we see what we said we wanted to see?

When those signals appear, you have permission to invest further. When they don’t, you have a clear reason to pause rather than responding to a quiet launch by adding more product.

Be willing to actually kill things

Real triage doesn’t just push features into phase two. It kills them.

If everything simply moves one release later, you’re not making decisions, you’re postponing them. When we de-scope something, we write down why: it doesn’t change whether a user experiences the core value, it doesn’t test a meaningful assumption, it makes the product feel more substantial without making it more useful.

That record is critical. The next time someone wants to bring an idea back, we can check whether anything has changed. Sometimes it has! The product is more mature, the audience has shifted, the business model is clearer, but often nothing has changed, and the original reasoning still holds.

Having it written down makes it easier to say no again without relitigating the whole history of the idea.

What this actually looks like

In practice, triage isn’t a single workshop where you solve the roadmap. It’s a series of small, steady edits.

A founder sends through a long list of non-negotiables. We cut it down and write out why certain things moved. The team ships a thinner version than they’re used to. Real people use it. Some get stuck in places nobody anticipated. Some invent workflows that weren’t planned for. Some do exactly what you hoped, which is useful in its own quiet way.

You take that and adjust. Features you assumed were essential drop away. Things you thought were optional become important because they unblock the core path or clarify the value moment. The roadmap shifts, not because you’re chasing every request, but because you’re constantly re-deciding what matters based on what you’re actually seeing.

What it gives you is a product that grows at the same pace as your understanding, rather than racing ahead of it. A clearer answer when someone asks why your product looks the way it does, and why you chose to build it this way first.

That turns out to be a more valuable thing to say than most founders expect.