An MVP is not a small product. It is an experiment with a deadline, and the deadline is the point.
The word everyone skips
Minimum viable product. Three words, and almost everyone reads two of them. Viable gets attention. Product gets attention. Minimum gets quietly ignored, because minimum feels like a compromise you make on someone else's project, never your own.
So the scope starts to grow, one reasonable sentence at a time. Auth needs social login and magic links. The dashboard needs filters. If there is a settings page there should be email preferences, and if there are email preferences there should be a way to test them, and now you are three weeks into a build that was meant to take three weeks and you have shipped a login screen.
How three weeks becomes four months
The trap is not one big decision. It is forty small ones, each reasonable on its own. Every feature has a plausible sentence behind it that starts with "users will expect" or "we will need this eventually." Neither of those is a reason to build something before you have a single user.
Watch it happen on a single feature. "Users will expect to edit their profile" is true, so you build a profile page. A profile page wants an avatar upload, which wants image resizing, which wants somewhere to store the files, which wants a settings screen to manage them. One reasonable sentence became a week, and not one user has asked to change their avatar, because there are no users yet.
The cost is not only the extra work. It is that the launch keeps moving, and while it moves you learn nothing. This is the whole point of Ries's build, measure, learn loop: you cannot measure or learn until you ship, so anything that delays the ship delays the one thing that matters.
The one question we ask
Before we scope anything, we ask the founder to finish one sentence.
This is working if a user can ______.
Whatever fills that blank is the product. Everything else is a feature you are welcome to want, later, once the blank is proven. For a marketplace it might be "book and pay for a session." For a SaaS it might be "connect their data and see one useful chart." The answer is almost never "sign up," because signing up is the cost of using the thing, not the thing itself.
Once the sentence is fixed, scope gets easy. If a feature helps a user reach that verb, it is in. If it does not, it waits. The argument stops being about taste and starts being about one shared line everyone already agreed to.
Tell us the one thing a user needs to do, and we scope it into a fixed-price build.
What we cut, and why it is fine
In a typical MVP we cut a lot, on purpose, and write down every cut so nothing is lost.
- The settings page, until there is something worth configuring.
- The second onboarding flow, until the first one has real users to confuse.
- Role-based permissions, until there is more than one kind of user.
- Half the admin panel, replaced by a database query we can run ourselves for now.
None of it is gone forever. It is parked, in writing, on the other side of the launch, where you can decide with real usage data instead of a hunch. Half of it you will never build, because the users will ask for something you did not predict, and you will be glad you kept the runway.
This is also why we price MVPs as a fixed scope with a fixed number. A clear finish line is the whole discipline. When the price floats with the hours, the scope floats with it, and the four-month version starts to feel normal. It should never feel normal. Pick the verb, build to it, ship, and let the users tell you what comes next.
Fixed scope, fixed price, a real finish line, in two to three weeks.