Scope Setting
Define what’s in/out and set boundaries.
What This Is
Draw a clear line around what you’re building in this project. Without boundaries, projects expand forever and never ship.
Minimum Viable Scope
Write two lists:
- In scope: What you’re building in this project
- Out of scope: What you’re explicitly NOT building (or saving for later)
Be specific about MVP vs future phases.
Red flag: No scope boundaries = project never finishes.
Good vs Bad Scope Definition
Bad example:
- ❌ “Build a social network”
This could mean anything. Facebook? Twitter? LinkedIn? All features or just some?
Good example:
- ✅ “In scope: user profiles, text posts, comments. Out of scope: photos, DMs, mobile app (phase 2)”
This makes it clear what ships in version 1 and what doesn’t.
Why Scope Matters
Without clear scope:
- Stakeholders keep adding “just one more thing”
- You never reach a shippable state
- Timeline extends indefinitely
- Team morale drops (“are we ever going to finish?”)
With clear scope:
- You can say “yes, that’s a good idea for phase 2”
- You know when you’re done
- You can make trade-off decisions
The MVP Question
What’s the minimum set of features that delivers value?
Not “what’s the minimum we can technically build” but “what’s the minimum that solves the user’s problem well enough that they’ll actually use it?”
Example:
- Calendar app MVP: Create events, view day/week/month, get reminder notifications
- NOT MVP: Color-coded categories, recurring events, sharing, mobile app
- Those are nice-to-haves. Get the core working first.
How to Say No
When someone requests a new feature:
- “That’s a great idea”
- “Is this critical for launch or can it wait for phase 2?”
- If critical: “What should we remove to fit this in?”
- If not critical: “Let’s add it to the phase 2 list”
Having a defined scope gives you permission to say “not now” without saying “never.”