The term MVP has been ruined. When Eric Ries coined “Minimum Viable Product,” he meant something lean, fast, and testable. What most founders hear is “crappy product that barely works.” And what most customers experience is exactly that — something so minimal it’s insulting.
I’ve stopped using the term. Instead, I talk about MVEs: Minimum Viable Experiences. The distinction isn’t semantic. It changes what you build, how you build it, and what you learn.
A product is a thing. An experience is what the customer feels when they interact with your thing. And feelings drive purchasing decisions, referrals, and retention far more than features do. This is something I learned not in a business school, but from performing magic — where the audience’s experience is the only thing that matters, not the method behind it.
Why MVPs Keep Failing
The standard MVP playbook says: strip your product to its absolute minimum feature set, launch it, and see what happens.
In theory, this is sound. In practice, it produces two specific failure modes.
Failure mode 1: The MVP is so minimal that customers can’t evaluate the core promise.
Imagine you’re testing a meal delivery service. Your MVP might be: build a website, let people order, cook the food yourself, and deliver it in your car. That’s lean. That’s minimal. But if the food shows up cold because your car isn’t insulated, and the packaging is a ziplock bag, the customer’s experience is “this is garbage” — not because the core idea is wrong, but because the experience was bad.
You’d conclude nobody wants meal delivery. The actual conclusion should be that nobody wants cold food in a ziplock bag. The MVP tested the wrong thing.
Failure mode 2: The MVP tests features, not the outcome.
A founder building a budgeting app ships an MVP with just expense tracking. Users try it, shrug, and leave. The founder concludes the market doesn’t want budgeting tools.
But the market doesn’t want expense tracking. They want to feel in control of their money. The MVP tested a feature (tracking) when it should have tested an outcome (feeling of control). A Google Sheets template with manual entry and a weekly summary email might have tested the same outcome more effectively.
Both failure modes stem from thinking in products rather than experiences. Products are things you build. Experiences are things your customers feel. Ship it ugly, sure — but ship something that delivers the core feeling.
What Makes an MVE Different
An MVE has three properties that distinguish it from a traditional MVP:
Property 1: It delivers the core outcome, even if manually.
An MVE doesn’t need to be automated. It doesn’t need to scale. It doesn’t even need to be a product in the traditional sense. But it must deliver the outcome the customer is paying for.
If you’re building a personal styling service, your MVE might be: the customer fills out a Google Form, you personally review their responses, pick outfits from online stores, and email them a styled lookbook. Zero technology. Full outcome.
Property 2: The rough edges are in the delivery mechanism, not the core experience.
Ugly is fine. Slow is fine. Manual is fine. What’s not fine is compromising the thing the customer actually cares about.
A restaurant can have plastic chairs and paper plates (rough delivery mechanism) as long as the food is excellent (core experience). An MVE works the same way. Figure out what the customer actually values, protect that ruthlessly, and let everything else be rough.
Property 3: It’s designed to answer a specific question.
Every MVE should have a hypothesis attached to it. “I believe [target customer] will pay [price] for [experience] because [reason].”
The MVE tests this hypothesis. Not “is my product good?” but “will this specific person pay this specific amount for this specific outcome?” That’s a question with a binary answer, and binary answers prevent the ambiguous “sort of validated” state that traps founders for months.
How to Design Your MVE
Here’s the process I use. It takes about a day of thinking and a day of building.
Step 1: Define the outcome in the customer’s words.
Not your words. Theirs. If you’ve done proper customer interviews, you have quotes about what they want. Use those quotes as your MVE specification.
“I just want to know if my business idea is any good before I waste six months” — that was an actual quote from a startup founder. The MVE for that isn’t a validation tool. It’s a 30-minute call where I tell them whether their idea has legs. Outcome: certainty. Mechanism: a conversation.
Step 2: Find the simplest way to deliver that outcome.
Forget technology. Forget scalability. Forget what it looks like. How can you deliver this outcome to one person with the least possible effort?
Often, the answer is some combination of:
- A Google Form for intake
- Your personal time for delivery
- Email for communication
- A Stripe link for payment
I’ve seen MVEs that were nothing more than a text message service where the founder personally sent daily tips. No app. No automation. Just a human texting another human. It worked because the outcome (daily actionable tips) was delivered perfectly.
Step 3: Test with 5-10 people.
Not 100. Not 1,000. Five to ten. Enough to see if the outcome is valued, not enough to need infrastructure.
Charge them. Even if it’s a reduced price. Free beta testers don’t give you validation data — they give you polite feedback. Paying customers give you truth.
Step 4: Watch what happens after delivery.
The most important data from an MVE isn’t whether people buy. It’s what they do after they’ve received the experience. Do they tell others? Do they come back? Do they ask for more?
If your 5-10 test customers use the thing once and forget about it, the outcome wasn’t compelling enough. If they refer friends without being asked, you’ve found something worth scaling.
MVE Examples Across Industries
Let me make this concrete with examples from founders I’ve worked with.
Fitness coaching service:
- Product MVP: Build an app with workout tracking, meal plans, and progress photos
- MVE: WhatsApp group where the founder sends daily workouts and checks in weekly via voice note
- Result: The MVE retained 80% of participants for 8 weeks. The core experience was accountability and personal attention, not technology.
B2B data analytics:
- Product MVP: Build a dashboard that pulls data from multiple sources
- MVE: Manually create weekly PDF reports using data the client emails over
- Result: Clients valued the insights (the outcome) and didn’t care about the delivery mechanism. This confirmed the business before a single line of code was written.
E-commerce curation:
- Product MVP: Build a marketplace for curated artisan products
- MVE: Instagram account with curated product photos linking to existing shops, plus a monthly “picks” email
- Result: Email subscribers converted at 12%. The curation was the value, not the platform.
Online education:
- Product MVP: Build a course platform with video, quizzes, and certificates
- MVE: Live Zoom sessions recorded and shared via Google Drive
- Result: Completion rates were 4x higher than typical online courses because the live format created accountability. This insight would never have emerged from building a self-paced platform first.
In every case, the MVE was faster to build, cheaper to run, and more informative than the product MVP would have been. And in every case, it revealed something unexpected about what customers actually valued — insights that shaped the eventual product in ways the founders couldn’t have predicted.
The MVE Canvas
I use a simple one-page canvas when designing MVEs. Here are the five boxes:
Box 1: Customer outcome What does the customer feel or achieve after using this?
Box 2: Current alternative How does the customer currently achieve this outcome (or a close approximation)?
Box 3: MVE mechanism What’s the simplest way to deliver the outcome? (Manual processes, existing tools, personal service)
Box 4: Hypothesis “I believe [who] will [action] because [reason], and I’ll know it worked if [metric].”
Box 5: Kill criteria What result would make me stop? (Be specific. “If fewer than 3 out of 10 test customers come back for a second round, this isn’t viable.”)
The kill criteria box is the most important and the most often skipped. Without it, founders rationalize disappointing results. With it, there’s a clear decision point that removes emotion from the equation.
I print this canvas and fill it out by hand. Something about physically writing the kill criteria makes them feel more binding than typing them into a document. Call it superstition. It works.
From MVE to Product: Making the Transition
Once your MVE is validated — people pay, people come back, people refer — you face the next question: when and how do you turn this manual process into a product?
The answer is: only automate the things that are bottlenecking growth.
If you can handle 10 customers manually but not 50, figure out which specific step breaks at 50 and automate just that step. Don’t build a full product. Build the minimum automation to handle the next stage of growth.
This is the “systematize before scaling” approach, and it’s the opposite of how most founders think. Most founders want to build the complete product first and then find customers. The MVE approach says find customers first, serve them manually, then automate only what needs automating.
The result is a product shaped entirely by real customer behavior rather than your assumptions. Every feature exists because a real bottleneck demanded it, not because you thought it would be “nice to have.”
This approach also has a hidden benefit: it makes you deeply understand your own business operations. When you’ve manually done every step of delivering your product, you know where the friction is, where the costs accumulate, and where the real value gets created. That operational knowledge is irreplaceable when you eventually scale.
Key Takeaways
- MVEs test outcomes, not features. An MVP asks “does this feature work?” An MVE asks “does this outcome matter enough for people to pay?”
- Manual is fine. Ugly is fine. The core experience must be protected. Rough edges in delivery are acceptable. Rough edges in the customer’s core outcome are not.
- Test with 5-10 paying customers, not 100 free users. Small numbers with real money produce better data than large numbers with no commitment.
- Define kill criteria before you start. If you don’t specify what failure looks like, you’ll rationalize your way past it.
- Automate only what bottlenecks growth. Don’t build a full product; build the minimum automation needed for the next stage.
