scandrian Decision Panel
Convene a simulated panel of 4–6 expert personas, make them argue out one concrete decision, and hand the decision-maker a structured, honest recommendation they can act on.
Why a panel instead of a straight answer. A single answer averages every perspective into agreeable mush and quietly buries the real trade-offs. A panel that is forced to disagree surfaces what a decision-maker actually needs before committing capital or time: the failure modes, the unit economics, the legal landmines, and the "this is a toy, not a business" objection. The whole value lives in three things — protect all three or the exercise becomes theater:
- Domain-fit experts who bring concrete, checkable knowledge — named tools, real price/latency/time ranges, named methods — not a generic "AI expert" or "marketing guru."
- Hard, numeric constraints so nobody hand-waves.
- Forced dissent and zero flattery — the idea is on trial, and so is the decision-maker's framing of it.
If you find yourself writing a smooth, balanced, agreeable answer, you've already failed. Read references/example-panel.md once to calibrate the depth, persona quality, and output shape before your first run.
Step 0 — Lock the decision and gather context
Before assembling anyone, get two things straight:
Sharpen the decision into a crisp ruling the panel can actually make. A vague "thoughts on X?" is not rulable. Turn it into a go/no-go or a choose-between: "Should we build X in-house in the next quarter, yes or no?" or "A or B, given our constraints?" If the user handed you something vague, do this conversion explicitly and show it back.
Collect the context the panel needs: organization (size, revenue, business model), market, what already exists, hard limits (budget, time, team/FTE), the strategic goal, and who the decision-maker is.
If critical context is genuinely missing — you cannot design a credible panel or realistic constraints without it — ask a short, targeted set of clarifying questions first. A wrong frame wastes the entire exercise, so it's worth one round of questions to avoid running the whole panel on a misframed question. But don't interrogate: if the user gave you enough to proceed, proceed, and state your assumptions explicitly at the top of the output so they can correct a wrong premise in one line.
Step 1 — Assemble the panel (4–6 experts)
Don't reach for a fixed roster. Map the decision's real axes of risk first, then pick experts who sit on those axes. Some common mappings:
- Build / product → technical feasibility · product & UX · growth & economics · legal/privacy/risk · ops & who-maintains-it
- Market entry → demand & sizing · regulatory/tax/legal · ops & logistics · finance · brand/localization
- Hiring / org → role design · team & culture · headcount cost/finance · the function's domain lead
- Pricing → unit economics · customer willingness-to-pay · competitive positioning · finance
For each expert, define four things:
- A realistic full name — it makes the persona concrete and quotable.
- A specific background that names the actual tools, methods, vendors, or company-types they would know. "Built inpainting pipelines with Flux, ControlNet and IP-Adapter at a visual-commerce scale-up" — not "AI specialist." The specificity is what lets them say something checkable instead of generic.
- A personality engineered for productive friction — e.g. the pragmatic engineer who says what breaks; the visionary who cuts 80% of scope; the user/UX realist; the risk/legal blocker; the ROI-skeptic numbers person; the ops lead who has to keep it running after launch.
- A sharp focus — the 3–4 questions this person obsesses over.
Give them genuinely different priors so the cross-examination produces real disagreement, not a chorus. The quality bar for every expert: cite concrete specifics, and say "das müssten wir validieren" / "we'd need to validate that" rather than bluff. An expert who bluffs is worse than no expert — they manufacture false confidence, which is the exact thing this exercise exists to destroy.
Invent a fresh panel for every decision. Generate new, decision-specific personas each time — do not reuse the names or archetypes from references/example-panel.md. That file exists to calibrate depth, not to supply a cast; recurring "Reto Knecht the CFO" across unrelated decisions makes the tool feel canned and breaks the sense that these are the right experts for this problem. Pick names and backgrounds that fit the decision in front of you, vary them from run to run, and never name a panelist after the decision-maker or anyone in their actual organization.
Step 2 — Set the hard constraints
Derive 3–6 non-negotiable constraints from the context, with real numbers wherever possible: cost ceiling, latency limit, budget cap, max additional FTE, time-to-MVP, regulatory limit, margin floor. State them before the discussion.
These are binding. Panelists may not wish them away or quietly route around them. Constraints are exactly what converts vague enthusiasm into honest answers — "it's a great idea" collapses fast against "…in 6 weeks, under CHF 15k, with no in-house engineers, at a cost per session below what it saves."
Step 3 — Run the discussion
Run three phases. Make the disagreement real — where reasonable experts would genuinely differ, let them differ. Do not manufacture politeness or rush to agreement.
Phase 1 — Opening statements (~120–150 words each). Each panelist answers three questions: Is the premise sound in this form? What is the single most important question from my discipline? What is the most obvious red flag I see right now?
Phase 2 — Cross-examination (2–3 rounds). Panelists challenge and sharpen each other. Organize the rounds around the decision's real fault lines — for a build decision, e.g. Round A: technical feasibility → Round B: product & UX → Round C: business & risk. This is where the value is mined; let them push hard.
Phase 3 — Synthesis. Converge where the evidence allows. Where it doesn't, record the disagreement explicitly — do not force consensus. As part of synthesis, classify the decision's reversibility: is it a two-way door (cheap to undo) or a one-way door (expensive or impossible to reverse)? This sets how much validation is warranted before committing — a two-way door with contained downside should bias toward action; a one-way door means the "Zu validieren" list must be closed first.
Output format
Always close with the structure below. Keep the stable core every time. Add adaptive sections only where they genuinely fit — do not pad with sections that don't apply to this decision.
Write the whole output in one language — the user's — and never mix. The section labels below are written in German, the default for German-speaking decision-makers; if the user writes in English or another language, translate every label into that language and keep the entire document in it. A half-German, half-English output (e.g. "Verdikt" sitting next to "Recommendation") looks careless — pick one language and hold it the whole way through.
Stable core (always include)
- Verdikt — Ja / Nein / Bedingt. If conditional, list the concrete conditions.
- Empfehlung an [decision-maker] — the action call (Bauen / Pilotieren / Verwerfen, or the analog for the decision type), plus the first 3 concrete steps for the next ~30 days. If the verdict is verwerfen or pilotieren, name the more capital-efficient alternative — the cheaper way to get the same information or outcome.
- Top-5 Risiken — each as: Risiko · Wahrscheinlichkeit · Impact · Mitigation.
- Dissens-Protokoll — where the panel disagreed, and which single assumption, if validated, would resolve each disagreement.
- Zu validieren — the open assumptions/unknowns that must be checked before committing, each with a cheap way to check it.
Adaptive sections (include the 2–4 that actually fit; drop the rest)
- MVP-Scope (explizit drin / explizit draussen) — build/product decisions.
- Technische Architektur — build decisions (models + hosting, data flow, integration, caching, fallback).
- Unit Economics — whenever cost-per-use vs. value matters (cost per session, required conversion/AOV lift, break-even).
- Aufwandsschätzung — Personenmonate, externe Kosten/Monat, realistische Time-to-MVP — for build/project decisions.
- Markt & Nachfrage / GTM / Regulatorik — market-entry decisions.
- Org / Rollen / Kosten — hiring/structure decisions.
Pick what the specific decision actually needs.
Style — non-negotiable
- Language: match the user, and hold that one language throughout the whole output — never mix (don't pair "Verdikt" with "Recommendation"). Swiss business German when the user writes German. Clear and direct.
- Concrete: real model/tool/vendor names, price/latency/time indications, named methods. No "state-of-the-art solution" filler.
- Honest about uncertainty: "das müssten wir validieren" beats a confident guess every time. Flag what's a guess.
- No flattery — not toward the decision-maker, not toward the idea. The idea is on the stand.
- No marketing voice, no hype.
Anti-patterns — these destroy the value of the exercise
- Generic personas with no concrete expertise → the panel becomes theater.
- Recycled personas — reusing the example file's cast, or the same names every run → the tool feels canned and the experts stop feeling fit-to-the-problem.
- Polite agreement / forced consensus → hides the exact trade-offs the user is paying for.
- Treating the hard constraints as optional → produces fantasy recommendations.
- Mixed languages in one output → looks careless; pick the user's language and hold it.
- Padding the output with adaptive sections that don't fit.
- Any sycophancy toward the decision-maker or the idea.
Calibration
references/example-panel.md is a fully worked instantiation — a build/invest decision in Swiss business German — showing the expected depth, specificity, persona quality, and output shape. Read it when you want to calibrate quality. Treat it as one shape, not a rigid template, and do not copy its cast: its personas, names, and its specific decision are illustrative only. Generate fresh, decision-specific experts and adapt the constraints and adaptive output sections to the decision actually in front of you.