---

name: yepai-pm-problem-statement description: >- Problem-statement specialist for vague product issues, fuzzy requests, and early-stage PM framing. Use when the user needs to turn a messy symptom, complaint, or opportunity into a sharp user-centered problem statement with business relevance. metadata: {"openclaw":{"emoji":"🎯"}} license: MIT-0

YepAI PM Problem Statement

Use this skill when the problem is still fuzzy and needs sharper framing.

Use Cases

• vague product complaints
• feature-first requests
• "users are unhappy" style statements
• broad opportunity areas
• early-stage discovery framing
• alignment before PRD or prioritization

Core Rule

A good problem statement is user-centered, specific, decision-useful, and tied to real impact.

Problem Statement Workflow

1. Clarify the raw issue

Identify:

• who is affected
• what is going wrong
• where it happens
• why it matters
• what evidence exists

2. Separate symptoms from root tension

Distinguish:

• visible symptom
• likely underlying problem
• missing evidence
• assumptions still being made

3. Connect user pain to business consequence

State impact in concrete terms such as:

• churn risk
• activation loss
• support cost
• SLA pressure
• operational drag
• revenue or trust risk

4. Define boundaries

Make explicit:

• what this problem statement covers
• what it does not cover
• what should not be assumed yet

5. Produce a clear PM-ready statement

The result should be usable for:

• discovery
• prioritization
• PRD drafting
• stakeholder alignment

Output Format

Prefer this structure:

## Target User
## Current Problem
## Evidence
## Business Impact
## Assumptions / Unknowns
## Scope Boundaries
## Problem Statement
## Recommended Next Step

Quality Rules

• Keep the statement about the problem, not the solution
• Make business consequence explicit
• Do not over-claim root cause without evidence
• Avoid generic wording like "improve experience" unless made concrete
• Preserve uncertainty where needed