How You Build Matters. Finding 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.

The MVP.

The minimum viable product.

The most misunderstood concept in the world of Lean startups.

And one of the most critical to get right.

Why Time To Build Doesn’t Matter

In this post about prioritizing, I argue that time to build shouldn’t be taken into consideration when deciding what to build next. You should always build the idea that will have the biggest impact on your goal next.

But what if you have a short runway or the most important thing also requires the biggest upfront investment?

This is where the concept of the MVP comes in handy. You can take any idea and distill it down to an MVP, something that you can iteratively test and refine over time.

Your initial idea may be big. It should be. You should always start from the ideal. What is the best thing I can build to drive progress toward my goal?

Bear in mind, there is a difference between “What are all the things I can build to drive progress toward my goal?” and “What is the best thing I can build to drive progress toward my goal?” At this point, we are focusing on a single idea.

Getting to an MVP

Now take that idea and ask yourself the following questions:

• What is the heart of this idea?
• How does the user derive value from this idea?
• What is the smallest piece of work we can do to capture that value?

Remember, the smallest is different from the easiest. Sometimes you have to tackle hard problems directly. But capture as much of the value as you can first.

This is where people go wrong with the idea of an MVP. The goal is to learn. Not to learn just anything, but to learn what creates value. Too often the value gets thrown out and replaced with something easy. The problem is, the easy idea might not offer much value. You have to balance minimum with viable.

Minimum forces you to think small, viable forces you to create value. You have to do both in an MVP. – Tweet This

So reduce as much as you can, but always do so in the context of delivering value.

Be Ruthless

You might think you’ve distilled your idea down to its simplest form. Do it again.

And yet again.

For each element or user story, ask yourself, “How can I make this idea work if we didn’t build this?” If you can come up with an answer, cut it.

This can be hard. As you reduce the scope, remind yourself, it’s not that you won’t build that, it’s that you aren’t building it now.

I like to think of these as tomorrow problems. Repeat after me, “That’s a tomorrow problem.”

Too often, we don’t reduce scope because we think it’s now or never. This type of thinking will slow down development and kill your product. It’s not now or never. It’s now or tomorrow.

If you don’t get now right, you won’t have a tomorrow. Be ruthless. – Tweet This

Keep Reducing the Scope as Engineers Build

Steve Blank likes to say, “No plan survives first contact with customers.” That’s true.

This is also true: “No requirement survives first contact with engineers.”

You cannot hand off requirements to your engineering team and think your job is done.

As they start to build, they will get a much better understanding of the job to be done than they could ever have while sitting around talking about it conceptually.

They will uncover hard problems. They will ask to change the scope. Sometimes broader. Sometimes narrower. They will need your help. Stay involved.

What To Do When Something is Impossible

Your ideal might be impossible. But I guarantee a close approximation is not. It’s your job to find that close approximation.

There will be times when your engineers come to you and say that something is impossible. This isn’t what they mean. Here’s what you should hear instead: The way they are currently thinking about this problem makes what you want impossible. You need to hep them think about the problem in a way that makes what you want possible.

There are a lot of debates about whether product people need to know how to code.

You don’t need to know how to code. But you do need to know how to make the impossible possible. – Tweet This

You have to be able to hold your own in an engineering discussion. You need to know how to push back, to question assumptions, and to reframe the problem over and over again until it becomes solvable.

If you don’t have the ability to do this, you will not be a good product manager.

What To Do When the Scope Grows

Inevitably as engineers build, the scope will grow. Bit by bit, they will ask, what about this corner case, can’t we add this or this, it will only take a couple of hours.

These are tempting. Be ruthless.

I know this sounds counterintuitive. Don’t dot your “i”s, don’t cross your “t’s.

You aren’t building a perfect product. You are trying to deliver as much value in as short of a period of time as possible.

Always be asking yourself, “Can I do that tomorrow?” If the answer is “yes,” do it tomorrow.

This flies in the face of everything you learn about planning ahead and productivity.

But your goal isn’t to get a lot done. Your goal is to get the right things done. Be ruthless. – Tweet This

Never Stop Looking for Short Cuts

It takes a lot of work to distill your requirements. It takes even more work to reign in the scope as engineers start to build. You need to create a culture around “less is more.” And you always need to be looking for how you can do less.

Not because you are lazy. Not because you can’t do more. And not because your team can’t do more.

But because your users don’t want more. They don’t want more features. They don’t want more options. They want value.

Relentlessly focus on delivering that value.

Are you up to the challenge? Share your experience in the comments below.

On Thursday, we’ll move on to look at how to measure success. Don’t miss out. Subscribe to the Product Talk mailing list.