A founder can spend three weeks building an AI demo and still learn less than a careful afternoon spent watching someone attempt the underlying job. The demo may prove that a model can produce an answer. It does not prove that the problem interrupts real work, that a buyer will change behavior, or that anyone will accept the result. Those are separate uncertainties, and most of them can be tested before an MVP exists.
The practical answer is to validate the risky behavior and the first transaction before automating delivery. Find out whether a specific person has the problem, already pays a cost for it, will take a meaningful step to solve it, and can receive value through a manual version of the workflow. An MVP becomes useful after those tests expose a product question that software, rather than conversation or service, must answer.
Define the decision before choosing the test
Validation is not a general search for encouragement. It supports a decision. The decision might be whether to spend another week on discovery, whether to serve a narrow segment manually, whether to ask for payment, or whether to build one product capability. A test that is sensible for one decision can be useless for another. Five thoughtful interviews may clarify the language of a problem, but they cannot establish that a workflow produces repeat value.
Write the decision as a sentence with a consequence: “If X appears in Y qualified cases, the next move is Z; otherwise, the idea will be revised or stopped.” The counts should reflect the cost and reversibility of the next move, not a universal benchmark. A two-day concierge test needs less evidence than hiring a team or committing to a long integration. The sentence forces the test to earn a change in behavior instead of producing another folder of interesting notes.
Rank assumptions by danger, not convenience
Most ideas contain at least four kinds of assumption. The problem assumption says a painful job exists. The audience assumption says a reachable group experiences it often enough. The value assumption says a better outcome matters. The transaction assumption says someone can commit money, time, data, access, or reputation to obtain that outcome. AI products add a delivery assumption: available models and workflow controls can create the result at acceptable quality and cost.
Score each assumption on two dimensions: how uncertain it is and how damaging it would be if false. Test the assumptions that are high on both. Founders often reverse this order because capability tests are comfortable. It is satisfying to improve a prompt or connect an API. Yet a beautiful extraction pipeline does not rescue a problem that occurs twice a year, and a compelling pain does not rescue a workflow that requires data the customer cannot share.
Use interviews to recover behavior, not approval
A useful problem interview begins with a recent event. Ask the participant to reconstruct the last time the job occurred: what triggered it, what information arrived, which tools were opened, who became involved, where the work paused, and what happened when the output was late or wrong. Concrete recall is imperfect, but it is usually more informative than asking whether someone would use a product described in flattering language.
Listen for costs that already exist. A team may pay with contractor hours, delayed revenue, senior review, duplicate work, customer risk, or an ugly spreadsheet that someone maintains every Friday. Also listen for the absence of consequence. People can dislike a task without caring enough to change it. The honest conclusion from a mildly annoying, rarely repeated job may be that it is not a startup problem, even when interviewees praise the concept.
Keep the proposed solution out of the first part of the conversation. Once the current behavior is clear, a concept can be introduced to test comprehension and objections. At that point, ask for a next step connected to the real workflow: permission to examine a redacted input, an introduction to the person who owns the budget, or a scheduled session to process the next live case. Agreement costs little. Calendar space and operational access cost more.
Deliver the outcome before automating the machinery
A concierge test replaces the product with a controlled manual service. The customer provides a real input under agreed boundaries. The founder uses available models, ordinary software, and human judgment behind the scenes, then returns the proposed outcome in the format and timeframe the customer would actually need. The customer does not need to believe the process is automated. The purpose is to test the value exchange and learn the workflow, not stage a magic trick.
Suppose the idea is an AI assistant that prepares first-pass vendor risk reviews. A no-MVP test does not require a portal, permissions system, or custom retrieval layer. A founder can agree on one permitted document set, prepare the review manually with model support, show sources for every material claim, and observe the security lead’s corrections. The revealing questions are whether the output enters the real review, which errors destroy trust, how much expert time remains, and whether another case is requested.
Concierge work is deliberately inefficient, so do not mistake its delivery cost for the eventual product economics. Record every manual step anyway. The repeated steps reveal what may deserve automation; the exceptions reveal where human control must remain. If value cannot survive careful manual delivery, faster automated delivery is unlikely to repair it.
Know what prototypes and landing pages cannot prove
A landing page is good at testing whether a particular audience notices and understands a promise. It can compare language, reveal which use case attracts attention, and recruit participants for a deeper test. It cannot show that users will supply sensitive context, accept uncertain output, change an approval process, or return after the novelty fades. Treat the page as a doorway into validation, not the final room.
A clickable prototype can test navigation, expectation, and the sequence in which people want to inspect or correct an answer. It cannot test output quality when every response is prewritten. It also hides latency, messy inputs, integration work, and the emotional difference between reviewing a fictional example and taking responsibility for a live decision. A prototype is strongest when the unknown is interaction. It is weak when the unknown is whether the system can earn trust under real conditions.
Ask for a commitment that resembles the future relationship
Commitment is not limited to payment. Early in a regulated workflow, access to sanitized data and an hour with the accountable reviewer may be harder to obtain and more informative than a small fee. In a self-serve consumer product, payment or repeated voluntary use may be the cleanest signal. In a team product, bringing a colleague into the next session can demonstrate that the problem crosses a real handoff rather than living only in one enthusiast’s imagination.
Choose a commitment that matches the adoption barrier. If the future product requires migration, ask for a small real dataset. If it requires a budget, present a paid pilot with a defined outcome. If it requires weekly behavior, schedule the next live case rather than asking whether the person would return. The test becomes more useful when the requested action exposes the same friction the eventual product must overcome.
Set evidence thresholds before the result can charm you
Before outreach begins, define three result bands. A success band authorizes a named next investment. A failure band rejects or materially changes an assumption. An ambiguous band identifies the follow-up needed to separate competing explanations. This is especially important with small samples, where one energetic participant can dominate the story and one silent participant can feel like a verdict.
Thresholds should combine behavior and interpretation. “Three teams complete a live case and two request another within the test window” is more useful than “five people like the idea.” Add quality conditions where the outcome carries risk: which errors are acceptable, who must review, and what time saving would matter. The threshold is not statistical proof. It is a pre-committed rule for making the next reversible decision with less self-deception.
A seven-day validation sequence
On day one, write the decision, rank assumptions, and choose the single riskiest one. On day two, recruit people who recently performed the target job and prepare questions anchored in past behavior. Days three and four are for interviews and workflow reconstruction. Do not pitch until the existing process, consequence, and owner are visible.
On day five, offer a concrete next step to the strongest candidates: a live-input working session, a concierge delivery, or a paid pilot with narrow boundaries. Day six is for delivering or prototyping only what that step requires. On day seven, compare observed behavior with the thresholds written on day one. Decide whether to stop, revise the audience or promise, run another manual case, or build the smallest product capability needed for the next uncertainty.
Validation without an MVP is not validation without making anything. The founder still makes an offer, a service, a workflow, and a decision rule. What gets postponed is the expensive fiction that software must exist before customers can reveal whether the problem, transaction, and outcome are real. Test those first. Then build because the next uncertainty requires a product, not because building is the easiest work to start.