Escaping the MVP Trap: How Value Testing Saves Product Teams

A few reflections from this week in product work.

I realised that “Minimum Viable Product” might be one of the most misunderstood phrases in our industry. Somewhere along the way, MVP stopped being about testing ideas and started sounding like a lighter version of your final product. A stripped-down v1, scoped just enough to ship.

But that’s not what we need.

What we’re really trying to do is validate whether the idea we have is worth pursuing. That’s it. Not to build faster. Not to cut corners. But to answer the question: does this solve a real problem in a way people actually want?

If that’s the goal, then maybe we need a better term—something that reflects the intent, not just the output.

That’s where Value Hypothesis Testing comes in.

The Problem with “Minimum Viable Product”

The phrase “Minimum Viable Product” has been around for over a decade. Most of us first heard it through The Lean Startup and adopted it as a standard part of how we build. But even now, it’s easy to see how often teams still miss the point.

Instead of testing whether an idea holds any real value, we jump straight into building. We scope, design, polish—and before we know it, the MVP has started to look a lot like a soft launch. It becomes more about shipping a tiny version of the product than learning anything useful.

The issue isn’t the idea behind MVP—it’s how we talk about it.

Language shapes how we work. And “Minimum Viable Product” still sounds like the goal is to build something. But what if we reframed it around what really matters: Are we right about the value this thing is supposed to deliver?

That’s the mindset shift behind Value Hypothesis Testing.

By focusing on value, we force ourselves to articulate the core assumption we’re testing—before writing a single line of code.

By calling it a hypothesis, we remind ourselves our ideas are unproven. And by emphasising testing, we prioritise speed and customer feedback over premature execution.

What This Article Covers

• Practical steps to escape the build trap and validate ideas faster.
• Why the term MVP often misleads teams into overbuilding.
• How Value Hypothesis Testing keeps the focus on learning.

Misinterpretation of “Minimum”

In theory, “minimum” means the smallest possible effort to validate a hypothesis. In practice, teams treat it as the first release of a product—loading it with “just one more feature” to make it feel complete.

• Example: A team building a food delivery app spends months perfecting a multi-restaurant interface before verifying if users even want the service.
• Reality: The true “minimum” might have been a manual concierge test (e.g., taking orders via WhatsApp) to prove demand.

As Marty Cagan points out in Inspired, product teams often mistake “minimum” for “first draft.” That’s how you end up sinking time into ideas that haven’t earned it.

“Viable” Misleads Teams

The word “viable” suggests something fully functional—a product that “works.” This pushes teams toward engineering completeness rather than learning speed.

• Scenario: A SaaS team delays testing their core value proposition because the onboarding flow “isn’t polished enough.”
• Reality: “Viable” should mean viable for testing, not viable for scaling.

An MVP isn’t a prototype, and it’s not a beta either.

Too often, we hear MVP used to mean two very different things—a rough demo to get initial feedback, or even a beta version of a near-complete product for early adopters.

But that’s missing the point. An MVP’s goal isn’t to perfect or refine a solution. It’s meant to answer one simple question: Is this problem worth solving?

Consider Dropbox’s early days. Their MVP wasn’t a half-built app packed with features. It was a simple video that showcased the concept—designed solely to gauge interest.

Contrast that with a team rushing to build a “beta MVP” with 80% of the features in place, all before checking if users actually cared.

This is where the root of the problem lies. The traditional MVP framework puts so much focus on producing an output—a product that seems complete—rather than driving the outcome: validated value.

The fix is simple: stop calling it an MVP. Instead, we should think of it as Value Hypothesis Testing.

Why “Value Hypothesis Testing” Is a Better Way to Frame It

The words we use shape how we think—and how we build. Minimum Viable Product puts the spotlight on building something, anything, that works. But Value Hypothesis Testing shifts the focus to what really matters: learning whether our idea delivers value.

It’s a small change in language, but it unlocks three big mindset shifts.

1. It brings clarity to what you’re actually testing

