How to Build a Minimum Viable Product: Scope, Tests and Examples

Write a decision sentence: after this release, we need to know whether a particular user can achieve a particular outcome through this process. For example, a hypothetical bookkeeping tool might test whether freelance designers can categorize a month of transactions with fewer unresolved items. The first release does not also need to manage payroll, tax filing and invoicing.

Y Combinator’s MVP lesson by Michael Seibel emphasizes talking to users, launching a limited initial product and learning from feedback. Treat that as a direction for reducing unnecessary delay, not a reason to release a product that cannot safely perform its promised task. Watch YC’s MVP planning lesson. List the decisions the first release will deliberately leave unanswered.

A clickable prototype can test comprehension and navigation, but it cannot establish reliable delivery of a service it only simulates. A manually supported pilot can test a workflow, but it does not prove the automation will work. A narrow working application can test actual task completion, provided the experience and limitations are explained clearly.

The distinction between understanding customer needs, testing a solution and examining willingness to pay also appears in Strategyzer’s testing roadmap. Choose the format that addresses your current uncertainty. If you still do not understand the user’s existing workflow, return to customer discovery before committing to a larger implementation.

Map the journey from a user’s starting situation to the promised result. Identify what must happen at each step, including onboarding, error recovery and support. Then challenge every proposed feature: if we remove it, can the participant still complete the core task and can we still interpret the result? If yes, it is a candidate for a later release.

Keep necessary protection and basic accessibility inside the scope. Reducing features does not justify exposing sensitive information or leaving users unable to recover from a failure. For an early pilot, synthetic or carefully minimized data may be sufficient. Explain any manual processing and agree how participant information will be handled before the test begins.

Consider a tool helping small creative agencies collect client approvals. The core hypothesis is that one shared approval link will reduce ambiguity about which version a client approved. The smallest working path might allow a team member to upload one asset, send a link and record an explicit approval or change request. A full project-management suite would obscure that test.

In this hypothetical plan, the team begins with a small invited pilot and records the starting workflow. It observes whether clients complete the review without explanation, where they hesitate, and whether the agency still needs a separate confirmation email. If the email remains necessary, the team investigates why before expanding the feature list.

Hold a release review with the original learning question in front of you. Compare what participants attempted with what they completed. Separate usability problems from lack of interest: a broken link and an unwanted workflow demand different responses. Record the amount of founder assistance required, because a successful guided session may conceal a difficult self-service experience.

Decide whether to fix the core path, test another segment, repeat the pilot or add a specific capability. Avoid declaring product-market fit from a small successful trial. Maintain a short learning log and preserve failed assumptions. NextUnicorn’s Idea2Unicorn page describes MVP-planning support for early ideas and prototypes; review that offer if you need help turning evidence into a focused build plan.

Review Idea2Unicorn’s support for shaping an early concept into an MVP plan.