Do Your Market Research Before You Build an AI Product

A demo proves the model can do the thing. It proves nothing about whether anyone will pay to have the thing done. For most software those two answers arrive together, which is why almost every validation playbook treats them as one question. For AI products they come apart, and the standard playbook has no way to tell you which of the two you just got.

Here is what that looks like from inside. The demo lands. Heads nod, someone says this would save us hours a week, and the call ends with a request for early access. Repeat that across a dozen conversations and the decision to build feels like it has already been made for you. Six months later the product ships, and the same dozen people never log in.

That team did not skip the research. They ran a real validation process and talked to real buyers. What they measured was whether the capability impressed people, and they read that measurement as demand.

Market research for an AI product has to answer questions a generic startup playbook never asks. The standard canon on validating a product idea was written for software where feasibility was rarely in doubt and the cost of serving one more user rounded to zero. Neither assumption holds here. An AI product can be technically achievable, wanted in the abstract, priced at a level people accept, and still be a bad business, because the thing that makes it impressive is not the thing that makes it valuable, and the cost of running it scales with how much anyone uses it.

So the rest of this is about what discriminates: what you have to prove before committing budget, which signals lie to you, and what the evidence bar should look like the day you decide to write code.

What the research has to prove before you build

Most validation advice collapses a single question: is there demand? For an AI product there are three, and they fail independently.

Is there demand? Someone has a job they currently do badly, slowly, or expensively, and they would pay to have it done better. This is the classic question and the only one generic playbooks cover well.

Is it feasible at real data volume? Your prototype worked on a curated sample. Production data is messier, longer, more ambiguous, and full of the edge cases nobody thought to include in a demo set. Plenty of AI products validate demand cleanly and then discover that accuracy at 60 percent of cases is worth nothing to a buyer who needs 95 percent.

Does the unit economics work? You can have real demand, achievable accuracy, and a price the market accepts, and still lose money on every active user, because inference cost scales with usage in a way that seat-based software never did.

Answering the first and deferring the other two to engineering is the sequencing error underneath most of what goes wrong. Feasibility and cost get filed as implementation problems, to be solved once the market says yes. They are conditions on whether the market saying yes means anything.

Which makes the research wider than a set of customer interviews. It includes a technical probe against real data and a cost model built on realistic usage, both before the commitment. The first of the three questions is also the one most often answered wrongly, because the instrument teams reach for is the instrument least able to answer it.

Why enthusiasm for a demo is not demand

AI demos pull unusually strong positive reactions, and the reasons are structural rather than personal.

Novelty does part of the work. A capability that felt impossible two years ago still reads as impressive, and impressed is a pleasant feeling that people express warmly. The prospect is also doing your imagining for you. Shown a summarization tool, they picture it applied to their worst document pile, on their best day, with none of the failure modes they have not hit yet. And a demo has no friction surface. Nothing has to be integrated, no data exported, no colleague has to change a habit, and no security review has been booked. The version of the product they are reacting to is the only version that costs them nothing.

There is a further problem specific to this category. Plenty of AI products work beautifully and are still worthless, because the job they do well is not a job anyone was paying to have done. A tool that drafts meeting summaries works. Whether meeting summaries were ever a bottleneck worth spending money on is a separate question, and no demo will surface the difference.

The symptoms are recognizable once you know to look for them:

• Discovery calls that are uniformly positive. Real demand produces disagreement, because people who have the problem have opinions about how it should be solved.
• Enthusiasm that never converts into a calendar commitment. Interest that cannot survive the request for a follow-up with the budget holder was never interest in buying.
• Pilots that begin easily and stall quietly. The pilot was cheap curiosity. Renewal is the first moment anyone has to decide it is worth something.
• Feedback that describes the technology rather than the outcome. When people say this is really cool rather than this would let us stop doing X, they are reacting to the capability.
• Requests for more features rather than faster access. Someone with an urgent problem asks when they can have it. Someone entertained by a demo asks what else it could do.

One of these on its own means little. All of them together mean you have measured interest in a capability and have not yet measured demand for a product. The substitution is not limited to demos, either. It runs through nearly every signal teams collect at this stage.

The signals people confuse

