EasyPlatform brainstorm

[IMPORTANT] Use

TaskCreate

to break ALL work into small tasks BEFORE starting. This prevents context loss from long sessions.

Critical Thinking Mindset — Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence >80% to act. Anti-hallucination: Never present guess as fact — cite sources for every claim, admit uncertainty freely, self-check output for errors, cross-reference independently, stay skeptical of own confidence — certainty without evidence root of all hallucination.

AI Mistake Prevention — Failure modes to avoid on every task:

• Check downstream references before deleting. Deleting components causes documentation and code staleness cascades. Map all referencing files before removal.
• Verify AI-generated content against actual code. AI hallucinates APIs, class names, and method signatures. Always grep to confirm existence before documenting or referencing.
• Trace full dependency chain after edits. Changing a definition misses downstream variables and consumers derived from it. Always trace the full chain.
• Trace ALL code paths when verifying correctness. Confirming code exists is not confirming it executes. Always trace early exits, error branches, and conditional skips — not just happy path.
• When debugging, ask "whose responsibility?" before fixing. Trace whether bug is in caller (wrong data) or callee (wrong handling). Fix at responsible layer — never patch symptom site.
• Assume existing values are intentional — ask WHY before changing. Before changing any constant, limit, flag, or pattern: read comments, check git blame, examine surrounding code.
• Verify ALL affected outputs, not just the first. Changes touching multiple stacks require verifying EVERY output. One green check is not all green checks.
• Holistic-first debugging — resist nearest-attention trap. When investigating any failure, list EVERY precondition first (config, env vars, DB names, endpoints, DI registrations, data preconditions), then verify each against evidence before forming any code-layer hypothesis.
• Surgical changes — apply the diff test. Bug fix: every changed line must trace directly to the bug. Don't restyle or improve adjacent code. Enhancement task: implement improvements AND announce them explicitly.
• Surface ambiguity before coding — don't pick silently. If request has multiple interpretations, present each with effort estimate and ask. Never assume all-records, file-based, or more complex path.

Quick Summary

Goal: Facilitate a structured PO/BA brainstorming session using the Double Diamond process — diverge to discover problems and opportunities, then converge to validate and prioritize ideas before committing to implementation.

Three Scenarios:

Double Diamond (master meta-framework):

DIAMOND 1: Right Problem          DIAMOND 2: Right Solution
────────────────────────────      ──────────────────────────
Discover ──► Define               Develop ──► Deliver
(diverge)    (converge)           (diverge)   (converge)

Golden Rule: NEVER evaluate ideas while generating them. Diverge and converge are separate modes. Mixing them kills creative output.

Be skeptical. Apply critical thinking. Every idea needs a testable hypothesis. Confidence >80% required before recommending.

Answer this question:

<question>$ARGUMENTS</question>

Phase 0: Session Setup (MANDATORY)

Use

AskUserQuestion

0.1 — Scenario Detection

Ask:

1. "What scenario are we in?"

   • Problem-solving — something is broken, users struggle, a metric is bad
   • New product — greenfield, no existing product in this space
   • Feature enhancement — existing product, add/improve/remove capability
   • Mixed — multiple of the above

2. "What is the primary role in this session?"

   • Product Owner — outcome-focused, business value, user outcomes
   • Business Analyst — requirements-focused, process analysis, stakeholder mapping
   • Both PO + BA — full discovery and requirements
   • Developer / Architect — technical feasibility brainstorm

3. "How much is already known?"

   • Raw seed — just an intuition or observation
   • Problem confirmed — we know the problem, need solutions
   • Solution direction known — need to evaluate and score options
   • Idea exists — need hypothesis validation only

0.2 — Context Loading

• If project codebase exists: read

  docs/business-features/

  to understand domain
• If greenfield: skip codebase reading; rely on user input and web research
• Load

  docs/project-reference/domain-entities-reference.md

  if entity context needed
• Use

  WebSearch

  for market/competitor context when scenario = New Product or Enhancement

Phase 1: Problem Framing — Diamond 1 Diverge

Goal: Fully understand the problem space before jumping to solutions. The #1 failure in brainstorming: solving the wrong problem.

Time-box: 20–45 minutes of session time.

1.1 — Problem Statement (POV Format)

Formulate a crisp problem statement BEFORE any ideation:

[User/Persona] needs [need/job-to-be-done]
because [insight/root cause/context],
but [current barrier/friction/failure].

