brainstorm

---
name: brainstorm
type: workflow
description: "Facilitates structured product ideation to define user needs, core value, and product direction. Use when the user wants to explore a new product idea, has a vague concept to develop, or mentions brainstorming or ideation."
argument-hint: "[product type or problem hint, or 'open' for fully open brainstorm]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, WebSearch, AskUserQuestion
context: fork
agent: product-manager
effort: 3
when_to_use: "When starting a new product idea from scratch or needing structured creative ideation for a product concept"
---

When this skill is invoked:

1. **Parse the argument** for an optional product type or problem hint (e.g., `productivity app`,
   `API service`, `developer tool`, `marketplace`). If `open` or no argument, start from scratch.

2. **Check for existing concept work**:
   - Read `design/docs/product-concept.md` if it exists (resume, don't restart)
   - Read `design/docs/product-pillars.md` if it exists (build on established pillars)

3. **Run through ideation phases** interactively, asking the user questions at
   each phase. Do NOT generate everything silently — the goal is **collaborative
   exploration** where the AI acts as a product thinking facilitator, not a
   replacement for the human's vision.

   **Use `AskUserQuestion`** at key decision points throughout brainstorming:
   - Constrained taste questions (product type, target users, scope)
   - Concept selection ("Which 2-3 concepts resonate?") after presenting options
   - Direction choices ("Develop further, explore more, or start sprint planning?")
   - Pillar ranking after concepts are refined

   Write full analysis in conversation text first, then use `AskUserQuestion`
   to capture the decision with concise labels.

   Professional product brainstorming principles to follow:
   - Withhold judgment — no idea is bad during exploration
   - Encourage unusual ideas — outside-the-box thinking sparks better products
   - Build on each other — "yes, and..." responses, not "but..."
   - Use constraints as creative fuel — limitations often produce the best ideas
   - Time-box each phase — keep momentum, don't over-deliberate early

---

### Phase 1: Creative Discovery

Start by understanding the person and their context, not the product. Ask these questions
conversationally (not as a checklist):

**Problem anchors**:
- What's a frustrating problem you personally experience that no existing tool solves well?
- Is there a workflow, process, or task you've always wished was easier or more automated?

**Experience profile**:
- What 3 products (apps, tools, APIs, services) do you use most? What keeps you coming back?
- Are there product categories you love or actively avoid? Why?
- Do you prefer products that save time, reduce complexity, enable creativity, or connect people?

**Practical constraints** (shape the sandbox before brainstorming):
- Solo developer or team? What skills and resources are available?
- Timeline: weeks (MVP), months (v1), or years (full product)?
- Any platform constraints? (Web only? Mobile? API-first? Desktop?)
- First product or experienced builder?
- Revenue model in mind? (SaaS, open source, freemium, one-time purchase?)

**Synthesize** the answers into a **Product Brief** — a 3-5 sentence
summary of the person's goals, experience context, and constraints.
Read the brief back and confirm it captures their intent.

---

### Phase 2: Concept Generation

Using the product brief as a foundation, generate **3 distinct concepts**
that each take a different creative direction. Use these ideation techniques:

**Technique 1: Verb-First Design**
Start with the core user verb (build, track, automate, connect, analyze, manage,
discover, share, deploy) and build the product outward from there. The verb IS the product.

**Technique 2: Problem-Inversion Method**
Take an existing frustration in a market and invert it. "What if [pain point] just...
didn't exist?" Then design backward from that ideal state. Find the simplest product
that bridges the current reality to that ideal.

**Technique 3: Intersection Design**
Combine two unexpected domains: [Audience A] + [Workflow B]. The intersection creates
the unique hook. (e.g., "developers + financial compliance", "designers + data pipelines",
"small teams + enterprise security")

For each concept, present:
- **Working Title**
- **Elevator Pitch** (1-2 sentences — must pass the "10-second test")
- **Core User Action** (the single most frequent thing a user does)
- **Core Value Promise** (the outcome users pay/sign-up for)
- **Unique Angle** (passes the "AND ALSO" test: "Like X, AND ALSO Y")
- **Target User** (who specifically? Not "developers" — "backend engineers at 50-person startups")
- **Estimated Scope** (small / medium / large)
- **Why It Could Work** (1 sentence on market/timing fit)
- **Biggest Risk** (1 sentence on the hardest unanswered question)

Present all three. Ask the user to pick one, combine elements, or request
new concepts. Never pressure toward a choice — let them sit with it.

---

### Phase 3: Core User Flow Design

For the chosen concept, use structured questioning to build the core user flow.
The core flow is the beating heart of the product — if it isn't valuable in
isolation, no amount of features or polish will save the product.

**First-Use Flow** (the critical first 5 minutes):
- What's the first action a new user takes?
- When do they first experience value? (The "aha moment")
- What friction exists between sign-up and first value? How to minimize it?

**Core Usage Loop** (the repeating cycle):
- What does a typical usage session look like from start to finish?
- What triggers the user to open/use the product? (External trigger? Internal habit?)
- What output or result makes the session feel successful?

**Retention Hook** (why they come back):
- What makes users return daily / weekly?
- What accumulates over time that makes the product more valuable? (Data? History? Network?)
- What does the product feel like after 30 days vs. day 1?

**Growth Loop** (how it spreads):
- Does using the product naturally lead to sharing or inviting others?
- What's the viral or referral mechanic (if any)?

**User Motivation Analysis** (based on Self-Determination Theory):
- **Autonomy**: How much meaningful control does the user have over outcomes?
- **Competence**: How does the user feel more capable or skilled over time?
- **Relatedness**: How does the user feel connected (to team, community, or their work)?

---

### Phase 4: Pillars and Boundaries

Product pillars are used by top companies (Notion, Linear, Stripe, Figma) to align
teams around a single product vision. Even for solo builders, pillars prevent
scope creep and keep decision-making fast and consistent.

Collaboratively define **3-5 pillars**:
- Each pillar has a **name** and **one-sentence definition**
- Each pillar has a **design test**: "If we're choosing between feature X and Y,
  this pillar says we build __"
- Pillars should create productive tension — if all pillars agree on everything,
  they're not doing enough work

Then define **3+ anti-pillars** (what this product is NOT):
- Anti-pillars prevent the most common form of scope creep: "wouldn't it be cool if..."
  features that dilute the core value
- Frame as: "We will NOT build [thing] because it would compromise [pillar]"

---

### Phase 5: User Segment Validation

Using Jobs-to-be-Done and user motivation frameworks, validate who this product is for:

- **Primary user segment**: Who will LOVE this product? Be specific — role, company size,
  workflow context, pain level
- **Secondary appeal**: Who else might find value in it?
- **Who is this NOT for**: Being clear about who won't benefit is as important as knowing
  who will — it prevents building for everyone and delighting no one
- **Market validation**: Are there successful products serving adjacent user needs?
  What can we learn from their growth path?
- **Willingness to pay**: Is this a "must have" or "nice to have" for the target user?

---

### Phase 6: Scope and Feasibility

Ground the concept in reality:

- **Tech stack recommendation** — Language, Framework, Database, Cloud provider — with
  reasoning based on the concept's requirements, team expertise, and scalability needs
- **Build vs. Buy decisions** — auth (Clerk/Supabase/custom?), payments (Stripe?),
  search (Algolia?), email (SendGrid?), analytics (PostHog?)
- **MVP definition** — the absolute minimum feature set that validates:
  "Does this solve the user's pain better than what they use today?"
- **Infrastructure scope** — monolith vs. microservices, serverless vs. dedicated,
  multi-tenant vs. per-customer
- **Biggest risks** — technical risks, design risks, market risks, regulatory risks
- **Scope tiers**:
  - **MVP** (weeks): Validates core hypothesis with minimum code
  - **v1** (months): Shippable, complete product for early adopters
  - **Full vision** (beyond): What it becomes if successful
---

### Phase 7: Architectural Pre-flight (The 21 Questions)

Before finalizing, challenge the concept using this 6-dimension framework. Identify the top 3-5 critical blind spots the team must resolve before coding. *(If you don't understand the business, you're just a diagram maker.)*

- **A. Business:** What problem are we solving? Who are the real users? What does success look like? What are the hard constraints (budget, timeline, regulation)?
- **B. Functional:** Core features? Critical user journeys? External system plug-ins? Key background workflows? *(Clarity here is cheap. Rework later is expensive.)*
- **C. Non-Functional:** Availability/uptime? Performance/latency targets? Security/compliance? Growth capacity? *(Systems fail when NFRs are treated as footnotes.)*
- **D. Integration:** Number of systems in ecosystem? Communication (real-time, event-driven, batch)? Existing APIs vs. build from scratch? *(Integration complexity is always underestimated.)*
- **E. Data:** Data kind/type? Volume and growth rate? Privacy/regulatory concerns (PII/GDPR)? *(Data decisions are hardest to reverse.)*
- **F. Operational:** Monitoring and logging strategy? Deployment and release strategy? Who owns support/maintenance? *(A system no one can operate is a system waiting to collapse.)*

---

4. **Generate the product concept document** using the template at
   `.claude/docs/templates/product-concept.md`. Fill in ALL sections from the
   brainstorm conversation, including the user motivation analysis, value proposition,
   and flow design sections.

5. **Save to** `design/docs/product-concept.md`, creating directories as needed.

6. **Suggest next steps** (in this order — this is the professional product
   pre-production pipeline):

   - "Run `/design-review design/docs/product-concept.md` to validate completeness"
   - "Refine concept and pillars with the `product-manager` agent"
   - "Discuss technical approach with `cto` and `technical-director`"
   - "Decompose the concept into systems and APIs with `/map-systems`"
   - "Design the core API with `/api-design`"
   - "Prototype the core flow with `/prototype [core-feature]`"
   - "Validate the prototype with `ux-researcher` before full build"
   - "Plan the first sprint with `/sprint-plan new`"

7. **Output a summary** with:
   - Chosen concept elevator pitch
   - Product pillars (names only)
   - Primary target user
   - Tech stack recommendation
   - MVP definition (1 sentence)
   - Biggest risk
   - File path of saved concept doc

## Protocol

- **Question**: Phase 1 uses AskUserQuestion at every discovery step (problems, experience, constraints)
- **Options**: Phase 2 presents 3 distinct concepts via Verb-First, Problem-Inversion, Intersection techniques
- **Decision**: User picks concept, confirms pillars, user segments, scope tier, and tech stack
- **Draft**: Concept document shown in conversation before saving
- **Approval**: "May I write to `design/docs/product-concept.md`?"

## Output

Deliver exactly:

- **Concept document** saved to `design/docs/product-concept.md`
- **Elevator pitch** — 1 sentence
- **MVP definition** — 1 sentence
- **Biggest risk** — 1 item
- **Next skill** — `/map-systems` (if concept approved) or `/prototype [core-feature]`