Brainstorming

⚠️ CRITICAL RULES - READ FIRST

1. READ CONSTITUTION: Always read docs/reference/pm/constitution.md first for product context
2. ONE QUESTION AT A TIME: Never ask multiple questions in one message
3. USE MULTIPLE CHOICE: Prefer AskUserQuestion tool with 2-4 options

Language Configuration

Before generating any content, check aico.json in project root for language field to determine the output language. If not set, default to English.

Process

1. Check context: Scan docs/reference/pm/ for existing product context
2. Understand problem: Ask clarifying questions one at a time
3. Explore alternatives: Propose 2-3 approaches with trade-offs
4. Validate concept: Present ideas in small sections (200-300 words), confirm each
5. Document outcome: Save validated concept for next steps

Core Pattern

| Phase | Action | Output | | ---------- | -------------------------------------- | ----------------- | | Understand | Ask clarifying questions one at a time | Problem statement | | Explore | Propose 2-3 approaches with trade-offs | Selected approach | | Validate | Present concept in small sections | Validated concept |

Key Rules

• ALWAYS ask ONE question per message - never overwhelm with multiple questions
• MUST prefer multiple choice over open-ended questions when possible
• ALWAYS explore 2-3 alternative approaches before settling on one
• Present ideas incrementally in 200-300 word sections, confirm each before continuing

Question Examples

• "What problem are you trying to solve for users?"
• "Who is the primary user for this feature?"
• "What does success look like? (A) metric improvement (B) user satisfaction (C) both"

Common Mistakes

• ❌ Ask multiple questions at once → ✅ One question per message
• ❌ Jump to solutions immediately → ✅ Understand problem first
• ❌ Skip alternatives → ✅ Always explore 2-3 approaches

---

Iron Law

NO IMPLEMENTATION DISCUSSION DURING BRAINSTORMING

This rule is non-negotiable. During brainstorming:

1. Focus only on WHAT, never HOW
2. No code, no architecture, no technical details
3. Capture all ideas without judgment
4. Defer feasibility analysis to later phases

Rationalization Defense

| Excuse | Reality | | -------------------------------------------- | ---------------------------------------------- | | "I already know what to build" | Unvalidated assumptions cause 3x rework | | "Let's save time and discuss implementation" | Premature optimization kills innovation | | "The solution is obvious" | Obvious solutions often miss edge cases | | "We don't have time for this" | 1 hour of brainstorming saves 3 days of rework |