MVPs often turn into feature checklists. “What’s the smallest thing we can ship?” becomes the guiding question, and before long, teams are back to building again—just with a tighter scope.

Value Hypothesis Testing flips that. It starts by asking: What’s the assumption we’re trying to prove?

It might look something like this:

“We believe [ solution] will solve [ problem] for [ audience], resulting in [metric improvement].”

Example:

• MVP mindset: “Let’s build a basic fitness app with a few tracking features.”
• VHT mindset: “We believe time-strapped professionals will pay for 5-minute home workouts. Let’s test that with a simple landing page and waitlist.”

By framing the effort as a hypothesis, we’re forced to be honest about what we’re assuming—and that’s where real learning starts.

2. It makes room for uncertainty (and lowers the ego)

When we call something an MVP, it often starts to feel like the product. Even if it’s early, even if it’s rough—we’ve built something, so we get attached. That attachment makes it harder to change direction, even when the signals are telling us to.

But Value Hypothesis Testing starts from a different place:
We’re not sure this is valuable yet.
We’re testing a belief, not defending a product.

It gives the team permission to be wrong—and that’s what creates a safe space for real learning. When you start with “we might be wrong,” it’s a lot easier to get to what’s right.

3. It shifts the goal from polish to pace

The word testing keeps us honest. It reminds the team that we’re not just launching—we’re learning. So instead of asking, “What can we build?” we ask:

• What’s the fastest way to know if this matters?
• What’s the least we can do to get a real signal?

That shift in thinking unlocks faster, scrappier ways to validate.

• Instead of building a whole marketplace, throw up a “coming soon” page and measure interest—just like Zappos did when they started by posting photos of shoes they didn’t even stock yet.
• Do not code a new SaaS feature just yet, run a concierge test. Manually deliver the outcome to 10 users. If they love it, then you earn the right to automate it.

Speed beats polish when the goal is to learn what’s worth building in the first place.

The Psychological Shift

MVP thinking asks: “Did we ship it?”

VHT thinking asks: “Did we learn?”

This reframing reduces sunk-cost bias, encourages experimentation, and—most importantly—keeps the team’s eyes on the customer problem, not the product output..

How PMs Fall into the “Build Trap” (And How to Climb Out)

Even with the best intentions, product teams often find themselves stuck in the build trap—shipping features instead of discovering value.

Here’s why it happens and how the Value Hypothesis Testing mindset helps escape it.

1. The Seduction of “Shipping” Over Learning

Why it happens:

• Cultural pressure: Organisations reward output (features shipped) over outcomes (problems solved).
• False progress: Building feels productive, while testing can seem like “just talking and wasting time.”

Twitter’s “Fleets” Feature (2020-2021)

Late 2020: Twitter launches Fleets. Their take on Stories—disappearing posts borrowed from Instagram and Snapchat. The idea was simple: if posts vanish in 24 hours, people might feel less self-conscious and share more. A quick fix for flat engagement. Engineers shipped it fast. Leadership clapped. Competitors? Noted.

But users didn’t care.

The team moved quickly, mistaking speed for insight. No one stopped to ask: Do Twitter users even want this? The assumption was clear—copying a popular format would drive results. But it didn’t. It was activity, not progress.

The data told the story. Most users skipped Fleets entirely. The few who used it? Already tweeting regularly. Not the new voices Twitter hoped to activate.

Instead of sparking conversation, Fleets added noise. Another feature that looked good on a roadmap but meant nothing to the people using the product.

To their credit, Twitter didn’t drag it out. Eight months later, Fleets was gone.
VP of Product Ilya Brown summed it up: “This didn’t work. Back to the drawing board.”

Here’s the real lesson: If Twitter had started by asking, “Do people even want more casual ways to share?”—and tested that with small experiments or rough prototypes—they could’ve saved time, money, and a lot of engineering hours.

Instead, they went all-in on a solution before proving the problem. Expensive way to learn, but they took the hit and came back with sharper focus on what users actually cared about.

The VHT approach:

Start with a problem interview. (See The Mom Test by Rob Fitzpatrick.) Focus on validating pain, not pitching ideas or obsessing over your competitors.

