stanislavnianko Problem Framing
Part of the discovery-phase skill pack ·
discoverygroup · readsdiscovery-context.md(runprofile-builderfirst if missing).
Turns whatever the client said into a testable, falsifiable hypothesis. If the client already proposed a solution (very common in outsourcing), this skill un-pitches it back into a problem statement before anything downstream runs.
Step 1 — Read discovery context
Read discovery-context.md (sections 1. Client, 2. Product / Initiative). If section 2 says the client already proposed a solution, flag it — this skill will need to extract the underlying problem from that solution rather than starting clean.
If discovery-context.md is missing, ask the BA inline: "(a) client name + sector; (b) what's being explored in one line; (c) did the client propose the solution or did the agency?" — tag any unverified canvas field as [ASSUMED]. Never block; recommend profile-builder for high-stakes work.
Step 2 — Forbid solution-speak (mid-skill rule)
Apply this rule throughout: any phrasing like "build X", "add Y feature", "implement Z" is intercepted and reframed as "what outcome would X produce, and why is that outcome missing today?"
This applies even to the client's own framing. If the discovery-context says they want "an AI assistant", the canvas asks: "What job is the AI assistant supposed to do, and what's broken about how that job gets done today?"
Step 3 — Fill the canvas
Walk the BA through the canvas. Each section is 1-3 sentences max.
- Problem statement — who has the problem, in what context, what outcome they're not getting
- Why now — what changed in the world / market / client's business that makes this worth solving this quarter
- Target user — role, segment, size; if B2B, name the buyer AND the end user if different (often same in SMB, different in enterprise)
- Current workaround — how the user solves this today (Excel, manual ops, a competitor, contractors, doing nothing)
- Success signal — metric + direction + rough magnitude (NOT a feature; a behavior or outcome)
- Out of scope — explicit exclusions
- Open questions — 3-5 items research must answer
If the BA cannot answer a section because the engagement is too early or the client hasn't been asked, mark "TBD — ask client" and add to a per-skill follow-up list at the bottom of the canvas. Do not invent.
Step 4 — Render hypothesis
One sentence:
We believe that
<user>experiences<problem>when<context>. Solving it would unlock<outcome>, measurable by<signal>.
Step 5 — Pressure test (4 checks)
Run these. If any fails, loop back to the linked section.
| Test | Question | Fix in section |
|---|---|---|
| Falsifiability | What concrete observation would make us drop this hypothesis? | Success signal + Open questions |
| Specificity | Can we name a real living person who has this problem right now? | Target user |
| Novelty | Does the current workaround already do 80%? Is the remaining 20% worth a project? | Current workaround |
| Strategic alignment | Does "why now" match the client's current priorities (not the agency's)? | Why now (and surface to stakeholder-mapping) |
If 3+ tests fail, tell the BA: "This hypothesis isn't ready. Three of four pressure tests failed. Loop back, ideally with another 30-minute conversation with the client."
Step 6 — Write artifact
Output: ./discovery/problem-canvas.md — see ./template.md.
Append to _log.md: [problem-framing | YYYY-MM-DD] hypothesis: <one-line>; pressure_tests: <4/4 pass | flags>.
Anti-patterns
- Accepting client's solution as the problem. "Client wants an AI chatbot" is not a problem statement. Force the un-pitch.
- Multi-problem canvas. If the BA cram 3 problems into one canvas, split into 3, pick one for this cycle.
- TBD in success signal. Without a measurable signal, every downstream phase is guesswork. Push the BA to call the client if necessary.
- Skipping pressure test for a friendly client. Especially dangerous in repeat engagements — comfort breeds vague hypotheses.