MVPs ≠ Experiments

​Dear es,​

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

A Practical Guide to Using OKRs in Product Management: This hands-on guide goes beyond the average "best practices" of OKR basics and instead focuses on the real challenges of Product Teams for using OKRs in addition to Product Discovery, Roadmaps, and Scrum.

Content I found Practical This Week

Should I Run an A/B Test? Blueprint Read it here

What did you think of this week's newsletter?

Who is Tim Herbig?

As a Product Management Coach, I guide Product Teams to measure the progress of their evidence-informed decisions.

I identify and share the patterns among better practices to connect the dots of Product Strategy, Product OKRs, and Product Discovery.