Define Problem Statement
- 532 installs
- 518 repo stars
- Updated August 4, 2026
- product-on-purpose/pm-skills
define-problem-statement is an agent skill that generates a structured problem framing document with user impact, business context, and success criteria for developers who need alignment before building features.
About
define-problem-statement is a pm-skills agent skill (version 2.0.0) that creates a concise problem framing document before any solution work begins. The skill walks through six template sections—Problem Summary, User Impact, Business Context, Success Criteria, Constraints and Considerations, and Open Questions—using references/TEMPLATE.md for consistent output structure. It prompts for specific user segments instead of vague personas, ties pain points to research or behavioral evidence, and defines time-bound metrics with baselines and targets. Developers invoke it via `/pm-skills:define-problem-statement` on Claude Code or by referencing skills/define-problem-statement/SKILL.md, and it chains naturally into hypothesis, PRD, and user-story skills in the pm-skills library. Reach for define-problem-statement when starting a new initiative, realigning a drifted project, or communicating priorities to leadership before writing requirements.
- define-problem-statement
- AI & Agent Building
- AI-coding skill
Define Problem Statement by the numbers
- 532 all-time installs (skills.sh)
- +33 installs in the week ending Aug 4, 2026 (Skillselion tracking)
- Ranked #1,706 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/product-on-purpose/pm-skills --skill define-problem-statementAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 532 |
|---|---|
| repo stars | ★ 518 |
| Last updated | August 4, 2026 |
| Repository | product-on-purpose/pm-skills ↗ |
How do you write a product problem statement?
Helps with ai & agent building tasks.
Who is it for?
Engineers or PMs starting a feature initiative who need a shared problem framing doc before PRDs or user stories.
Skip if: Teams that already have an approved PRD and only need implementation guidance or code generation.
When should I use this skill?
A developer asks to define the problem, write a problem statement, or align the team before scoping a new feature.
What you get
Problem statement document with user segment, pain points, success metrics, constraints, and open questions.
- problem statement document
- success criteria with baselines
By the numbers
- Produces 6 structured template sections per problem statement
- Skill version 2.0.0 in the pm-skills define phase
Files
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
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-hypothesisand 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.
Scenario: mobile checkout abandonment
This is the INPUT brief for an output-quality eval. The skill arm and the control arm each receive everything below (and nothing else about how to do the work) and produce a problem-statement artifact for it. Judges never see this header. Note: the input is deliberately RAW (an unframed situation with data), not a pre-written problem statement.
Situation brief
Product: a direct-to-consumer e-commerce app (skincare). Most traffic is mobile.
What we are seeing (raw signals):
- Mobile checkout completion rate is 48% (desktop is 71%). The gap has held for two quarters.
- Of mobile users who abandon, 62% drop on the payment-and-shipping step specifically.
- Support gets recurring complaints: "it made me re-enter my card," "the address form kept resetting,"
"I couldn't tell if my discount code worked."
- Session replays show mobile users pinch-zooming the form fields and toggling between the app and
their banking app to copy a one-time code.
- Average mobile order value is $54; roughly 9,000 mobile checkout attempts per week.
- A competitor recently launched one-tap wallet pay and is advertising "checkout in 10 seconds."
Business context the team mentioned:
- Next quarter's company goal is to grow repeat-purchase revenue without increasing paid acquisition.
- Engineering capacity is tight; a payments-platform migration is already half-planned for the year.
- Finance is sensitive to anything touching PCI scope.
What is NOT yet known:
- Whether the drop is driven by the form UX, the payment method options, perceived security, or
unexpected shipping cost shown late.
- Whether logged-in returning customers abandon at the same rate as guests.
Audience for the artifact: the product leadership team, who will decide whether to fund a checkout workstream this quarter.
{
"schema": 1,
"skill": "define-problem-statement",
"runs_per_query": 3,
"trigger_threshold": 0.5,
"queries": [
{
"q": "Write a problem statement for the drop-off we're seeing in mobile checkout",
"expect": "trigger",
"split": "train"
},
{
"q": "This project has drifted so far that nobody remembers what we set out to fix; help me re-anchor it in the original problem",
"expect": "trigger",
"split": "train",
"notes": "Intent-only ask; realigning a drifted project"
},
{
"q": "I need to explain to leadership why activation matters before they'll fund the work; frame the problem with user impact and success criteria",
"expect": "trigger",
"split": "train"
},
{
"q": "Frame the support-ticket backlog issue as a crisp problem doc the team can align on before we discuss solutions",
"expect": "trigger",
"split": "train"
},
{
"q": "New engineers keep jumping to solutions; create the document that establishes what problem we're solving and how we'll know it's solved",
"expect": "trigger",
"split": "train"
},
{
"q": "Kick off the retention initiative with a clear problem framing: who is affected, what it costs us, and what success looks like",
"expect": "trigger",
"split": "train"
},
{
"q": "Draft a problem statement for enterprise admins struggling with user provisioning",
"expect": "trigger",
"split": "validation"
},
{
"q": "Before we commit a team to this, I want one page that nails the problem, the impact, and the success criteria",
"expect": "trigger",
"split": "validation"
},
{
"q": "Our VP asked what problem we are actually solving here and I didn't have a good answer; help me write it down properly",
"expect": "trigger",
"split": "validation",
"notes": "Intent-only ask, no artifact keyword"
},
{
"q": "Someone proposed a chatbot but I'm not convinced it addresses the real issue; help me articulate the core problem first",
"expect": "trigger",
"split": "validation",
"notes": "Evaluating whether a proposed solution addresses the core problem"
},
{
"q": "The problem is agreed and funded; write the full requirements doc so engineering can start building",
"expect": "no-trigger",
"split": "train",
"near_miss_of": "deliver-prd",
"notes": "Agreed problem plus spec ask belongs to the PRD, per When NOT to Use"
},
{
"q": "We think onboarding emails will lift activation by 10 percent; turn that assumption into something testable with success metrics",
"expect": "no-trigger",
"split": "validation",
"near_miss_of": "define-hypothesis",
"notes": "An unvalidated assumption to test, not a problem to frame, per When NOT to Use"
},
{
"q": "Compare three solution approaches for the latency issue in a one-page brief for stakeholders",
"expect": "no-trigger",
"split": "train",
"notes": "Proposing and comparing solutions; develop-solution-brief territory"
},
{
"q": "Build a JTBD canvas for why customers hire our scheduling product",
"expect": "no-trigger",
"split": "train"
},
{
"q": "Map our desired retention outcome to opportunities and solution ideas in a discovery tree",
"expect": "no-trigger",
"split": "validation"
},
{
"q": "Create a persona for our power-user segment based on last quarter's research",
"expect": "no-trigger",
"split": "train"
},
{
"q": "Debug this null pointer exception showing up in our checkout service logs",
"expect": "no-trigger",
"split": "train",
"notes": "Unrelated debugging ask"
},
{
"q": "Write a regex that extracts order IDs from these log lines",
"expect": "no-trigger",
"split": "validation",
"notes": "Unrelated technical ask"
},
{
"q": "Find me a good hotel near the conference center in Berlin for next week",
"expect": "no-trigger",
"split": "train",
"notes": "Unrelated logistics ask"
},
{
"q": "Run RICE and MoSCoW over this feature list and tell me where they disagree",
"expect": "no-trigger",
"split": "validation"
}
]
}
define-problem-statement - Version History
| Version | Date | Release | Effort | Type | Summary |
|---|---|---|---|---|---|
| 2.1.0 | 2026-06-10 | v2.26.0 | F-12-batch-2 | minor | Quality convergence: When NOT to Use + output-contract enumeration (F-12 Batch 2) |
| 2.0.0 | 2026-01-26 | - | - | baseline | Prior published version |
2.1.0 (2026-06-10)
Quality-convergence minor (F-12 Batch 2): added a "When NOT to Use" section with boundary pointers to neighboring skills, and the Output Format now enumerates the template sections a complete artifact fills. No template or example changes.
2.0.0 (2026-01-26)
Baseline row for the prior published version; see git history for its changes.
Problem Statement: Mobile Checkout Abandonment
Problem Summary
Mobile shoppers on our e-commerce platform abandon their carts at checkout at significantly higher rates than desktop users. Despite having items in their cart and reaching the checkout page, 73% of mobile users leave without completing their purchase, representing a substantial revenue opportunity and a frustrating experience for customers who intended to buy.
User Impact
Who is affected?
Mobile shoppers who add items to their cart and initiate checkout. This segment represents 62% of our total traffic and skews toward younger demographics (18-34) who prefer shopping on their phones.
How are they affected?
Users report frustration with:
- Small form fields that are difficult to complete on mobile keyboards
- Having to re-enter payment information each session
- Confusion about shipping costs that appear late in the flow
- Slow page loads between checkout steps causing timeouts
- Difficulty applying promo codes on the mobile interface
Scale of impact
- 2.3 million mobile checkout sessions per month
- 73% abandonment rate (vs. 45% on desktop)
- Approximately 1.68 million abandoned checkouts monthly
- Average cart value of abandoned sessions: $67
Business Context
Strategic Alignment
Mobile-first commerce is a key pillar of our 2026 strategy. The executive team has committed to achieving mobile revenue parity with desktop by Q4. Reducing mobile checkout friction directly supports OKR 2.1: "Increase mobile conversion rate by 25%."
Business Impact
- Potential monthly revenue recovery: $14.8M (assuming 20% of abandoned carts convert)
- Estimated annual impact: $177M revenue opportunity
- Secondary impact: Higher mobile conversion improves CAC payback for mobile ad spend
- Customer lifetime value: Mobile-acquired customers have 23% higher repeat purchase rate
Why Now?
- Q4 holiday season approaching with 40% of annual mobile traffic
- Competitor launched one-tap checkout in September, creating pressure
- New payment provider integration enables Apple Pay/Google Pay
- Mobile traffic growing 8% MoM while desktop is flat
Success Criteria
| Metric | Current Baseline | Target | Timeline |
|---|---|---|---|
| Mobile checkout abandonment rate | 73% | 60% | Q1 2026 |
| Mobile conversion rate | 1.8% | 2.3% | Q1 2026 |
| Checkout completion time (mobile) | 4.2 min | 2.5 min | Q1 2026 |
| Mobile revenue as % of total | 38% | 45% | Q2 2026 |
| Customer satisfaction (checkout NPS) | 32 | 50 | Q1 2026 |
Constraints & Considerations
- Payment provider contract limits changes to payment form UI until March
- Must maintain PCI compliance for any checkout modifications
- iOS and Android apps share checkout webview - changes affect both platforms
- Engineering capacity: 2 engineers available, 6-week runway before feature freeze
- Cannot remove guest checkout option (legal requirement in EU markets)
- Must preserve existing promo code functionality for marketing campaigns
Open Questions
- [ ] What percentage of abandoners return later on desktop to complete purchase?
- [ ] Are there specific points in the checkout flow where drop-off spikes?
- [ ] How do abandonment rates vary by product category or cart value?
- [ ] What do competitors' mobile checkout flows look like?
- [ ] Would users prefer saved payment methods vs. digital wallet integration?
- [ ] Is shipping cost surprise a larger factor than form friction?
Problem Statement: [Problem Title]
Problem Summary
<!-- 2-3 sentences that capture the essence of the problem. Should be understandable by anyone in the organization. -->
[Describe the problem in clear, jargon-free language. Focus on the user's experience and the gap between current state and desired state.]
User Impact
Who is affected?
<!-- Specific user segment, persona, or role -->
[User segment description]
How are they affected?
<!-- Describe the friction, frustration, or unmet need -->
[Pain point description]
Scale of impact
<!-- How many users? How often does this occur? -->
[Quantify the reach and frequency]
Business Context
Strategic Alignment
<!-- How does this connect to company goals, OKRs, or strategy? -->
[Connection to business priorities]
Business Impact
<!-- Revenue, retention, growth, cost implications -->
[Quantified business impact]
Why Now?
<!-- What makes this urgent or timely? -->
[Timing rationale]
Success Criteria
| Metric | Current Baseline | Target | Timeline |
|---|---|---|---|
| [Primary metric] | [Current value] | [Target value] | [By when] |
| [Secondary metric] | [Current value] | [Target value] | [By when] |
| [Guardrail metric] | [Current value] | [Maintain] | [Ongoing] |
Constraints & Considerations
<!-- Technical limitations, resource constraints, regulatory requirements, dependencies -->
- [Constraint 1]
- [Constraint 2]
- [Consideration 1]
Open Questions
<!-- What don't we know yet? What assumptions need validation? -->
- [ ] [Question 1]
- [ ] [Question 2]
- [ ] [Question 3]
Related skills
Setup Matt Pocock SkillsScaffold the per-repo configuration that Matt Pocock’s engineering agent skills rely on so they understand the issue tracker, triage labels, and domain documentation la495k196k
Lark AppsConnect Claude, Cursor or custom agents directly to Lark (Feishu) for messaging, document automation, approval workflows and enterprise data access.402k
CavemanSlash token usage by roughly 75% while keeping every technical detail intact when working with Claude Code, Cursor or similar agents.391k94.7k
Lark Skill MakerQuickly turn any Lark/Feishu OpenAPI call or multi-step workflow into a reusable agent skill with its own SKILL.md.386k16k
Running Claude Code Via Litellm CopilotRun Claude Code at a fraction of the cost by routing requests through LiteLLM to the GitHub Copilot Chat API.270k72
Codex PetGenerate a complete Codex Pet spritesheet and metadata from one reference image without needing an OpenAI key or Codex Pro.246k10How it compares
Pick define-problem-statement over deliver-prd when you need problem alignment and success metrics before any solution or requirements document exists.
FAQ
What sections does define-problem-statement include?
define-problem-statement fills six sections from references/TEMPLATE.md: Problem Summary, User Impact, Business Context, Success Criteria, Constraints and Considerations, and Open Questions. Each section prompts for evidence-backed, jargon-free framing before solution work.
How do you invoke define-problem-statement?
define-problem-statement runs via `/pm-skills:define-problem-statement "context"` on Claude Code or `$define-problem-statement` on Codex. Developers can also reference skills/define-problem-statement/SKILL.md directly in agent sessions.