Measure progress by what you’ve learned—not what you’ve launched.

Instead of:

“We shipped our MVP this sprint.”

Try:

“We invalidated our pricing assumption in two weeks.

2. Confusing “More Features” with “More Value”

Why it happens:

• Internal bias: Teams assume their preferences match customer needs.
• Fear of simplicity: Stakeholders worry a barebones test will disappoint users.

The VHT approach:

• Start by separating what’s essential from what’s just noise. Tools like the Kano Model can help you tell the difference between must-haves and nice-to-haves.
• Then pretotype it. (Hat tip to The Right It by Alberto Savoia.) Don’t build a full uploader—ask about past behaviors or current pain points (e.g., “How do you share medical records today?”)

3. Mistaking Early Adopters for Market Fit

Why it happens:

• Pilot users usually tolerate incomplete or rough features, creating false confidence.
• Early traction can look like product-market fit—but without real usage data, it’s just wishful thinking.

Example:
A B2B startup felt confident after 10 pilot customers signed up. But once real pricing kicked in, they all churned.

The VHT mindset:
Start by mapping your riskiest assumptions—just like in The Lean Startup.

Type of Risk	Question	How to Test It
1. Value Risk	Do users actually care?	Test with a landing page
2. Feasibility Risk	Can we build it?	Run a quick tech spike
3. Usability Risk	Can they use it?	Try a Figma flow

Prove each step before you move on.

4. The Roadmap Mirage

Why it happens:

• Annual plans reward certainty, not discovery.
• And let’s be honest—HIPPOs (highest paid person’s opinions) often set the course.

Example:
One team built out a year of features from the exec wishlist. After launch? Crickets. Low usage across the board.

The VHT mindset:
Ditch rigid roadmaps. Use an opportunity tree (from Continuous Discovery Habits by Teresa Torres) to stay grounded in real problems:

• Start with a business goal: “Increase conversions”
• Break it down into customer problems: “Users abandon at checkout”
• Test ideas surgically: “Would a 1-click upsell change that?”

Escaping the Trap: A VHT Checklist

For every idea, ask:

1. What exactly are we assuming? (Write the hypothesis.)
2. What’s the fastest way to prove/disprove it? (Design the test.)
3. What will we do if we’re wrong? (Define pivot/kill criteria.)

Practical Steps to Shift from MVP to Value Hypothesis Testing

The shift from MVP thinking to Value Hypothesis Testing (VHT) requires more than a terminology change—it demands a new workflow.

Here’s how to put this into practice, step by step.

Step 1: Define Your Core Value Hypothesis

Stop asking: “What’s the minimum product we can build?”
Start asking: “What’s the riskiest assumption we need to validate?”

Use this template:

“We believe [target users] will [expected behavior] because [value proposition], resulting in [outcome].
Our team can deliver this because [capabilities/resources], and we’ll know it’s feasible when [technical/ops milestone].”

Example:

“We believe busy parents will pay £20/month for pre-packed healthy meal kits because they struggle with meal planning, resulting in 10% conversion from our landing page.
Our team can deliver this because we have culinary expertise and local supplier relationships, and we’ll know it’s feasible when we successfully fulfill 50 test orders manually.”

Step 2: Choose the Fastest Path to Validation

Tactics by Hypothesis Type:

Type	Tactic	Example
Problem existence	Customer interviews	“Walk me through how you handle X.”
Willingness to pay	Fake door test	“Get early access” → Measure clicks.
Usability	Rough prototype	Hand-drawn UI flows with users/ figma or prompting
Behavior change	Concierge test	Manually deliver the service.

Key: Always test with actual users in real-world scenarios (no proxy users!)

Example:

Instead of coding an onboarding flow for your SaaS, try sketching it out on paper or using no-code tools, then record a Loom demo.

Publish then link it to a Typeform asking users to “complete setup.” Track drop-off. You’ll learn more in a day than you would in a sprint.

