MVP Scoper
A scoped MVP with what's in, what's explicitly out, and the riskiest question it needs to answer.
Every candidate feature seems reasonable in isolation, so 'reasonable' features quietly accumulate into a build that takes months instead of weeks — without anyone making a deliberate decision to let that happen.
When to use it
Use once you have a validated problem and a decision to proceed, before development starts.
When not to use it
Not useful before you've decided to proceed — scope a decision, not an unvalidated idea.
The method
Start from your riskiest open question — the one assumption you're least sure of — and let it drive scope more than anything else. For each candidate feature, separate genuine necessity (the product fails to deliver its core value without it) from nice-to-have (people just wouldn't notice). Weigh build effort honestly, especially for nice-but-cheap features, where most scope creep actually hides. Before committing engineering time to anything, ask whether it could be delivered manually first — a concierge process, a spreadsheet — and reserve real build effort for what you've already confirmed matters.
Ways to use this
Recommended starting point: MVP Scoper: the GuideGuide — Learn how
Template — Do it yourself
Source
Developed from A Bit Gamey material on minimum viable products and 80/20 app development, including deciding what to build first and what to explicitly leave out.