Install
$ agentstack add skill-uthumany-uthy-legacy-os-problem-statement ✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
About
Problem Statement
Overview
A well-crafted problem statement aligns teams around what to solve before arguing about how to solve it. This skill guides you through writing evidence-based problem statements that frame the customer problem, its impact, and why it matters — without prescribing a solution.
When to Use
- Starting a new feature, product, or initiative
- Aligning cross-functional stakeholders on what to prioritize
- Writing a PRD or project brief
- Responding to a vague request ("We need to do something about X")
- Don't use for: execution work where the problem is already well-understood
Instructions
1. Gather Evidence
A problem statement is only as strong as its evidence. Collect:
- Qualitative: Customer interview quotes, support tickets, user feedback
- Quantitative: Usage data, funnel drop-offs, revenue impact, churn stats
- Context: Market trends, competitive moves, business goals
2. Write the Problem Statement
Use this template:
> [Who] has a problem [what/that]. This matters because [impact on user business]. We have evidence: [evidence summary]. Solving this would [desired outcome].
Example: > "Mid-market engineering teams have a problem staying aligned on project status across distributed teams. This matters because they spend 4+ hours/week in status meetings instead of building. We have evidence: 6/8 interview participants described status sync as their #1 time waste, and our analytics show 70% of daily active users check project boards for status updates. Solving this would reduce status overhead by 50% and increase time for feature work."
3. Validate the Statement
Check your problem statement against these criteria:
- No solution embedded: Does it describe WHAT not HOW? (Bad: "We need a chatbot" / Good: "Users struggle to find answers")
- Evidence-backed: Can you point to real data or interviews for each claim?
- Scoped: Is it specific enough to act on, broad enough to allow creative solutions?
- User-centered: Is the problem from the user's perspective, not the business's?
4. Get Stakeholder Buy-in
- Share with 3-5 stakeholders. Ask: "Does this match your understanding? What's missing?"
- Track disagreements — they reveal hidden assumptions
- Iterate until people say "Yes, that's exactly the problem" not "Yes, and here's how to solve it"
Sample Output
Good: > "First-time managers at scaling startups have a problem tracking their team's progress without micromanaging. This matters because they spend 30% of their week checking in on work, and their teams report feeling distrusted. We have evidence: 8 manager interviews showed 7/8 use spreadsheets as their 'real tracker' despite having project management tools. Solving this would reduce manager overhead by 10 hours/week and improve team autonomy scores."
Bad (contains solution): > "We need to build a lightweight status reporting tool for managers." (This defines the solution, not the problem)
Common Pitfalls
- Writing a solution, not a problem — If your statement mentions a specific feature, rewrite it
- Vague and unbounded — "Users need a better experience" tells no one anything
- No evidence — Without data, it's an opinion. With evidence, it's a case
- Too broad — "World hunger" is a problem. "Low-income families can't access fresh produce within 1 mile" is a problem statement
- Stakeholder by committee — If 10 people edit it, it'll be bland. Own the statement, seek input
Verification Checklist
- [ ] Problem statement uses [Who] has a problem [what]. Evidence: [data]. Outcome: [goal].
- [ ] No solution is embedded in the statement
- [ ] At least 2 sources of evidence cited (qual + quant preferred)
- [ ] Statement is testable — you can validate whether you solved it
- [ ] Stakeholders reviewed and aligned
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: uthumany
- Source: uthumany/uthy-legacy-os
- License: MIT
- Homepage: https://uthumany.github.io/uthy-legacy-os/
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet — be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.