Example:

HR Managers need to quickly identify top performers for promotion
because quarterly reviews create promotion backlogs,
but the current system shows raw scores with no ranking or comparison.

Use

AskUserQuestion

• "Is this the core problem, or a symptom of a deeper problem?"
• "Who specifically experiences this? How often? What's the cost?"
• "What evidence do we have this problem actually exists?"

1.2 — Root Cause Analysis (for Problem-Solving scenario)

Apply one of:

5 Whys:

Problem: [stated problem]
Why 1: [first cause]
Why 2: [cause of cause 1]
Why 3: [cause of cause 2]
Why 4: [cause of cause 3]
Why 5: [root cause] ← Fix HERE, not at Why 1

Fishbone (Ishikawa) — for systemic problems: Spine = problem statement. Bones = 6 cause categories:

• People, Process, Technology, Data, Environment, Policy
• For each bone: ask "What in this category could cause the problem?"

1.3 — JTBD (Jobs-To-Be-Done) — for New Product & Enhancement

Replace user stories with job stories to expose real motivation:

User Story (what): As a manager, I want to see employee scores, so that I can make decisions.

Job Story (why + context): When I'm preparing for quarterly reviews with limited time, I want to instantly see who deserves promotion without reading every profile, so I can make fair, defensible decisions before the deadline.

Job Story Formula:

When [triggering situation + context],
I want to [motivation / job to be done],
so I can [outcome / expected result].

Generate 3–5 job stories covering main user segments. Each story = one opportunity.

1.4 — HMW (How Might We) Reframing

Transform problem statements into ideation-ready questions:

Formula: "How might we [verb] [object] so that [desired outcome]?"

From the POV statement:

• "How might we help HR managers rank employees so that promotion decisions take minutes not days?"
• "How might we surface hidden top performers so that managers discover talent they'd otherwise miss?"
• "How might we reduce bias in performance scoring so that promotion feels fair to all employees?"

Rules:

• Each HMW covers ONE idea direction
• Generate 5–10 HMW questions per problem
• Too broad = "How might we improve HR?" (useless) → too narrow = "How might we add a sort button?" (skip ideation, just build it)
• Sweet spot: one-concept questions that invite multiple solutions

Output of Phase 1:

• Problem statement (POV format)
• Root cause (5 Whys or Fishbone) — Problem-Solving only
• 3–5 Job Stories
• 5–10 HMW questions

Phase 2: Opportunity Framing — Diamond 1 Converge

Goal: Narrow problem space to the highest-opportunity focus areas before ideating solutions.

2.1 — Opportunity Solution Tree (OST) — for Enhancement

Teresa Torres' framework. Maps desired outcome → opportunities → solutions → experiments.

Desired Outcome (business metric)
├── Opportunity 1 (unmet user need / pain / want)
│   ├── Solution A
│   └── Solution B
├── Opportunity 2
│   ├── Solution C
│   └── Solution D
└── Opportunity 3 (deprioritized)

Step 1: State ONE desired outcome (lagging metric the team owns — e.g., "Increase manager satisfaction with review process from 3.2 to 4.0 CSAT") Step 2: Map ALL known opportunities (pains, needs, wants) from research/interviews Step 3: For each top opportunity, generate solution directions (not detailed solutions yet) Step 4: Pick 1–2 opportunities to develop further in Phase 3

2.2 — Lean Canvas — for New Product

One-page business model for greenfield ideas (Ash Maurya):

Fill one canvas per major target segment. Keep it to 20 min — speed is the point.

2.3 — Blue Ocean ERRC Grid — for Enhancement or New Product

Eliminate-Reduce-Raise-Create grid (Chan Kim & Mauborgne):

Rule: Every innovation should have at least ONE item in Create AND one in Eliminate. A product with only Raise entries is incremental — not differentiated.

2.4 — Value Proposition Canvas

Connects customer profile to product value:

Customer Profile:

• Jobs (functional, social, emotional)
• Pains (frustrations, obstacles, risks)
• Gains (benefits, desires, measures of success)

Value Map:

• Products & Services (what you offer)
• Pain Relievers (how you reduce pains)
• Gain Creators (how you produce gains)

Fit = where Pain Relievers match Pains + Gain Creators match Gains.

Output of Phase 2:

• OST with 2 selected opportunities (Enhancement)
• Lean Canvas (New Product)
• ERRC grid (New Product or Enhancement)
• Value Proposition fit assessment

Phase 3: Ideation — Diamond 2 Diverge

Goal: Generate maximum quantity of solution ideas without judgment. Quality comes in Phase 4.

Critical rule: NO evaluation in this phase. Every idea is valid. "Yes, and..." not "Yes, but..."

3.1 — SCAMPER

Apply each lens to the problem/existing product to generate solution directions:

Generate at least 2 ideas per SCAMPER letter = minimum 14 ideas.

3.2 — Crazy 8s (Rapid Visual Ideation)

Time-box: 8 minutes. 8 ideas. No refinement.

Process:

1. Fold paper into 8 sections (or create 8 boxes mentally)
2. Sketch one idea concept per box — rough is fine
3. Timer forces quantity over perfection
4. Share and build on sketches

For AI-facilitated sessions:

• AI generates 8 distinct solution directions in 2 minutes
• User picks top 3 to explore deeper
• Each direction = 1 sentence + 1 key differentiator

3.3 — Brainwriting 6-3-5

For multi-stakeholder sessions (async-friendly):

• 6 participants, 3 ideas each, 5 rounds
• Each round: read previous ideas → add 3 new ideas OR build on existing
• Result: up to 108 ideas in 30 minutes (works async via shared doc)

For AI-facilitated sessions:

• AI plays all 6 roles across 3 rounds
• Generates ideas from: PO perspective, BA perspective, End User perspective, Dev perspective, Ops perspective, Business perspective

3.4 — Impact Mapping

Gojko Adzic's technique. Maps Goal → Actors → Impacts → Deliverables:

GOAL: [business outcome with measurable target]
├── ACTOR: Who can help/hinder?
│   ├── IMPACT: How should behavior change?
│   │   └── DELIVERABLE: What feature produces this impact?
│   └── IMPACT: What negative behavior to prevent?
│       └── DELIVERABLE: What reduces this risk?
└── ACTOR: ...

Key insight: Work backward from GOAL. If a deliverable doesn't trace to an actor behavior change, don't build it.

3.5 — Analogical Thinking

"How does [industry X] solve [similar problem Y]?"

Output of Phase 3:

• SCAMPER grid with 14+ ideas
• Crazy 8s — 8 solution directions
• Impact Map (top 2 goals)
• Analogy-inspired ideas (3–5)
• Total raw idea count: target 25–40 ideas

Phase 4: Evaluation & Convergence — Diamond 2 Converge

Goal: Reduce 25–40 raw ideas to a ranked shortlist of 3–5 candidates for hypothesis testing.

4.1 — Dot Voting (First Pass)

Before scoring, do a quick gut-check elimination:

• Each idea gets a ✅ (keep) / ❌ (drop) / 🔄 (merge with another)
• Merge near-identical ideas
• Drop ideas that violate hard constraints (budget, tech, legal)
• Target: reduce to 10–15 candidates

4.2 — RICE Scoring

Rank remaining candidates:

RICE Score = (Reach × Impact × Confidence) / Effort

Reach:      Users affected per quarter (100 / 500 / 1000 / 5000+)
Impact:     0.25 minimal | 0.5 low | 1 medium | 2 high | 3 massive
Confidence: 0.5 low (gut feel) | 0.8 medium (some data) | 1.0 high (validated)
Effort:     Story Points — 1 trivial | 3 small | 5 medium | 8 large | 13 very large

Score all 10–15 candidates. Sort descending. Top 5 = shortlist.

4.3 — Kano Model Classification

For each shortlisted idea, classify:

Strategy: Must-Be → Performance → Delighter. Never skip Must-Be items for Delighters.

4.4 — Effort × Impact 2×2

Quick visual triage:

HIGH IMPACT
    │  Quick Wins ★    │  Major Projects ⚙️
    │  (do first)      │  (schedule carefully)
────┼──────────────────┼────────────────────
    │  Fill-Ins 📋     │  Money Pits ⚠️
    │  (if time)       │  (avoid or cut)
LOW IMPACT
         LOW EFFORT         HIGH EFFORT

Plot each shortlisted idea. Quick Wins = default first picks unless Major Project has strategic necessity.

4.5 — MoSCoW for Release Scope

For each idea in the shortlist, assign release priority:

Output of Phase 4:

