Building a minimum viable product: scope, speed and what to measure

TUREFF• •0

A minimum viable product, or MVP, is one of the most used and misused ideas in startups. The term was coined by Frank Robinson in 2001 and popularised by Steve Blank and Eric Ries, whose book The Lean Startup (2011) defines it as the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort. The key word is learning. An MVP is an experiment, not a cheap version of your dream product.

Start from the question, not the feature list

Before deciding what to build, write down what you need to learn. Typical questions:

Will this customer segment use it repeatedly, not just once?
Will they pay, and roughly how much?
Which part of the problem matters most to them?
Can we reach them through a channel we can afford?

The MVP is whatever lets you answer those questions fastest. Sometimes that is software; sometimes it is a spreadsheet, a form and you doing the work by hand.

Cutting scope

Most first versions are too big. To shrink yours:

Describe the single most important job the user needs done.
Map the shortest path from sign-up to that job being done.
Remove everything not on that path: settings, admin dashboards, integrations, multiple user roles, polished onboarding.
Replace hard parts with manual work behind the scenes where you can.
Ask of each remaining item: if this were missing, would the experiment fail?

"Viable" still matters. The product must actually solve the core problem well enough that people would use it again. A buggy, confusing MVP teaches you about your bugs, not your market.

Speed

Set a deadline measured in weeks, and cut scope to meet it rather than moving the date.
Use existing tools. No-code builders, templates, hosted services and off-the-shelf payments let you test a business before you invest in engineering.
Avoid premature scaling. Building for a million users when you have ten wastes time you need for learning. Keep security, privacy and data protection basics in place from day one, though: they are not optional extras.
Ship to a small group first, such as people from your interviews, so you can watch closely and talk to every user.

What to measure

Decide your metrics before launch so you are not tempted to pick flattering ones afterwards.

Activation: the share of new users who reach the point where they get real value, the moment your product works for them.
Retention: whether they come back and use it again over the following days and weeks. This is the strongest early signal.
Engagement depth: how much of the core action they do, not page views.
Willingness to pay: conversions to paid, deposits or signed pilots.
Qualitative feedback: why people stayed or left. Talk to both groups.

Dave McClure's "pirate metrics" framework, AARRR (acquisition, activation, retention, referral, revenue), is a common checklist. Be wary of vanity metrics, numbers that grow but do not guide decisions, such as total sign-ups or social media followers.

The build, measure, learn loop

Ries describes product development as a loop: build something, measure how people respond, learn from it, and decide what to build next. Run the loop quickly. After each cycle, write down what you expected, what happened and what you will change. A team that completes many small cycles usually learns more than one that ships a single big release.

Common mistakes

Building in secret for months because the product "is not ready".
Treating launch as the finish line rather than the start of measurement.
Adding features every time a user asks instead of looking for patterns.
Testing several changes at once so you cannot tell which made the difference.
Ignoring a weak result because you are attached to the idea.

What did your first MVP look like, and what did it teach you? Share your experience in the comments.