How to scope an mvp without cutting its value

I scope an mvp by choosing one user, one costly problem and one complete outcome, then fitting the smallest credible solution inside a fixed time budget. I cut secondary workflows and automate less, while keeping the reliability, safeguards and measurement needed to test whether the product is worth using.

Define the user outcome before listing features

I start with a sentence that describes a change in someone's working day. For a hypothetical invoice-chasing product, that might be: an independent consultant can identify an overdue invoice and send the right reminder without rebuilding the context from email. That is narrower than “manage invoices”, but it still describes something worth paying for.

I then name the starting conditions. The consultant already has an invoice, knows the customer and has permission to contact them. Creating invoices, finding customers and collecting payment are separate jobs. Excluding them is a scope decision, not an admission that the product is incomplete. I also name the initial audience: consultants handling a few overdue invoices, not finance teams managing thousands.

My test is simple: can I describe what the person finishes, rather than what the software contains? “A dashboard, reminders and reporting” fails that test. “Send a checked reminder and know whether it went out” passes. I keep that outcome visible during design reviews because attractive adjacent features arrive quickly.

Set a time budget before estimating the solution

Basecamp's Shape Up separates appetite from estimation. Appetite is the amount of time a problem deserves; an estimate predicts how long a proposed solution might take. I use that distinction before drawing screens. Otherwise, the first plausible design becomes the assumed scope, and every conversation turns into defending its delivery date.

For the invoice example, I might allow four weeks for one designer and two engineers. That is a planning constraint, not a promise that any version will fit. I make the available capacity explicit, including support duties and review time. Four calendar weeks with frequent interruptions is not the same budget as four protected weeks.

I then look for a version that fits. Perhaps it accepts manually entered invoice details rather than connecting to accounting software. If no worthwhile version fits, I change the budget or decline the work. I don't preserve the date by quietly removing testing, accessibility checks or recovery from common failures. Those omissions create work after release rather than removing it.

Test the riskiest assumption before building

Marty Cagan's four product risks give me a useful sorting method: value, usability, feasibility and business viability. I translate them into questions about this particular product. Will consultants trust it with customer communication? Can they check a reminder accurately? Can the delivery service support the promise? Can the service operate at an acceptable cost?

I test the assumption most likely to kill the idea before investing in the rest. If trust is uncertain, a realistic reminder preview and a conversation about an actual overdue invoice may teach me more than a working email integration. If delivery constraints are uncertain, I want an engineering investigation rather than another polished prototype.

I keep the evidence categories separate. Completing a prototype task suggests someone can use the design; it doesn't prove they will return or pay. Positive interview comments don't establish demand. I write down what each test can settle, what remains uncertain and which uncertainty the first release must expose through real use.

Map the smallest complete workflow

I map the path from the user's starting point to a confirmed result, including the points where mistakes matter. For the reminder product, that means entering invoice details, checking the recipient and amount, reviewing the message, sending it and seeing its status. Each step earns its place by supporting the promised outcome, not by resembling an established competitor.

The happy path isn't enough. A consultant may mistype an address, click send twice or lose connection after submitting. I decide which failures need prevention, which need recovery and which need an honest explanation. Preventing duplicate messages may matter more than adding saved templates. A clear failure state may matter more than a tidy activity chart.

I use this map to spot false cuts. Removing the preview saves a screen but weakens confidence before an irreversible action. Removing delivery status leaves the user guessing whether the job finished. By contrast, removing custom branding may leave the whole outcome intact. I judge the cut by its effect on the task, not its screen count.

Cut workflow variations before cutting quality

My first cuts usually target the number of situations the product supports. One customer type, one input method and one delivery channel are easier to reason about than a thin implementation of five. Narrow eligibility is useful only when it is explicit. I would rather reject an unsupported invoice format clearly than accept it and produce unreliable results.

For the worked example, I might postpone recurring schedules, bulk sending, accounting integrations, team permissions and custom templates. These are distinct expansions, not missing steps in the single-reminder workflow. I would keep accurate amounts, recipient checking and truthful send status. The distinction is between serving fewer cases properly and serving every case poorly.

I also consider manual operations behind the product. A pilot can use manual account setup or assisted data import if users know what to expect. I record the labour per account and the limits on capacity. I don't make sensitive handling casual, or present a person-dependent service as instant automation. Manual work buys learning time; it doesn't make operating costs disappear.

Measure completion, repeat use and operating cost

I define the release decision before choosing analytics events. For a hypothetical pilot of 12 consultants, I might require nine to send a valid reminder without assistance, with no duplicate sends. That is an example decision rule, not an industry benchmark. A small pilot can reveal failures and patterns, but it cannot establish a dependable market conversion rate.

I measure the path rather than registrations alone: who had an eligible invoice, who started, who checked the message and who completed the send. I separate people who had nothing overdue from people who abandoned the task. Otherwise, a low usage figure mixes absent need with a product problem and gives me little direction.

I track support time and return use when the next relevant need occurs. Daily activity makes little sense for someone chasing invoices monthly. I also inspect abandonment reasons and failed sends, not just averages. Before the pilot, I specify what would make me expand access, revise the workflow or stop. I don't want enthusiasm after launch to move those thresholds.

Write a scope agreement before delivery starts

I put the outcome, audience, appetite, supported workflow, exclusions and release criteria into one short document. I include the unresolved questions and the person responsible for each decision. Shape Up's approach to shaping work is useful here: the proposal needs enough definition to expose difficult parts without prescribing every implementation detail before the team investigates them.

I make exclusions concrete. “No advanced features” invites arguments. “One sender per account; no scheduled or bulk reminders” gives design and engineering an actual boundary. I describe acceptance in observable terms too: a repeated submission must not produce two messages, and an unsuccessful send must not appear successful. These checks protect the promise better than a percentage-complete report.

During delivery, I judge new requests against that agreement. A newly discovered failure that prevents a correct reminder belongs in the scope discussion. A request for a second accounting integration usually doesn't. If essential work exceeds the appetite, I remove a supported variation, renegotiate the budget or stop. I keep those choices explicit rather than letting unfinished work become an unplanned launch condition.

Questions people ask

How many features should an mvp have?

I don't use a feature count. I include what one defined user needs to complete one valuable task, including essential safeguards. Three features can still be too broad if each supports several different workflows.

How long should it take to build an mvp?

I set a time budget based on the decision the release needs to support, then shape the solution to fit. There is no universal duration. External dependencies and regulated workflows can make a small product expensive to deliver.

What is the difference between a prototype and an mvp?

I use a prototype to test specific assumptions without providing the full service. An mvp must deliver a real outcome under stated conditions. A convincing simulation can test comprehension, but it cannot establish operational reliability.

What should I cut from an mvp first?

I cut secondary audiences, integrations, customisation and workflow variations first. I consider manual operations next, with explicit capacity limits. I don't cut protections against costly mistakes simply because they add no visible feature.

Where I checked my thinking

• Basecamp Shape Up
• Marty Cagan: The Four Big Risks