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