The MVP Was Not the MVP

What people actually mean when they say MVP

When a founder says MVP, they usually mean: "the smallest thing I can show to investors and the press." That version is closer to a polished demo.

When engineering says MVP, they usually mean: "the version that doesn't break in production." That version is closer to a stable v1.

When sales says MVP, they usually mean: "the smallest thing I can credibly sell." That version usually has more features than either of the above.

When the customer hears MVP, they often hear: "this product is unfinished — I should wait." Which is the worst possible interpretation, because it kills the early validation loop the MVP exists to create.

Four versions of MVP, three of them wrong. PM job: get all four parties to mean the same thing before any code is written.

How I actually scope an MVP now

A practice that has helped me, painfully arrived at:

1. Write the customer's first three minutes. Not the customer's full journey. Just the first three minutes — what they see, what they do, what they feel. If I can describe a complete first three minutes the customer would happily come back from, I have an MVP. If I can't, I have a feature list pretending to be an MVP.

2. Identify the one signal worth measuring. Every MVP should have exactly one signal that matters. Not five. Not a dashboard. One. If you can't articulate the one signal, the MVP is not an MVP — it's a launch trying to look small. (At LexMeet, the signal for our first release wasn't sign-ups. It was "lawyer responds to a request within 24 hours." Everything else was vanity.)

3. Cut anything that doesn't change the signal. This is where MVP scoping actually happens. Every feature in the backlog gets the question: does this move the one signal? If yes, ship it. If no, defer it — even if it's elegant, even if it's two days of work, even if a stakeholder loves it. The discipline of cutting is the discipline of MVP.

The thing that nobody warns you about

When you ship a true MVP — one that is genuinely small — half the team will feel underwhelmed. Stakeholders will ask why "more features didn't make it." Sales will say it's "not enough to demo." Engineering will worry it looks unfinished.

This is normal. It is not a sign you scoped wrong. It is a sign you scoped *correctly* — because a true MVP, by definition, leaves out things people wanted in.

The PM's job in that moment is to hold the line. Ship the MVP. Watch the one signal. Then make data-led decisions about what to add. The teams that flinch and add features back in before launch end up shipping a v1 disguised as an MVP — which means they get neither the speed of an MVP nor the polish of a v1.

A small operational tip

I write the MVP scope as one paragraph, in customer language, in present tense. "When a lawyer receives a new request, they see X, can do Y, and feel Z." That paragraph goes on the wall, in the doc, in every sprint kickoff.

Anyone trying to add scope has to argue with the paragraph, not with me. It works better than any prioritisation framework I've seen.

The shorter version

MVP isn't a size. It's an alignment. The hard part isn't building it small. The hard part is keeping all four definitions of "small" in the same room until you ship.

Get that part right and the rest of the product gets a lot easier.