How to Build a Minimum Viable Product (MVP)

How to build a minimum viable product: scope the smallest version that tests your riskiest assumption, instrument it, launch it and decide what's next.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

This skill covers how to build a minimum viable product once you know what you need to learn. Eric Ries defines an MVP as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort" (Ries, Minimum Viable Product guide). The definition sets two limits at once. The product has to be small enough to build quickly, and it has to be real enough that customer behavior around it counts as evidence. Building an MVP for startups and for new products inside larger companies comes down to holding both limits.

Ries is explicit that the MVP is "not about creating minimal products." A minimal product is a small version of the final plan. An MVP is an instrument for one question, and it may look nothing like the final product. The Lean Startup method explains where the MVP sits in the Build-Measure-Learn loop. This page is about the build itself: scoping, choosing the build approach, instrumenting, launching and reading the result.

The skill produces two things. The first is the product, however rough, that a defined group of customers can use to complete one core task. The second is a measurement plan that names the metric, the audience and the pass mark before launch. Without the plan, the team has a demo that anyone can read however they like. Without the product, the team has a specification that tells it nothing about behavior.

Most MVPs fail at scoping. Teams add features to avoid embarrassment, and each feature adds build time and adds noise to the result. Ries describes his own experience at IMVU, where the first MVP took six months to reach the market, and says of a later feature that took two weeks to build that "two weeks was way too long" (MVP guide). The standard is set by the question. If a smaller artifact can answer it, the larger one is waste.

If you have not yet picked a format, such as a concierge service, a landing page or a single working feature, start with choosing among the types of MVP. That skill decides what kind of thing to build. This one covers how to build it well.

How It Works

The MVP development process starts from the riskiest assumption and works backward. Ries plans the loop in reverse: decide what you need to learn, then what to measure, then what to build (Ries on planning in reverse). Applied to building, that means the feature list is derived from the measurement. Anything the measurement does not need is out of scope.

Scope is set by the core flow. The core flow is the shortest path from the moment a customer arrives to the moment the assumption is tested. For a willingness-to-pay assumption, that path ends at a payment or a firm commitment. For an engagement assumption, it ends when the customer comes back without being prompted. Each screen or interaction on that path is in scope. Each one off it waits.

Manual work is allowed and often preferred. Many MVPs deliver the promised result by hand behind a simple interface, which lets the team test demand before building the automation. In the Food on the Table case, the team wrote code only for tasks that had become too time consuming to do by hand (Food on the Table case study). Building by hand also shows the team exactly what customers ask for, which improves the eventual product.

Instrumentation is part of the build. Decide which events you will record, such as arrival, the first step of the core flow and completion, and check that they fire before launch. Pair the numbers with a qualitative channel, such as a short follow-up call, because numbers show what people did and conversations show why. Ries's advice to trace metrics back to individual customers applies here (Vanity Metrics vs. Actionable Metrics).

Quality has a floor. Early adopters forgive missing features, but they do not forgive a core flow that breaks. The MVP article on Wikipedia notes criticism that negative feedback on a poor MVP can hurt a company's reputation. Make the core flow reliable, and cut everything around it.

The result is read against the pass mark written before launch. A clear pass moves the team to the next riskiest assumption. A clear miss sends the team to decide whether to iterate or pivot. An unclear result usually means the MVP tested two things at once or the audience was wrong, and both are fixable in the next build.

Step-by-Step Guide

Step 1: Name the one assumption this MVP tests

Take the ranked list of leap-of-faith assumptions and pick the one that is most important and least proven. Write it as a hypothesis with a metric and a pass mark, using the lean startup hypothesis template if you have one. If two assumptions compete, test one now and the other next. An MVP that tests two assumptions produces results you cannot attribute to either.

Step 2: Map the core flow

Draw the shortest path from arrival to the moment the assumption is tested, one box per screen or interaction. Remove every box that does not serve the test. Mark which boxes can be done by hand behind the scenes. The drawing becomes the build scope, and it should fit on one page.

