MVP Thinking

The smallest version that proves the core idea — products, cart, order, payment — and the line between what can be simplified and what cannot be ignored.

MVP Thinking
▶ lab

The smallest version that proves the core idea — for the store, products, cart, order, payment — and nothing that does not change whether the idea is proven. Not the product with features removed; the product with the proof left in.

Q · What is the smallest version of this that would tell me whether the core idea works, and how do I stop it growing into the whole product?
What Is Not V1
▶ lab

Deciding what stays out is the same decision as deciding what goes in, made honestly: each excluded feature gets a reason, a trigger for revisiting it, and the assumption it leaves behind in the code.

Q · How do I say "not yet" to a feature in a way that survives the meeting, and what does saying it commit me to?
MVP vs Bad Prototype

An MVP simplifies scope and keeps correctness where the idea lives; a bad prototype simplifies correctness and keeps scope. The first tests an idea; the second tests whether customers notice.

Q · My V1 is small — but is it small in the right places, or have I cut the parts that make the result mean anything?
What Cannot Be Simplified

Most of a system can be simplified in V1; a few things can only be done or not done — money, identity, and data that cannot be recreated. Knowing which is which is the whole skill of scoping an MVP.

Q · Of everything in this system, which parts can I make smaller without making them wrong — and which parts have no smaller version?
Growing From the MVP

V1 shipped and something was learned. The next version is not "V1 plus the phase-2 list"; it is the smallest change that acts on what was learned, with each simplification undone only when its trigger fires.

Q · V1 is in front of real users. How do I decide what the next version is, and how do I keep it from becoming the full feature list I refused to build the first time?