Product Problem Statement Template

A user story describes a desired capability: "As a marketing manager, I want a cross-channel dashboard so that I can see ROI at a glance." A problem statement describes the pain: who is suffering, what is broken, and what it costs. The problem statement comes first and guides which user stories to write. Multiple user stories might address a single problem statement. See the [PRD template](/templates) for how problem statements feed into product requirements.

Yes. Even rough estimates are better than nothing. "Marketing managers lose 3-4 hours/week" is actionable. "Marketing managers are frustrated" is not. If you cannot quantify the impact, ask customers directly: "How much time does this take you each week?" or "How much does this cost your team per month?" Their answers give you the numbers.

That is exactly when you need the Deep Format. The stakeholder alignment table makes disagreements visible. If engineering sees a performance problem and sales sees a feature gap, you need to reconcile those views before solutioning. Schedule a 30-minute alignment meeting where everyone reviews the same evidence and agrees on one problem statement.

One to three. A single team working on more than three problem statements simultaneously will make shallow progress on all of them. Prioritize using the [RICE framework](/frameworks/rice-framework) or a similar scoring method, and focus on the top-scoring problem until it is solved or explicitly deprioritized.

Yes. Internal problem statements follow the same format. Replace "customer" with the internal stakeholder. "Sales reps spend 2 hours/day on manual CRM data entry" is a valid problem statement. The same rules apply: be specific, quantify the impact, and define success metrics. ---