From idea to MVP: how we arrive at a first working version

Almost every software project starts with a list. Everything the product should ever be able to do, written down on an enthusiastic afternoon. That list is valuable. It just isn't a plan.

Because anyone who wants to build everything at once is still left months later without users and without an answer to the question that really matters: will people use this? That's why we start with an MVP. In this article you'll read how we get from an idea to a first working version, and which choices we make along the way.

What an MVP is, and what it isn't

MVP stands for minimum viable product. The smallest version of your product that real users can do something with, and that teaches you something.

That last part is often forgotten. An MVP is not a demo that looks nice in a presentation. Nor is it the first phase of a fixed project plan in which everything has already been decided. It's a working piece of software that tests one important assumption. For example, whether customers would rather enter their request themselves than call, or whether engineers really use a schedule on their phone.

Small doesn't mean sloppy, by the way. What's in it has to work well. There's just less in it.

Step 1: getting the problem clear

We don't start with features, but with people. Who is going to use this? What do they do now, and where does it get stuck? We usually talk to a few future users and watch how they work today. Spreadsheets, emails and loose notes often tell you more than a requirements document.

Step 2: choosing the key assumption

Behind every idea there are assumptions. That customers are willing to pay. That staff will open a new app. That the data you need is already available somewhere. We look for the riskiest assumption: if it doesn't hold, the rest makes little sense. That's what the first version tests.

Step 3: reducing the scope

This is where it gets difficult, and interesting too. We go through the list together and ask the same question about every item: do we need this to test the assumption? An extensive permissions/roles system, reports, an integration with the accounting software: important, but often not for version one. What gets cut doesn't disappear. It goes onto the roadmap.

Step 4: building in short rounds (iterations)

We build in rounds of one to two weeks. After each round you see something that works, not a progress report. That way you notice early if something turns out differently than planned, and changing course is still cheap.

Technically, we choose a foundation that can grow. An MVP may be small, but we don't build it in a way that means you have to start over after six months.

Step 5: live with real users

An MVP is only finished when someone works with it. We put the first version in front of a small group of users and watch what happens. What do they use, where do they drop off, what do they ask for? Those are the answers it was all about.

And after the first version?

That is when the real work begins. With real users and real data, you no longer choose the next step on gut feeling. Sometimes a feature that sat at the top of the list turns out to be barely missed. Sometimes users ask for something nobody had thought of.

It can also turn out that the most important assumption is wrong. That feels like a setback, but it is exactly what an MVP should deliver: an answer, before most of the budget is gone.