The pattern underneath every symptom above is a weak signal being read as a strong one. Side by side, the substitutions are obvious. In the moment, they are not.

Read the right-hand column as calibration rather than cynicism. Every one of those signals is worth collecting, because cheap weak evidence is how you decide which expensive strong evidence to go get. The failure is treating the cheap signal as the conclusion. A funded competitor tells you the hypothesis is not absurd. It does not tell you the hypothesis is correct, and in a category this crowded it may only tell you that a lot of people read the same market report.

The last row decides more outcomes than the others, quietly. The data a pilot runs on is rarely the data you would get in production, and getting that data turns out to be its own problem.

Before demand, find out whether you can get the data

This gate has no equivalent in generic product validation, and skipping it is how teams validate a market they cannot serve.

Your product needs data that currently belongs to your buyer. Three things have to be true, and they frequently are not.

Legally available. The data may be governed by contracts with the buyer's own customers, by regulatory constraints on where it can be processed, or by terms that prohibit sending it to a third-party model provider. Healthcare, financial services, and anything touching EU personal data routinely fail here, and the failure surfaces during legal review rather than during discovery.

Practically accessible. The data exists, and it sits inside a system with no usable export, or spread across a decade of inconsistent records, or held by a team with no reason to help you. A buyer can want your product badly and still be unable to hand you its input within a quarter.

Good enough to work on. Volume is not quality. Records that are inconsistently labeled, sparsely populated, or produced by a process that changed twice in three years will not support the accuracy your demo implied.

Put these questions into discovery directly, early, and before you have invested in a relationship you would hate to lose:

• Where does this data live today, and who owns the system it lives in?
• Has anything like this left that system before, and what did that approval take?
• Who would have to sign off on sending it to a third party, and have they said no to something similar recently?
• Could we see a realistic sample this month, not a curated one?

A validated need sitting behind an inaccessible data wall leaves you with a market you can describe accurately and cannot sell to. Those are not the same asset, whatever the deck says.

Research methods that actually discriminate

The methods below are ordered by how much they should move your decision, and the ordering follows one rule: evidence strength tracks what the other party gives up. Attention is cheap. Time costs more. Money costs most.

Workflow observation. Sit with someone doing the job your product would change. Watch what they do rather than what they describe. Cost is a few hours per session. It proves the problem exists in the form you think it does, and it regularly proves it does not. The step people complain about is often not the step that eats their day. This replaces the "tell me about your process" interview, which returns a tidied narrative rather than the real one.

Failure-log review. Ask to see where the current process breaks: the escalations, the rework queue, the tickets that got reopened, the spreadsheet someone maintains to catch what the system misses. Cost is low, access is the hard part. It proves the problem has a measurable cost, and it hands you the number you will need later for pricing. This replaces asking people to estimate how much time something wastes, which they cannot do accurately.

Wizard-of-oz tests. Deliver the outcome manually behind an interface that looks automated. High cost in labor, near-zero in engineering. It proves people will change their behavior to use the output, which is the one thing a demo cannot prove, and it tells you what quality bar is required before you have built anything capable of hitting it.

Paid pilots. A pilot with a price on it, even a small one. Cost is a real sales cycle. It proves someone will move money, a different act from expressing interest, and it surfaces the procurement path you would otherwise meet much later. A free pilot proves almost nothing by comparison, because the only thing it filters for is curiosity.

Willingness-to-pay ladders. Rather than asking what someone would pay, present a concrete price and watch what happens, then move the price and repeat across prospects. Cost is low once you are already in conversations. It shows you where interest dies, which a stated-preference survey cannot, because people answer a hypothetical price question as a question about whether they like you.

Two rules make this list work in practice.

Run the cheap methods first and let them tell you which expensive method to run. Workflow observation and failure-log review are how you decide what to build a wizard-of-oz test around.

Do not let a strong method inherit a weak method's conclusion. A paid pilot that you sold by promising capability you cannot deliver at production volume has validated exactly one thing, and it is your ability to sell a promise.

Both of the last two methods turn on price. Price is where AI products carry a problem this canon was never written for.

Testing willingness to pay when your costs are variable

Classic software validation rests on a hidden assumption: once the product exists, serving one more user costs approximately nothing. That assumption is why so much pricing advice focuses entirely on the demand side. If marginal cost is near zero, any price above zero that the market accepts is a viable business, and the only remaining question is how much value you can capture.

