There’s a distinction that gets blurred in most discussions about starting new products: the difference between a minimum viable product and a minimum viable proof.

They’re not the same thing. They’re optimized for different goals, require different amounts of work, and answer different questions. Building a product when you need a proof is one of the most reliable ways to spend months on something that doesn’t validate anything.

What a Proof Is

A minimum viable proof answers one question: does the core mechanism work?

Not “will people pay for this?” Not “can we acquire customers?” Not “is there a market?” Those are real questions, but they’re downstream of a more fundamental one: does the thing you’re building actually do what you think it does?

For a document synthesis tool, the question is: can a system that has never seen a data room before extract the right information from a real one, apply the right domain interpretation, and produce output that a professional would recognize as useful? If the answer is no, no amount of pricing research or landing page testing matters. You don’t have a product. You have a hypothesis.

The proof is the experiment that tests the hypothesis. It’s not a product. It doesn’t need onboarding, billing, settings, or a dashboard. It needs to demonstrate that the mechanism works with real inputs.

What a Product Is

A minimum viable product answers a different question: will the right people pay for this, repeatedly, in a way that’s sustainable?

This requires more than a working mechanism. It requires delivery (the user can actually use it, not just see a demo), repeatability (it works consistently, not just in the one scenario you tested), and pricing clarity (the user understands what they’re getting and what it costs).

A product has to work reliably with inputs the builder didn’t hand-select. It has to work for users who aren’t the builder. It has to be good enough that the user comes back, and tells someone else about it.

This is a much higher bar than a proof — and it’s the wrong bar to aim for first. Building to product quality before you have a proof means building to the wrong spec. You might refine delivery, repeatability, and pricing for a mechanism that doesn’t work.

The Sequence That Works

The right sequence is proof first, then product.

A proof is typically small: a script, a notebook, a manually orchestrated workflow. It uses real data (not synthetic data, not idealized inputs). It’s evaluated by someone who would actually use the product — ideally someone with domain expertise who can judge the output quality without being told what the answer should be.

If the proof works, you know the mechanism is sound. The remaining questions are about delivery and distribution, not core functionality. Those are hard problems, but they’re solvable in a different way than “does this actually work.”

If the proof doesn’t work, you’ve learned something critical: the mechanism needs more work, or the assumption behind it is wrong. You haven’t wasted months building onboarding flows for something that doesn’t function. You’ve spent days discovering a problem you can now try to solve.

Why People Skip the Proof

The proof step gets skipped because it’s unglamorous. A script that processes one document and prints output to a terminal doesn’t look like a product. It’s hard to share. It doesn’t have a URL. You can’t post it on a launch platform or send it to potential investors.

There’s also an asymmetry in how the two activities feel. Building a product feels like progress. The UI is taking shape. The deployment works. The landing page looks good. None of this proves the mechanism works, but it feels like real work — which creates the illusion of de-risked progress.

A proof, by contrast, feels scrappy. You’re not building anything durable. You’re running an experiment. The output is knowledge about whether the thing works, not a thing that works. But that knowledge is the most valuable thing you can produce at this stage, because it determines whether everything else is worth building.

The Test for Which One You Need

If you can describe exactly what success looks like for the core mechanism, you need a proof. If the mechanism already has demonstrated evidence of working (your own prior work, a published benchmark, a similar product that has it), you can move to product.

Most new things — genuinely new mechanisms, novel combinations, applications to new domains — need a proof first. The core assumption hasn’t been tested. The domain knowledge hasn’t been exercised against real data. The output quality is unknown.

Build the proof. It’s small. It’s fast. It answers the question that matters most.

Then build the product.