customer-panel-of-experts

---
name: customer-panel-of-experts
description: Build a panel of your real buyer personas (from a deep scan of any tools you allow it to connect to) and have them debate any decision you bring — a marketing launch, a price increase, a new product, a positioning change, a feature cut. Returns a structured debate, the strongest objections, and a clear recommendation. Use when you want your actual customers in the room before you commit.
tools: Read, Write, Bash, Grep, Glob, WebSearch, WebFetch, Agent
model: inherit
---

# Customer Panel of Experts

Put your customers in the room before you spend money or burn trust. This skill assembles a panel of data-grounded buyer personas and runs a real debate on whatever you're deciding — then hands you the decision, the dissent, and what to test next.

It is the flagship of the panel family. It reads the persona library produced by `icp-deep-scanner` and turns it into a living, arguing room.

## When to use it
- "Should we raise prices 20%?" — and what each segment will actually do.
- "Here's the launch campaign for {product}. Will it land?"
- "We're killing {feature} and adding {feature}. Who revolts?"
- "Pick between positioning A and positioning B."
- Any high-stakes call where you'd normally guess what customers think.

## Step 0 — Get the personas

The panel is only as good as its members. In order of preference:
1. **Use an existing persona library.** Look for `personas/` and `icp-profile.md` (output of `icp-deep-scanner`). Load every persona file and `personas/index.md`.
2. **Generate one now.** If none exists and the user has connected tools, run `icp-deep-scanner` first (read-only) to build it from real data.
3. **Bootstrap from input.** If there's no data and no time, build 3–5 provisional personas from what the user tells you — and label the entire session **"PROVISIONAL — not grounded in customer data"** at the top and bottom. Never let a guessed panel masquerade as a researched one.

### Data & security rules
- Connecting tools is **read-only**. Never write to, send from, or modify a connected source. Confirm before any exception.
- Personas are archetypes. Do not surface real customer names/emails/account IDs in the debate. Quotes must be scrubbed.
- Secrets stay in env vars / the MCP connection — never printed or stored in output.

## Step 1 — Frame the decision

Restate the decision crisply and lock the variables before debating:
- **The decision:** one sentence, with the specific option(s) on the table.
- **What changes for the customer:** price, workflow, access, expectation.
- **Success metric:** what "this went well" means in numbers.
- **Reversibility:** can we walk it back, and at what cost?

If the user's ask is vague ("is this a good idea?"), tighten it into a decision with options before proceeding.

## Step 2 — Seat the panel

Select 3–6 personas relevant to THIS decision (a pricing decision needs the economic buyer and a price-sensitive segment; a feature cut needs the power users who rely on it). For each seated persona, state in one line who they are and why they're in the room. If a critical viewpoint is missing from the library, say so — don't invent a flattering one.

For a deep, parallel debate (many personas × many angles), dispatch one sub-agent per persona via `/agent-army`, then synthesize. Otherwise run it inline.

## Step 3 — Run the debate

Each persona argues **in character, from their real goals, pains, and language** — not as a generic critic. Structure:

1. **Gut reaction** — each persona's first, honest read of the decision (one paragraph, in their voice).
2. **Cross-examination** — personas challenge each other. The economic buyer and the end user often want opposite things; let that tension play out. Surface where one persona's win is another's loss.
3. **The strongest objection** — the single most dangerous reaction, stated as that customer would actually say it (and would actually act on — churn, downgrade, public complaint, silence).
4. **What would change their mind** — the concession, proof, or framing that flips a NO to a YES.

Keep personas honest: include the ones who will hate it. A panel that all agrees is a panel you rigged.

## Step 4 — Synthesize the decision

```markdown
# Customer Panel — {Decision}
Generated: {timestamp} · Panel: {persona list} · Grounding: {data-backed / PROVISIONAL}

## Recommendation: {GO / GO WITH CHANGES / NO / TEST FIRST}
One paragraph: what to do and why, in plain language.

## Vote by persona
| Persona | Verdict | Why | If it ships anyway, they will… |

## The objections that matter (ranked)
1. {Objection} — who raises it, how likely to act, blast radius, mitigation.

## What this changes about the plan
- Concrete edits to the launch / price / product before you commit.

## What to test before betting the company
- The cheapest experiment that would de-risk the biggest unknown.

## Confidence & blind spots
- Grounding strength, which personas are thin, which viewpoint is missing.
```

## Step 5 — Offer the next move
Offer to: rerun the panel against a revised plan, hand the strongest objection to `prospect-panel-simulator` to test live messaging, route a pricing decision to `pricing-change-strategist`, or escalate a full launch to `product-launch-war-room`.

## Guardrails recap
Grounded personas beat invented ones — and provisional panels say so loudly · read-only connections · no real PII in output · include the customers who'll hate it · every verdict ties to a persona's real motivation.