The most common MVP mistake: treating "minimum" as "fast to build." That's not what it means.
"An MVP is a version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort." — Eric Ries
Minimum means minimum to learn what you need to learn — not minimum features. An MVP that teaches you nothing is not an MVP. It's just a small product.
The BABOK / Agile Extension definition is more precise:
"MVP is used to identify the smallest set of features or requirements to deliver value to stakeholders and satisfy early adopters in the shortest time possible."
Three-step process for designing an MVP that actually works:
- State the hypothesis. What specific assumption are you testing? Not "users will like it" — something falsifiable: "users will pay for this before the full feature is built."
- Define the minimum. What's the cheapest thing that tests this hypothesis? A landing page, a concierge service, a prototype, a fake button. The Zappos story is the classic example: they photographed shoes from local stores and manually delivered orders before building any inventory system.
- Define success criteria first. What signal tells you the assumption is confirmed or invalidated? Set this before you build, not after.
For PSPO candidates, the MVP connects directly to the Sprint Goal — both are hypotheses being tested within a time box. The PO's job is to ensure the team is testing the right assumption, not just shipping features.
Exam tip: An MVP is not a beta product. It's a learning tool. Exam scenarios that describe an MVP as "a version with fewer features" are often leading you toward a wrong answer.