Practice Defining Your MVP

Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery.

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 rsvp
• the ability to view who has responded
• the ability to add comments
• and so on.

These are all easy things to build. Arguably, this is the minimum feature set to be viable. So what’s the problem? The problem is:

You can’t define an MVP without first knowing what you are trying to learn. – Tweet This

An MVP is not the smallest or the easiest product you can get out the door. It’s the smallest or easiest product you can release to learn what you need to learn.

Start With What You Need to Learn

How do you know what you need to learn?  That depends on your vision.

Why are you building an event site? Who is your audience? How are their needs different from what eVite or Facebook offer? And the most important question, what are you assuming that needs to be true for your new product to work?

Let’s suppose that I’m creating an event site for soccer teams. I want to figure out who can make each game so I can ensure that I have enough players. Facebook doesn’t work for me because I’m not friends with everyone on my soccer team. eVite doesn’t work because not everyone checks their email regularly.

In this scenario, my audience is narrower than both Facebook and eVite and my needs are different. Instead of email, I’m planning to build my event tool around SMS.

Define the Smallest Test to Learn What You Need to Learn

What do I need to make this happen? You might still be thinking you need:

• a basic event listing
• the ability to RSVP
• the ability to view the RSVPs
• maybe we can hold off on comments.

Again, these are all easy things to build. Let’s get started.

Hold on. While they may be easy to build, they don’t represent the smallest thing I can build to learn what I need to learn.

My whole plan hinges on one big assumption.

This plan assume that my teammates who don’t respond via email will respond via SMS. If that’s not true, I’m no better off than I was when using eVite.

What’s the smallest thing I can build to test that assumption? – Tweet This

Easy. I don’t have to build anything.

Instead, I can pick up my phone and text my teammates who haven’t responded to my eVite and ask them if they are coming to the next game.

I can start collecting data right away. I can start to understand how many more player responses I will get long before I make any technical investments.

It’s Not as Simple as It Sounds

This sounds simple. Of course, I should text my teammates and see if they respond before building a service based around SMS.

But most people won’t.

And it’s not because they are dumb or lazy or not Lean enough. It’s because:

Identifying the assumptions that you believe to be true that are required for your idea to work is hard. – Tweet This

While this example is simple, odds are, if you were building this idea, you would never stop to question whether or not your teammates would respond via SMS.

You text your friends all the time. You respond to texts all the time. It’s easy to assume it will just work.

But there are lots of reasons why it might not.

What if I’m at dinner when I get the text and I forget to respond later?

What if I don’t know if I can make the game when I get the text and I forget to go back to it when I later do know?

I forget things all the time. I bet you do too.

What if I still use an old flip phone and I have to use the dreaded t9 entry to text? What if I don’t get text messages at all? Those people exist.

What if I just don’t think RSVP’ing is important and I want to decide right before the game if I’m going or not?

Stop Assuming and Start Testing

What’s the best way to identify your assumptions?

Talk to your customers. Talk to other people about your ideas.

Don’t say, “Isn’t this the best idea ever?” That doesn’t give them permission to disagree with you.

The more you can distance yourself from the idea, the better feedback you’ll get. – Tweet This

Ask, “I heard of this service that uses text messages to RSVP to events, do you think we should use that instead of eVite?”

Not, “I have a great idea for a text-based event site. Would you use it?”

With the first question, you’ll get honest feedback because they won’t know it’s your idea. With the second question, you’ll get a lot of people saying, “Sure” because they want to be agreeable and polite.

Never believe someone when they say they will use your service. Talking to people isn’t validation. It just helps you to uncover your assumptions. You still have to run a test to see if people will do what they say they will do.

What’s Your MVP?

You’ve read it a million times.

An MVP is about learning. It’s not about shipping a small or easy product.- Tweet This

Did you know that you rarely learn by reading? You learn by doing. So let’s try something new.

Take three minutes right now and think about what you are working on at work.

• What are you trying to learn?
• What assumption has to be true for your product to work?
• What’s the easiest way to test that?
• What’s your MVP?

If you are having a hard time identifying your assumptions, run it by a coworker, someone who isn’t as close to the product as you are.

Now go one step further and share it in the comments. I’ll provide feedback on every single one.

You don’t have to share where you work or any state secretes, just enough to evaluate whether it’s a good MVP. What are you waiting for? Get started.

Take 3 minutes to answer these two questions in the comments:

• What assumption are you making that has to be true for your product to work?
• What are you doing to test that assumption?

On Thursday, we’ll move on to talking about how to measure success. Don’t miss it. Subscribe to the Product Talk mailing list.