Your MVP Isn't Small — It's a Bet You Never Wrote Down

Day 4: Your MVP Isn't a Size. It's a Bet You Named.

Nobody's going to hand you a scoped backlog this time. There's no PM upstream of you deciding what's in and what's out — you have to decide what 'minimum' even means, on your own, probably for the first time. Get it wrong here and you won't just lose a sprint. You'll lose two weeks, or worse, two months of agent-assisted 'fast' building, shipping a smaller version of the entire product that still answers absolutely nothing.

The two-week 'lean' v1 that answered nothing

A team I worked with called their v1 'lean.' Two weeks, they said, just the essentials. What actually shipped: login, a settings page, role-based permissions. Smaller than the full product — technically an MVP if you go by size. It was also useless as a test, because nobody on the team could tell you what question it had just answered. They hadn't built a minimum viable product. They'd built a small full product.

The tell

Here's the diagnostic I run now, on other people's teams and on my own: ask anyone in the room, 'what assumption are we testing with this release?' If the answer is a feature list — 'we're testing the onboarding flow,' 'we're testing the dashboard' — that's not an assumption, that's just scope wearing a different hat. A real answer sounds like 'we're testing whether users will trust an AI agent to send an email on their behalf without reviewing it first.' One describes what got built. The other is a bet you can actually lose.

• ▹Scope answer: 'We're testing the settings and roles flow.' (describes the build, not a risk)
• ▹Risk answer: 'We're testing whether teams will let an autonomous agent modify production config without a human approval step.' (names the thing that could kill the product)
• ▹If your team can't answer with a sentence that could be proven false, you haven't defined an MVP — you've defined a smaller backlog.

'Minimum' modifies the question, not the product

MVP is a risk-resolution tool, full stop. 'Minimum' was never about how few features ship — it's about how narrow a question you're allowed to ask. Full-product scoping asks 'what does this need to do?' MVP scoping asks one much meaner question: 'what's the one thing we don't know that, if we're wrong about it, makes everything else pointless?' Then you build the smallest possible thing that answers that — nothing bolted on for completeness, nothing added because shipping without it would feel weird.

This gets more important in the AI era, not less. Agents make it cheap to spin up a full CRUD app, a polished UI, a working onboarding flow, all in an afternoon. That cheapness is a trap — it kills the friction that used to force scope discipline on you by default. When code is nearly free, the discipline has to move earlier: into naming the assumption before you write a single prompt. Skip that step and you'll agent your way to a fully-built, fully-wrong product faster than any team before you ever could.

The assumption we should have named at my own startup

At my own company, we were building a tool where an AI agent would triage and draft responses to customer support tickets. We spent two weeks on ticket ingestion, a queue UI, agent assignment, a drafting interface — solid engineering, genuinely well built. The actual risky assumption, the one thing our entire business hinged on, was: 'support agents will trust and use AI-drafted responses without rewriting them from scratch.' We never once wrote that sentence down. We built the pipeline instead, because pipelines feel like progress and naming an assumption feels like admitting you don't know something yet. When we finally put a rough draft-suggestion box in front of three support agents — no queue, no assignment logic, just a textarea and a 'was this useful?' button — we had our answer in three days, not two weeks. The answer was 'not without heavy editing.' That single sentence changed the entire product direction, and everything we'd built in those first two weeks got thrown away — it was infrastructure for a product whose core bet we'd never actually tested.

How to apply it on Day 4

Before you write a line of code — before you even open your editor, before you prompt an agent to scaffold anything — write this sentence, and mean it:

We are testing: ___________________________
We are NOT shipping value yet.

Example:
We are testing whether engineers will trust an autonomous
coding agent to open a PR without a human reviewing the diff first.
We are NOT shipping a full CI/CD integration yet.

Then use that sentence as a filter, not a formality. For every feature you were planning to build, ask: does this help answer the named assumption, or does it just make the thing feel more like a real product? Login, settings, roles, retry logic, a nice empty state — almost none of that resolves an assumption. What it resolves is your own discomfort with shipping something incomplete. Let the sentence cut those features from your plan. If you can't delete at least half of what you originally planned after writing it honestly, you haven't found the real assumption yet — keep asking 'what would make this whole idea wrong?' until you do.

Bridge to Day 5

Naming the assumption tells you what to build. It doesn't tell you what to keep. Tomorrow: once your MVP has answered its question, how do you decide what's disposable — the throwaway scaffolding you built just to get an answer — versus what's actually the first brick of the real product.

Extend your knowledge

• ▹Eric Ries, The Lean Startup — the original build-measure-learn loop; read it specifically for the 'validated learning' framing, not the startup-hype parts.
• ▹Marty Cagan, Inspired (and the SVPG blog) — on separating 'risk' (value, usability, feasibility, viability) from 'scope,' which maps directly onto today's lesson.
• ▹Rob Fitzpatrick, The Mom Test — useful for the step before this one: talking to users in a way that surfaces the real risky assumption instead of the one you already believe.
• ▹Try it this week: before your next side-project commit or agent prompt, say the 'We are testing ___' sentence out loud to a teammate and see if they can guess what you're building from it alone — if they can, you've named a feature, not an assumption.