How to know what to build, when AI lets you build anything

There is a moment in any AI-assisted project where the cost of building drops below the cost of thinking. You can describe a product to Claude in a paragraph and have a working prototype in an hour. The machine never gets tired, never asks "are you sure", never points out that nobody actually needs this.

That is the trap. The tools are not the problem. They are extraordinary. The problem is that they have made the building part cheap without making the being-wrong part any cheaper. A wrong idea still burns real time and real attention, and AI now lets you burn it faster and across more wrong ideas at once.

This creates a question that did not exist before: if the prototype only costs a weekend, is the prototype itself the validation? The answer is usually no. A working prototype proves you can build the thing. It does not prove anyone needs it, will pay for it, or will come back. Validation is still a separate discipline. What has changed is the temptation to skip it, because the build is no longer the bottleneck.

This post expands on the opening item of the series overview: start with the problem, not the prompt. Product validation is the discipline that decides whether the rest of the work is worth doing. I have spent years running it, first in market and UX research, then in product management. None of this is hard to learn. The hard part is making yourself actually do it.

What validation is, and what it is not

Validation is not asking your friends if they like your idea. They will say yes. Friends are the worst possible source of signal because they are biased toward making you feel good and they are not the people who will actually use the thing.

Validation is not a survey of 200 people asking "would you pay £10 a month for this?" Surveys measure what people say. Behaviour measures what people do. The gap between the two is large enough to bury most products that were validated by surveys.

Validation is not the moment after you launch when you check whether anyone signed up. By then you have already spent the time, paid the cost, and built the wrong thing. Whatever you learn from launch metrics is feedback for version two, not validation for version one.

What validation actually is: a structured attempt to prove yourself wrong about the problem, the audience, and the solution before you commit serious time to building. The keyword is wrong. You are not looking for evidence that your idea is good. You are looking for evidence that it is not, because the only evidence that survives an honest search is the evidence worth building on.

If that sounds like the scientific method, that is because it is.

The three things you are actually validating

A quick distinction before going further. Research and validation are not the same thing. Research is what you do to understand the problem, the audience, and the way they currently cope. Validation is what you do to test whether any of them will commit something (money, time, signature, waitlist spot) to the solution you are proposing. You do research first so that you know what hypothesis to validate. The first question below is really a research question. The second two are validation questions. In practice the line blurs, but keeping the distinction in mind stops you from calling it "validation" when you have only done research.

Most builders treat validation as one big question and answer none of it properly. Break it into three smaller questions and ask them in order:

1. Does the problem actually exist?

Not "would this thing be useful?" but "does anyone currently have a workaround they hate, a tool they curse at, a workflow they postpone, or a cost they pay quietly because they have not found a better option?" Real problems have evidence in the present tense. People are already doing something painful. Your job is to find them and watch them do it.

2. Does the right audience have it?

A problem that one person has is a curiosity. A problem that a defined, reachable group has consistently is a market. The question is not just "does this exist" but "can I describe the people who have this in a way precise enough to find more of them tomorrow?" If your audience is "small business owners" you have not done this work. If it is "independent retail shop owners in the UK who use Square as their POS and currently lose two hours a week to manual inventory updates" you have.

Three measurements matter for the audience answer: how many people fit the description, how often the pain hits them, and how badly it hurts when it does. A small group with daily, severe pain is usually a better starting market than a huge group with an occasional mild irritation. If you cannot put rough numbers on all three, keep asking.

3. Will the proposed solution actually solve it?

This is the third question, not the first, and skipping straight to it is the most common mistake. You are not testing your build. You are testing whether the shape of your proposed solution would meaningfully change the workflow of the person with the problem. The build comes later.

You can be right about question one and wrong about questions two and three. You can be right about all three and still build the wrong product because you did not test the price, the channel, or the timing. But getting questions one through three right gets you most of the way there. Skipping them gets you a beautiful prototype nobody opens twice.

Who to talk to (and how to find them)

The smallest useful validation effort is a handful of conversations with the right people. Three is the bare floor. Five is more comfortable. Not 50 emails. Not a survey. Real conversations, scheduled, with specific humans who match your audience description, where you ask them about their existing behaviour, not your idea. Better still, watch them work. People are unreliable narrators of their own workflows. Watching what they actually do is the difference between "I spend maybe ten minutes on this" and seeing the forty-five real minutes unfold, tabs open, shortcuts fumbled, quiet curses included.

