Problem Statement

A problem statement is a concise document that frames the problem you're solving, articulates the impact on users and the business, and defines clear success criteria. It serves as the foundation for all subsequent product work by ensuring alignment on what problem to solve before jumping to how to solve it.

When to Use

• Starting a new initiative or project to establish shared understanding
• Realigning a drifted project back to its original intent
• Communicating up to leadership or stakeholders about priorities
• Evaluating whether a proposed solution actually addresses the core problem
• Onboarding new team members to provide context

When NOT to Use

• The problem is already agreed and engineering needs the spec -> use deliver-prd
• You want to propose and compare solution approaches -> use develop-solution-brief
• You are capturing customer motivation rather than a business problem -> use define-jtbd-canvas
• The "problem" is really an unvalidated assumption -> frame it with define-hypothesis and test it before committing a team to it

Instructions

When asked to create a problem statement, follow these steps:

1. Identify the User Segment Ask who is experiencing this problem. Get specific about the user persona, role, or segment. Avoid vague descriptions like "users" - instead target "mobile shoppers completing checkout" or "enterprise admins managing 50+ users."
2. Understand the Pain Points Explore what friction, frustration, or unmet need the user experiences. Ask probing questions to understand the severity and frequency of the problem. Look for evidence from user research, support tickets, or behavioral data.
3. Establish Business Context Connect the user problem to business impact. How does this problem affect revenue, retention, growth, or strategic goals? Why should the organization invest in solving this now versus later?
4. Define Success Metrics Identify how you will measure success. What metrics will move if this problem is solved? Establish current baselines and target improvements. Be specific and time-bound.
5. Surface Constraints and Considerations Note any technical limitations, resource constraints, regulatory requirements, or dependencies that will shape the solution space.
6. Capture Open Questions Document what you don't know yet. What assumptions need validation? What additional research is needed?

Output Format

Use the template in references/TEMPLATE.md to structure the output. A complete problem statement fills every template section: Problem Summary; User Impact; Business Context; Success Criteria; Constraints & Considerations; and Open Questions.

Quality Checklist

Before finalizing, verify:

• Problem is specific to a defined user segment (not "all users")
• Impact is quantified with data or reasonable estimates
• Success metrics have baselines and targets
• Problem describes the "what" without prescribing the "how"
• Business context explains why this matters now
• Open questions are captured for follow-up

Examples

See references/EXAMPLE.md for a completed example.