Your MVP is too big

99 problems and your MVP design is definitely one.

Just a note on the design of your next Minimal Viable Product (MVP). MVPs are often misunderstood and several things can go wrong in their design and execution.

In fairness, MVPs can be more art than science. The physics that surround a business experiment are more fluid than the natural sciences.

There seems to be no area of building that people are less open to changing their minds on than the development of MVPs. Once they have an idea, they tend to run with it.

We try to live by the mantra of “strong opinions loosely held,” but goddamn, people fall in love with their MVPs and there is usually no going back.

I’m suggesting a habit of taking some time to pause and reflect.

Here is the most common problem with MVPs I see: they are too freakin’ big. The classic is people who absolutely insist on having a whole app coded as the first MVP to test their business idea.

My response is always the same...people use apps. That’s not the uncertainty.

“But, Chris, you’re wrong. I HAVE to have an app to test this idea.” Ok, let’s walk through a mental exercise to test that assumption.

What if I told you that I have a business idea to open a grocery store that is filled with ONLY beet-based products. I am going to call this store Everything Beets.

In that scenario, do you think that my riskiest assumption is either a.) people will shop in grocery stores or b.) people only want beet-based products?


So, why in the hell are you building out so much when the riskiest assumptions in your business model are much more specific?

You don’t need to build an app right away. We know people use apps to do all sorts of things.

Eliminating the waste

There is a lot of natural waste in building MVPs.

One of the first places I am inclined to waste time on building an MVP is in the backend. When Ries defines an MVP, he reminds us that it needs to be something we are going to show a customer – just the front end.

Often, I see builders spend quite a bit of time building out the back end. Automation, systems, blah, blah, blah. Stuff the customer will never see and doesn’t care about yet.

I did this the other day – a complete waste of time. I burned three hours trying to build a kill shot set of Zaps. I messaged Monte, told him that the next time I waste so much time he should feel free to punch me, and then I got the MVP up in 20 minutes – all without the backend.

When your idea takes off, you can hire someone to go in and do all that backend for you.

Some steps to better MVPs

Keeping MVPs small and specific is very hard to do. We have a natural inclination to build the whole damn thing. There are a couple of questions I like to keep in my back pocket to keep this urge in check.

The first question is, “What exactly am I trying to learn?” Remember, in Lean Startup, our MVPs are part of experiments that are testing our riskiest assumption – also known as the LOFA.

When I look at my MVP and the work it will take to launch that MVP, I try to strip away whatever doesn’t directly contribute to learning that one thing.

The second way you can keep your MVPs in check is to do a little exercise by asking yourself about some possible other ways you could test your LOFA.

This exercise is worth spending some time on. I’ve noticed that people tend to go with their first idea for an MVP, and that idea is usually too much.

You should riff on your idea a bit. Step back from it and challenge yourself to outline 2-3 other ways you could run this experiment. Resist the urge to believe there’s only one way to do things.

Eating dog food

Here is an example from just yesterday.

Monte and I were having a discussion around an MVP for a project that we want to partner on. The initial MVP was to put on a series of classes, then do some guided work, and finally, schedule a series of 1:1 coaching sessions.

Our gut told us this was too much. We went back to our LOFA and took a hard look. We clarified the LOFA but ended up with the same experiment. We riffed a bit on the experimental design and whittled it down to a sign-up form and teaching a handful of classes.

Still felt like too much.

We pulled a third person into the conversation and began to go back to work on the experiment design. 20 minutes later, we decided that we could learn everything we need to know by showing our customers what amounts to a pitch deck.

In terms of effort to build our MVP, we went from 60 hours of work to 30 hours of work to 5 hours of work. That was time well spent.

Go fast

If you are thinking about building something where the time horizon for learning is measured in weeks, then I’d challenge you to think about what you can learn in the next two days.

Always push that timeline to go faster. To be more specific in the learning. The fastest learners win.