Product Practice #321

MVPs ≠ Experiments

READ ON

HERBIG.CO

PUBLISHED

May 10, 2024

READING TIME

2 min & 42 sec

Dear Reader,

Don’t make the mistake of “Let’s test this assumption with an MVP.” I called out MVPs for being too expensive for shortening the lead time towards reducing uncertainty during Product Discovery back in 2017:

As Casey Winters defined it, “An MVP is all about delivering value to users by building the smallest product you can to test a hypothesis. You ship to learn, which influences future product development.”

While shipping to learn can be a crucial choice for further reducing uncertainty, there’s so much more you can do before building even the smallest version of a product.

In contrast, you can use experiments to test assumptions without delivering value to customers. Think of usability testing of Figma prototypes or fake door tests. That doesn’t make these techniques better or worse than an MVP; they are just differently suited for different contexts.

One of my favorite prompts to help product teams move out of Discovery motions and get into Discovery action is this:

“If you only had one week to reduce uncertainty as much as possible, what would you do? And why aren’t you doing it now?”

That doesn’t mean Discovery has to be done within a week, but it enforces a sense of urgency toward reducing uncertainty with the shortest possible lead time. Otherwise, Discovery work will continually expand to whatever time box you give. Consequently, aiming for an MVP as a Discovery artifact will carry overhead and dependencies since it requires actual code to be shipped to production.

When to use Experiments to reduce uncertainty further

You’re building towards initial informed conviction by investigating problem and solution spaces.
You want to iterate in short cycles to observe and interpret new data points.
You don’t need to put value in customers' hands to test an assumption.

When to use an MVP to reduce uncertainty further

Your informed conviction about an idea’s desirability is high enough that it justifies the commitment of engineering resources.
When user interviews feel like Groundhog Day.
When you find yourself saying things like, "Once we talked to these users, we're done with Discovery."

Did you enjoy this one or have feedback? Do reply. It's motivating. I'm not a robot; I read and respond to every subscriber email I get (just ask around). If this newsletter isn't for you anymore, you can unsubscribe here.

Thank you for Practicing Product,

Tim

How to Dive Deeper into Product Discovery

Learn how I helped companies like Deutsche Telekom and Forto hone their Product Discovery practices. I closely work with product organizations through workshops and coaching to introduce and adapt Product Discovery.

Learn more about my Discovery Consulting

Content I found Practical This Week

Product Leaders: Getting Teams Started with Product Discovery

As a leader, you need to coach your team to get better. Even if you don’t know their exact process and aren’t intimately familiar with the product itself, you can guide them. Start by scrutinizing their learnings. This prevents them from just going through the motions of Product Discovery. What have they learned that they didn’t know before they started? What changes will they make to the product as a result of customer feedback?

Read it here

Should I Run an A/B Test? Blueprint

Read it here

Champion Vs. Decision Maker: Whom to Target in B2B Customer Discovery?

The decision-maker is the individual who has the authority to decide whether a solution should be purchased and implemented within a company. This is typically a higher-level manager or in smaller companies the C-Suite. It's obvious why the decision-maker is important for the success of your product: Without her support, you can't succeed. The champion is the person who deeply understands the problems you want to solve with your product.

Read it here