brainstormlisted

# Brainstorm Frame a raw need into an agreed problem statement before any solution gets designed. ## When to use When a new ask arrives — a feature request, a bug report reframed as a need, or any item without an agreed problem/scope yet — or whenever the workflow reaches an intake step. ## Method Frame the need *before* reaching for solutions, in this order: 1. **Problem** — what user-facing or business problem is this, stated as an outcome, not a feature ("users can't X" not "add a button"). 2. **Users** — who specifically is affected; which segment, not "everyone". 3. **Scope** — what's in scope for a first useful version. 4. **Out of scope** — what is explicitly excluded, so nobody assumes it's included later. 5. **Risks** — name the risk(s) most likely to kill or derail this: value (will users want it), usability (can they use it), feasibility (can it be built with what we have), business viability (does it fit constraints/compliance/cost) — per SVPG's four big risks. 6. **Success metric** — one metric that will tell us the outcome was achieved. Offer 2-3 directions with trade-offs once the problem is framed; let the user react and converge on a shared understanding. Do not write code or a full spec at this stage — that belongs to the next capability. ## Output contract Write the framed brief as a granular note/task comment (one line at a time): problem statement, users, scope, out-of-scope, top risk(s), success metric. Report to the orchestrator and group