# [Problem / Feature Name]

> Start with just the problem name—before you know what the feature will be. That's not only okay, it's preferable.

---

## 1. Problem Discovery

### The Problem Statement
> What user or business problem does this solve? Be specific about the pain point. No solutions yet.

> **Discovery Tool: The Five Whys**
> If your problem statement feels surface-level, ask "why" 3-5 times. Stop when you hit something actionable within your domain. Document the root cause above.

### Problem Validation Checklist

Before you build anything, ask yourself:

1. **Whose problem is this, specifically?**
   (Can you name the exact user segment or role? Not “our customers” — *which* ones?)

2. **How painful is it (this will be helpful in prioritizing)?**
   (What evidence do we have from support messages, calls, data, behavior?)

3. **What are they doing today to cope?**
   (Workarounds reveal pain depth; the more elaborate, the more serious.)

4. **What measurable change would tell us the problem is gone?**
   (Define the *results* - efficiency gains, reduced errors, lower stress - not the *solution*. How will we know if we’ve solved it?)

5. **What are the competing constraints?**
   (Who else is affected? What trade-offs or conflicts exist across stakeholders?)

6. **What won’t we do?**
   (Set explicit boundaries — appetite, scope, and no-gos.)

7. **Where does this problem begin?**
   (Trace it upstream. Is this problem a symptom of something earlier — process, policy, or product? Fixing the origin is almost always cheaper than fixing the symptom.)

8. **What assumptions are we making?**
   (List them openly so they can be tested, not buried.)

9. **What could make this the wrong problem?**
   (Pre-mortem the work — what would prove we’re solving the wrong thing?)

10. **If we solve this, what becomes possible next?**
   (Solving the right problem should expand what’s possible - for us and for our users.)

---

## 2. Discovery Notes

### What We Learned
> Key insights from customer interviews, support tickets, usage patterns

### Edge Cases & Technical Complications
> Potential challenges identified during discovery

### Open Questions
> What still needs validation before we build

---

## 3. Constraint Budget

### Time & Effort Allocation
> How much time are we willing to spend? We're solving this problem **within constraints**. There's always a better solution—we're finding the right solution for our budget.

### Resource Considerations
> Team size, dependencies, technical debt affecting timeline

### What We're NOT Doing
> Explicit exclusions to fit our budget and keep the problem tractable

---

## 4. Pre-Mortem: What If We're Wrong?

### Failure Scenarios
> It's 6 months later and this failed. What happened?

### What Would Prove Us Wrong
> What evidence would show we're solving the wrong problem?

### Early Warning Signs
> What metrics/feedback would signal we're off track?

---

## 5. Solution

### What It Is (Plain English)
> Describe the solution in terms anyone can understand

### Problem-Solution Fit
> Map each pain point to how the solution addresses it

+ **Pain Point 1:** [from Problem Discovery]
+ **How We Solve It:**

+ **Pain Point 2:** [from Problem Discovery]
+ **How We Solve It:**

### Why This Solution
> Opinionated decisions and rationale. Why this approach over alternatives?

### What This Doesn't Solve
> Be honest about remaining pain and accepted trade-offs

---

## 6. Success Criteria

### Problem-Solved Metrics
> How we'll measure whether the problem is actually gone (not whether the feature shipped)

**Leading Indicators** (early signals):

**Lagging Indicators** (ultimate outcomes):

---

## 7. Confidence Assessment

Rate your confidence (1-10):

- [ ] **Problem Understanding**: ___ /10
- [ ] **Solution Fit**: ___ /10
- [ ] **Scope Accuracy**: ___ /10
- [ ] **Success Metrics**: ___ /10

**Overall**: ___ /40 (Need 32+ to proceed)

---

## 8. Logistics

### Team & Responsibilities

> List the team members involved, along with their roles and responsibilities.

### Important Links
- [Asana card]()
- [Wireframes]()
- [Overview video]()

> Include links to relevant resources like the Asana ticket, wireframe/design documents, videos, etc.

### Terminology (define important terms)

> List and define key terms related to the feature, alphabetized for easy reference in the format shown below:

+ **Term**: definition