The term MVP gets thrown around so often it’s practically lost its meaning. Somewhere along the way, “minimum viable product” became a polite way of saying “we shipped something half-baked and called it a strategy.”

That’s not what Eric Ries had in mind when he wrote The Lean Startup in 2011. And it’s definitely not what good agile teams do.

“A real MVP isn’t just small. It’s something that solves a real problem for the user and for the team. It has to teach you something. If it doesn’t, it’s not viable.”

The “minimum” and the “viable” are both hard

Most teams obsess over minimum and forget about viable. They cut scope until there’s barely anything left, then wonder why users don’t engage with it. Or they do the opposite, and they add “just a few more” features until the thing takes six months to build and the original hypothesis is buried.

Getting both right requires something uncomfortable: Deeply understanding your user’s problem before writing a single line of code or placing a single element on a canvas.

The question isn’t “What’s the smallest thing we can build?” It’s “What’s the smallest thing we can build that tells us whether we’re solving the right problem?”

Finding the core

One useful team exercise is simply called “finding the core.” It’s a collaborative process of stripping a complex feature down to its essential purpose: The single thing that must be true for the feature to have any value at all.

Everything else is additive. Nice-to-have. Subsequent sprints. Finding the core forces the honest conversation: If we only built this one thing, would it still be worth something?

A quick test for your own features:

  • Does this feature solve a real problem as the user describes it, not as we imagine it?
  • If we strip out everything except the core action, is there still something useful left?
  • Will shipping this teach us something we don’t already know?
  • Could we kill this feature after testing it, or have we already over-invested?

Start with one

There’s a second principle that pairs beautifully with finding the core, and it’s even more tactically useful: “Start with one.”

The instinct in design is to build the whole system at once: An entire dashboard, a complete filtering interface, and a full data management tool. The problem is that this delays feedback, encourages overbuilding, and makes the feature emotionally hard to kill if it isn’t working. We get attached to things we’ve spent time on.

Starting with one means that instead of designing ten charts, design the single most important one and see if users actually want more. Don’t build a system to manage thousands of entries before users have accumulated ten. Don’t design four notification types before the first one has proven useful.

“One gives you a signal. Ten gives you noise and a lot of wasted work if the signal says no.”

Pivot or persevere

All of this is in service of a single decision that every product team has to make: Do we keep going, or do we change course?

Good MVPs make that decision easier, faster, and cheaper. Bad ones make teams feel busy while avoiding it entirely.

The goal of building small isn’t modesty. It’s clarity. And sometimes, the most important thing a small experiment can tell you is: This isn’t the right direction. Go somewhere else.

That’s not failure; that’s the whole point.

The article originally appeared on Substack.