AI products break this. Every use consumes inference. A heavy user can cost multiples of a light user on the same subscription, and the users who love the product most are the expensive ones. The margin structure inverts in a way seat-based software never had to model.

Which means willingness-to-pay research has to run against a cost model, not on its own.

Build the cost side first, roughly. Estimate calls per active user per month at realistic usage rather than demo usage, multiply by your cost per call including retries and the longer contexts that real documents produce, and add the overhead that never appears in a prototype: evaluation runs, human review of low-confidence outputs, reprocessing when you change models.

Then test price against that floor. The question is not whether a prospect will pay $200 a month. It is whether they will pay $200 a month at the usage level that makes the product valuable to them. A price that clears for a light user and inverts for a heavy user has validated a segment rather than a price, and possibly the wrong segment.

Two things make the modeling less stable than it looks. Per-token inference prices have fallen substantially over the past few years, which argues for patience on any product that is marginal today. Model capability and context lengths have risen alongside, which pushes consumption up as teams feed in more per request. Your cost per unit of work moves in both directions at once, so model a range rather than a point, and know which end of the range still works.

Test the boundary too. If your pricing needs usage caps, throttling, or a fair-use policy, that is a product decision the market has to accept, and it belongs in validation rather than on a pricing page eighteen months later.

Using AI tools for the research, and where they mislead you

There is an entire industry of AI-powered market research tools, and most of the published rankings of them are written by companies that appear in their own rankings. The tools are useful. They are useful for specific things.

Where they help:

• Widening the question set. Generating hypotheses, surfacing objections you had not considered, and pressure-testing your assumptions before you spend a real interview slot on them.
• Analyzing what you have already collected. Clustering open-ended responses, pulling themes out of call transcripts, and summarizing long competitor material are real speed gains on work you would otherwise do by hand.
• Desk research at breadth. Mapping a competitive landscape or assembling background quickly, as a starting point rather than an output.

Where they mislead:

• Synthetic respondents cannot surprise you. A simulated persona generates plausible answers drawn from patterns in its training data. The entire value of customer research is the answer you did not anticipate, which is the one thing a model trained on the expected answer will not produce.
• Generated market sizes recycle a small number of sources. Ask three tools for the size of a category and you will often get three confident numbers derived from the same handful of published reports, which creates an impression of corroboration where there is none.
• Sentiment on your own idea is unreliable by construction. A model asked to evaluate a business idea drifts toward the helpful, balanced assessment, which is a different thing from an accurate one.
• Summarization drops the outlier. The one interview where someone said something strange is often the most valuable interview you ran, and it is exactly what gets compressed away.

A workable rule: use AI to widen the question set, never to close the decision. Anything that changes whether you build should rest on evidence from a human who gave up something real. The second failure on that list deserves its own section, because the numbers being recycled are shakier than they look.

Sizing a market that has no clean comparables

Top-down sizing is the weakest part of most AI product research, because the available numbers were built for a different purpose than yours.

Published AI market forecasts for the same year differ by a factor of two to three, from roughly $376 billion to $900 billion for 2026 across Fortune Business Insights (2026) and Precedence Research (2026), and the variance is mostly definitional rather than analytical. One report counts chips and infrastructure. Another counts enterprise software with an AI component. A third counts services revenue. None of them measures the market for your specific product, and dividing a headline number by an assumed share produces a figure with no informational content.

Before using any published market figure, establish three things: what it counts, what it excludes, and whether it measures spending that exists today or spending someone projects will exist in five years. A forecast is a claim about the future wearing the clothes of a measurement.

Bottom-up sizing is slower and far more useful. Start from the buyer you can name. How many organizations have the workflow you observed, roughly, and by what definition? Of those, how many have the data access you confirmed is necessary? Of those, how many have a budget line this would come out of, and who controls it? What does that budget currently buy, and what would have to stop being bought?

That last question makes the estimate real. New categories rarely get new money. They get money that is currently going somewhere else, which means your competition is frequently not another AI product but the headcount, the outsourced vendor, or the manual process that already owns the budget.

