MVPs
that test the assumptions your product rests on.
An MVP is the smallest build that can test the key assumptions your product rests on; this work sets its prioritised scope. It matters when you have to decide what to build first and how to test whether it solves a real problem.
The real question
Whether the first release can prove you wrong, or only prove that it shipped.
Step 02 of 06 · Product & Venture Building
The path
From idea
to launch.
Six steps, each feeding the next. This page is one of them.
- Product discovery
- MVPs (this page)
- UX
- Implementation
- Brand
- Launch support
01Questions
The questions
it answers.
Which assumption has to hold first?
The assumptions from discovery are ranked by how unsure each is and the cost of being wrong; the one most likely to end the product is tested first.
What is the smallest build that tests the assumption?
The first scope is one path a user can finish end to end, chosen because it exercises the top-ranked assumption.
What is left out, and what must still be right?
Exclusions are written down with a reason each, and the few things a first release cannot get wrong are named and held to a full standard.
What result would change the plan?
Each assumption has a test, and the results that mean continue, change course or stop are agreed before the build.
02Pitfalls
Where it
usually breaks.
A first release that cannot fail
No result was agreed that would count as a no, so every outcome reads as encouragement. The build is paid for and decides nothing.
A little of every feature, none of it finished
The scope is cut by thinning every feature instead of choosing one path. Nothing can be used from start to finish, so the first release has no assumption it can test.
Exclusions nobody wrote down
Deferred features return one conversation at a time. Each is small; together they move the date, and no record shows when the scope changed.
A working build read as proof of demand
The slice works and the tests pass, so the product is called validated. Nobody outside the team has used it, and the demand assumption is still open.
03Approach
How I work
on it.
Rank the assumptions, give each a test
I take the assumptions written down in discovery, rank each by how unsure it is and the cost of being wrong, give each a test and mark which need a build.
Cut the scope to one finished path
With your team I choose the smallest end-to-end path that tests the top assumptions, and put any unproven dependency behind a spike before it is promised.
Record what is out and what decides
I write down the exclusions with their reasons, the acceptance scenarios for the first slice and the result that would change the plan.
What you leave with
- A ranked list of the assumptions the product rests on, each with the test that would settle it.
- A prioritised MVP scope: one end-to-end path first, then the order in which the rest follows.
- A written list of what stays out of the MVP, with the reason for each exclusion.
- Acceptance scenarios for the first slice, and the result that would change the plan, agreed before design and build.
04Measures
What I
would measure.
Signals to read, not targets to hit: what counts as good enough is your team’s decision.
Time until the top assumption has an answer
If it lengthens, scope has grown around the test, and more of the budget is spent before the answer arrives.
Scope additions without a recorded decision
A rise means the exclusions list is no longer in use, and the first release is growing without anyone deciding that it should.
Plan changes that follow a test result
If results never change the plan, either every assumption held or the tests could not fail, and it is worth knowing which.
05Evidence
The topic,
in practice.
From my own ventures, each labelled by its actual stage. They show what was scoped first, not demand tested against a result agreed in advance.
Ventures of my own
YoMaxi
In development, not released: the spec put one habit first, completed offline and rewarded once, and kept an LLM coach out. No user testing has run; demand is untested.
Deal Wizard
Live as a free public beta: the product was defined as one path, listing to strategy to report, and real investors and deal sourcers were asked what was missing.
City Dreams
A trading business with a live site: money and availability were named as the two things a booking site cannot get wrong, and exercised before it went live.
Building or launching
something similar?
Tell me about the product, where it is today and what you need next.