How to Build an MVP

MVP as a Learning Tool, Not a Feature List

A minimum viable product is not a product with minimum features — it is the minimum investment required to test one specific hypothesis about your business. The distinction matters because most founding teams approach an MVP as a scope reduction exercise ("what features can we cut?") rather than a learning design exercise ("what is the one thing we need to prove before building anything?"). The wrong framing produces a smaller product that still takes three months to build; the right framing sometimes produces a landing page, a manual process, or a video that tests the hypothesis in three days.

Every MVP should be built backward from a falsifiable hypothesis: "We believe that [target user] will [take this action] because [this motivation]." The MVP's only job is to either confirm or refute that belief with enough evidence to justify the next investment decision. Evidence that refutes the hypothesis is not failure — it is the learning the MVP was designed to produce, and it saves the team from spending six months building a product for a motivation that does not exist. An MVP that takes 90 days to build and produces ambiguous results has failed regardless of the product quality.

Dropbox and Zappos: Validation Without a Working Product

Drew Houston launched Dropbox with a three-minute screen recording demonstrating the product experience before a single line of production code existed. The video explained the problem, showed the synchronisation behaviour, and ended with a waitlist signup. The waitlist grew from 5,000 to 75,000 names overnight. This validated not just that people wanted the product, but that the specific framing of the value proposition — seamless file sync across devices — resonated strongly enough to motivate an immediate signup action. No engineering work was required to generate this signal.

Zappos founder Nick Swick-Hsieh tested online shoe retail by photographing inventory from local stores, listing the photos on a basic website, and fulfilling orders by purchasing the shoes from the store at retail price and shipping them manually when orders arrived. No inventory, no warehouse, no logistics software — just a test of whether people would buy shoes online without trying them on. The operational losses on each order (buying retail, selling at comparable price) were the cost of testing a hypothesis that, once validated, justified the investment in real inventory and fulfillment infrastructure. Both examples demonstrate that the most expensive part of MVP validation is building a real product, and that real products are usually not required to validate demand.

Finding the Core Loop

The core loop is the sequence of actions where a user first experiences the product's central value — the moment the product delivers on its promise. For a project management tool, it might be the moment a task is assigned, completed, and marked done by the assignee. For a financial modeling tool, it is the moment the user changes one assumption and sees the downstream effect cascade through the model. Users who do not reach the core loop in their first session are overwhelmingly likely to churn: research across multiple SaaS products finds that users who fail to reach the core value moment in session one have 80 percent churn by week two.

Identifying the core loop requires mapping the full new-user journey from signup to first-value moment and measuring drop-off at each step. The step with the highest drop-off before the core loop is the primary onboarding problem to solve. An onboarding flow that takes 15 steps before the user experiences core value will lose the majority of new users before they understand why the product is worth their time. The right MVP size is the minimum feature set that allows a user to reach the core loop in a single session — everything else, including reporting dashboards, team management settings, and API access, is a feature added after that loop is proven to create retention.

RICE Score for Feature Prioritisation

RICE scoring assigns a numerical priority to each potential feature using four variables: Reach (how many users will this affect in a given period), Impact (how much will it move the target metric, scored 0.25 to 3), Confidence (what percentage certainty do you have in the Reach and Impact estimates), and Effort (in person-weeks to ship). The formula is (Reach × Impact × Confidence) ÷ Effort. A feature affecting 1,000 users per month with 3.0 impact, 80 percent confidence, and 2 person-weeks of effort scores 1,200 — which can be directly compared to every other item in the backlog.

The features that belong in an MVP are those that score highest on RICE and directly enable the core loop. Features excluded from the MVP typically include the admin panel, advanced reporting, multi-language support, public API access, and settings pages — all of which affect a small percentage of users, have low impact on core loop completion, and consume significant engineering effort. A useful MVP scope check: for each proposed feature, ask whether removing it would prevent a user from experiencing the core value once. If the answer is no, the feature does not belong in the MVP, regardless of how useful it will be in version two.

Frequently Asked Questions

What is the difference between an MVP and a prototype? A prototype tests a design hypothesis; an MVP tests a business hypothesis. A prototype may be a mockup or demo for user feedback. An MVP delivers real value to real users and measures whether they take the specific action that validates the business model.

How did Dropbox validate its product without building it? Drew Houston made a three-minute screen recording of the product experience. The waitlist grew from 5,000 to 75,000 overnight. This validated demand and product framing without any production code, using the video as the MVP rather than the product itself.

What is the core loop and why does it determine MVP scope? The core loop is the sequence where a user first experiences the product's central value. Users who do not reach the core loop in session one have 80 percent churn by week two. The MVP should contain exactly the features required for a user to reach the core loop in a single session.

How is RICE score calculated? RICE = (Reach × Impact × Confidence) ÷ Effort. Reach is monthly users affected, Impact is scored 0.25 to 3, Confidence is expressed as a percentage (80% = 0.8), and Effort is in person-weeks. A score of 1,200 can be directly compared to all other backlog items.

What features should be excluded from an MVP? Admin panels, advanced reporting, multi-language support, public API access, and settings pages. These affect a small percentage of users, have low impact on core loop completion, and consume significant engineering effort that delays the moment the hypothesis is tested.