Name the question first

An MVP is an experiment, and an experiment without a hypothesis produces data nobody can interpret. Before any feature discussion, write the single question this build exists to answer.

"Will independent garages pay a monthly fee for automated parts ordering?" is a question. "Build a parts platform" is not, and it gives you no basis for deciding what to leave out.

Cut breadth, never quality

The common misreading of "minimum" is to build everything badly. That produces a product whose failure tells you nothing, because you cannot distinguish a bad idea from a bad implementation.

Support one user type, one workflow, one segment — and make that one path genuinely good. A narrow product that works is a valid test. A broad one that half-works is not.

Do the unscalable parts by hand

If the question is whether people want the outcome, the machinery producing it can be a person for a while. Manual matching, manual review, and manual onboarding are all legitimate ways to test demand before building automation.

The line worth holding: the user must receive the real outcome. Simulating the back office is a shortcut; fabricating the result is a lie, and it invalidates the test as well as the ethics of it.

Decide the stopping rule in advance

Agree, before launch, what result would cause you to stop, to persevere, or to change direction. Written down beforehand, this is a decision. Discussed afterwards, it becomes a negotiation that the sunk cost always wins.

Include a time limit as well as a metric. Many MVPs are not killed by a bad result but by an ambiguous one that nobody wants to call.

Instrument before you launch

Decide what you need to measure and confirm it is actually being recorded before the first user arrives. Retrofitting analytics after launch means the earliest and most informative cohort is invisible.

Measure behaviour rather than opinion. What people did is a far better signal than what they said in a survey.

Keep it disposable

An MVP is a question, and questions get answered. Build it so it can be discarded without regret, and resist the pressure to make it the foundation of the real product before you know whether there is a real product.

Where the answer is positive, rebuilding on better foundations is a cheap, well-understood cost. Where it is negative, you have saved everything you did not build.

Written by the Global IT Solutions engineering team. Working through this decision right now?

Start a conversation