Skill: Client Notes → Problems & Solution Directions
Purpose
Transform raw, unstructured client meeting notes into:
- •validated problems and pain points
- •wants vs needs distinctions
- •high-level solution directions
This skill is analytical and interpretive. It MUST NOT produce features, epics, or technical decisions.
Trigger
Use this skill when:
- •given raw client meeting notes
- •onboarding a new project
- •restarting discovery for an unclear product
Inputs
- •Raw meeting notes (text, bullets, transcripts, mixed quality)
- •Optional business context or constraints
Outputs (mandatory artifacts)
1) docs/discovery/client-problems.md
Each problem must include:
- •problem statement (solution-free)
- •who is affected
- •frequency / impact
- •evidence from notes
- •confidence level (high / medium / low)
2) docs/discovery/wants-vs-needs.md
For each major client request:
- •original client phrasing
- •interpreted want
- •inferred underlying need
- •risk of implementing the want directly
3) docs/discovery/solution-directions.md
For each solution direction:
- •problems addressed
- •intended outcome
- •assumptions
- •risks
- •non-goals
Solution directions must be:
- •technology-agnostic
- •capability-oriented
- •limited in number (prefer 3–6)
Process (must follow)
- •
Extract signals
- •explicit statements
- •implicit frustrations
- •repeated themes
- •emotional cues
- •
Normalize into problems
- •remove solution language
- •consolidate duplicates
- •discard weak or unsupported claims
- •
Separate wants from needs
- •explicitly document the distinction
- •flag high-risk wants
- •
Propose solution directions
- •one direction may address multiple problems
- •every direction must map to ≥1 problem
Guardrails
- •Do NOT define epics or features
- •Do NOT assume technology
- •Do NOT optimize for feasibility
- •Do NOT prioritize
This skill answers “what problem space are we in?” not “what should we build?”
Acceptance criteria
The skill is complete only when:
- •all three discovery artifacts exist
- •every solution direction maps to real problems
- •wants vs needs are explicitly documented
- •no feature-level language is present