Think Tank

/think-tank

A pre-planning skill that simulates a moderated expert debate to surface trade-offs, blind spots, and perspectives before committing to a plan. Inspired by real think tanks: the output is NOT a single answer but a structured analysis of approaches, trade-offs, and consensus points that helps the human make a better-informed decision. For open-ended idea generation rather than a decision, use brainstorming.

Why This Exists

When facing architectural, strategic, or design decisions, a single perspective (even a well-informed one) tends to gravitate toward conventional wisdom and miss important trade-offs. A think tank forces consideration of multiple angles -- technical, organizational, philosophical -- before planning begins. The result is plans that account for more of reality.

How It Works

The think tank uses multiple personas debating within a single context -- not separate agents. This keeps all perspectives aware of each other's arguments, enables real-time synthesis, and produces a coherent output. The personas argue, concede points, build on each other's ideas, and occasionally surprise everyone (including the user).

Running the Think Tank

Phase 1: Frame the Decision

Before assembling the panel, clearly understand what is being decided. Ask the user (if not already clear):

1. What is the decision or problem? (e.g., "monolith vs microservices for a new e-commerce platform")
2. What constraints exist? (team size, timeline, budget, existing systems, regulatory)
3. What has already been tried or considered? (avoid rehashing known ground)
4. What would a successful outcome look like? (helps the panel focus)

Restate the problem back to the user in a crisp problem statement before proceeding. This ensures the think tank debates the right question.

Phase 2: Assemble the Panel

Build a panel of 4-6 personas. The composition matters -- diversity of perspective is the whole point.

Panel structure:

• 1 Moderator -- a knowledgeable, neutral figure who keeps the debate focused, synthesizes, and pushes for clarity. Pick someone known for balanced analysis in the relevant domain. The moderator opens and closes the session, asks provocative follow-up questions, and calls out when panelists are talking past each other.

• 2-3 Domain voices -- people (real or fictional) with known, distinct positions on the topic. These are the core debaters. They should genuinely disagree on something substantive -- not just have mild preferences. Ask: who would advocate strongly for approach A, and who would push back hardest? Look for different schools of thought, not different levels of enthusiasm for the same idea.

• 1 Wildcard / outside thinker -- someone who has not written directly about this topic but brings transferable wisdom from another domain. This is where the unexpected insights come from: a management theorist in a technical debate, a philosopher in a product discussion, a novelist in an architecture review. The wildcard prevents the conversation from being too predictable.

• 1 Practitioner voice (optional) -- someone who has actually done the thing at scale, in production, with real users. Keeps the debate grounded.

Persona guidelines:

• Use real, named figures when possible -- richer, more differentiated responses come from inhabiting a specific person vs a generic "senior engineer."
• Personas speak in first person, in their authentic voice. Martin Fowler is thoughtful and measured. DHH is direct and opinionated. Peter Drucker asks questions that reframe the problem.
• Fictional characters are fine for the wildcard slot. They add variety.
• If the user suggests specific panelists, use them. If not, propose a panel and let the user approve or adjust before proceeding.

Phase 3: Run the Debate

Structure the debate as a moderated discussion, not a series of independent monologues. The personas respond to each other, not just state their positions in isolation.

The user is a participant, not a spectator. The user sits at the table -- the moderator and panelists address them directly, ask them questions, and incorporate their answers into the ongoing debate. The user is the decision-maker; the panel is there to serve them.

Debate structure:

1. Opening statements (~1 paragraph each) -- each panelist states their initial position. Keep these concise; the real value comes from the interaction.

2. First check-in with the user -- after opening statements, the moderator pauses and turns to the user: "Did any of these opening positions surprise you, or miss something important about your situation?" This is a real pause -- wait for the user's response and feed it back into the debate. If the user reveals something (e.g., "we only have 2 developers"), the panelists react and adjust their arguments.

3. Moderated discussion (2-4 rounds) -- the moderator poses focused questions: "What's the strongest argument against your own position?", "Where do you two actually agree, and where does the disagreement really lie?", "What would change your mind?", "What's the risk we're not talking about?", "How does this look at 10x scale? At 0.1x scale?"

4. Panelists can question the user directly. When a panelist needs more context to argue effectively, they turn to the user (e.g., "How experienced is your team with distributed systems?"). Pause the debate, wait for the answer, then resume with panelists reacting to the new information. This back-and-forth is where the real value lies.

5. Wildcard interjection -- the outside thinker offers a reframing or analogy from their domain. This often shifts the conversation in productive ways.

6. Second check-in with the user -- before converging: "Is there anything you feel we haven't addressed? Has anything changed how you're thinking about the problem?"

7. Convergence check -- the moderator identifies points of genuine consensus, the real axis of disagreement (often narrower than it first appeared), and conditions under which each approach wins ("If X is true, do A; if Y is true, do B").

Tone guidelines:

• Argue substantively with evidence, examples, analogies -- not just opinions.
• Allow personas to change position if persuaded; that is a sign of a good debate.
• The moderator pushes back on vague claims: "Scalable in what dimension?"
• High energy, respectful. Real intellectual disagreement, not performative conflict.
• Address the user directly and genuinely -- not deferentially.

Phase 4: Produce the Output

After the debate, produce a structured summary. This is what feeds into planning:

## Think Tank Summary: [Problem Statement]

### Panel
[Panelists and their roles/perspectives]

### Key Debate Highlights
[2-3 of the most illuminating exchanges, including moments where user input changed the direction]

### User-Revealed Context
[Constraints, preferences, or realities the user shared that shaped the panel's thinking]

### Consensus Points
[Things all or most panelists agreed on -- high-confidence inputs to planning]

### Core Trade-offs
[The real axes of disagreement, stated as trade-offs: choosing X gives you [...] but costs you [...]]

### Conditional Recommendations
[If [condition], then [approach] because [reasoning]]

### Risks & Blind Spots
[Under-discussed or easy-to-overlook items]

### Open Questions
[What needs more information or experimentation to resolve]

### Suggested Next Steps
[Concrete things to research, prototype, test, or decide before planning]

Phase 5: Hand Off to Planning

After presenting the summary, ask: "Does this capture the key considerations? Which trade-offs feel most important to your situation? Ready to move into planning, or dig deeper on any point?"

The think tank output is input to the plan -- not the plan itself. The human makes the decision; the think tank provides the analysis.

Tips for Better Think Tanks

• Prime the context first. If relevant documents, code, or diagrams exist, have the user share them before running the think tank.
• Don't over-specify the panel. Suggesting panelists often surfaces relevant experts the user would not have thought of.
• Run multiple rounds if needed. Reconvene the panel (or a subset) for focused follow-ups.
• Use the wildcard aggressively. Don't let them be polite; have them challenge assumptions.
• The summary is the deliverable. The debate is entertaining; the structured summary is what improves planning. Make it sharp and actionable.

Usage

/think-tank $ARGUMENTS