Pro tip:
Ash Maurya’s Experiment Map (from Running Lean) is a gem for matching the right test to the risk you’re tackling.

Step 3: Define Clear Success Metrics (Before Testing)

If you don’t set metrics upfront, it’s easy to slip into wishful thinking—“Three users loved it, so we’re onto something!” or “It just needs more features.” That’s not learning, that’s storytelling.

Value Hypothesis Testing forces a clearer standard: define what success looks like ahead of time, so you can cut through the noise and make confident decisions.

How to Set Useful Metrics (Without Fooling Yourself)

Tie your metric to the hypothesis you’re testing—not just activity.

If you’re testing problem importance, look for:

• % of users who bring it up unprompted
• Emotional weight (e.g., “How painful is this?” rated 1–10)

If you’re testing willingness to pay, track:

• Conversion on a pricing page
• Real intent: credit card entry via Stripe mock checkout

Ditch the vanity metrics.
❌ “1,000 visitors” means nothing without action.
✅ “10% clicked ‘Buy Now’ at £50/month” tells you something worth acting on.

Set Thresholds in Advance

• Example:
  • “If 15% of users sign up for our waitlist, we’ll build the beta. If <5%, we’ll pivot.”
• Use ranges for uncertainty:
  • “5-10% = ambiguous; run another test. >10% = proceed.

Step 4: Run the Test — Then Stop

Here’s where teams get stuck: the endless loop of tweaking, retesting, and hoping numbers go up. Don’t fall for it.

• Enforce a Clear Finish Line
  • Timebox the test.
  • Set a hard deadline:
    • “We’ll run this fake door test for 7 days—no extensions.”
  • Book the decision meeting before in advance. Don’t leave the ending open-ended.

• Stick to the Success Criteria
  • Use your pre-defined metrics to cut through the debate:
    • “We said <5% conversion = pivot. We got 4%. We’re done.”

• Document Learnings
  • Use this simple format to document outcomes:

Field	Details
What we tested	Will users pay for AI-generated workout plans?
What happened	2% conversion (target was 10%)
Why it didn’t work	People wanted personalised advice, not automation
Next step	Pivot to a hybrid model (human + AI)

One Mental Hack

Celebrate the kill. Frame it as a win:
“We just saved 3 months of dev time and £200K. That’s a successful test.”

That’s the discipline VHT demands—and the clarity it delivers.

Institutionalise Learning

Most teams still get rewarded for shipping features. But if we want to build things that matter, we need to reward learning—especially when it leads to not building.

Start with a Hypothesis Backlog

Instead of saying, “Here’s our Q3 roadmap,” shift to:
“Here are the top 3 riskiest assumptions we’re testing next.”

Example:

• “Freemium users will upgrade for advanced analytics.”
• “SMBs want API access, not just a UI.”
• “Users will complete a 2-step onboarding flow.”

Prioritise based on two things:

1. Risk — what breaks the business if we’re wrong?
2. Leverage — what unlocks the most value if we’re right?

Make Learning a Weekly Habit

Build a lightweight ritual into your team’s rhythm: a “What did we learn?” sync. Every test gets reported in a simple format:

• What we tested: “Pricing page A/B – £50 vs. £99”
• What we saw: “£50 had 2x conversions, but lower LTV”
• What we’re doing next: “Proceed with £50, test add-on upsells”

Every quarter, run a “Killed Ideas” retro. Celebrate the ones that saved you time, money, and focus—like, “We saved £1M by not building X.”

Reward Learning, Not Just Launching

Track the right metrics for product teams:

• How many risky assumptions did we test this quarter?
• What % of features were validated before we built them?
• Are we increasing our learning velocity over time?

Recommended Books to Read:

• The Lean Startup – Eric Ries (original MVP concept)
• Inspired – Marty Cagan (on PMs falling into the “build trap”)
• The Right It – Alberto Savoia (on testing before building)
• Continuous Discovery Habits – Teresa Torres
• Running Lean – Ash Maurya

Usecases (Source):

The Atlantic’s Paywall Launch and Strategy (NiemanLab, 2019)