What is an MVE?

MVE stands for Minimum Viable Experience: the smallest thing you can put in front of a real customer to learn whether they want the solution.

That's the full definition I promised back in Part 04, at the design-concepts step.

Read it again, because the word carrying all the weight isn't in the acronym. It's LEARN. An MVE is not the smallest product you can get away with shipping. It's an experiment, dressed in just enough product for a real customer to react to.

That's the Experience in the name. A real customer reacting to something real, without you having to ship a product. A clickable mock, the kind of tap-through screens that look like a working app but aren't wired to anything. A working prototype built in a spreadsheet. A short demo someone can watch.

Putting a prototype in front of one customer isn't shipping. Shipping means releasing it, selling it, and supporting it for everyone.

You'll hear other names for it. MVP, minimum viable product. POC, proof of concept, which is my own everyday word for it on the design-thinking page. They all point at the same object, the smallest version you put in front of a customer, and customers don't care which acronym wins. I'm leading with MVE here on purpose, because the E forces the point the other names let you forget. The whole job is the Experience and what it teaches you, not the product.

And here's why the name you pick can't save you. The moment a real customer touches the thing, they expect it to work, they expect support when it doesn't, and they expect it to still be there next week. The humble label is for you, not for them. I wrote it on LinkedIn back in 2022. "As soon as you release a product, it becomes a product." Name it as humbly as you want. Once it's out, it's out.

Even if you release the MVP or the product and slap a "beta" tag in the top corner, to the customer, it's still the product. THEY. DO. NOT. CARE. Most customers don't understand that nuance and don't care.

So this page's title is a bit of a trap. The question that matters isn't "what is an MVE?" It's "am I running an experiment to learn, or am I shipping a small product and calling it one?" Same object, either way. The only thing that separates the two is the discipline you bring to it, and the acronym you choose doesn't supply that discipline. You do.

Confusing the two is one of the most expensive mistakes in product, and I can show you the bill. I lived it.

Eighteen months of "minimum"

Maybe you've met this team. They've been "in MVP" for a year and a half. Nobody can say what question the MVP is supposed to answer, or when the "minimum" stage ends. There's a roadmap, though. There's always a roadmap. More building, never an answer.

I didn't just meet that team. I spent three years inside one. I used to work at a very large insurance company, and in those three years I shipped exactly one product. One. A healthy team ships and learns from something many times in three years. We shipped once. Everything ran waterfall, one phase fully finished before the next began. Months of concept work. A year or more of design back-and-forth. Then development discovering the designs couldn't be built as drawn. And then, somewhere around the testing phase, the project would just get canceled. Costing too much. Competitors already there. Never mind.

And the thing is, the teams tried to do it right. They asked the textbook question, what is the least we can build to get something out? It still took a year and a half, closer to two, for those projects to ship or die.

That's what happens when "minimum viable" gets bolted onto a product mindset. The word minimum doesn't shrink the product; the product swallows the word. You inherit the full machinery of a launch, requirements, sign-offs, release plans, and two years in, nobody can answer the only question that mattered on day one. Does anyone actually want this?

The platform that won small and died big

Years later, on a consulting project building a company's AI strategy, I watched both sides of this lesson show up on one product inside one company. A win that came from staying small. A death that came from forgetting it.

You don't build a strategy on guesses, so I started by learning how the company's past projects had won and lost. Part of that discovery was the diagnostic questionnaire I showed you on the design-thinking page, sent to the senior leadership team. Two of the questions asked which projects had succeeded, which had failed, and why.

The same internal platform showed up in both answers.

First, the win. Version one of a request-management platform, the internal tool people used to file and track requests, built years earlier. In the leaders' own words, it succeeded "through maintaining a precise, limited, and specific scope using existing technology and in-house personnel." Read that like a recipe. Limited scope. Technology they already had. People already in the building. They didn't fund a moonshot to find out whether the idea was good. They ran the smallest version that could prove it, and it proved it.

Now watch the same team kill it.

Then came version 2.0. The platform was a certified success, so naturally everyone wanted it to do more. The failure answer, again in their own words, came "when the software was modified to accommodate more than its intended purpose." The expansion had no real technical leadership behind it, and quality, training, and communication all fell behind. The product that earned its life through limited scope was killed by unlimited scope.

I didn't write either of those sentences. The people who lived it did, in a questionnaire. When a leadership team names its biggest win as "precise, limited, and specific scope" and its biggest failure as "more than its intended purpose," that isn't my opinion about small experiments anymore. It's their own verdict on their own product, the same product in both answers. Only the scope changed.