The hard part is finding them. A few patterns that work:

• Communities where the audience already gathers. Subreddits, Slack groups, Discord servers, professional associations, LinkedIn groups, niche newsletters. Spend a week being useful in these places before you ask anyone for their time. Then ask in public, not in DMs.
• Your own network, two hops out. Not your friends directly, but your friends' colleagues. "Do you know anyone who runs an indie refill shop in the UK and might be willing to chat for 20 minutes?" Two-hop introductions are warm enough to convert and cold enough to be honest.
• Cold outreach with a specific ask. A polite, short message that explains who you are, why you are asking them specifically, what you want (a 20-minute call, no agenda beyond learning), and what is in it for them (a free coffee, an early look at what you build, or just the satisfaction of being heard). Response rates on cold messages vary wildly, but a targeted, well-written ask gets a small but useful reply rate. Plan to send tens of messages to get a handful of calls.
• Going where they are physically. For local or vertical products, this still works in 2026. A morning in three indie shops will teach you more than a month of surveys.

A common mistake is talking to people who kind of match the audience and then generalising from them. A conversation with the wrong person is worse than no conversation, because it gives you false confidence. It is better to have three calls with the right people than ten with the wrong ones.

Where AI actually helps in this stage

Ironically, the same tools that tempt you to skip validation are genuinely useful during it, as long as you use them for the boring parts. A few concrete uses:

• Drafting outreach messages that feel human. Give Claude the context (who you are, who they are, what you want) and iterate until the message does not sound like a sales email.
• Synthesising interview notes. After five 30-minute calls you have 150 minutes of transcript and a fuzzy memory. Paste the notes into Claude and ask it to cluster the themes, flag contradictions, and pull out the recurring language your audience uses. It is faster than doing it by hand and often catches patterns you missed.
• Finding the communities. "Where do independent UK refill shop owners gather online?" is a question Claude can answer in a few seconds and would take you an hour of Googling.
• Generating interview question drafts, then ruthlessly pruning. The machine produces ten questions. You pick the three that ask about the past rather than the future.

What AI cannot do for you: run the interviews, read the micro-expressions, or tell the difference between a polite "sure, that sounds interesting" and genuine enthusiasm. The human parts are still human.

The questions that work

The single best book on this is Rob Fitzpatrick's The Mom Test. The premise is simple: ask the kind of questions that would get an honest answer even if you were asking your mum about your business idea. Bad questions invite flattery. Good questions surface facts.

A few rules that translate any topic into questions that work:

Ask about the past, not the future. "Tell me about the last time you had to do a stock count" is a fact. "Would you use a tool that automates stock counting?" is a wish. People are unreliable narrators of their future selves and reliable narrators of last Tuesday.

Ask for stories, not opinions. "Walk me through what happened the last time this went wrong" is a story. "Do you think this is a problem?" is an opinion. Stories contain detail, friction, and emotion. Opinions contain whatever the person thinks you want to hear.

Ask what they have already done about it. "Have you ever tried to solve this? What did you try? Why did it not work?" If they have never tried to solve a problem, the problem is probably not painful enough to matter. The presence of a half-broken workaround is one of the strongest signals you can find.

Ask what they have spent. Time, money, attention, political capital. "How much time per week does this cost you?" "Have you ever paid for a tool that tried to solve this?" Spending is the strongest signal because it is real. Anyone can claim to care about a problem. People who paid money have voted with their wallet.

Avoid your idea entirely until the end. Not because it is precious, but because the moment you describe what you are building, the conversation flips from research to sales pitch and you stop learning. Save the pitch for the last five minutes, if at all. The first 25 minutes are for them.

A few questions that almost always lie to you:

• "Would you use this?" They will say yes.
• "Would you pay for this?" They will say yes.
• "Is this a good idea?" They will say yes.
• "What features should it have?" They will design a Frankenstein.
• "How much would you pay?" Whatever number flatters their self-image.

Banish these from your interviews. They sound like research and they produce noise.

When interviews are not enough

Five interviews can confirm that a problem exists, that an audience has it, and that your proposed solution shape is roughly right. They cannot tell you how many people will actually click subscribe, pay, or come back next week. For that you need a lightweight test that produces behaviour, not opinions.

