Practice Defining Your MVP

Teresa Torres argues that an MVP should be defined by what you need to learn, not by the smallest or easiest feature set to ship. Using a hypothetical SMS-based event tool for soccer teams, she shows how the riskiest assumption (that teammates will respond via text) can be tested with almost no building. She notes that identifying hidden assumptions is hard because founders take their own habits as universal. She recommends talking to customers without pitching the idea, and never trusting stated intent, since real behavior is the only validation. The lesson applies to any product team deciding what to build first.

01Key takeaways

• Define your MVP by the specific things you need to learn, not by a feature checklist.
• Identify the riskiest assumption your product depends on before writing any code.
• Test the core assumption with the cheapest manual method available, such as messaging real users directly.
• Look for hidden assumptions based on habits you take for granted, since users may not share them.
• Frame feedback questions around a neutral third-party idea so people don't just agree to be polite.
• Treat what people say they will do as a hypothesis; only observed behavior validates the idea.

02Key sections

MVP is about learning

An MVP is the smallest product that yields the learning you need, not the easiest feature set to launch. Feature lists like RSVP and comments are easy to build but may skip the key question.

Start with the assumptions

Clarify the vision, audience, and differences from existing solutions, then identify what must be true for the product to work. The example's core bet is that users will respond by SMS.

Test the riskiest assumption cheaply

Before building anything, the smallest test may be manual, such as texting teammates to see whether they reply. This yields data before any technical investment.

Surface hidden assumptions

Assumptions feel obvious because we use the behavior ourselves, so they are easy to miss. Consider forgetfulness, phone types, and differing attitudes toward RSVPs.

Ask neutrally and test behavior

Describe the idea as someone else's to get honest feedback rather than polite agreement. Stated intent is not validation; run a test to see what people actually do.

03From the post

“Suppose you are building eVite. Or Facebook Events. Or whatever your favorite event site is. And you need to define your MVP. How would you think about it? Some of you might already be jumping right in. You are thinking you’ll need: * a basic event listing * the ability to”

04Frameworks mentioned

Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.