Build the Smallest Product Customers Can Use

Task

Prioritize MVP features tied to the repeated customer outcome.

Summary

Prioritize only the capabilities needed to produce a useful customer result.

Build the Smallest Product That Delivers the Customer Result

Task ID: S3-02

An effective minimum viable product is not simply the shortest feature list the team can ship. It is the smallest dependable product that lets a defined customer complete an important job, achieve a recognizable result, and provide evidence about willingness to use and pay. This article explains how to connect every included feature to that result and turn the decisions into an MVP scope and testable product requirements.

A company has completed the same kind of customer work several times. The delivery team knows the recurring steps. Sales knows which parts customers ask about in demonstrations. Engineering can imagine dozens of ways to automate, integrate, and improve the process.

This is where the first standalone product can become either too broad or too thin.

If every customer request, internal preference, edge case, and future ambition enters the first release, the company may recreate a custom service project in software. Development takes longer, onboarding remains complicated, and the product accumulates features before the team knows whether customers will use its core workflow.

If the team cuts indiscriminately, the product may be small but not useful. Customers can start a task but cannot finish it, obtain the result, share it, or trust it enough to use in real work.

The practical task is to find the smallest end-to-end path to a repeated customer outcome. The resulting MVP scope should show why each included capability is necessary, what evidence supports it, how it will be tested, and what the company has intentionally deferred.

The operating principle

Every feature in the MVP should support at least one of three things:

1. The customer’s primary result.
2. The customer’s first meaningful success on the way to that result.
3. A necessary condition for adoption, trust, delivery, or safe operation.

A feature that does none of these does not belong in the MVP.

The distinction between a feature and an outcome matters. “Upload a file,” “send an alert,” and “export a report” are features. “Identify the exceptions that require attention before tomorrow’s deadline” is an outcome. Customers may ask for particular features because those are the solutions they can imagine, but the product team must determine which combination of capabilities actually produces the desired result.

A useful outcome statement identifies the customer, the situation, the result, and the evidence of success:

When [target customer] faces [recurring situation or trigger], the product helps them [complete an important job] so that they achieve [observable result], measured by [time, quality, cost, risk, revenue, or another relevant indicator].

“First meaningful success” is the earliest point at which the customer receives enough real value to believe the product can solve the problem. It is not account creation, completion of a product tour, or the first button click unless one of those actions itself produces value.

For an exception-reporting product, first meaningful success might occur when the user uploads real operating data and receives a correctly classified list of issues. The full outcome might be reached when the user reviews, resolves, and shares an approved report. The MVP normally needs the complete path to the promised result, but each step should be tested to find where adoption stalls.

Recent academic work describes an MVP as an artifact that is concrete enough for external testing but not yet a fully optimized commercial system. Depending on the uncertainty being tested, that artifact could be a demonstration, prototype, simulated service, landing page, or working product. The important question is not whether the artifact contains software; it is whether it is realistic enough to test the relevant assumption.

For this task, a demonstration alone may test whether buyers understand and want the proposed result. A working product is eventually required to test whether customers can complete the workflow, receive value, and operate without extensive custom support. Teams should therefore distinguish a demand test, a usability test, an outcome test, and a commercial test rather than asking one early MVP to answer every question at once.

Why feature prioritization changes at this stage

The company is no longer deciding whether a broad problem exists. It has already seen useful work repeated in customer engagements. The question is whether one part of that work can become a product customers buy and use without the company reconstructing a custom project around every account.

Although no formal dependency is specified for this task, sound feature prioritization still depends on evidence about the customer, the recurring problem, the workflow, and the expected result. “No dependency” means the task need not wait for another formal deliverable; it does not mean the team should invent the MVP from an empty backlog.

The most useful inputs normally include completed project records, sales conversations, customer interviews, support requests, delivery time records, workarounds, errors, exceptions, and examples of the final result customers accepted. The team should look for repetition across customers rather than treating one large or vocal account as the market.

This protects the product from two common errors.

The first is feature accumulation. A feature can sound attractive during a sales conversation without improving the customer’s experience after purchase. Research on “feature fatigue” found that people can give greater weight to capability before using a product and greater weight to usability after using it. As a result, adding features may improve initial appeal while producing a product that is more difficult and less satisfying to use.

The second is customer-specific automation. A design partner may provide excellent access to a real workflow, but the requested solution can contain organization-specific approvals, terminology, data structures, and exceptions. Encoding all of them into the core product can preserve the economics and complexity of custom service work.