• Dot-voted shortlist (10–15 ideas)
• RICE-scored table (top 5 ranked)
• Kano classification for each shortlisted idea
• 2×2 matrix placement
• MoSCoW assignment per idea

Phase 5: Hypothesis Validation

Goal: Before committing to build, test your riskiest assumptions. 42% of startups fail because no market need — validate before building.

5.1 — Problem Hypothesis

**We believe** [target users/persona]
**Experience** [specific problem]
**Because** [root cause]
**We'll know this is true when** [validation metric/observable evidence]

Example:

We believe HR Managers
Experience frustration identifying top performers during review cycles
Because scoring data is fragmented across 3 systems with no unified ranking
We'll know this is true when 3+ managers confirm they spend >2hrs per cycle on manual data aggregation

5.2 — Value Hypothesis

**We believe** [feature/solution]
**Will deliver** [specific value/outcome]
**To** [target users]
**We'll know we're right when** [measurable success metric]

5.3 — Riskiest Assumption Test (RAT)

Identify the ONE assumption whose failure kills the idea:

1. List all assumptions: user behavior, technical feasibility, market demand, business model
2. Score each:

   Probability of being wrong (0–1) × Impact if wrong (0–1)

3. Highest score = Riskiest Assumption
4. Design cheapest possible test to validate/invalidate it before full build:
   • User interview (2–3 days)
   • Landing page / fake door test (1 week)
   • Prototype click-through (3–5 days)
   • Concierge MVP (1–2 weeks)
   • Smoke test / pre-sell (2–4 weeks)

5.4 — Build-Measure-Learn Loop

For each top idea, define the loop:

BUILD: Minimum experiment to test the assumption (not a full product)
MEASURE: One metric that proves/disproves the hypothesis
LEARN: What decision do we make if metric is met / not met?
PIVOT: If hypothesis invalidated — which alternative from Phase 3 do we try next?

Output of Phase 5:

• Problem hypothesis card per top-3 idea
• Value hypothesis card per top-3 idea
• Riskiest Assumption identified per idea
• Cheapest test designed
• Build-Measure-Learn loop defined

Phase 6: Decision & Recommendations

Goal: Present a clear, opinionated recommendation with trade-offs. Not "here are all the options" — "here's what we recommend and why."

6.1 — Top 3 Options Table

Present final shortlist as a decision table:

6.2 — Recommendation Statement

RECOMMENDED: [Option Name]

Why: [1–2 sentences on RICE + Kano + strategic fit]
Risk: [Primary risk + mitigation]
First step: [Cheapest test to validate before full commitment]
Time to validation: [Days/weeks]

6.3 — Dependency & Sequencing Check

• Does Option A depend on any existing feature/data/service not yet built?
• Can experiments run in parallel?
• What's the critical path to first validated learning?

Phase 7: Documentation & Handoff

Report Output

Use naming pattern from

## Naming

Create markdown summary report:

# Brainstorm Session Report: [Topic]

## Session Context

- Scenario: [Problem-Solving / New Product / Enhancement]
- Role: [PO / BA / Mixed]
- Date: [YYYY-MM-DD]
- Input: [Original question/problem]

## Problem Statement

[POV format]

## Root Cause Analysis

[5 Whys or Fishbone — if Problem-Solving]

## Job Stories

1. [Job Story 1]
2. [Job Story 2]
3. [Job Story 3]

## HMW Questions

1. How might we...
2. How might we...

## Opportunity Map

[OST or Lean Canvas — per scenario]

## Raw Ideas Generated

[Total count: XX ideas across SCAMPER / Crazy 8s / Impact Mapping]

## Scored Shortlist (RICE)

| Rank | Idea | RICE | Kano | Effort | Priority    |
| ---- | ---- | ---- | ---- | ------ | ----------- |
| 1    | ...  | ...  | ...  | ...    | Must Have   |
| 2    | ...  | ...  | ...  | ...    | Should Have |

## Hypothesis Cards

### Top Recommendation: [Option Name]

- Problem Hypothesis: ...
- Value Hypothesis: ...
- Riskiest Assumption: ...
- Cheapest Test: ...
- Success Metric: ...

## Decision

[Recommendation + rationale]

## Next Steps

- [ ] [First concrete action]
- [ ] [Validation test]
- [ ] [Stakeholder alignment needed]

Technique Quick Reference

Role-Specific Guidance

