MVP, Prototype or Pilot: What Should You Build First?

The business situations in this article are fictional illustrations, not accounts of Parikh Advisory client engagements.

A founder shows a clickable expense approval screen to a finance director. She understands it immediately and says she would use it. The founder calls the MVP validated. Then someone asks what happens when an approver is absent, a receipt is submitted twice, or a claim must be reversed after payment. None of those events occurred in the demonstration.

Illustrative scenario. The finance director’s response is useful evidence about comprehension. It says little about whether the organization can approve and reimburse real claims reliably. The question is not which fashionable label to put on the experiment. It is which uncertainty the next experiment must reduce.

Start with the claim you need to test

Prototype, pilot and MVP are used differently across organizations. Agree on working definitions for this decision, then state precisely what each activity can and cannot show. A clickable prototype might test whether a person understands the route through a claim. A bounded pilot might test how the approval workflow operates with real participants and controlled support. A limited live product might test whether a complete service creates repeatable value under ordinary use. None, by itself, proves the commercial case.

For the expense product, the risky assumption may be that employees can submit a claim without help. Or it may be that finance can enforce delegation and audit rules. A prototype is well matched to the first question; a workflow pilot is better matched to the second. Building a polished service before asking either question raises the cost of learning.

The choice is not always a neat three-step ladder. A founder may test a price or a manual concierge service before any interface exists. A team with a mature platform may be able to release a narrow capability safely. The method follows the risk, the available evidence and the consequence of a wrong answer.

What evidence does each experiment produce?

• Prototype: Put a representation of the interaction in front of intended users. Observe where they hesitate, what they expect, and whether they can explain the outcome. Their approval is an opinion; completing a representative task is stronger evidence of comprehension. A prototype does not establish integration, data quality or operational reliability.
• Controlled pilot: Limit the participants, duration and claim types. Assign someone to observe exceptions, intervene and document what happened. Measure the work created for finance and support as well as the apparent convenience for employees. A pilot may establish feasibility in that setting without proving the same performance at scale.
• Limited live release: Define a complete supported journey, an owner, a help route and a stop condition. Observe actual use and outcomes over time. A live release generates stronger behavioural evidence, but adoption by a small group does not automatically validate pricing, distribution or wider demand.

Before starting, write the claim in a form that could be disproved: “For routine claims under our existing policy, employees can submit evidence and learn the final decision without asking finance for clarification.” Decide what counts as a routine claim, which group participates, what the current baseline is and what observation would cause a change of plan. If every possible result is interpreted as validation, the experiment is a demonstration.

The exception reveals a different product

Suppose the pilot includes ten employees and one approver who is away for a week. Who can delegate authority? Who sees the stalled claim? What can the employee do without resubmitting it? If the system sends a notification but nobody may make the decision, the interface has surfaced an operating problem rather than solved it.

The duplicate receipt is another test. Detecting a repeated file is not necessarily the same as detecting a repeated expense. Finance needs a rule, evidence and a route for a legitimate correction. A prototype can show how this might appear. A pilot can show whether the people and data needed to apply the rule are actually available.

Because reimbursement touches money and personal information, a live pilot also needs the relevant finance, security and legal owners to agree on the boundary. The acceptable experiment may be a simulation or a narrow internal workflow until those controls are ready. A small audience does not make a harmful failure harmless.

Choose the next commitment, not a grand label

Return to the finance director with two separate findings. First: intended users understood the proposed screen in the observed sessions. Second: authority and exception handling remain untested. If comprehension was the main risk, refine the prototype. If the business is about to rely on the workflow, run a bounded operational test with absent approvers, duplicate evidence and interrupted claims deliberately included.

The decision record can fit on one page: the claim, test participants, observed behaviour, exceptions, limits of the evidence, next investment and the person who can stop or change the test. This keeps the founder from reporting “validated” when only one part of the promise has been examined.

The judgment

The smallest experiment is the one that answers the most consequential current question with acceptable risk. It need not resemble the final product. A good prototype can prevent a needless build; a good pilot can expose an operating rule the prototype could never test; a narrow live release can show whether people depend on the service. Call each by the name your team agrees on, then describe the evidence more carefully than the label.

Questions to take into the room

• What assumption would most change the investment if it proved false?
• What can this test observe directly, and what will remain an inference?
• Which exception or handoff could invalidate an otherwise successful happy path?
• Who may intervene, stop the experiment and explain an adverse result?
• What finding would justify the next commitment, and what finding would make us reconsider?

Research note: the UK Government Service Manual’s alpha guidance describes testing risky assumptions with prototypes before a service is built. Silicon Valley Product Group’s product discovery discussion distinguishes learning about value, usability, feasibility and business viability. These are methodological references; the expense scenario is fictional and does not report a Parikh Advisory client outcome.