A true MVP is the smallest thing that tests your riskiest assumption with real users. It is not a cut-down version of the final product. If you can answer your biggest unknown with a spreadsheet and a phone call, that is your MVP, and the code can wait.
An MVP can drift when its scope answers "what could users want?" instead of "what do we need to learn?". The steps below force the second question.
Step 1: Write down the riskiest assumption
Every product rests on a few beliefs. List them, then pick the one that kills the idea if it's wrong.
Typical candidates:
- Desirability: people have this problem and care enough to change behaviour.
- Willingness to pay: they will pay, or give you something equivalent (time, data, a commitment).
- Feasibility: you can deliver the core result at a cost that works.
- Acquisition: you can reach these people at all.
Phrase it as a falsifiable sentence: "Facility managers at 20 to 100 person companies will send a written brief for office space through a form instead of calling brokers." You should be able to say what result would prove it wrong.
Step 2: Pick one core job
Describe the single job the user hires your product to do, in one sentence. "Help me shortlist office spaces in my city" is a job. "Manage my real estate workflow" is a category.
Everything that does not serve that job in the first release goes on a later list. The list of features to cut from a first MVP goes through the usual suspects and the signal that tells you to add each back.
Step 3: Narrow the user segment
A narrow segment lets you make decisions without arguing. One city, one role, one company size. Their needs overlap enough that the core job looks the same for everyone, and you can reach them directly.
Broad segments produce settings screens, permission models and onboarding branches. Those are expensive and teach you little.
Step 4: Fake or do manually whatever you can
A concierge MVP delivers the result by hand while the user sees a simple interface. A Wizard of Oz MVP looks automated to the user, with a person behind it. Both can test demand before you automate. Tell participants when human involvement affects privacy, turnaround or the promise being tested.
Candidates for manual work:
- Matching, recommendations, and approvals (a person decides).
- Data entry and listing curation (a spreadsheet or admin console).
- Notifications (send them yourself from a shared inbox or WhatsApp at first).
- Payments (invoice by hand before wiring up a billing system).
Manual work doesn't scale, and that's fine. The goal is to learn what is worth automating. If you later automate messaging, our WhatsApp CRM integration guide covers the plumbing.
Step 5: Set a timebox
Pick a fixed period, then cut scope to fit. Scope-first planning ("we'll ship when it's done") drifts. Time-first planning forces trade-offs early.
A reasonable rule: if the plan needs more than a few weeks of build before any real user touches it, the scope still contains assumptions you could test cheaper. Treat that as a signal to cut, not to hire more people.
Step 6: Deploy early, to real people
Deploy to production-like infrastructure on day one of development, not at the end. Put a handful of real users on it as soon as the core job works, even if it is rough. Our pre-launch technical checklist covers what must be true before strangers use it.
Don't wait for polish. Wait for the basics: it works, it doesn't lose data, and you'd notice if it broke.
Step 7: Instrument the core event
Decide before launch what counts as success, and track exactly that. Typically that is an activation event (the user got the first real value) and a core action (the thing they come back to do). See what to track in MVP analytics.
Without instrumentation, "learning" turns into opinion.
Step 8: Learn, then decide
Set the decision rule before you look at data. Write it down:
- If at least X of Y invited users complete the core action, continue.
- If users complete it but don't return, fix retention before adding features.
- If nobody completes it despite clear instructions, revisit the assumption, not the button colour.
Then make one of three calls: persevere (build the next riskiest thing), pivot (change the segment, job or model), or stop. Stopping early on a failed assumption is a good outcome. It is cheap.
A sample scoping worksheet
Fill this out on one page before anyone writes code. The values below are illustrative.
MVP SCOPING WORKSHEET
Riskiest assumption : Small teams will submit a written brief instead of calling brokers.
Disproved if : Fewer than 5 of 30 invited teams send a brief within 2 weeks.
Core job (1 sentence): Help a team shortlist office spaces in one city.
Target segment : Ops/admin leads, companies of 20-100 people, Pune.
Success event : brief_submitted
Return event : shortlist_viewed (second session within 14 days)
IN (must exist)
- Search listings by locality and type
- Send a brief (form)
- Email confirmation
MANUAL BEHIND THE SCENES
- Listings added by us in a spreadsheet/admin console
- Shortlists assembled and emailed by a person
- Site tours scheduled over phone/WhatsApp
OUT (explicitly later)
- User accounts beyond email
- Payments, reviews, saved searches
- Multi-city, multi-language
Timebox : 4 weeks to first real users
Decision date : 2 weeks after launch
Decision rule : continue / pivot / stop (see thresholds above)
The "OUT" list is the most useful part. It stops scope creep by making the exclusions visible.
How Apex approaches it
For product builds we run product grooming sessions first, where the team and the client work through the assumptions, the core flow and what to leave out. Before production code, we build a clickable prototype so people can react to the flow while changes are still cheap. After launch we spend a month tuning the product with the client based on real usage. The details are on our product development page.
None of this replaces the steps above. It is one way to run them.
Common failure modes
- Building for everyone. No segment means no clear core job.
- Treating "MVP" as "version 1 of everything". Version 1 of everything is just a slow launch.
- Skipping the decision rule. Without one, any data can be read as encouraging.
- Automating before learning. You build the wrong automation well.
- Shipping with no analytics. You find out nothing.
Summary
Name the riskiest assumption, pick one job for one segment, do manually what you can, fix a deadline, ship, measure the core event, and decide against a rule you wrote earlier. Confirm that users can complete the promised job safely, even when the feature list is narrow.
References
- Martin Fowler: Strangler Fig Application (for replacing manual parts incrementally)
- PostHog docs: capturing events
- web.dev: Learn (baseline quality checks before launch)