A product is a product is a product

An MVP is still a product. The moment it ships to real customers, all of product's gravity applies. Support. Quality expectations. Scope pressure. Opinions. No acronym, however humble, exempts you.

"But our MVP is our experiment. We're learning from it." Maybe. Two questions will tell you.

What question is this experiment designed to answer? A real experiment states it in one sentence. Will this specific group of customers trade money or time for this solution? A product in disguise answers with a feature list.

When does it end? An experiment has an end date with a decision waiting on it. Persevere, pivot, or kill. Keep going as planned, change direction, or stop. And you make that call against the one-sentence question you wrote at the start. Did this group of customers trade money or time, or didn't they? That answer is what tells you which of the three to do. A product in disguise has a roadmap instead. If the only plan for your MVP is to keep building, you're not in the minimum stage of anything. You shipped. Own it, staff it, and stop calling it an experiment.

Do as little work as possible to learn the most

And it's almost always less work than you think.

Say you're an analyst with an idea for a reporting tool. Your customer here is internal, the team that would use the reports, and an internal user is still a real customer for this purpose. You could spend months designing the sharpest dashboard your company has ever seen. Or you could build the prototype in Excel. Pull in the data, make the graphs, send it to the people you'd be building for, and find out whether anyone values the information. That's a couple of days of work. Build the huge, amazing version first and you might spend months discovering that nobody wanted the data at all.

And this isn't a new position I've talked myself into. In 2021 I wrote, "What is the smallest experiment you could run to solve a portion of the complex challenge? Run it, test the results, and persevere or pivot." I called it an MVP in that post, but what I described was an experiment. The label has drifted over the years. The discipline never moved.

Keep them short, too. The cadence from the design-thinking page applies here with full force. Two weeks is the ceiling for building and testing one, a month at the absolute outside. The Excel prototype lands well under that, and most good experiments do. If yours is creeping past two weeks, that's usually the product mindset sneaking back in.

Plan on iterations, not a verdict

Each experiment also has to stay small because you're going to need several. Here's why several.

You're really answering two different questions, in order, and each one is its own experiment. The first question is whether the problem is even worth solving. Does the analyst's team want that reporting data at all? The second question only matters if the first one came back yes. Now you need a version that actually solves it, the report that gives them something they'll act on. Two questions, two experiments, minimum, and the first one almost never lands the answer to the second.

So speed matters twice, once to each question, and small is the thing that lets you run both. A bloated, polished experiment can answer one question slowly. Two cheap ones answer both, back to back. That's why how many experiments you can run matters more than how finished any single one looks.

The same post that said "it becomes a product" also said this. "Regardless of how much effort you put into your first release, it will take iterations." Six extra months of polish doesn't buy you out of that. It just makes iteration one slower and more expensive.

What a win looks like

How do you read the result? Watch what the customer is willing to give up for it. When a currency changes hands, money, time, or contact information, you've learned something real, and it points you toward persevere. Money is the strongest signal. Time is next. A customer who sits through a working session with your rough prototype is paying you in hours. Contact information is the weakest signal that still counts.

And no currency offered reads just as clearly. When nobody will trade you anything, cheaply and quickly, that's your kill. You didn't fail. You learned the cheap way, which is the whole point.

Two examples from Part 04 make both ends of that range concrete. Dropbox ran an explainer video before the product existed, and a waiting list of contact information, people trading their email for a thing nobody could touch yet, told them to go build it. At the other end is a kill, told in full on the design-concepts step. A team faked a $100,000 add-on with a cheap stand-in on a $15-a-month server, and in under a week proved nobody wanted it. They kept the tool they already had and never built the expensive one.

Hold on to that last one. Most teams get it backwards. An experiment has two good outcomes. It earns the next investment, or it kills the idea before the idea kills your budget. The kills are wins, and I make that case in full on the segmentation page. Plenty of my own experiments ended in a kill, and that's the system working. The only bad outcome is the one the insurance company kept buying. Two years and a canceled project, when a two-week experiment would have taught the same lesson for pocket change.

So run the audit on your own work, today. Take the thing your team currently calls an MVP, or a POC, or whatever the acronym of the month is. Write the one-sentence question it exists to answer. Write the date it ends and the decision that gets made on that date. If you can write both, you're running an experiment, and you can call it anything you like. If you can't, you're building a product. Treat it like one, or kill it like one.