Product strategy · 4 min
What belongs in an MVP — and what doesn’t
How to cut a product idea down to a first release that tests real demand without being thrown away afterwards.
Published 27 September 2026 · QuantumPlug Technologies LLP
A minimum viable product is the smallest release that can answer the most important question about your idea: will the people you are building for actually use it, and will they pay? Too many MVPs fail not because the idea was wrong but because the first release tried to do everything — or was built so hastily that it had to be rebuilt the moment it worked.
01
Name the question the MVP must answer
Every MVP should exist to test one or two specific assumptions. “Will coaching institutes record attendance daily in a new tool?” is testable. “Will people like our platform?” is not.
Write the question down, then decide what evidence would answer it: a number of active users, repeat usage, paid sign-ups or a change in an operational metric.
02
Keep the one workflow that proves value
Identify the single journey that delivers the core value, from the first screen to the moment the user gets what they came for. Build that journey properly, with care for every step and state. Everything else is a candidate for later.
- → Keep: the core workflow, sign-in, the essential data, basic analytics
- → Defer: advanced settings, multiple roles, exports, integrations that can be done manually
- → Replace with manual work: onboarding, reports, notifications that a person can send for now
03
Minimum does not mean fragile
An MVP can be small without being flimsy. The data model, security basics and deployment pipeline are expensive to change later and cheap to get right now. Cutting features is smart; cutting foundations usually means rebuilding once the product succeeds.
Choose mainstream, well-supported technology so the codebase can grow with the product and new engineers can join easily.
04
Measure from the first day
Instrument the key steps of the core workflow before launch, so you can see where users succeed and where they drop off. Pair the numbers with conversations: five honest user interviews often explain what the analytics cannot.
05
Decide in advance what happens next
Before launch, agree what result would lead you to invest further, change direction or stop. It keeps the team honest and prevents an MVP from drifting into an unfocused full product without the evidence to justify it.
A good MVP is a precise instrument: one clear question, one well-built workflow, solid foundations and honest measurement. Build that, learn quickly, and let real usage decide what the second release should be.