Your must-have list is still too big. Every item on it feels essential, which is exactly why the list will sink your first version if you try to build all of it. This chapter cuts that list down to an MVP: the smallest thing you can ship that actually helps one real person.
An MVP is the smallest version worth shipping1.2.1
MVP stands for minimum viable product. It is the leanest version of your idea that still delivers real value to one kind of user and can go live.
Two words carry the weight. "Minimum" means you cut ruthlessly. "Viable" means what is left still works for someone, end to end, on its own.
Apply the one core job test1.2.2
Every product exists to do one core job. For everything on your list, ask a single question: does this feature directly serve that one job, or does it just decorate it?
| Product | The one core job |
|---|---|
| A note app | Write a note and find it again |
| A store | Buy one item and pay |
| A booking tool | Reserve one slot at one time |
If a feature is not required for that core job to work once, it is not in the MVP. It can be the best idea you have and still wait.
Expect to cut some must-haves too1.2.3
Here is the uncomfortable part: some features you marked must-have in the previous chapter still get pushed to a later version. "Must-have eventually" and "must-have to ship the first slice" are different bars.
| In the MVP | Pushed to later |
|---|---|
| Sign in with email | Sign in with Google, Apple |
| Post one item for sale | Bulk upload, drafts, scheduling |
| Pay with one card | Saved cards, refunds, coupons |
| One language | Translations |
Build a walking skeleton, not half of everything1.2.4
A walking skeleton is one thin path through your whole app that actually works: a user arrives, does the core job once, and gets a result. It is skinny, but every bone connects.
This beats building many features to fifty percent. Ten half-finished features ship nothing a person can use. One complete path, however plain, is a product you can put in front of someone tomorrow.
Guard the line against scope creep1.2.5
Scope creep is the slow drift of "while we are at it, let us also..." that turns a two-week build into a six-month one. Every added feature feels small in the moment and enormous in total.
Write your MVP list down and treat new ideas as a separate "later" pile, not an edit to the plan. The plan is closed; the pile stays open.
Example: An MVP for a food-delivery app: one restaurant, a fixed menu, one delivery address, pay with one card. No search, no ratings, no live tracking. A hungry person can still order dinner, so it is viable.
Do this now: from your must-have list, circle the single core job, then keep only the stories needed to do that job once, end to end. Move the rest to a "later" pile.
