MVP does not mean cheap and ugly
It means narrow and real. Hosted, usable, with the permissions and audit trail that workflow needs — and nothing else. A slide deck is not an MVP. A private demo with dummy data is not an MVP. Someone in the business completing the job on Tuesday morning, without you in the room, is.
How to choose the slice
Write the expensive assumption as a sentence. “Warehouse staff will record dispatches in the system instead of WhatsApp.” Then build only what that sentence requires. Reports can wait. The customer portal can wait. The second warehouse can wait.
If you cannot name the assumption, you are not ready to build an MVP. You are ready for a workshop.
What we refuse to strip out
Login, roles, backups, a way to undo a bad action, and a handover. Cutting those to hit a date produces something you cannot put in front of staff. That is a prototype. Call it that and budget the next step; do not call it an MVP and then wonder why nobody uses it.
What goes in the first slice, written down
For a dispatch MVP: log in, create a dispatch against an order, print or send a note, see today’s list, undo a mistake, export for accounts. That is enough to test “will warehouse staff stop using WhatsApp?”. Not in the slice: customer login, route optimisation, a driver app, last year’s analytics, the bilingual help site.
Write two lists before anyone opens Visual Studio. If a stakeholder adds an item to the first list, something else leaves, or the date moves. An MVP with a growing first list is a full project in denial.
How you know the test passed
The assumption was a sentence. After two weeks of real use, either staff complete that job in the system most of the time, or they do not. “They said it looks nice” is not a pass. If they do not, you have learned something cheap: the problem was not software, or the slice was the wrong job. That is the point of an MVP. A nine-month build that learns the same thing is just expensive.
Anti-patterns that kill the test
Adding “just the reports” because a director asked once. Building the customer login before staff will use the back-office. Calling a clickable Figma file an MVP. Shipping without backups so you can hit a date. Each of those produces something you cannot learn from. An MVP you cannot put in front of the people who do the job is a prototype. Budget the next step and say so.
Another pattern: the first list grows in the standup every morning. That is a full project. Either something leaves the list, or the date moves, or you stop calling it an MVP. Stakeholders who cannot accept that sentence are not ready for an MVP. They are ready for a scoped phase with a change log — which is also fine, and costs more.
How to brief an MVP so the room stays honest
Write the assumption as a sentence. Write the in-list and the out-list. Write who will use it on Tuesday without you. Write what you will count after two weeks. Send that page with the same one-page job description you would send any vendor. If a director adds an item, ask which item leaves or which week moves. Doing that in email is kinder than doing it in a demo in week ten.
An MVP is allowed to look unimpressive. It is not allowed to be unmeasured. “They liked the colours” is a prototype review. “Dispatch notes are created in the system four days out of five” is an MVP result. Only the second one tells you whether to fund the portal.
A dispatch MVP, week by week
Week 1: sit on the warehouse floor. Photograph the WhatsApp group, the printed list, the way they cancel a line. Write the in-list: login, create dispatch against an order, print or send a note, today’s list, undo, export for accounts. Week 2–6: build that, migrate enough orders that yesterday exists, put it on a phone the supervisor already has. Week 7–8: they use it without you. You count how many dispatches still went through WhatsApp. That number is the result.
Not in those eight weeks: the customer portal, route maps, last year’s charts, a driver app. Those are next sentences. If a director adds them in week 3, show the two lists and ask which week moves. That conversation is the MVP. The software is how you test the sentence.
Handover still happens. Source, hosting, backups, a way to undo, a named week of support. Cutting those to look “more MVP” produces a prototype you cannot leave with staff. Call it a prototype and budget the next step, or keep the word MVP and keep the boring parts. Cost of that shape is in how much custom software costs.
What happens after the two-week test
If staff complete the job in the system most of the time, you earned the next slice — the report, the second warehouse, the portal. Sequence those as new MVPs or as a backlog with the same discipline. If they do not, you learned cheap: the problem was the process, the incentive, or the wrong job. Do not “add features” to rescue a failed assumption. That is how you fund a nine-month build that nobody wanted.
Cost and sequencing sit in how much custom software costs. If the alternative is buying a product and bending it, read the build versus buy comparison first.
What to tell a director who wants “the full platform”
Show the assumption sentence and the two-week count. If the count is not there yet, the platform is a guess with more screens. If the count passed, the next slice gets its own sentence — “dealers will raise claims here instead of email” — not a grab-bag of leftover wishes. Directors who need a roadmap can have one: three sentences, three dates, three counts. That is a programme. Twelve modules on one slide is a brochure.
If they still want everything by a festival date, you are not in MVP work. Say so. Price a scoped phase or walk away. Calling a festival deadline an MVP is how you ship without backups and call it lean. A scoped phase with a change log is respectable. It is just not an MVP. Use the word that matches the list, or the date will lie. Write the word on the purchase order so nobody “clarifies” it in week six. If they change the word, change the date and the list in the same email, or you have agreed a different job. Silence in that email is how festival dates eat backups.