How to Build an MVP for Your Business Without Burning a Year on Version One

A good first version answers one market question quickly, well before it tries to be the whole company. Here's how to build one that ships in weeks and teaches you something real.

A founder spots a real problem, pictures the product that solves it, and starts building. A few weeks in, someone says "we'll need user accounts," then "we should send email notifications," then "the dashboard really needs history." Each request is sensible, and together they turn a six-week build into a nine-month one that spends the money, delays the first honest feedback from customers, and raises the odds that the market has moved by launch day.

Eric Ries gave that first version a name, the minimum viable product, as a way to learn faster, and the idea has been adopted almost everywhere since. In practice it often drifts into something else, a smaller copy of the eventual product. The version that works best is closer to a well-designed experiment, built to answer one question about the market as quickly and cheaply as possible, and it follows the rules experiments follow.

One hypothesis per build

Every first version should test a single market hypothesis that could turn out to be wrong. One, rather than three or a cluster, because that single question is what everything else in the build hangs on.

A useful hypothesis reads like this: If we build [specific capability], then [specific group of users] will [specific, measurable behavior] because [specific reason]. Each part is specific so the result can clearly confirm or contradict it, and that clarity is what makes the test worth running.

Once the hypothesis is written, choosing features becomes almost mechanical. For each proposed feature, ask whether including it or leaving it out changes whether the hypothesis turns out true. If the answer is no, the feature belongs in version two.

Finding the smallest set of features

With one hypothesis in hand, work backward from the behavior it predicts, in three steps.

Map the path. List exactly what a user has to do to perform the predicted behavior. If the hypothesis is that restaurant owners will pay for automated menu management, the path might be: sign up, connect the existing menu, make a change, and publish it. Every screen and field on that path is needed, and everything off it can wait.

Look for steps a person can do by hand. For each step, ask whether you could handle it manually, behind the scenes, without spoiling the test. Many founders find that big pieces of what they planned to build can be done by hand for the first 10 to 50 users, which cuts the build and gets the product in front of customers sooner.

Write down what "done" means. Give each feature on the path a written definition of done before development starts. "User can connect their existing menu" leaves a lot open. "User can import a menu from a Square account through OAuth and see it in the dashboard within 30 seconds" leaves almost nothing, and that precision prevents the drift that grows in the gap between what was said and what was heard.

Protecting the scope while you build

Scope creep almost never arrives as one big decision, it shows up as a string of small, reasonable additions, each too minor to argue about, until twelve of them have made the product three months late and twice the budget. The protection has to exist before development starts.

Treat the scope document as the agreement. Before any code is written, list every feature in the first version with its definition of done, along with the features deliberately saved for later. Any new idea gets compared against that document, and anything not on it waits by default.

Ask three questions about every addition. When someone proposes a new feature mid-build, ask whether leaving it out would make the hypothesis impossible to test, whether it could be added after the first ten paying customers without losing them, and whether it would take more than two days to build. If the answers are no, yes, and yes, it waits.

Build, measure, learn, in practice

Most founders know the build, measure, learn loop. Running it reliably takes more specific habits at each stage than the phrase suggests, and the table below shows what each one needs and where it usually goes wrong.

Eight weeks for the build stage isn't a law of nature, and it's a useful limit. A build that can't fit in eight weeks is either too big to be a first version or not scoped well enough to know what it is, and in both cases the right move is to go back to scoping instead of stretching the timeline.

Ship a little before you feel ready

The first versions that went on to matter were usually released before their founders felt ready. Dropbox launched with a demo video before the software existed, Airbnb started in one city for one event, and Stripe's early API needed people working manually behind the scenes.

That feeling of not being ready is useful information, because it means you're about to learn something from real customers that no amount of planning could have told you, and "ready" is impossible to define until the market has shown you what it means.

Shipping early still means shipping something that works. You release the smallest set of features the hypothesis calls for, each meeting its definition of done, without the extras that crept in along the way, and everything within that scope works properly even though the product doesn't yet do everything you imagine it eventually will.

A first version built this way is a tool for learning, and the founders who build the most efficient ones spend the most time at the start: writing the hypothesis, mapping the path, and defining done before a line of code gets written. That early care is what gets a product in front of customers in weeks instead of seasons.

Back to articles