Start with a repeated, consequential job and the people who use, buy, approve and bear the risk of changing it. Record the current workaround, the evidence that the problem matters, and a specific outcome that would change a buyer’s decision. Compare AI with a rules-based, conventional software, human or no-change option. Only then test a narrow AI workflow using representative cases, a measurable baseline, explicit failure handling and authorized data. A model demo, interview or pilot can reduce one uncertainty; none proves a durable market, safe deployment or scalable economics by itself.
Why “AI-first” is not the hypothesis
“AI can transform this industry” describes a broad possibility, not a customer problem. A useful hypothesis names a particular user, task, context, current alternative and expected improvement. The question is not whether a model can produce an impressive output in a demonstration. The question is whether the complete product system can help a defined user achieve a valuable outcome with acceptable cost, risk and effort.
NSF’s I-Corps program describes customer discovery as experiential learning for assessing the market potential of technologies. That supports a disciplined learning process; it does not mean that interviews alone establish purchase intent or product-market fit. NIST’s voluntary AI Risk Management Framework organizes risk work under Govern, Map, Measure and Manage. NIST says the functions are iterative and contextual, not a universal ordered checklist or certification.
The five-part test: Job, buyer, evidence, AI fit and control
- Job: Write one sentence describing the recurring task. Name its trigger, input, output, handoff, exception and cost of failure. “Improve customer service” is too broad; “help an authorized claims reviewer locate the policy clause relevant to a submitted document” is testable.
- Buyer: Separate the end user from the budget holder, approver, security/privacy reviewer and affected person. Ask who can authorize a workflow change and what procurement or integration conditions could stop it.
- Evidence: Observe the current process where permission allows. Record repeated work, delay, rework, error exposure, existing spend, a workaround or a prior attempt to solve the problem. Distinguish direct observations from a person’s opinion about a future product.
- AI fit: Compare a language model or other AI method against rules, search, standard automation, a human workflow and doing nothing. State why AI might improve the outcome: handling variation, reducing a bounded manual step, improving retrieval or making a useful interface possible. Test the simplest credible alternative as well.
- Control: Define the quality threshold, human review, abstention or fallback, audit trail, data permissions, retention, security checks, incident owner and stop condition before a consequential pilot.
Build an evidence record before building a product
Use one dated row per hypothesis:
| Field | Record |
|---|---|
| User and job | Who performs which task, in what context? |
| Current alternative | What happens today, including workarounds and no-change? |
| Buyer and decision | Who funds or approves a change, and what evidence do they require? |
| Observed signal | What happened, when, and how was it observed? |
| AI-specific claim | What should AI improve relative to a named baseline? |
| Failure and impact | What could go wrong, who is affected, and how is it caught or reversed? |
| Next experiment | Smallest ethical test that could change a decision, with an owner and date. |
| Decision rule | What result means proceed, revise or stop? |
Keep private or regulated records out of an unapproved public form or test environment. Use only data for which the venture has a verified lawful basis and permission. A synthetic example can test interface flow, but does not validate real-world performance.
Choose a test that can fail usefully
Begin with the least expensive test capable of separating competing explanations. A workflow observation may reveal that the hard part is permissions rather than model quality. A manual concierge test can check whether the proposed result matters before automating it. A benchmark built from representative, rights-cleared cases can test model behavior, but must disclose how cases were sampled and what is missing. A pilot should identify the participants, baseline, success threshold, review process, data boundary, duration and the decision that follows.
Do not optimize only for output acceptance. Track completion, corrections, escalations, time saved after review, failure severity, user effort, operational cost and continued use where the test is designed to measure them. State the denominator, cohort, time window and missing observations. In high-impact settings, involve qualified domain and legal reviewers before deployment.
Worked hypothetical
A fictional operations team spends time locating information across long internal documents. The founder first maps who requests an answer, what source material may be used, how staff check it and what happens when the answer is missing. The team compares keyword search, document templates, a human researcher and an AI-assisted retrieval workflow. A small rights-cleared test set includes representative documents and intentionally difficult cases. Reviewers record whether the answer cites the correct source, when it should abstain, how much correction is needed and what the manual review costs. The test has no real customer, partner, deployment or result; it illustrates the method only.
Decide: proceed, revise or stop
- Proceed to the next test only when predeclared evidence is met and the remaining risk can be bounded.
- Revise when a different user, task, data source or non-AI approach better explains the evidence.
- Stop when the problem is infrequent, no buyer owns it, a simpler alternative works adequately, the data cannot be used responsibly, or failures cannot be controlled at a proportionate cost.
Limits
This framework is an editorial learning tool, not a validated score, investment recommendation, security certification or legal assessment. Customer discovery does not establish a market size; a benchmark does not prove customer value; one pilot does not prove repeatable adoption. NIST describes the AI RMF as voluntary and its current resource page notes that version 1.0 is being updated; verify the source immediately before publication.
FAQ
Does a working AI prototype validate a startup idea? No. It can show that a technical task is possible in selected conditions. Demand, procurement, repeat use, safety, cost and distribution require separate evidence.
Should every startup use AI? No. Compare AI with standard software, automation, human work and no change. Use AI when it creates an observable advantage that justifies its added complexity and risk.
How many customer interviews prove demand? There is no universal interview count that proves demand. Define which uncertainty the interviews address, how participants were selected, and what behavior or decision would provide stronger evidence.
Can a pilot prove product-market fit? A pilot can inform a specific decision. Its meaning depends on the buyer, sample, timeframe, success rule, deployment conditions and whether the result repeats.
Source notes — reviewed 2026-10-31
- NSF, About I-Corps — customer discovery and its stated purpose; does not guarantee commercial success.
- NIST, AI RMF Core and AI RMF — voluntary framework, four functions and update status; not certification.
This guide is Silicon Founders editorial material for general educational purposes. Examples are hypothetical. It is not investment, legal, accounting, technical assurance or regulatory advice, and it does not describe an active investment, partnership, client mandate or company result. Source links are provided for context; the editorial framework is Silicon Founders’ synthesis.