Step 3: Freeze the feature boundary

List the features the flow needs and label everything else as later. Get the people who will build and sponsor the MVP to agree to the list in writing. When someone proposes an addition mid-build, ask whether it changes the team's ability to test the assumption. If it does not, it goes on the later list.

Step 4: Pick the cheapest build approach

Choose among hand-delivered service, existing tools stitched together, no-code builders and custom code, in that rough order of cost. The CRV guide describes piecemeal MVPs as combining existing tools to deliver an offering without building new technology (CRV, What is an MVP?). Write code only where no cheaper option can deliver the core flow. Set a firm timebox for the build and treat running over it as a scoping problem.

Step 5: Instrument before launch

Define the events that measure the pass mark and confirm each one records correctly with a test account. Add one qualitative channel, such as a follow-up call or a single open question after the core task. Decide in advance how you will count each customer, so the numbers can be traced back to individuals. A launch without working instrumentation wastes the whole cycle.

Step 6: Launch to a defined audience

Recruit people who match the target segment, ideally early adopters who feel the problem strongly. Keep the audience defined, because a mix of segments blurs the result. Watch the first sessions closely and fix anything that blocks the core flow. Do not change the flow itself mid-test, or the early and late results will not be comparable.

Step 7: Compare the result with the pass mark

When the test window closes, put the result next to the pass mark written in step 1 and state plainly whether it passed. Read the qualitative notes to understand why. Resist moving the pass mark after the fact. If the result falls in between, say so and decide what additional evidence would settle it.

Step 8: Decide and record the next step

Choose one of three outcomes: move to the next riskiest assumption, iterate on this MVP to fix a specific problem, or take the result to a pivot or persevere decision. Record the assumption, the MVP, the result and the decision in one place. That record is the validated learning the MVP was built to produce.

Best Practices

• Write the measurement plan before the build plan. The plan tells you what to build, and writing it first stops the team from building and then searching the data for a success.
• Keep the core flow reliable and everything else rough. Early adopters tolerate missing features, but a broken core task gives you no data about the assumption.
• Do things by hand until the manual work becomes the bottleneck. Manual delivery is cheaper to change than code and teaches you what to automate.
• Talk to a sample of users after they try it. Ries's advice to treat "metrics are people, too" means checking numbers against real accounts (Vanity Metrics vs. Actionable Metrics).
• Timebox the build and cut scope to fit. When the timebox is at risk, remove features rather than extending the date.
• Keep a later list. Writing down deferred ideas makes it easier for the team to let them go for now.

Common Mistakes

• Building the first release instead of an experiment: The team ships a small version of the roadmap and cannot tell which assumption the result speaks to. Start from one assumption and derive the scope from it.
• Launching without a pass mark: Any result can be read as encouraging when nothing was agreed in advance. Write the metric and the threshold before launch and share them.
• Testing on the wrong audience: Friends, colleagues and general sign-up lists behave differently from the target segment. Recruit people who have the problem and screen them.
• Polishing the edges: Time spent on settings pages, branding and edge cases delays the answer. Spend it on the core flow only.
• Adding scope during the test: Changing the product mid-test splits the data into two incomparable halves. Log requests and apply them in the next cycle.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Lean Startup

Related Skills

• Types of MVP: How to Choose the Right Format
• Lean Startup Hypothesis Template: Testable Hypotheses
• Designing Validated Learning Experiments
• Running the Build-Measure-Learn Loop
• Innovation Accounting Metrics: Tracking Real Progress
• Pivot or Persevere: When to Pivot a Startup
• Customer Discovery Interview Questions and Technique

Sources

• Eric Ries: Minimum Viable Product, a guide
• Eric Ries quote on planning the loop in reverse
• Manuel Rosso: Food on the Table case study
• Eric Ries: Vanity Metrics vs. Actionable Metrics
• CRV: What is an MVP?
• Wikipedia: Minimum viable product

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.