Research on lead users supports involving customers who experience strong needs earlier than the wider market; such users can offer unusually useful information about emerging needs and possible solutions. However, newer research also finds that long-standing customer relationships can pull product development toward familiar, incremental requirements. That makes design-partner selection and cross-customer validation important.

The usual advice to “listen to customers” therefore needs qualification. Listen closely to their problem, context, constraints, workarounds, buying trigger, and definition of success. Treat their preferred feature set as evidence to examine, not instructions to copy.

What the evidence says about minimum scope

There is no universal formula for the right number of MVP features. The 2024 review of MVP theory notes that the concept is widely used but has had relatively little foundational scholarly development. The appropriate MVP form and scope depend on what the company needs to learn, how realistic the test must be, and the risks created by releasing an incomplete product.

Several established findings do, however, support a disciplined approach.

Begin with the user’s full job, not the product’s component list. The United Kingdom Government Digital Service requires teams to understand the user’s wider context and the problem being solved, not merely the moment when the user interacts with a particular system. Its service standard also warns against both fragments that fail to solve the user’s problem and oversized services that try to solve everything at once.

For a commercial product, “solve the whole problem” does not mean automating every surrounding business process. It means selecting a clear boundary within which the customer can achieve the promised result. A product that generates an analysis but provides no practical way to review or use it may be incomplete. A product that also tries to manage every upstream data source, approval process, and downstream system may be unnecessarily broad.

Compare value and cost explicitly. Requirements-prioritization research has long recommended evaluating candidate requirements according to both stakeholder value and implementation cost rather than ranking them by enthusiasm alone. Karlsson and Ryan’s cost-value approach used structured comparisons to show that a relatively small group of requirements could account for a large portion of perceived value in an industrial setting.

Cost-value analysis does not eliminate judgment. Development effort can be uncertain, stakeholders may value different outcomes, and requirements can depend on one another. Its value is that it forces the team to discuss those differences instead of hiding them inside a single backlog order.

Define value before defining the roadmap. Amazon Web Services’ published product-development guidance recommends establishing the product vision, customer journey, intended business outcomes, and success measures before prioritizing features. Its Working Backwards approach uses a proposed press release and frequently asked questions to clarify customer value and scope before converting the idea into epics or user stories.

State exclusions as clearly as inclusions. Basecamp’s published Shape Up method treats a time budget, identified risks, and explicit “no-gos” as essential parts of a product proposal. The exclusions prevent reasonable-looking adjacent use cases from silently expanding the project.

These approaches share a principle: product scope is a decision about the result the team will deliver and the uncertainty it will test. It is not the sum of all plausible features that fit within a development estimate.

How to build the feature-to-outcome map

A feature-to-outcome map provides traceability from the customer result to each capability in the MVP. It should be simple enough for product, engineering, sales, onboarding, and support teams to challenge together.

flowchart LR
    A[Repeated customer problem] --> B[Defined customer outcome]
    B --> C[Steps required to reach the outcome]
    C --> D[Candidate capabilities]
    D --> E{Supports outcome or necessary condition?}
    E -->|No| F[Exclude or defer]
    E -->|Yes| G{Required for first meaningful success?}
    G -->|Yes| H[Core MVP scope]
    G -->|No| I[Optional or specialized]
    H --> J[Test with real customer workflow]
    J --> K{Outcome achieved with acceptable effort?}
    K -->|No| L[Revise scope or product]
    K -->|Yes| M[Proceed to commercial validation]

Text description: begin with the repeated problem and customer outcome, break the outcome into workflow steps, map candidate capabilities to those steps, exclude unmapped work, and validate the core end-to-end path before expanding the product.

The mapping process should proceed in the following order.

Fix the customer and outcome. Choose the initial customer segment, user, buying situation, and result. A generic outcome such as “improve productivity” is too broad to prioritize against. “Enable a regional operations manager to produce an approved weekly exception report from standard source data in less than one hour” is specific enough to test.

Map the customer’s current job. Record the steps the customer completes today, including manual work, decisions, handoffs, delays, errors, and the final proof that the work is complete. The purpose is not to reproduce every step. It is to understand which steps create the outcome and which exist only because the current process is inefficient.

Inventory candidate capabilities. Include ideas from customer interviews, existing service delivery, sales requests, technical requirements, competitive research, and known operational risks. Do not prioritize during collection; premature ranking can cause the team to overlook important dependencies.

Apply an outcome gate before a scoring model. A capability should pass at least one of these tests:

• The customer’s primary job fails without it.
• The customer cannot reach first meaningful success without it.
• Adoption is likely to stall without it.
• It is required for security, privacy, accessibility, reliability, contractual compliance, or another material risk.
• It is necessary for the company to onboard, support, measure, or charge for the product without unreasonable manual work.

