Project Scope Definition
Define clear project scope with explicit in/out boundaries and assumptions.
Prompt
You are a product manager helping me define clear scope for a project. I need explicit boundaries to prevent scope creep and align stakeholders.
Project Context:
- Project name: [Your project]
- Problem being solved: [The core problem]
- Target users: [Who this is for]
- Timeline: [Expected duration]
- Resources: [Team and constraints]
Please help me define comprehensive scope:
1. Project Overview
One-sentence summary:
[What we're building and why]
Success statement:
"This project is successful when [specific, measurable outcome]"
2. In Scope (Explicitly)
Features & Functionality:
? [Feature 1]: [Brief description]
? [Feature 2]: [Brief description]
? [Feature 3]: [Brief description]
User Flows:
? [Flow 1]: [Brief description]
? [Flow 2]: [Brief description]
Platforms/Environments:
? [e.g., Web, iOS, Android]
? [e.g., Production only, or includes staging]
User Segments:
? [Which users this applies to]
Integrations:
? [Systems that must integrate]
3. Out of Scope (Explicitly)
NOT building:
? [Feature explicitly excluded]: [Why]
? [Feature explicitly excluded]: [Why]
? [Feature explicitly excluded]: [Why]
NOT addressing:
? [User need explicitly deferred]: [Why/when it might be addressed]
? [Edge case explicitly excluded]: [Why]
NOT supporting:
? [Platform/browser/device]: [Why]
? [User segment]: [Why]
Future consideration:
- [Item for potential future phase]
- [Item for potential future phase]
4. Scope Boundaries
| Decision Point | In Scope | Out of Scope | Rationale |
|----------------|----------|--------------|-----------|
| [Example: User types] | Admins, Members | Guests | MVP focused on core users |
5. Assumptions
We are assuming:
? [Technical assumption]: [Impact if wrong]
? [User assumption]: [Impact if wrong]
? [Business assumption]: [Impact if wrong]
? [Resource assumption]: [Impact if wrong]
Dependencies:
? [Dependency]: [Owner, risk if not met]
6. Constraints
Hard constraints (cannot change):
- [Timeline constraint]
- [Budget constraint]
- [Technical constraint]
- [Regulatory constraint]
Soft constraints (prefer to maintain):
- [Preferred constraint]
7. Success Criteria
Minimum viable scope (must have for launch):
? [Requirement 1]
? [Requirement 2]
? [Requirement 3]
Target scope (plan to include):
? [Additional item 1]
? [Additional item 2]
Stretch scope (if time permits):
? [Nice to have 1]
? [Nice to have 2]
8. Scope Change Process
If scope change is requested:
1. Document the change request
2. Assess impact on timeline, resources, other scope
3. Get approval from [decision maker]
4. Update scope document and communicate
Triggers for scope discussion:
- [Scenario that would require revisiting scope]
9. Sign-off
This scope is agreed by:
- Product: [Name, Date]
- Engineering: [Name, Date]
- Design: [Name, Date]
- Stakeholders: [Name, Date]How to use
- 1Start with the problem you're solving and success criteria
- 2Replace placeholders with your specific project
- 3Be explicit about what's OUT - this prevents arguments later
- 4Document assumptions that could change scope
- 5Define your minimum viable scope clearly
- 6Get sign-off from key stakeholders
- 7Reference this document when scope discussions arise
Tips
- Out of scope is as important as in scope - be explicit
- If it's ambiguous, it will expand - clarify boundaries
- Document assumptions - they're hidden scope risks
- Separate must-have from nice-to-have clearly
- Get engineering input before finalizing scope
- Make the scope change process clear upfront
- Review scope document whenever someone asks "can we also..."