PO Mode (Outcome Focus)

• Lead with: desired business outcome → opportunities → experiments
• Use: OST, Impact Mapping, RICE, Build-Measure-Learn
• Ask: "What behavior change do we need to see in users?"
• Resist: jumping to features before validating the outcome

BA Mode (Requirements Focus)

• Lead with: stakeholder needs → process gaps → requirements
• Use: BABOK elicitation (interviews, workshops, document analysis), Fishbone, JTBD
• Ask: "What does the system need to do to enable that behavior?"
• Resist: over-specifying before the PO validates the opportunity

Mixed PO + BA Mode

• PO owns: problem statement, opportunity framing, prioritization, hypothesis
• BA owns: requirements elicitation, acceptance criteria, edge cases, process mapping
• Handoff point: after Phase 4 (scored shortlist) → BA writes acceptance criteria per idea

Collaboration Tools

• planner

  agent — research industry best practices for specific domain

• docs-manager

  agent — understand existing feature constraints and domain context

• WebSearch

  — market/competitor context for new product scenarios

• docs-seeker

  skill — latest documentation for external plugins/APIs

• ai-multimodal

  skill — analyze visual mockups, screenshots, competitor UIs

• sequential-thinking

  skill — complex problem decomposition requiring structured causal chains

• web-research

  skill — deep market research for greenfield or competitive analysis

Scenario Cheat Sheets

Scenario A: Problem-Solving

1. POV Statement → 2. 5 Whys / Fishbone → 3. HMW Questions
→ 4. SCAMPER on current solution → 5. RICE scoring
→ 6. Problem Hypothesis + RAT → 7. Recommend + cheapest test

Scenario B: New Product

1. Job Stories (JTBD) → 2. Lean Canvas → 3. Blue Ocean ERRC
→ 4. HMW Questions → 5. Crazy 8s / Brainwriting
→ 6. Kano Classification → 7. Value Hypothesis + RAT → 8. MVP scope

Scenario C: Feature Enhancement

1. Job Stories (JTBD) → 2. Opportunity Solution Tree
→ 3. HMW Questions → 4. SCAMPER on existing feature
→ 5. Impact Mapping → 6. RICE scoring → 7. 2×2 matrix
→ 8. Value Hypothesis + RAT → 9. Recommend + next experiment

Anti-Patterns to Avoid

Critical Constraints

• DO NOT implement solutions — brainstorm and advise only
• DO validate hypotheses before endorsing any approach
• DO prioritize long-term maintainability over short-term convenience
• DO consider both technical excellence and business pragmatism
• DO produce a scored, ranked shortlist — never just a flat idea list
• DO always design the cheapest validation test — RAT before full spec

Workflow Integration

After brainstorm session concludes, use

AskUserQuestion

/idea

idea

/refine

refine

/web-research

web-research

/plan

plan

/design-spec

design-spec

/domain-analysis

domain-analysis

Closing Reminders

• MANDATORY IMPORTANT MUST ATTENTION break work into small todo tasks using

  TaskCreate

  BEFORE starting
• MANDATORY IMPORTANT MUST ATTENTION detect scenario type FIRST — different scenarios use different technique sequences
• MANDATORY IMPORTANT MUST ATTENTION separate diverge (generate) and converge (evaluate) — NEVER mix them
• MANDATORY IMPORTANT MUST ATTENTION write a hypothesis card for every top-3 recommendation
• MANDATORY IMPORTANT MUST ATTENTION design cheapest validation test before recommending full implementation
• MANDATORY IMPORTANT MUST ATTENTION cite evidence for every claim — confidence >80% to recommend
• MANDATORY IMPORTANT MUST ATTENTION use

  AskUserQuestion

  for all user decisions — never auto-decide
• MANDATORY IMPORTANT MUST ATTENTION add a final review todo task to verify work quality <!-- SYNC:critical-thinking-mindset:reminder -->
• MUST ATTENTION apply critical thinking — every claim needs traced proof, confidence >80% to act. Anti-hallucination: never present guess as fact. <!-- /SYNC:critical-thinking-mindset:reminder --> <!-- SYNC:ai-mistake-prevention:reminder -->
• MUST ATTENTION apply AI mistake prevention — holistic-first debugging, fix at responsible layer, surface ambiguity before coding, re-read files after compaction. <!-- /SYNC:ai-mistake-prevention:reminder -->