How I Decide What to Build Next

The advice is to be data-driven and ship what users want. Fine — but in practice that collapses into one of two defaults, and both are traps. The first is building the loudest thing: whatever was asked for most recently or most insistently. The second is building the most fun thing: the refactor I've been itching to write, the shiny rewrite that scratches an engineering itch. Neither is necessarily what matters. After shipping Delivery Sheet and Listemizde solo, the hardest ongoing decision isn't scoping a new product — I've written about where I draw the MVP line — it's choosing what to build next inside one that's already live. That's a different discipline, and the defaults will make it for you if you let them.

The two defaults, and why both lie

The loudest thing feels responsive. Someone asked, so you built it — that's listening to users, right? Except "loudest" is a measure of volume, not importance. The person who emails twice and posts once is not automatically describing your biggest problem; they're describing theirs, at the top of their voice. Ship to the loudest and your roadmap becomes a queue ordered by who complained most recently.

The shiny thing feels productive. Rewriting that tangled module, adopting the new framework, the refactor that would make everything cleaner — it's real work, it's satisfying, and it produces a commit history that looks like progress. But most of the time it's motion the user never sees. I'm not against paying down debt; I'm against dressing up "the thing I felt like building" as "the thing the product needed." The tell is that the shiny refactor is always most attractive precisely when the important work is boring.

What I actually build from

Strip both defaults away and three sources of signal remain.

The recurring problem, not the one-off ask. One person hitting a wall is an anecdote. The same wall showing up in five different conversations, worded five different ways, is a priority. I'm looking for the pattern underneath the requests, not reacting to each request as it lands.

What removes a reason people churn or don't convert. Delivery Sheet ships with no free plan — people either get enough value to pay or they don't. That makes the question sharp: what's stopping someone who has the problem from getting the outcome? A feature that removes a real reason people bounce beats ten features that merely add surface area.

What the tickets and consented analytics keep pointing at. Support tickets are the unfiltered version of the recurring problem — people don't open a ticket for fun. And analytics I only collect after consent tell me where people actually stall, as a pattern across many users rather than the testimony of the single loudest one. That distinction is the whole game: one insistent voice is a data point; a shape across the data is a direction.

Most requests are a problem wearing a solution

Here's the reframe that changed how I read every feature request. A request is almost never the thing to build — it's a real problem that a user has already diagnosed and prescribed for. They felt a pain, guessed at a fix, and sent me the fix. The pain is the gold. The fix is one person's first guess.

This is exactly the philosophy Delivery Sheet is built on. The whole product exists to turn a vague leadership ask into a clear, reviewable delivery decision — commit, shape, pause, or decline. "Shape" is the recognition that the ask as delivered is rarely the ask as meant; you have to reshape it before you can decide well. My roadmap runs on the same move. When a request comes in, I shape it: what's the problem underneath, how many people have it, and is the requested feature even the right answer to it? Often it isn't. Often five different-sounding requests turn out to be the same problem, and the right build is one thing none of them named.

"

A feature request is a real problem wearing a specific solution. My job is to build the problem, not the costume it arrived in.

The roadmap is mostly a list of noes

For one person, the roadmap is not the list of things I'll build. It's mostly the list of things I decided not to. I can build one thing at a time, which means every yes is a no to everything else that period — the saying-no is the actual work, not the paperwork around it.

And the noes protect something specific: focus. Adding features is precisely how a sharp product becomes a vague one — not in one bad decision, but in a hundred reasonable yeses, each defensible on its own, that together blur what the thing is for. This is why I build narrow in the first place, and the discipline doesn't stop once the product ships — it gets harder, because now there are real users each pulling toward their own edge case. Listemizde is built on community recommendations with no paid rankings; the fastest way to wreck it would be to keep bolting on reasonable-sounding features until nobody could say what it was anymore. Every yes to a feature is a no to focus, and focus is the product.

Docs versus reality

On paper, the backlog is the roadmap — a tidy list where every idea sits at equal weight, waiting its turn. That's the graveyard. In a backlog everything looks buildable, everything looks reasonable, and nothing is prioritised, because a list can't tell you which of its items matters.

The reality is that the shipped thing is the one I decided mattered — on purpose, against the pull of the loudest request and the shiniest refactor. Prioritising isn't sorting the backlog; it's the deliberate act of pulling one problem out and declaring it more important than the rest, then defending that call when the next loud email lands. Same move as my kill criteria, pointed forward instead of back: the honest question is never how many people asked, it's whether this is the problem most worth the only pair of hands I've got.

Build from the recurring problem, not the loudest voice. Build the problem, not the request. Treat every yes as a no to focus. Do that and the roadmap stops being a graveyard of equal ideas and becomes what it should be — a short, deliberate list of things you decided mattered.

Part of Building AI Products. See also how I scope an MVP and my kill criteria for product experiments. The newsletter sends one practical build lesson every two weeks.