What MVP Means in Practice, and How to Ship One in Three Weeks
The term minimum viable product, usually shortened to MVP, is another one of those startup phrases that gets used far more often than it gets defined. Founders often build something they call an MVP that took six months and cost a small fortune, and they wonder why the whole exercise did not produce the learning that Eric Ries had promised.
The problem is not that the founders were doing it wrong exactly, it is that they had internalised a definition of MVP that had grown out of shape over the years, and they were building something much larger than the term was originally meant to describe.
The purpose of this piece is to give you a working definition of MVP that fits an actual small startup, and a specific three week plan for shipping one, so that you can stop treating the term as a vague ideal and start treating it as a concrete practice.
What MVP actually means
An MVP is the smallest possible version of your product that lets you test whether the core assumption behind the business is true. The core assumption is not "will people like this product", it is something more specific, usually shaped as "will people in situation X do behaviour Y often enough to justify us continuing to build this". The MVP exists to answer that question, and everything else the product could eventually do is out of scope for the MVP itself.
This means the MVP is much smaller than most founders think it should be, and the discomfort you feel while building one is usually a sign that you are on the right track. If you are proud of how polished your MVP is, you probably built too much. If you are slightly embarrassed to show it to anyone, you probably built the right amount.
The three week plan
The first week is spent defining the assumption you are actually testing and the smallest thing that would test it.
On Monday and Tuesday, write down the core assumption in one sentence, and write down what you would need to see in order to believe or disbelieve it. On Wednesday and Thursday, sketch the smallest possible version of a product that would let you observe that behaviour, usually a single flow with one input and one output, and nothing else. On Friday, write down a list of exactly what needs to be built to make that flow work, and cut everything from the list that is not strictly necessary.
The second week is spent building the flow. This is the actual construction, and it should be shockingly quick if the first week produced a tight enough list. If the second week runs long, that is a signal that the list was not tight enough, and you should stop building and go back to cutting the list rather than continuing.
The third week is spent finding five to ten users to try the flow, watching them use it, and recording what they do. This is the most important week, and most founders skip it because they are still in build mode and cannot quite shift to observation mode. Do not skip it. The whole point of the MVP was to observe what happens when real people try the thing, and if you never do that observation, you have wasted the previous two weeks.
What to do at the end of week three
At the end of the third week, you should be able to write a short summary, usually less than a page, of what your assumption was, what you built, what happened when people used it, and what you now believe about the underlying business as a result. This summary is the actual output of the MVP process, and it should either give you confidence to keep building in the same direction, or tell you to change direction, or tell you that the underlying idea does not work and you should stop.
Why three weeks specifically
The three week window is short enough to force you to cut ruthlessly and long enough to actually build something functional. Anything shorter than three weeks tends to produce something so rough it does not really test the assumption, and anything longer tends to allow the scope to grow beyond what the MVP was meant to be. Founders who commit to the three week window tend to ship real MVPs, while founders who allow themselves an open ended timeline tend to build much larger products under the same name, which defeats the whole purpose of the exercise.
The discipline is the entire point. An MVP built in three weeks with a clear question produces real information. An MVP built in six months without a clear question produces a product you now have to maintain without knowing whether it should exist. Choose the version that produces information rather than the version that produces something to show off, and you will save yourself months of confused effort down the line.
Comments