How to validate an AI product idea before you build

The hardest part of building an AI product isn't the model. It's knowing whether anyone actually needs the thing you're about to spend six months building. Most founders skip this step — they fall in love with a demo, raise a little money, ship, and then discover the demand was never there. This is a playbook for doing the opposite: proving (or killing) your AI idea before you write serious code.

Start with the problem, not the AI

The fastest way to spot a weak AI idea is that it starts with the technology. "We use AI to…" is a feature, not a reason to exist. Flip it: what painful, frequent, expensive problem does a specific group of people have today — and what do they do about it right now?

If the honest answer to "what do they use instead" is nothing, because it's not that big a deal, you have a vitamin, not a painkiller. AI makes vitamins cheaper to build, which is exactly why the market is flooding with them. The winners solve a problem people were already paying — in money, time, or frustration — to work around.

Write your idea as a single sentence: "[who] struggles to [do what], and today they [current workaround], which is bad because [why]." If you can't fill that in with something specific, that's your first finding.

Name the riskiest assumption

Every idea is a stack of assumptions. Some are safe. One is usually fatal. The skill is finding the fatal one before it finds you.

Sort your assumptions into three buckets:

• Desirability — do people actually want this? (Usually the riskiest for a new product.)
• Viability — can it make money, and can you reach the people who'd pay?
• Feasibility — can it be built reliably, especially given how often AI is wrong?

For each, ask: "If this turned out to be false, is the product dead?" The one where the answer is yes and you're least sure is your riskiest assumption. Test that first. Everything else can wait.

Our free Riskiest-Assumption Finder will surface these for your specific idea and hand you the cheapest test for each — it's a good ten-minute starting point.

Test demand before you build anything

You do not need a product to test demand. You need evidence that people want the outcome. Cheap tests, in rough order of strength:

1. Talk to fifteen people in your target group. Not "would you use this?" — ask what they do today, where it hurts, and what they've tried. If the pain isn't obvious in their own words, be suspicious.
2. Watch what they already do. Search Reddit, forums, and review sites for people complaining about the current tools. A recurring complaint is a pre-validated opportunity.
3. Put up a landing page that describes the outcome and asks for an email or a pre-order. Real intent — an email, a deposit, a "when can I have this" — beats a hundred polite yeses.
4. Do it manually first. Deliver the result by hand (a "concierge MVP") before automating. If people won't take the value when a human does it, an AI won't save you.

The bar is simple: are people willing to give you something scarce — time, money, or their email — for the promise of this outcome? Enthusiasm is free. Commitment is signal.

Look hard at the landscape

"No competitors" is almost never good news — it usually means no market, or that you haven't looked. Map who's already out there, how they're positioned, and where users are underserved. The gap you can own is usually a specific complaint about existing tools, not a blank space.

This is also where you pressure-test whether AI is actually your edge. If three funded companies already do this with AI, your wedge has to be sharper than "we also use AI" — a narrower audience, a better experience, a workflow the incumbents can't copy without breaking their own product. Our Market Need Analyzer and Competitor Landscape Teardown are built for exactly this read.

Set kill criteria in advance

The reason validation fails is that founders move the goalposts. You run the test, the result is lukewarm, and you talk yourself into building anyway. Prevent this by deciding before the test what result would make you stop or pivot.

For example: "If fewer than five of fifteen people describe this problem unprompted, I rethink the audience." Written down in advance, a weak result becomes information instead of a threat to your ego.

Then — and only then — scope the smallest real version

Once demand looks real and you know your riskiest assumption is survivable, the job changes from should we build this to what's the smallest thing that proves it. That's a different discipline — finding the single core loop and scoping an MVP around it — which we cover in finding the core loop.

Validation isn't a phase you finish; it's a habit. But doing the cheap version up front is the highest-leverage work an early founder can do. It's the difference between building the right thing slowly and the wrong thing fast.

---

Working through this for your own idea? The free AI Product Readiness Scorecard gives you an honest read in a couple of minutes — or, if you'd rather think it through with people who do this daily, that's exactly what our AI Product Strategy work is for.