Test the Riskiest Assumption First
A minimum viable product should test the assumption most likely to sink the product, which is rarely whether the team can build it. Rank your assumptions by risk and build the smallest test of the top one.
A minimum viable product is meant to test your riskiest assumption. Most teams build one that tests the easiest: whether they can build it.
Eric Ries set out the idea in The Lean Startup (2011): build the smallest thing that tests the belief your product most depends on. In practice, MVP has come to mean “ship the cheapest thing and see what sticks”, which produces clicks rather than answers. The same trap waits for any new internal system or AI project.
Ranking the Assumptions
Every product rests on a stack of assumptions: the problem exists, people will pay to solve it, the technology works, the team can deliver. Most teams test “can we build it?” first, because they control it, though it is the one least likely to sink them.
Chronologiq is an AI product our founder, Shan Peiris, built before neesh Inc. The engineering below is from it, and the numbers are his rather than a client’s.
Here is the assumption stack for building Chronologiq, which turns pasted text into a timeline, from scratch:
Libraries exist and any front-end team can build one. A prototype settles it in days.
A frontier model can pull dates and categories out of text. Reliability at volume is the open question.
Unknown until tested: whether people have scattered events they need to see on a timeline at all.
If users treat AI timelines as a toy and never rely on them, the product is a novelty.
Free tools exist, and a spreadsheet can draw a basic timeline. The value has to beat 'I could just use a spreadsheet.'
Sorted by risk, the trust assumption rises to the top and “we can build a timeline UI”, the one most teams test first, falls to the bottom. A first version built to test the top assumption looks nothing like one built to test the bottom.
Two First Versions of the Same Product
A polished timeline with drag-and-drop, several views and manual event entry, and no AI. Ships in 6 weeks. Proves the team can build software; learns nothing about whether the product should exist.
A plain screen with one view. The AI parses pasted text into events, and a preview lets users approve or reject each one. Ships in 3 weeks. Shows whether users trust the AI's output enough to act on it.
The second version is rougher and more useful. If users reject the AI’s events, no amount of polish saves the product. If they approve and use them, you know where to invest next.
How to Choose the Test
List Assumptions
Every belief the product depends on to succeed
Rank by Risk
Which one, if wrong, sinks the product?
Build the Test
The smallest thing that proves or disproves the top one
What you build is a test with a product around it. The interface exists to make the test possible.
Why Teams Build the Wrong One
What the Chronologiq Test Showed
Shan tested the trust assumption first. The first version showed the AI’s events in a plain preview screen, where users checked, unchecked and edited each one before submitting. They approved 87% of the AI-parsed events without changing them. They did not need perfect accuracy; they needed to see each event and be able to correct it. That preview-and-approve step became the core of the product, and the analysis layer added later follows the same rule: show the evidence and let the person decide.
Which assumption would sink your next project if it were wrong?
Book Free Assessment