Scoping the MVP
Scoping the MVP
IN THIS LESSON
If the interviewer asks what you would build first, the task is not to remove features until the product becomes small. The task is to identify the smallest coherent version that preserves the mechanism by which the product creates value.
An MVP should still solve the selected customer problem well enough to teach you whether the core product idea works. Features that are helpful but not necessary to that test can wait.
What this task proves about you
MVP scoping tests whether you can distinguish the product’s essential value from everything that could eventually surround it.
That is a product judgment problem. Teams have limited time and capacity, and an early version should answer an important question about whether the product deserves further investment. If you cut the mechanism of value, the product may be smaller but the test becomes uninformative. If you keep everything, you delay learning and increase the cost of being wrong.
Start with the mechanism you are trying to prove
Return to the pain and the reason your chosen solution should improve it.
For the adaptive study planner, the mechanism is that the learner can see the real workload against the remaining deadline and receive an actionable daily recommendation. A first version therefore needs enough information to estimate the remaining work, a deadline, and a way to translate those into a daily plan.
It does not necessarily need a large content library, social study groups, expert tutoring, sophisticated rewards, or deep personalization. Those might improve the mature product, but the first question is whether making the workload and required daily commitment explicit actually helps deadline-driven learners allocate their time better.
That statement gives you a useful scoping test: if you remove this capability, can the MVP still test the mechanism you said creates value?
Preserve a coherent customer experience
A minimum product still has to work as a product.
Suppose you keep the deadline and task list but remove the daily recommendation. You have simplified the system, but you may also have removed the key behavior that differentiates the idea from an ordinary checklist. The resulting product would not test the same hypothesis.
At the other extreme, you may not need automatic integrations with every calendar or learning platform. The first version could ask the learner to enter their deadline and available study time manually if that is sufficient to test whether the recommendation is useful.
This is the difference between reducing convenience and removing value. Manual work, narrower coverage, or simpler operations can be reasonable early compromises when they preserve the customer outcome you need to learn about.
Scope around the riskiest coherent test
The MVP becomes more useful when it is designed to resolve an important uncertainty.
If the biggest question is whether learners will trust a daily study recommendation, build enough to produce that recommendation credibly and observe whether they follow it. If the biggest question is whether task-time estimates can be accurate enough, the first version needs a way to create, communicate, and update those estimates. If the risk is expert availability in a marketplace, a manually operated supply process may be necessary even when the long-term product will automate much of it.
You are not trying to build the cheapest possible thing. You are trying to make the smallest investment that creates meaningful evidence about the product decision.
Use constraints deliberately
A first version often becomes smaller by constraining where, for whom, or how it works.
You might support one exam type before every kind of goal-based learning, use manual task entry before integrations, or launch with a limited set of expert topics before broader supply. Those constraints are useful when they reduce build complexity while leaving the core customer problem and mechanism intact.
Do not choose a constraint merely because MVP conversations conventionally require one. Explain what complexity it removes and why the remaining product still tests the important value proposition.
Separate MVP from the roadmap
Once the first version is clear, you may briefly identify what you would add later, but do not turn MVP scoping into a roadmap exercise unless the interviewer asks.
A candidate might say:
For the first version, I’d keep the deadline, remaining-work estimate, and daily recommendation, but I’d make schedule and task entry manual and support one exam category. That lets us test whether learners actually change how they allocate their time without first building integrations and a broad content system. If that behavior is strong, integrations and richer personalization become sensible next investments.
The explanation makes the tradeoff visible: preserve the mechanism, defer expensive convenience and breadth.
Practice
Take a solution from a completed Product Sense case and write down every capability you included or implied.
Then identify:
- the customer outcome the product must still create
- the mechanism that produces that outcome
- the biggest uncertainty you want the first version to resolve
- the capabilities required for that test
- the capabilities that can be made manual, narrower, or deferred without destroying the mechanism
Describe the resulting MVP in three or four spoken sentences. Make clear what remains, what is intentionally deferred, and why the smaller product still provides useful evidence.
The point
An MVP is the smallest coherent product that preserves the mechanism of value and creates useful evidence about whether the idea works. Scope by protecting the customer outcome and the important learning, not by arbitrarily cutting features until the product is small.
Was this lesson helpful?
Your feedback helps improve lesson quality.