The output is a smaller number than a top-down estimate and a far more defensible one, because every step is a claim you gathered evidence for rather than a percentage you assumed. It also puts a name to the person who controls that budget line, who is usually not the person who loved your demo.

Validate the buying process, not just the buyer

Enterprise AI purchases fail late, and they fail for reasons that never appear in a discovery call with an enthusiastic user.

The person who loves your product often cannot buy it. Between their enthusiasm and a signature sit a set of gates that have nothing to do with whether the product is good:

• Security review. How data is transmitted, where it is processed, what the model provider retains, and whether subprocessors are acceptable.
• Data-processing agreements. Which jurisdictions are involved, what the retention terms are, and whether the buyer's own customer contracts permit the arrangement.
• AI governance sign-off. The newest of these gates and the one with the least settled process, covering model risk, human oversight, auditability, and in regulated sectors, explainability.
• Budget ownership. The person in your pilot may be spending a discretionary innovation budget that does not renew. The person who owns the operating budget was never in the room.
• Procurement itself. Vendor onboarding, insurance requirements, security questionnaires, and a legal review that can outlast a startup's runway.

The gap this creates shows up in the survey data. McKinsey's State of AI (2025) found 88% of organizations reporting AI use in at least one business function, and its 2026 survey still puts the share attributing an EBIT impact of 5% or more at 6%, which is the statistical shadow of a great many pilots that never became anything .

So validate the path, not just the appetite. Ask directly: who else has to say yes, what happened to the last AI tool that went through this process, how long did it take, and what killed the ones that died? Buyers will tell you, because they found the process frustrating too. A prospect who cannot answer those questions is not yet a qualified opportunity, whatever the demo looked like.

The evidence bar to clear before you write code

Validated is a word that usually describes a feeling. Here is a version with edges. Before committing engineering budget to an AI product , you should be able to produce:

1. Named buyers with an observed workflow cost. Not a segment. Specific organizations where you have watched the work happen and can state, in their terms, what the current process costs them.
2. Confirmed data access. A realistic sample in hand, or a documented path to one, with the legal question asked and answered rather than assumed.
3. A quality bar you know you have to hit. Established from a wizard-of-oz test or equivalent, and tested against production-shaped data rather than a demo set.
4. A price tested against modeled unit economics. Including the heavy user, not just the average one.
5. At least one paid commitment ahead of the build. Money moved before the product exists is the strongest signal available at this stage, and it is strong because it is hard to get.
6. A mapped procurement path. You know who signs, what they will ask, and roughly how long it takes.

Six items, none of which requires a finished product, all of which are cheaper to establish than a wrong build.

The counterweight matters as much as the list. Research has diminishing returns, and there is a real failure mode on this side too: the team that runs its twentieth interview because a twentieth interview is more comfortable than a decision. You are done when new conversations stop changing your mind. When the fifth interview in a row tells you what the previous four did, you have your answer, and continuing is procrastination with a methodology.

The other honest signal arrives when a question can only be settled by building. Some things cannot be learned from research at all, particularly whether accuracy holds at production volume . At that point the right move is the smallest real thing that answers the specific question, scoped so a disappointing result is affordable, rather than another round of interviews.

What this changes

The asymmetry is the whole argument. A few weeks of research aimed at the right questions costs a fraction of a six-month build aimed at the wrong one, and the research is the only one of the two that can tell you which you are about to do.

Key takeaways:

• A demo proves feasibility. It does not prove demand, and for AI products those two signals come apart more than in any other category of software.
• Three questions have to be answered before you build, not one: is there demand, does it hold at real data volume, and does the unit economics survive a heavy user.
• Data access is a validation gate with no equivalent in generic product research. A need you cannot reach is not a market.
• Evidence strength tracks what the other party gives up. Attention is cheap, time costs more, money costs most, and only the last one reliably predicts a purchase.
• AI research tools are for widening the question set, not for closing the decision.

Next step

If the six items above read as a list you cannot currently produce, that gap is the work, and it is a scoping problem rather than a research-skills problem.

AI Transformation Discovery is a one-week sprint that runs exactly this process against your product idea: the workflow observation, the data-access check, the cost model, and the procurement path, delivered as a concrete roadmap rather than a report.

Book a Discovery Sprint