MVP-like Scoping¶
Scope definition — instantiates Minimum Sufficient Solution
Draws the smallest product boundary that delivers the core value and lays the roadmap by which deferred scope returns.
MVP-like Scoping draws a single boundary: the smallest version of a product or service that still delivers its core value, plus the roadmap along which everything left out will return. Its defining move is that it is a forward-looking boundary-and-sequence decision — it commits to one release line and the ordered path beyond it — rather than a per-item sort or a test. Applied inside this archetype the emphasis is sufficiency, not learning: the scope is sized to satisfy a known requirement now, with a plan to grow, not merely to run an experiment. It still keeps the non-negotiables inside version one — a "minimum" product that drops security or accessibility has not been scoped, it has been broken.
Example¶
A three-person startup is building a meal-kit ordering app and could spend a year on the full vision: personalized recipes, dietary AI, a loyalty program, a social feed, same-day delivery windows. MVP-like Scoping draws the boundary at the core value — a customer can pick a set of meals for the week and receive the ingredients — and nothing that value does not require. Version one is: browse a fixed weekly menu, add kits to a cart, pay, and get a delivery date. Personalization, loyalty, and the social feed are not deleted; they are placed on an explicit roadmap, sequenced so that whichever the early data most demands comes first. Inside version one, the non-negotiables stay: secure payment handling, an accessible checkout, and honest allergen labeling — none of which are "features" to be trimmed. The result is a coherent product the team can ship in ten weeks, with a written path for what version two and three add and in what order.
How it works¶
- Fix the core value. State the one outcome the first release must deliver for a user; the boundary is drawn around that and nothing it does not need.
- Keep the release coherent. The minimum must be a whole, usable product — an end-to-end path a real customer can complete — not a pile of half-features.
- Protect the non-negotiables inside v1. Security, accessibility, and legal duties are part of the minimum, not roadmap items.
- Sequence the remainder. Everything cut is placed on an ordered roadmap so growth follows a plan rather than the loudest request.
Tuning parameters¶
- Core-value narrowness — how tightly v1 is drawn around a single outcome. Narrower ships sooner but risks a product too thin to be worth using; wider is safer but slower.
- Release coherence — how complete the end-to-end path must be before shipping. Demanding full coherence protects the user experience but pushes out the launch.
- Roadmap commitment — how firmly the expansion sequence is fixed versus left open to evidence. A firm roadmap aligns the team; a loose one adapts but can drift back into everything-at-once.
- Invariant floor — how much non-negotiable capability sits inside v1. A higher floor is safer and heavier; too low a floor smuggles a broken product past the "minimum" label.
When it helps, and when it misleads¶
Its strength is that it converts an open-ended build into a shippable boundary plus a plan, so a team can serve the core need now and grow deliberately instead of waiting for a complete version. The term borrows the minimum viable product language of Lean Startup,[n1] and here is the borrowing's main hazard: an MVP sized to learn whether users care is a different object from one sized to satisfy a requirement now, and conflating them ships a probe where a product was promised. The classic misuse is calling a broken or unsafe cut "minimum viable" — dropping the invariants to hit a date. The guarding discipline is to insist the minimum be coherent and to keep the non-negotiables inside the boundary rather than on the roadmap.
How it implements the components¶
core_requirement— the boundary is drawn around a single stated core value the first release must deliver, which is what makes it a scope decision rather than a wishlist.expansion_path— everything cut is sequenced onto an explicit roadmap, so the minimum can grow along a plan as evidence arrives.preserved_invariant_set— security, accessibility, and legal duties are held inside version one as part of the minimum, not deferred as enhancements.
It draws the boundary and roadmap but never runs the live sufficiency_test, review_trigger, or exception_rule that prove the scoped product actually works in the field — that is Pilotable Solution, its nearest twin. Nor does it strip a program to its active ingredients via nonessential_feature_filter traced to a stakeholder_need_trace, which is Simple Intervention Package's move.
Related¶
- Instantiates: Minimum Sufficient Solution — MVP-like scoping is the archetype applied to a product, drawing the smallest sufficient release boundary.
- Consumes: Must/Should/Could Filter supplies the graded tiers the boundary is drawn along.
- Sibling mechanisms: Essential Feature Set · Must/Should/Could Filter · Lean Policy Design · Minimum Viable Documentation · Pilotable Solution · Simple Intervention Package · Minimum Viable Process
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: MVP-like Scoping operates as a non-executable information artifact that externalizes static or prospective structure because it draws the smallest product boundary that delivers the core value and lays the roadmap by which deferred scope returns.
Independent corroboration: The frozen evidence defines MVP-like Scoping as 'Draws the smallest product boundary that delivers the core value and lays the roadmap by which deferred scope returns', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Innovation & Entrepreneurship
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Minimum viable product scoping emerged from Lean Startup and product-development practice.
Related originating lineages:
- Computer Science & Software Engineering — Iterative software delivery supplied the practical release context.
- Organizational & Management Science — Project scope and roadmap governance manage deferred work.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
Sufficiency scoping and learning-release scoping look identical on a whiteboard and differ in their success test: a sufficient minimum is judged by whether it satisfies the known requirement, a learning release by whether it generates the evidence sought — the concern of Minimum Viable Process and its learning-release siblings. Choosing the wrong success test points the whole build at the wrong finish line.
[n1] The minimum viable product — the smallest version of a product that delivers value — was named by Frank Robinson and popularized by Eric Ries in The Lean Startup, where it is framed around validated learning. That learning framing is precisely why an MVP built to test demand must not be confused with a minimum built to satisfy a requirement. ↩