Capabilities that support no validated customer job or necessary operating condition should be removed from the MVP, regardless of how inexpensive they appear. Capabilities needed only by a narrow context should be marked specialized rather than quietly treated as universal. This core, optional, and specialized classification is reflected in the working capability-mapping structure for the product requirements.

Compare the survivors. A simple priority score can support discussion:

The values can use a small ordinal scale, such as one to five. The result is not a financial calculation and should not decide the roadmap automatically. Its purpose is to expose disagreements. A high-impact capability supported only by one interview should not be treated as equivalent to one observed repeatedly in delivery records.

A practical map might look like this:

Select a thin end-to-end slice. The MVP should normally include enough capability to carry one defined customer through the whole core workflow. Building all import options before any output exists is a horizontal technical slice. Supporting one common input, one validated processing path, and one useful output is a vertical customer-value slice.

This does not require low technical quality. Security, data integrity, recovery, and reliability may be essential to the outcome even when customers do not describe them as features. The product team should map such requirements to the condition they enable: permission to adopt, confidence in the result, safe operation, or manageable support.

Turn the map into MVP requirements

The feature-to-outcome map explains why each capability belongs. Product requirements explain what must be true for that capability to be considered complete.

A credible MVP requirements document should contain the following information:

Product scope The product, target customer, buying situation, repeated problem, and promised result.

Outcome measure The baseline, expected improvement, calculation method, measurement window, and data source.

Primary scenario The end-to-end sequence through which the customer reaches first value and the final result.

In-scope capabilities Each capability, the customer job it supports, its evidence, and its classification.

Necessary operating requirements Security, privacy, reliability, accessibility, performance, data retention, interoperability, and support requirements that affect adoption or safe operation.

Acceptance criteria Observable conditions that determine whether each requirement works with representative customer data and scenarios.

Instrumentation The events and outcome data needed to measure use, completion, errors, support effort, and customer results.

Exclusions Use cases, segments, integrations, configuration options, and edge cases intentionally outside the MVP.

Assumptions and unresolved risks What is believed but not yet demonstrated, the evidence needed, the owner, and the review date.

Validation and release plan Design partners, test sequence, support model, rollout boundaries, and the conditions for proceeding, revising, or stopping.

Requirements should be written so a customer-facing employee, developer, and tester can reach the same interpretation.

A vague requirement says:

The system should quickly generate useful exception reports.

A testable hypothetical requirement says:

When an authorized operations manager uploads a file that follows the published input format, the system must identify missing required fields, apply the approved exception rules, present the resulting exceptions for review, and generate a shareable report. Completion time, classification corrections, failures, and support interventions must be recorded.

The second version still needs numeric acceptance thresholds before implementation, but it identifies the actor, trigger, behavior, output, and measurement requirements.

The requirements document should also separate facts from assumptions. An observed step in five completed customer workflows is evidence. A design partner’s prediction that every buyer will need a particular integration is a hypothesis. Both can influence the MVP, but they should not receive the same confidence label.

Useful evidence labels include:

• Observed: seen in actual customer behavior, delivery records, or product use.
• Committed: supported by a purchase, paid pilot, contract condition, or clear resource commitment.
• Stated: reported in an interview, survey, or sales conversation.
• Inferred: derived from related evidence but not directly tested.
• Assumed: included provisionally because testing has not yet occurred.

This prevents an attractive but weakly supported request from appearing as certain simply because it has been converted into a formal requirement.

Validate the scope with design partners

In a demo-led direct-sales motion, the best early demonstration follows the customer’s job rather than the product’s menu structure.

Begin with the triggering situation. Use representative data. Show the customer completing the core workflow. End with the result they would use in their job. A feature tour can produce compliments while leaving the central assumption untested.

Each design-partner session should answer a defined question, such as:

• Can the user begin without the delivery team restructuring their data?
• Can the user recognize and correct an inaccurate result?
• Can the user finish the job without a founder or specialist taking over?
• Does the output meet the decision, reporting, or compliance need that triggered the purchase?
• Will the buyer commit money, time, data, access, or internal sponsorship to continue?

Observed behavior is generally stronger evidence than stated preference. A customer who says a feature is valuable but does not use it provides weaker evidence than one who completes the workflow repeatedly. A paid pilot or purchasing commitment adds commercial evidence, but payment alone does not prove that onboarding and ongoing use will be repeatable.

Design partners should represent the intended initial market, but they should not all be identical. Variation in organization size, data quality, workflow maturity, and user skill can reveal whether the proposed core is genuinely reusable. At the same time, the team should resist expanding the MVP to satisfy every variation. The purpose is to discover the stable core and identify which differences belong in configuration, specialized packages, later releases, or exclusions.

