# Problem Statement > Frame the customer problem with evidence before jumping to solutions. Use when starting a new initiative, aligning stakeholders, or writing a PRD. - **Type:** Skill - **Install:** `agentstack add skill-uthumany-uthy-legacy-os-problem-statement` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [uthumany](https://agentstack.voostack.com/s/uthumany) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [uthumany](https://github.com/uthumany) - **Source:** https://github.com/uthumany/uthy-legacy-os/tree/main/skills/problem-definition/problem-statement - **Website:** https://uthumany.github.io/uthy-legacy-os/ ## Install ```sh agentstack add skill-uthumany-uthy-legacy-os-problem-statement ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## 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 1. **Writing a solution, not a problem** — If your statement mentions a specific feature, rewrite it 2. **Vague and unbounded** — "Users need a better experience" tells no one anything 3. **No evidence** — Without data, it's an opinion. With evidence, it's a case 4. **Too broad** — "World hunger" is a problem. "Low-income families can't access fresh produce within 1 mile" is a problem statement 5. **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](https://github.com/uthumany) - **Source:** [uthumany/uthy-legacy-os](https://github.com/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. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-uthumany-uthy-legacy-os-problem-statement - Seller: https://agentstack.voostack.com/s/uthumany - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.