Minimum viable product: the sentence that decides what to build first

The idea is clear in your head. The problem starts the moment you sit down to build it, because "clear in your head" produces a feature list with forty items on it, and forty items is not a minimum anything. Most founders don't overbuild because they lack discipline. They overbuild because nobody made them write down, in one sentence, what the product is actually for.

That sentence is cheap to write and expensive to skip. Without it, every feature decision becomes a negotiation with your own enthusiasm, and enthusiasm rarely says no to anything.

The usual advice ("just build the minimum") doesn't actually help, because minimum is exactly the part nobody agrees on. One founder's minimum includes a polished onboarding flow because "first impressions matter." Another's includes a referral system because "growth needs to be built in from day one." Both can sound reasonable in a planning meeting and both are how a four-week MVP becomes a four-month one. The fix isn't willpower. It's a test that settles the argument before it starts.

The sentence, and the four buckets that follow it

The MVP Playbook gives a fill-in-the-blank formula for that sentence: "For target customer, who statement of need, our product name is a product category that statement of benefit." The book's own worked example: "For freelancers who struggle with time management and invoicing, our FreelanceFlow app is an all-in-one productivity tool that automates time tracking and payment collection, allowing you to focus on your work and get paid faster." Read that sentence back and every feature question gets easier to answer: does automatic invoice reminders belong in version one? Clearly yes. Does a built-in client CRM? Not obviously, and that's the point: the sentence gives you something to check a feature against besides your own excitement about it.

Once the value proposition is written, the book sorts every candidate feature into four buckets using the MoSCoW method:

• Must-have: features without which the product doesn't function or deliver its core value proposition at all.
• Should-have: important, adds real value, but the product survives its absence at launch.
• Could-have: nice additions with small impact if left out.
• Won't-have: explicitly out of scope for this release, named on purpose so the debate about it stops.

The book is specific about what an MVP is for at this stage: not a perfect product, a viable one: just enough to test your core assumptions and gather real feedback from actual early users. That framing matters because it changes what "done" means. A must-have feature has to work without embarrassing bugs. A could-have feature that's slightly rough is fine, because it was never supposed to be the reason someone signed up.

The book also pairs feature prioritization with a second lens (the Impact vs. Effort matrix) to catch a mistake MoSCoW alone doesn't: a feature that everyone agrees is a must-have but takes three months to build has no place in a minimum product, whatever bucket it's technically in. High impact and low effort gets built first; high impact and high effort gets scrutinized hard before it's allowed into version one at all.

Where people go wrong

The first mistake is treating "must-have" as a vibe instead of a test. The book's actual bar is whether the product functions or delivers its core value without the feature, not whether the feature would be nice, not whether a competitor has it.

The second is feature creep from stakeholders who weren't in the room when the value proposition was written. Every additional voice tends to add "one more thing," and without a Won't-have list stated out loud and shared, there's no polite way to say no to any of them: the book's own recommendation is to keep a visible "parking lot" for these requests so they get acknowledged without being smuggled into the current build.

The third shows up constantly across the Business Foundations guide: polishing secondary features while the core function is still shaky. An MVP with a beautiful settings page and a checkout flow that occasionally breaks has its priorities backwards: the book's advice is blunt about this, focus on the must-haves working flawlessly even if everything else is rough, and let the could-haves stay visibly unfinished until there's evidence they're worth the time.