01 — Idea / Problem: Example

This example shows a completed problem statement for a retrospective tool.

Problem Statement

Problem: Engineering teams struggle to get actionable insights from retrospectives
Target Users: Engineering teams of 5-15 people
Context: During sprint retrospectives, teams spend 30-60 minutes but often don't identify clear action items
Impact: Teams repeat the same issues, don't improve sprint over sprint, leading to frustration

Jobs-to-Be-Done

Job 1

When: During our sprint retrospective
I want: To quickly identify what went well and what didn't
So that: We can make concrete improvements for the next sprint

Job 2

When: I'm facilitating a retrospective
I want: To help the team focus on actionable items
So that: The retrospective feels valuable and not like a waste of time

Job 3

When: We complete a retrospective
I want: To track whether we've implemented previous action items
So that: We can see if we're actually improving over time

Value Proposition

For engineering teams who struggle to get actionable insights from retrospectives,
RetroAI is a retrospective tool that provides AI-generated insights and action items.
Unlike traditional retrospectives or basic tools, we automatically identify patterns,
suggest concrete improvements, and track follow-through.

User Validation

User Interview Results

Interviewed: 7 engineering teams

Responses:

• 7 out of 10 teams confirmed the problem

• Average frequency: 2x per month (every sprint)

• Severity: Rated 7/10 on pain scale

• Common frustrations:

  • "We spend time but don't get clear next steps"

  • "Hard to see patterns across retrospectives"

  • "Action items get forgotten"

Problem Worthiness Assessment

• Frequency: Weekly ✓ (Every sprint)

• Severity: 7/10 ✓ (Moderately to very painful)

• Urgency: Moderately urgent ✓

• Willingness to Pay: 60% said yes if it saved them 30+ minutes ✓

Conclusion: Problem is worth solving. Proceed to next chapter.

---

This example demonstrates:

• Specific problem statement

• Multiple Jobs-to-Be-Done

• Clear value proposition

• Validated through user interviews

• Problem worthiness assessed