What to design before a line of MVP code is written

An MVP is a question, not a small product

Eric Ries defined the minimum viable product as the version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort. The important word is learning. An MVP exists to answer a question the business depends on, and MVP product design starts with writing that question down.

Most early products skip this. They start from a feature list, cut it until it fits the budget, and call what is left the MVP. The result is a small version of the product that tests nothing in particular, because nobody decided what it was for.

Write the riskiest assumption first

Every product rests on a few assumptions. Some are safe: people can log in, a table can show data. One or two are risky, and if they are wrong the product fails. Will bookkeepers trust an automatic match enough to stop checking it by hand? Will a business pay to be warned about tenders before a competitor finds them? Will a teenager keep reading aloud for a gift card?

Write the riskiest assumption as one sentence. That sentence is the MVP's brief. Everything designed next either tests it or supports the test, and anything that does neither can wait.

Design one core loop, and nothing else

The core loop is the shortest sequence of screens in which a user gets the value the product promises: arrive, do the job, see the result, come back. For a reconciliation product, that loop is: connect the bank, see the suggested matches, confirm them, see the account balance. On Fincline, the work was the matching layer and the interface that makes a human comfortable trusting it, and the MVP was fifteen screens for two buyer types, not the whole accounting product.

Design that loop properly and leave the rest as a list. Settings, notifications, admin, reporting and integrations beyond the first one can almost always wait. A first version should be conventional everywhere except the part that makes it different, which is the argument in your SaaS shouldn't look unique everywhere.

The states are part of the minimum

Minimum means fewer features, not fewer states. The core loop needs its empty state on day one, its loading state, its error state, the case where the data is partial, and what a returning user sees. These are not polish. They are most of what the first real users will experience, because a new product is empty, slow and imperfect before it is anything else.

A core loop designed only for the happy path tests a situation the first users will rarely be in.

Test a prototype before you build

A clickable prototype tests most of what an MVP needs to learn, for a fraction of the cost of building it. Nielsen Norman Group describes a prototype MVP as a quick, low-risk way to test the key assumptions behind a value proposition, and lists the questions it can answer: do people understand what the product can do for them, do they find it useful, and can they complete the core flow without confusion?

Put the prototype in front of five people who match the target user, and ask them to do the job it is for. If they cannot tell what it does, or do not care, the build would have found the same thing much later and at much higher cost. Keep that first prototype rough on purpose, because a polished prototype makes a weak idea harder to question.

Write down what is not in version one

The most useful document in an MVP is often the list of what it will not do. Write it at the start and agree it with everyone who will be tempted to add to it. When a new idea arrives mid-build, the question becomes "does this test the riskiest assumption?" rather than "would this be nice?", and the answer is usually no.

That second list is what keeps an MVP small. Without it, scope grows one reasonable feature at a time.

Hand over something engineers can estimate

An MVP design is finished when engineers can estimate and build it without guessing. That means the core loop at real fidelity, every state drawn, the components the loop needs, and a short note on each decision and the alternative that lost. A folder of attractive screens with the edge cases left for later leads to an MVP that ships late and behaves differently from the design.

The point

An MVP is a question with the least product around it. Write down the riskiest assumption, design one core loop and all of its states, test it as a prototype with real users, and agree what version one will not do. Then build only what survives.