Project Scope Definition

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]