How to build an MVP that tells you something

A minimum viable product is not a cheap version of the real product. It is an experiment with a specific question attached. If you cannot say what the first release is meant to prove, you are not building an MVP — you are building version one slowly.

Start from the riskiest assumption

Every product idea rests on assumptions. People want this. They will pay. They will change how they work to use it. We can deliver it at this cost. One of those is riskier than the rest, and the first version should test that one.

Cut along the workflow, not the quality

The wrong way to shrink scope is to build every feature badly. The right way is to support one complete path through the product properly, and leave the rest out. A user who can finish one real task tells you something. A user who cannot finish anything tells you nothing.

What can almost always wait

• Granular roles and permissions — one or two roles are usually enough at first.
• Self-service onboarding, while you can still onboard users by hand.
• Admin interfaces for things your own team can do directly in the database.
• Native mobile apps, when a responsive web app answers the same question.
• Integrations beyond the one that is essential to the core workflow.

What should never be cut

• Analytics. Without instrumentation the experiment produces opinions instead of evidence.
• Authentication done properly. Security shortcuts outlive every other shortcut.
• A sensible data model. Reshaping data after launch is the most expensive kind of rewrite.
• A deployment pipeline. If shipping is painful, you will stop shipping exactly when iteration matters most.

Build it to survive success

The MVPs that cause problems are the ones built as throwaway prototypes that then get customers. Typed code, tested core logic and a clean data model cost little at this size and mean the second version extends the first rather than replacing it.