What an MVP has to prove
Before a line of code, one question: what are we trying to find out? That people will pay for this, that they come back, that a partner agrees to plug into it. That question sets the entire scope, and it eliminates half the features everyone thought were essential.
Choosing the scope of the first batch
The most common and most expensive mistake is building the complete product before showing it. The useful discipline is the opposite: decide what does not go into the first batch, and write it down.
- One user journey carried through to the end, rather than five sketched out
- Administration reduced to the strict minimum, often direct data access at first
- Rare edge cases handled by hand to begin with
- Everything deferred, listed explicitly, so it is not rediscovered mid-course
Acceptable shortcuts, and expensive ones
Not all shortcuts are equal. Some save weeks with no consequence, others come due with the first real customer.
- Acceptable: little design, little automation, little back office, manual steps
- Acceptable: one language, one payment method, no native mobile app
- Expensive: a rushed data model, which will constrain every later change
- Expensive: no authentication or permissions, very hard to retrofit
- Expensive: no tracking or measurement, so nobody will know whether the MVP answered the question
MVPs and first products delivered
A marketplace connecting travellers with people sending parcels, with search, messaging and escrowed payment. A delivery platform that started as a courier application before opening up to customers and restaurants.
See the eleven documented projects
Frequently asked questions
Will the MVP code have to be thrown away?
No, and this is a point I do not compromise on. We reduce the functional scope, not the quality of the foundations: data model, authentication and deployment are done properly from the start.
I have no specification. Is that a blocker?
No. Scoping is part of the work. A well described problem is often more useful than a detailed specification written too early.
What if the MVP finds no market?
That is a result, not a failure, and far cheaper to learn than after building the full product. It is exactly what the approach exists to discover early.