Problem Statement
Frame a customer-backed problem statement with I-am / trying-to / but / because narrative before solutioning or writing specs.
Overview
problem-statement is an agent skill most often used in Validate (also Idea research) that structures user pain into a narrative and one-sentence problem statement without smuggling in the solution.
Install
npx skills add https://github.com/deanpeters/product-manager-skills --skill problem-statementWhat is this skill?
- Narrative template: I am, trying to, but, because, which makes me feel, plus context and constraints
- Contrasts strong framing (e.g. Slack distributed-team pain) with weak solution-in-disguise statements
- Forces problem-not-solution wording so AI analytics features are not mistaken for the underlying need
- Final one-sentence problem statement suitable for PRDs, landing copy, and validation interviews
- Integrates with broader product-manager-skills collection for discovery discipline
- Includes at least 2 worked examples (Slack-style strong framing and bad solution-in-disguise case)
- Seven narrative blocks: I am, trying to, but, because, which makes me feel, context, final statement
Adoption & trust: 1.3k installs on skills.sh; 5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You keep describing features instead of the user struggle, so validation interviews and specs chase the wrong problem.
Who is it for?
Solo founders and PMs in early discovery who need shared language for who hurts, why, and under what constraints.
Skip if: Teams that already have a signed PRD with validated problem evidence and only need implementation breakdown or code review.
When should I use this skill?
Before committing to a feature, PRD section, or positioning doc when pain is vague or stated as a solution (“we need AI analytics”).
What do I get? / Deliverables
You produce a narrative-backed final problem statement you can paste into PRDs, discovery docs, and landing hero copy before design or build work.
- Completed problem framing narrative
- Single-sentence final problem statement ready for PRD or landing copy
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Validate is where you prove the problem is real and scoped; a crisp statement gates prototype and pricing conversations. Scope is the subphase for narrowing who suffers, what constraint blocks them, and what outcome metrics will later test.
Where it fits
Synthesize interview notes into an I-am/trying-to/but narrative before you rank opportunities.
Lock a one-sentence problem statement that gates whether you build a prototype or run a landing test.
Reuse the final statement as the hero problem line so marketing copy matches validated pain.
How it compares
A narrative template for problem framing—not a market sizing spreadsheet or automated competitor scraper.
Common Questions / FAQ
Who is problem-statement for?
Indie builders and product managers who own discovery and need to articulate customer pain before specifying features or AI capabilities.
When should I use problem-statement?
During Validate scope work before prototypes; during Idea research when interviewing users; and before Launch copy when hero messaging must state the problem not the product SKU.
Is problem-statement safe to install?
It is documentation and examples only; review the Security Audits panel on this Prism page like any community skill before piping outputs into production repos.
SKILL.md
READMESKILL.md - Problem Statement
# Problem Statement Examples ## Example 1: Slack (Early Problem Statement) **Problem Framing Narrative:** **I am:** A software developer on a distributed team - Working across multiple time zones with teammates I rarely see in person - Collaborating on complex technical projects requiring frequent communication - Drowning in email threads that are hard to follow and unsearchable **Trying to:** - Communicate in real-time with my team without losing context or important decisions **But:** - Email is too slow and threads get buried - Skype/IM is ephemeral—conversations disappear and can't be searched later - Important decisions get lost, forcing me to re-ask questions or hunt through old messages **Because:** - No tool combines real-time chat with persistent, searchable history **Which makes me feel:** - Frustrated, inefficient, and disconnected from my team **Context & Constraints:** - Distributed teams across time zones - Need for asynchronous + synchronous communication - Must integrate with dev tools (GitHub, Jira, CI/CD) **Final Problem Statement:** "Distributed software teams need a way to communicate in real-time with persistent, searchable history because email is too slow and IM is ephemeral, which causes lost context and repeated questions." --- ## Example 2: Bad Problem Statement (Solution in Disguise) **Problem Framing Narrative:** **I am:** A product manager **Trying to:** - Use AI-powered analytics **But:** - We don't have AI features **Because:** - Our competitors do **Which makes me feel:** - Behind the times **Final Problem Statement:** "We need AI-powered analytics to compete." **Why this fails:** - "Trying to" is a solution, not an outcome - "But" is a missing feature, not a barrier - "Because" is competitor-driven, not user-driven - "Makes me feel" is about the PM, not the user **How to fix it:** Reframe from the user's perspective: **I am:** A product manager analyzing user behavior across multiple features **Trying to:** - Identify which user segments are at risk of churning within the next 30 days **But:** - Current analytics require manual SQL queries and hours of data wrangling - By the time I identify at-risk users, many have already churned **Because:** - Our analytics tools don't surface predictive insights automatically **Which makes me feel:** - Reactive instead of proactive, and like I'm failing to retain customers **Final Problem Statement:** "Product managers need a way to proactively identify at-risk users before they churn because current analytics are manual and slow, which causes missed retention opportunities." --- name: problem-statement description: Write a user-centered problem statement with who is blocked, what they are trying to do, why it matters, and how it feels. Use when framing discovery, prioritization, or a PRD. intent: >- Articulate a problem from the user's perspective using an empathy-driven framework that captures who they are, what they're trying to do, what's blocking them, why, and how it makes them feel. Use this to align stakeholders on the problem before jumping to solutions, and to frame product work around user outcomes rather than feature requests. type: component --- ## Purpose Articulate a problem from the user's perspective using an empathy-driven framework that captures who they are, what they're trying to do, what's blocking them, why, and how it makes them feel. Use this to align stakeholders on the problem before jumping to solutions, and to frame product work around user outcomes rather than feature requests. This is not a requirements doc—it's a human-centered problem narrative that ensures you're solving a problem worth solving. ## Key Concepts ### The Problem Framing Framework Based on Jobs-to-be-Done and empathy mapping, the framework structures problems as: **Problem Framing Narrative:** - **I am:** [Describe the persona experiencing the problem] - **Trying to:** [Desired outcomes the persona cares about] - **But:** [B