A few that work for solo builders:

Landing page tests. Build the smallest possible page that describes the product as if it already existed, with a single call to action: an email signup, a waitlist, or a "notify me when it launches" button. Drive a small amount of targeted traffic to it: a Reddit comment, a Twitter thread, a £20 Google ad. Measure signups against visits. If almost nobody signs up, your messaging is wrong, your audience is wrong, or your premise is wrong. Find out which.

Do the job manually first. Instead of building the product, do the work by hand for the first few users. If your idea is "an AI that automates X", just do X yourself for five customers and see whether they keep coming back. If they do, you have validated demand and learned the workflow well enough to automate it properly. If they do not, you have learned that the problem is less painful than you thought without writing a line of code. (This is sometimes called a concierge MVP.)

Charge before you build. The strongest possible signal short of an actual product. If someone pays £20 for a discounted lifetime account before the product exists, they are telling you something a survey never could. Pre-sales and paid waitlists prove willingness to pay in a way that "would you pay for this?" never can.

Measure interest with a fake button. Add the proposed feature to an existing product as a button that does nothing except log the click. Measure click-through. People who click are telling you they want the thing. People who do not are telling you the messaging or the placement is wrong. (This is sometimes called a painted door test.)

The point of all these tests is the same: replace opinions with behaviour. Behaviour is harder to fake.

How much signal is enough?

Validation is progressive. You start small and cheap: three conversations, a rough landing page, a week. If the signal is strong you widen the test: more interviews, more traffic, a concierge MVP. Each round either kills the idea or buys permission to invest more in the next round. You never do "all the validation" at once, because most ideas die in the first round and doing more would be wasted.

The honest answer to "how much" is: it depends on what you are risking. If you are spending a weekend, do five interviews and a landing page test, and ship. If you are spending three months and turning down other work, do twenty interviews, two landing page tests, and a concierge MVP. The amount of validation should be proportional to the cost of being wrong.

A useful rule of thumb: validate until you can answer three questions with specific evidence rather than guesses.

1. Who is the person I am building for, and why are they currently in pain?

You should be able to describe them in one paragraph that includes their role, their workflow, the specific moment the pain shows up, and what they currently do about it. If you cannot, you are not done.

2. How would I find more of them tomorrow if I needed to?

You should be able to name three specific channels where this audience exists in numbers, and describe how you would reach them. If your only answer is "advertising on Facebook", you have not done the work.

3. What is the smallest change to their workflow that would make their life meaningfully better, and how do I know that change matters?

You should be able to describe the change in one sentence, and point at three pieces of evidence (interview quotes, observed behaviour, stated willingness to pay) that say it matters. If you cannot, you are guessing.

When you have answers to all three, you are not certain. Nobody is. But you have moved from guessing to informed risk-taking, which is the most you can ask for at this stage.

If you already have users, a different set of validation questions applies: what features to add, what to remove, how to price, how to retain. That is a later post in this series.

What this looks like in a week

If you are reading this with a half-formed idea and an itch to start building, here is the plan for the next seven days. It is the plan I would do for myself.

Days 1 and 2. Write down your assumptions. Who is this for, in one paragraph. What problem are they solving badly today, in one paragraph. What change would help, in one sentence. These are your hypotheses. They are not facts yet.

Days 3 and 4. Find five people who match the audience description. Use any of the channels above. Send the messages. Schedule the calls.

Days 5 and 6. Do the calls. Twenty to thirty minutes each. Ask about the past, ask for stories, ask what they have spent, ask what they have tried. Take notes. Do not pitch your idea until the last five minutes, and only if it feels natural. Listen for the language they use to describe the problem. You will steal it later.

Day 7. Read your notes. Look for patterns. If three or more of the five described the same problem in similar language, used similar workarounds, and expressed similar frustration, you have signal. If the conversations went in five different directions and nobody seemed especially bothered, you have signal too. The signal is: this is not the right problem. Pick another and try again.

After seven days you will know far more than you would have learned in the same time spent building.

What is next in the series

The rest of this series walks through everything that comes after validation: your first session with an AI coding tool, staying close to the problem as you build, picking a stack, and every topic between a working idea and something real users rely on. Later posts cover retention, pricing, and monetisation for readers who are past this stage.

Subscribe below if you want each post in your inbox when it lands.