Public product-development practices offer two useful models. Amazon’s Working Backwards materials formalize the customer, problem, proposed experience, scope, and business result before feature planning. The UK Government Digital Service assesses whether a team has tested enough of the wider journey to show that users can successfully complete it, rather than accepting a limited component test as proof of a complete service.

After each customer test, update four records:

1. What happened.
2. What the result means.
3. Which assumption changed.
4. Which scope or requirement decision follows.

Do not change the roadmap merely because a customer mentioned an idea. Change it when the evidence changes the team’s understanding of the repeated outcome, the core workflow, the buying decision, or the cost of delivering and supporting the product.

Evidence, measures, and the decision to proceed

The expected evidence at completion is not merely a prioritized backlog. It is an MVP scope and a set of product requirements that show how the product will produce, measure, and validate the repeated customer outcome.

The primary working measure is feature-to-outcome mapping coverage:

A working target of 100% is sensible as a scope-control rule. Every included capability should have an explicit reason to exist. The mapping can point either to the customer result or to a necessary adoption, risk, measurement, or operating condition.

This target is not an industry benchmark and does not mean:

• every possible customer need has been covered;
• every mapping is supported by equally strong evidence;
• the product will achieve product-market fit;
• the outcome has already been demonstrated;
• the scope will never change.

An MVP can reach 100% mapping coverage while still being based on weak assumptions. For that reason, the map should include evidence strength and validation status rather than a simple yes-or-no link.

The wider scorecard should distinguish product activity from customer and commercial results:

Government Digital Service guidance similarly recommends choosing metrics that indicate how well a service solves its intended problem and using performance data to decide what to improve. AWS guidance recommends connecting success measures directly to the intended business outcome and designing the measurement mechanism early enough that it can be built into the product.

The team is ready to depend on the MVP scope when the following evidence exists:

• The initial customer and repeated outcome are specific.
• The end-to-end core workflow is understood.
• Every included feature has an outcome or enabling-condition mapping.
• Core, optional, specialized, and excluded capabilities are clearly separated.
• The requirements are testable with representative customer scenarios and data.
• The product records the measures needed to assess first value, completion, and outcomes.
• Design partners can complete the core job with support effort consistent with the intended business model.
• The buyer’s willingness to pay or commit has been tested.
• Material security, reliability, privacy, contractual, and operational risks have owners and acceptance criteria.
• The next decision rules are documented before results are collected.

Proceed when target customers can achieve the intended result, the buyer recognizes enough value to continue commercially, and onboarding and support do not require the company to rebuild the original service engagement.

Revise the MVP when the problem remains important but customers cannot complete the workflow, the output is not trusted, the first-value point occurs too late, or support effort is materially higher than the intended model allows.

Stop or change direction when the supposedly repeated result is not consistent across the target market, customers will not commit to the product, or the core capability cannot be delivered safely and economically within the company’s constraints.

The completed work should make one decision substantially clearer: whether the company has defined a small, dependable product that delivers a real customer result—or has merely written a shorter list of features.

Sources

Primary and official sources

• Amazon Web Services, “Start with why,” including customer journeys and the Working Backwards press release and frequently asked questions.
• Amazon Web Services, “Define success metrics.”
• Government Digital Service, “Understand users and their needs.”
• Government Digital Service, “Solve a whole problem for users.”
• Government Digital Service, “Define what success looks like and publish performance data.”
• Government Digital Service, “Carry out a due diligence check alpha assessment.”
• Basecamp, Shape Up: “Write the Pitch,” “Set Boundaries,” and “Risks and Rabbit Holes.”
• Agile Manifesto authors, “Principles behind the Agile Manifesto.”

Open research

• Stevenson, Regan, Devin Burnell, and Greg Fisher, “The Minimum Viable Product: Theory and Practice,” Academy of Management Review, 2024.
• Karlsson, Joachim, and Kevin Ryan, “A Cost-Value Approach for Prioritizing Requirements,” IEEE Software, 1997.
• Thompson, Debora Viana, Rebecca W. Hamilton, and Roland T. Rust, “Feature Fatigue: When Product Capabilities Become Too Much of a Good Thing,” Journal of Marketing Research, 2005.
• von Hippel, Eric, “Lead Users: A Source of Novel Product Concepts,” Management Science, 1986.
• de Jong, Jeroen P. J., and colleagues, “Industrial Product Development with Lead Users as a Source of Schumpeterian Opportunity,” Journal of Product Innovation Management, 2024.