Menu Email Us


How to get it right? How long can you expect it to take when shipping the first version of your idea?

The Minimum Viable Product or MVP is the first step in bringing your idea and product to market. Perhaps ironically, it is also the easiest one to get wrong.

Over the past fiften years, I've personally built or led the development of the first version of at least a dozen products. Some were small in scope, others were on the larger side. If there is one thing I have learned through these experiences, it is that the MVP is the one that most founders and teams tend to miss the mark on.

You can get an MVP wrong in one of two ways:

1) You build the wrong thing based on incorrect assumptions. Though not obvious at first, this is actually good news. You'll probably discover what your customer actually wants, and are one step closer to building it -- so long as, you didn't commit the second mistake.

2) You took too long, over-complicated, over-built, and over-engineered the MVP.

But we would never do that.

Of course, no one ever starts out thinking that they will spend far too long and over-complicate their initial product and solution. It is in fact surprisingly more common than you would imagine. Of all the unforced errors teams make, this one likely ranks right at the top.

In my experience, there are two things that derail MVPs: 1) not thinking through what's truly important in the first version and 2) having a team that doesn't understand trade-offs.

The first has to do with product, the second with engineering.

Scope & Simplicity

The first version of your product needs to answer one, and only one question -- are we solving the right problem? I don't need to stress the reason for why this is important. What does matter is getting to this answer as quickly as possible.

And how do you get to this quickly? It starts with getting the scope and simplicity right. Most founders and teams make the cardinal mistake of thinking that think more features is better. Or that those few extra features will make customers use or like the product more. The truth couldn't be further from this.

The key to building an effective MVP is to keep the scope tight and leave the crap out. This is easier said than done. The temptation is to add, but the instinct should be to subtract.

Note that this is not license to build something that feels unfinished. Minimum viable does not mean half-assed. We don't want to sacrifice quality at the altar of the MVP.

Getting the scope right is an exercise in restraint. Our goal is to plan twice, cut once.

How do you actually do this? Think in terms of the capabilities the product needs to have, not features. What do we want the user to accomplish? What is material to their experience of the product? What can they live without?


I will say this right at the outset -- for most products, your MVP should take somewhere in the order of two to six weeks from start to finish.

This is of course not true for every product, and depending on the nature of the product, it could vary a bit. But by and large, this timeframe suits most web/mobile products. Less than two weeks could be ambitious, more than eight weeks probably means you're over-building or your team doesn't understand trade-offs.

It is very much possible today to build a viable, and dare I say, delightful product in that timeframe. But only if your team understands the trade-offs it needs to make.

I generally view the trade-offs at this stage as picking two of the following three

        Time to market
             /  \
            /    \
           /      \
          /        \
         /  pick 2  \
        /            \
Longevity/         Code cleanliness/
scalability of     best practices

Far too many teams try to do all three. I don't think it's possible. They try to build for the future, do it right today, and want to get there faster.

I personally lean towards optimizing for time to market and code cleanliness/best practices. Time to market for obvious reasons. Code cleanliness and best practices because it helps you move faster and deal with less technical debt. Longevity and scalability are high-class problems. If you survive out of the gates, and your customers actually want your product, you will live to build it for the future.

I've tried to outline our thinking on what it takes to build great MVPs, and get there faster and in one piece. If you think we can help you with yours, feel free to reach out to us at