How do you know if a product idea is worth building?

I run it through a short filter before writing any code: is it a real problem I've hit repeatedly (not a clever idea), can I state the outcome in one sentence a user would recognize, is it small enough to ship solo, is there a plausible path to someone actually caring (distribution or willingness to pay), and would I genuinely use it myself. An idea has to pass all of these. If it fails any, it goes on a not-now list rather than into development, because the cost of building the wrong thing is the same whether you're a team or one person.

What is the biggest mistake when choosing what to build?

Building a clever idea instead of a felt problem. Ideas are abundant and seductive, especially when AI makes building feel cheap — but most of them solve a problem nobody actually has badly enough to change behaviour. The fix is to only build problems you've personally met more than once and wished something existed for. That single filter kills more bad projects than any amount of market research, because lived, repeated friction is the strongest signal that a problem is real.

Should you validate a product idea before building it?

Yes, but for a solo builder the cheapest validation is a hard filter applied to your own honest answers, not a big research project. Can you state the outcome in one sentence? Have you hit the problem repeatedly yourself? Is there any path to distribution or payment? Would you use it? If the honest answers are weak, no amount of building will fix it. Fast, honest self-filtering up front beats validating a wrong idea slowly by building it.

How I Decide Whether an AI Product Idea Is Worth Building

The standard advice for choosing what to build is to validate it — run surveys, interview users, hunt for product-market fit before you commit. That's the textbook answer, and for one person it's mostly an elaborate way to postpone the decision. Here's the filter I've earned instead. Before I write a line of code, an idea has to clear five honest questions: is it a real recurring problem I've hit, can I state the outcome in one sentence, is it small enough to ship solo, is there a path to someone caring, and would I use it myself? Fail any one and it doesn't go into development. It goes on a not-now list. The filter costs nothing, and it kills bad projects before they cost me months — which matters more now that AI has made building feel almost free.

The problem with cheap building

When building was expensive, the cost did the filtering for you — nobody spends six months on a maybe. AI took that filter away. I can now build almost anything in a weekend, which sounds like a gift and isn't: it moves the whole discipline earlier, onto deciding what deserves to exist at all. Skip that and "I could build that" slides quietly into "I'm building that," and you look up with a folder of half-finished answers to questions nobody asked. Delivery Sheet exists because it cleared the filter. Several ideas I liked more never did.

The five tests

Every idea has to pass all five:

Have I hit this problem repeatedly? Not "is this clever" — have I personally run into this friction more than once and wished something existed? Lived, repeated friction is the strongest signal a problem is real. Everything else is a guess.
Can I state the outcome in one sentence? If I can't say, in a line a user would recognize, what's true when it works, I don't understand the idea well enough to build it.
Is it small enough to ship solo? One person has to build it, run it, and support it. If it needs a team or a moat of infrastructure, it isn't a solo product, however good it is.
Is there a path to someone caring? Some honest route to distribution or willingness to pay. Not a business plan — just an answer to "how would anyone find this, and why would they use or pay for it?"
Would I use it myself? If I wouldn't, I don't understand the problem well enough to build the right thing for the people who would.

The not-now list

A builder whose every idea turns into a project isn't disciplined; he's just busy. Saying "not now" on purpose is what protects the attention for the one idea that passed.

Why this is the highest-leverage decision

The cost of building the wrong thing is the same whether you're a team or one person — you just feel it more alone, because there's no one to absorb the wasted months. So choosing well beats building fast: shipping quickly in the wrong direction is still the wrong direction, now with momentum behind it. I learned this watching enterprise programmes fail — almost never on execution, almost always on committing to the wrong outcome first. The problem, not the solution, is what needs checking first.

What usually goes wrong

Falling for clever ideas. Building something interesting instead of something needed — the classic solo trap, and worse now that AI makes the interesting thing easy.
No stated outcome. Starting before you can say in one sentence what success is, so the product wanders and never quite arrives.
Ignoring distribution. Building with no honest path to anyone finding it — a product that ships straight into silence.
Every idea becomes a project. No not-now list, so attention smears across too many half-built things and none of them ships.

Run the five questions, put the failures on the not-now list, and build only what passes — and your scarce solo attention goes to problems that are real, understood, shippable, and wanted. It's the front gate of my whole operating system, and the quiet decision that determines whether any of the rest works.

Part of Building AI Products. See also my product operating system and why I write the expected output before the screen. The newsletter sends one practical build lesson every two weeks.