--- 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]`