AgentStack
SKILL verified MIT Self-run

Problem Statement

skill-uthumany-uthy-legacy-os-problem-statement · by uthumany

Frame the customer problem with evidence before jumping to solutions. Use when starting a new initiative, aligning stakeholders, or writing a PRD.

No reviews yet
0 installs
0 views
view→install

Install

$ agentstack add skill-uthumany-uthy-legacy-os-problem-statement

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No 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.

Are you the author of Problem Statement? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

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.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.