From a seven-day AI MVP to a controlled pilot

Start with the decision the MVP must improve

The fastest route to a useful MVP is not choosing a model or drafting screens. It is naming the operational decision that currently waits, repeats or lacks context. Describe the trigger, the person or team receiving the input, the action the product supports, the output and the next decision. If the statement includes several user groups, unrelated hand-offs or a broad ambition such as transform customer service, it is a programme hypothesis rather than a one-week build scope.

A good MVP question is deliberately narrow: can a service coordinator turn one known source into a reviewed next action; can a delivery owner classify a defined set of incoming requests; can a reviewer compare an AI-assisted draft with a stated standard; can a team retrieve the right evidence from a bounded corpus. The wording matters because it sets the acceptance test and exposes which parts of the future product are intentionally outside the first release.

Make exclusions visible before estimating effort

Scope control is more than a short feature list. A credible MVP states what will not be delivered in the window: additional roles, historic data migration, complex identity federation, production integrations, multilingual support, broad analytics, automated decisions, high-risk processing or an enterprise administration layer. These exclusions are not an apology. They are the conditions that allow a small product to be dependable enough to evaluate.

The team should distinguish a demonstrator, an internal prototype and a controlled MVP. A demonstrator may use synthetic or manually prepared inputs. A controlled MVP may use real work only where permissions, data handling, human oversight and support are defined. Calling each stage the same thing creates avoidable misunderstanding about security, resilience, availability and what users should rely on.

Design the smallest dependable path through the system

An AI MVP is still a product. The model call is only one component among the input boundary, prompt or instruction, retrieval or business logic where applicable, interface, error handling, user review, logging and release process. The shortest path is the one that removes unnecessary surface area without hiding the risks that make the result unusable. A response that cannot be traced to its input, reviewed by the right person or handled when unavailable is not automatically fit for operational use.

Choose one acceptance route that a sponsor can inspect. It might be a user completing a task, a defined input producing a reviewed result, an integration returning an agreed response or a tester recording performance against representative examples. Agree what happens on uncertain, missing or harmful output. That single exception path often tells a team more about maturity than adding a second feature.

Use day eight to make a decision, not to conceal unfinished work

A one-week MVP should end with evidence and a decision: move into a pilot, iterate a specific assumption, complete prerequisites or stop. Record what was tested, which inputs were representative, what was excluded, who reviewed it and which limits remain. This prevents a narrow proof from becoming an accidental claim that the whole operational problem is solved.

For an AI-enabled workflow, the next decision normally includes whether the output is useful enough, what human review remains necessary, which data or integration dependency must be strengthened and whether the organisation has an owner for controlled use. The later pilot can then be planned around users, monitoring and adoption rather than treating the MVP as an unexamined production launch.

A working check before committing the next stage.

• 01

  Write one user-to-decision workflow in plain language.

• 02

  List explicit exclusions and the intended maturity of the release.

• 03

  Confirm authorised access, a decision-maker and release ownership.

• 04

  Define representative inputs and the uncertain-output path.

• 05

  Agree an observable acceptance test before build work starts.

• 06

  Schedule the evidence review and next decision.