Skills/Product management/Expert council debate

Expert council debate: four to six lenses, real disagreement, one committed answer

A structured debate method where the lenses are disciplines and published frameworks rather than people, divergence is the output, and the synthesis has to commit to one path anyway.

Not yet measured skill 3,574 words MIT by Locul Verified safe · 0 secrets Written 2026-08-19
No account, no install, nothing to sign up for. Copy it or download it and it works in Claude Code today. One-click import lands here shortly.
We have not measured this skill. There is no result on this page because we have not run one. It is written, it has been read for accuracy, and it is free to take. Nothing below claims it improves an output, because we have not shown that. This is different from a skill that failed our test: those are not published at all.
What it is, and what we are not claiming

Untested. The asset is the tier-weighting rule and the instruction to commit to one path after the disagreement is on the table.

We have not measured this one. It is published because the method is specific and checkable, not because it beat a run without it.

The first thing to know is what it is not. The multi-perspective format is common, and the common version is a roster of named practitioners speaking in the first person. This does not do that, and the refusal is deliberate rather than cautious. The lenses here are disciplines paired with published frameworks: the positioning lens applying a competitive-alternatives framework, the pricing lens applying a value-metric framework, the retention lens applying a cohort-curve framing. A named person's actual view shifts with the decade and the context, and nobody can check what they would have said about your situation. A published framework has written mechanics, so a lens built on it can be applied correctly, applied badly, or shown not to fit.

What it knows, concretely. First, a tier-weighting rule tied to the altitude of the question: three tiers of lens, and a fixed composition for strategic, operational and tactical decisions, because Tier 1 lenses aimed at a tactical question re-litigate strategy in a way that feels profound and answers nothing.

Second, a three-bucket debate in which divergence is the deliverable rather than a defect, plus a typology for what the divergence is actually about: a fact, a time horizon, a risk tolerance, or a definition of success. Each type has a different correct response and only one of them is a research task.

Third, an extrapolation-flagging rule with fixed wording, and a commit-anyway instruction at synthesis, which is the thing that stops multi-perspective output collapsing into "it depends".

Who it is not for. Anyone facing a reversible decision, where this is slower than deciding. Anyone who wants a specific practitioner simulated. And anyone who will read a preserved tension as the skill having failed to answer.

When to reach for it

  • When a decision has been discussed three times and moved zero times, which is what an unnamed disagreement about risk tolerance looks like from the outside.
  • Immediately before an irreversible commercial change such as switching the pricing metric or hiring the first salesperson, at the point where being wrong costs a year rather than a sprint.
  • When everyone in the room agrees quickly and nobody has said what would have to be true for the plan to fail.
  • When you are the only senior person on a decision and there is nobody whose job it is to disagree with you.
  • When two credible advisers have given opposite advice and you need the disagreement mapped rather than averaged.

Why there is no number on this page

Measuring one skill honestly costs about twenty model sessions: five runs with it, five without, on real material, each output graded alone by a session that is not told the other arm exists, against a rubric written by somebody who never saw the skill. We have not spent that on this one yet, so it ships labelled rather than ships silently.

How it would be measured. Tier B with a partial objective spine. Six invented decision briefs spread across the three altitudes, two of them deliberately underspecified so the correct move is to ask questions or split the question rather than convene; mechanically checkable are whether the lens count is between four and six, whether the composition matches the altitude rule, whether each block contains all five required parts, whether the divergence bucket is non-empty and each divergence is typed, whether exactly one committed recommendation exists with a falsification window, and whether every framework named is a real published one. The quality of the disagreement is judgement, so the debates go to blind pairwise preference.

The output is an argument, and arguments have no ground truth on the day they are written. Whether the committed recommendation was right is knowable a year later, in one business, once.

The partial objective spine is worth building. A grader can check the lens count, whether the composition matches the stated altitude, whether every block carries all five parts, whether the divergence bucket is non-empty and every divergence is typed, whether exactly one committed recommendation exists with a falsification window, and whether every named framework is real. Two briefs should be deliberately underspecified, so that asking two or three questions, or splitting the question, is the correct behaviour and can be scored.

The doubt is the disagreement itself. An assistant asked for multiple perspectives already produces several plausible viewpoints. Whether they genuinely conflict, or quietly agree in different vocabulary, is what a blind pairwise comparison would settle.

The rule that decides pass or fail was written down before any run was executed and it does not move afterwards. It is in the method note on the hub, along with the full results table including every skill that was tested and cut.

What it does not do

Stated plainly, because a skill that claims everything is useful for nothing.

  • It does not represent the views of any named individual and it will refuse to. Every lens is a discipline plus a published framework, so if what you wanted was a simulation of a particular practitioner, this is not that and will not become it.
  • It cannot supply the facts. Most genuine divergence turns out to be a factual disagreement in disguise, and the output there is a research task with a deadline rather than an answer.
  • It cannot settle a values question. When the fork is risk tolerance, it hands both paths back with the price of each attached, which some readers experience as the skill failing.
  • A real advisory board with equity or reputation at stake outperforms it, because those people carry consequences and a framework does not. Two named advisers who disagree in front of you is better again.
  • It is expensive for reversible decisions. For anything you can undo inside a week, one clear owner and a deadline beats six lenses, and convening anyway is procrastination with better formatting.

Install it

  1. Open Locul, go to Library, and choose Import. One-click import from this page lands shortly.
  2. Locul writes the file to the right folder for every assistant you have connected, so you do not have to know where each one keeps its skills.
  3. Environment variables and headers in any shared config are replaced with a placeholder before they reach you, so importing a stranger's setup cannot hand you their credentials or take yours.
  4. Locul is free to start, on Mac and Windows. Get it here.
  1. Download SKILL.md using the button above, or copy the file.
  2. Save it at .claude/skills/expert-council-debate/SKILL.md in your project, or under ~/.claude/skills/expert-council-debate/SKILL.md on Mac and Linux, or %USERPROFILE%\.claude\skills\expert-council-debate\SKILL.md on Windows, to make it available everywhere.
  3. Start a new session. Claude Code picks up the skill from the name and description in the file's frontmatter, so you can also invoke it by name.
  1. Download or copy the file.
  2. For Claude Desktop, add it through the skills panel in settings, or drop the folder into your skills directory.
  3. For Cursor and other assistants that read plain instruction files, paste the body into your project rules file. The skill is plain markdown with no tool bindings, so it carries across.

Pairs well with

What else does this job

Two people who actually disagree, in a room, with something at stake, beat every structured method. If you have a board, a co-founder who is not conflict-averse, or an adviser willing to be unpopular, use them and stop reading.

A pre-mortem is faster and often better. Assume the decision has failed a year from now, write the story of how, and you get most of the risk surface in twenty minutes with no roster to select. It is the right tool once you have chosen a plan. It is the wrong one when the job is choosing between two.

Six Thinking Hats is the lighter structured option and it works on groups rather than on documents, but its modes are cognitive rather than expert, so it improves the quality of the thinking without adding any discipline knowledge.

The model with no skill will produce several sensible perspectives and a balanced summary. That is genuinely fine for a low-stakes call. The things it tends not to do are hold the divergence open instead of dissolving it, and then commit anyway. Those two behaviours pull in opposite directions, which is precisely why they need writing down.

Read the full source
---
name: expert-council-debate
description: Convenes four to six expert lenses on a decision, where each lens is a discipline paired with a named published framework rather than a person, selects them by the altitude of the question using a three-tier roster, stages the debate in convergence, divergence and build-on buckets, and synthesises to one committed recommendation with the unresolved tensions preserved. It flags extrapolation explicitly, types every disagreement as being about a fact, a time horizon, a risk tolerance or a definition of success, and refuses to end in "it depends". This skill should be used for consequential and hard-to-reverse product, pricing, positioning, channel or business-model decisions, especially when the team agrees too quickly or has been circling the same choice for weeks.
---

# Expert council debate

## The claim this skill is built on

Multi-perspective analysis fails in two opposite directions, and both look like success on the page.

The first failure is fake consensus. Several perspectives are produced, they all point the same way, and the reader concludes the answer is obvious. Usually it is not obvious. It is that nobody made the perspectives disagree, so what got produced was one opinion in several vocabularies.

The second failure is hedging. Genuine disagreement appears, and the summary averages it into "it depends on your context", which is true, useless, and indistinguishable from having no view. The reader arrived with a decision to make and leaves with a longer version of the same ambiguity.

This method is built to fail in neither direction. Disagreement is manufactured deliberately, by selecting lenses whose frameworks reach different conclusions, and then it is preserved through the synthesis rather than dissolved. And after preserving it, you commit to one path anyway, with a falsification window attached, because a recommendation that cannot be wrong by a date is not a recommendation.

## Why the lenses are disciplines, not people

Every lens here is a discipline paired with a published framework: the positioning lens applying a competitive-alternatives framework, the pricing lens applying a value-metric framework, the activation lens applying a time-to-first-value framing.

None of them is a person, and this is a design decision rather than a legal formality.

A named practitioner's stance is a moving target. It was formed in a particular market, at a particular time, about particular companies, and it changes. Nobody can check what any of them would say about your decision, so a lens built on a person is unfalsifiable by construction: it can be neither applied correctly nor caught being applied wrongly, and any confidence it produces is borrowed rather than earned.

A framework is checkable. It has written mechanics, stated preconditions, and a domain where it is known to break. You can apply it properly, apply it sloppily, or show that its preconditions do not hold in your case, and a reader can verify all three. That is what makes a lens argue rather than assert.

So: name frameworks, and cite whose they are the way you would in any other document. Never write a lens as a person, never write "as X would say", and never invent a quotation. If a framework's author is relevant, they appear as an attribution and not as a voice.

## The roster

Three tiers, organised by the altitude of the question a lens is good at. The point of a tiered roster is that it makes the selection rule possible.

**Tier 1: strategic architects.** Whether to do the thing at all. Horizons of multiple quarters.

| Lens | Framework it applies |
| --- | --- |
| Market structure | Jobs to be done, and the disruption model set out by Clayton Christensen |
| Positioning | Competitive alternatives, from April Dunford's Obviously Awesome |
| Systems | The four fits: market and product, product and channel, channel and model, model and market, from Brian Balfour |
| Business model | The business model canvas, from Alexander Osterwalder and Yves Pigneur |
| Unit economics | Contribution margin, payback period, and the ratio of lifetime value to acquisition cost |
| Category | Category design, and the budget-line question of which existing line pays for this |
| Distribution strategy | Channel and model fit, and the ceiling every channel eventually hits |

**Tier 2: practitioners.** How to build and run it. Horizons of weeks to a quarter.

| Lens | Framework it applies |
| --- | --- |
| Discovery | The opportunity solution tree, from Teresa Torres |
| Customer research | Past-behaviour interviewing, from Rob Fitzpatrick's The Mom Test |
| Pricing | The value metric, and the fences between tiers |
| Activation | Time to first value, and the count of steps before it |
| Retention | The cohort curve, and whether it flattens or decays to zero |
| Growth loops | The five-stage loop: trigger, action, reward, shared output, new users |
| Prioritisation | RICE scoring, or cost of delay where sequencing is the question |

**Tier 3: tactical specialists.** One artefact, this week.

| Lens | Framework it applies |
| --- | --- |
| Conversion copy | AIDA, or problem, agitate, solve |
| Onboarding | Progressive disclosure and empty-state design |
| Paid channel | Payback arithmetic and structured creative testing |
| Lifecycle messaging | Behaviour-triggered sequences rather than time-based ones |
| Instrumentation | Event taxonomy, and the definition of an active user |
| Support and operations | Cost to serve, per account, per month |
| Procurement and compliance | The security review as an input to the sales cycle |
| Accessibility | WCAG conformance as a procurement gate |

This roster is not exhaustive and is not meant to be. Add a lens when the decision genuinely lives in a discipline that is missing, and give it a real published framework when you do.

## Step 1: restate and classify

Restate the decision in one sentence, in the form "should we X or Y", with both options named. If you cannot name a second option, there is no decision yet, only a plan awaiting approval, and a council will produce theatre.

Then classify the altitude on three tests:

| Test | Altitude A, strategic | Altitude B, operational | Altitude C, tactical |
| --- | --- | --- | --- |
| Reversibility | A year or more to undo | About a month | Days |
| Horizon | Several quarters | One quarter | Weeks |
| Blast radius | The whole company | One team or one funnel stage | One artefact |

Where the tests disagree, reversibility wins. A change that takes a day to make and a year to unwind is Altitude A.

## Step 2: select four to six lenses, and say why

Composition is fixed by altitude. This is the rule that does most of the work.

| Altitude | Tier 1 | Tier 2 | Tier 3 |
| --- | --- | --- | --- |
| A, strategic | 3 | 2 | 0 to 1 |
| B, operational | 1 | 3 | 1 |
| C, tactical | 0 to 1 | 1 to 2 | 3 |

Four to six lenses, never the whole roster. State in one line why each selected lens is here, and name at least one lens you deliberately left out and why, because the exclusions are where the reasoning shows.

**The two mismatches, and what each looks like.** Tier 1 lenses on an Altitude C question produce a re-litigation of strategy in response to a request about a button. It reads as depth and answers nothing, and the visible symptom is that the recommended action cannot be started this week. Tier 3 lenses on an Altitude A question produce confident, well-argued tactics for a decision that should not be made at all, and the symptom is a numbered action list with no line in it about whether to proceed.

**The dissent seat.** At least one lens is chosen specifically because its framework is likely to reach the opposite conclusion to the one the question is leaning towards. Name it as the dissent seat when you select it. Without this, selection quietly optimises for agreement, because the lenses that come to mind first are the ones that fit the plan.

## Step 3: the lens block

Each lens gets a fixed block of 150 to 300 words containing five parts, in this order:

1. **Characteristic stance**, one line. What this framework habitually treats as the important variable.
2. **What it recommends here, and why**, argued from the specifics of the decision rather than in general.
3. **The framework, named, with its mechanics applied.** Not a mention. The actual mechanism, run on this case, producing a result.
4. **What it would warn against**, including the condition under which its own recommendation goes wrong.
5. **One specific action**, small enough to start within a week.

The word band is not arbitrary. Under about 150 words a block degenerates into a slogan and every lens sounds the same. Over about 300 it starts restating the other lenses, and the reader stops being able to tell them apart, which is the exact failure the format exists to avoid.

Part three is the one that gets faked. A framework named in passing, with nothing downstream that would change if you deleted the name, is decoration. The test: remove the framework's name from the block. If the argument is unaffected, the framework was never applied.

## Step 4: stage the debate in three buckets

Present this as an exchange, not as three lists. A position, then the rebuttal that names the specific assumption it attacks. Never "on the other hand".

**Bucket one: convergence.** Where lenses agree. It only counts as convergence if they arrived by different routes, so name the route each one took. Two lenses that agree because they share an upstream assumption are one vote, not two, and should be recorded as such. This is the single most common way a debate inflates its own confidence.

**Bucket two: divergence. This is the deliverable.** A council that produces no divergence has either an unusually clear decision or a badly chosen roster, and the second is far more likely. For each divergence, write three things:

- **The fork.** One sentence naming both positions.
- **The type.** Which of the four it is, from the table below.
- **What would settle it.** Concretely, and with a cost.

| Type of disagreement | What it is really about | The correct response |
| --- | --- | --- |
| Fact | Both lenses would agree if they knew one thing neither has | A research task with a deadline and a default if it does not run |
| Time horizon | Both are right, over different periods | A strategy choice about which period you are optimising for, made explicitly |
| Risk tolerance | The same expected value, different variance | Hand it back. No framework resolves a values question |
| Definition of success | The lenses are optimising different metrics | Fix the metric first, then rerun the fork |

Typing the divergence is what converts an interesting argument into an action. An untyped disagreement gets summarised, and a summarised disagreement gets ignored.

**Bucket three: build-on.** Where one lens's recommendation is only viable if another lens's precondition holds. Write these as a dependency chain, because it produces the sequencing that the action list later needs.

## Step 5: synthesis, in four sections

1. **Consensus.** One committed recommendation, stated as something a person can start, with the reasoning, a confidence level, and the falsification window: what would have to be observed, by when, for this to be wrong.
2. **Key tensions to resolve.** Carried forward from the divergence bucket, deliberately unresolved, each with its type.
3. **Prioritised actions**, numbered, sequenced according to the build-on chain.
4. **What to validate before deciding**, each with its cheapest available test.

**The commit-anyway rule.** Even when the divergence is wide, name the path you would take and why. Two constraints on that commitment: it must be falsifiable inside a stated window, and it must name what the losing lenses were right about. A synthesis that names no cost is not a synthesis, it is a summary of whichever lens you already agreed with.

## Guardrails

**Never present one lens as the truth.** A lens is a framework applied to a case, and frameworks have domains.

**Flag extrapolation, in fixed wording.** When a framework's published mechanics do not cover the case, write "applying framework X, this lens would likely" and then say which part is the extrapolation. Never state an extrapolation as though the framework covers it.

**Allow abstention.** A lens with no genuine position on the question says so in one line. Abstention is a signal about the roster: if two or more lenses abstain, reselect rather than pad, because the composition was wrong.

**Flag preconditions that do not hold.** Frameworks have stated conditions. A retention framework assumes repeat usage, so it has little to say about a product bought once. A loop framework assumes an artefact that leaves the account. Say when a precondition fails and downgrade that lens rather than stretching it.

**Ask before convening, but only two or three questions.** If you cannot state the decision, its reversibility, and the binding constraint, ask two to three targeted questions first. Not more. A council that opens with a questionnaire never convenes.

## The decision rule

At synthesis, take exactly one branch.

- **Broad convergence, divergence only about sequencing.** Commit at high confidence, order the actions by the build-on chain, and set the falsification window generously.
- **Divergence is typed as a fact.** Do not commit to the strategy. Commit to the research: name the fact, the test, its cost, its deadline, and the default action if the deadline passes with no answer. The default is the part people skip and it is the part that gets executed.
- **Divergence is typed as risk tolerance.** Hand it back explicitly, with both paths priced. Say plainly that no framework resolves this and that the choice belongs to whoever carries the consequence. Then still say which path you would take, and why, and be clear that this is a preference rather than a finding.
- **Divergence is typed as a definition of success.** Stop the council. Fix the metric, then rerun the same roster against it. Running a debate where two lenses are optimising different numbers produces disagreement that looks substantive and is arithmetic.
- **You cannot tell which type the divergence is.** This means the question is underspecified, and the wrong response is convening more lenses, which is what everyone does. Split the question into two decisions and ask which one has to be settled before the other is even answerable. Run the council on that one. If you cannot split it either, the honest output is the two or three questions from the guardrail above and no debate at all.

## Worked example, compressed

**The decision.** A project management tool for building subcontractors, currently self-serve at a low monthly price per user, is considering moving to annual contracts sold by a two-person sales team.

**Altitude.** Reversibility: about a year, because signed annual contracts and hired people do not unwind quickly. Blast radius: the whole company. Altitude A. Composition: three Tier 1, two Tier 2, one Tier 3.

**Roster, with reasons.** Positioning lens, because the alternative determines what the buyer thinks they are paying for. Unit economics lens, because a sales team has to be funded by the deal size. Distribution strategy lens, because the question is really about a motion. Pricing lens, because the current metric is the suspect. Retention lens, as the dissent seat, because it is the framework most likely to argue against the plan. Procurement lens from Tier 3, because contract length is a procurement artefact. Left out: the conversion copy lens, because no artefact is in question.

**Convergence, by different routes.** The current per-seat metric is wrong for this market. The positioning lens gets there because the real alternative is a group chat plus a spreadsheet, which costs nothing per person, so per-seat pricing invites a comparison the product loses. The unit economics lens gets there because crews expand in the customer's busy months, so per-seat revenue rises exactly when the customer is most price-sensitive, and falls in winter when they are deciding whether to renew. Different routes, so this counts as convergence.

**Divergence one.** The pricing lens says change the value metric now and keep self-serve. The distribution lens says the motion is the constraint and the metric is a detail. Typed as a **fact**: both would agree if they knew whether current churn is concentrated in accounts that hit the seat ceiling. Settled by one query against the existing billing data, at a cost of about an hour.

**Divergence two.** The retention lens, in the dissent seat, argues that annual contracts do not improve retention, they postpone the evidence of its absence by twelve months, and that a flat cohort curve should be earned before it is contracted. The distribution lens argues the cycle length in this market makes annual terms standard and the comparison is therefore not optional. Typed as a **time horizon** disagreement: both are right, over one year and over three.

**Build-on.** The Tier 3 procurement lens notes that subcontractors buy on schedules dictated by their main contractors, so an annual term starting in the wrong month is a discount request in disguise. That only matters if the sales motion happens, which depends on the deal size, which depends on the pricing lens landing first.

**Verdict, committed.** Change the value metric from seats to active projects this quarter, keep self-serve, and do not hire the sales team yet. Falsifiable by the end of the following quarter: if churn among the largest accounts does not fall after the metric change, the binding constraint was the motion rather than the price, and the sales hire moves to the front of the queue. What the losing lenses were right about: the distribution lens is correct that this market eventually requires annual terms, and the retention lens is correct that signing them before the curve flattens buys silence rather than loyalty. Tension left open on purpose: whether the three-year picture justifies accepting a worse one-year picture. That is a risk-tolerance question and it belongs to the founders.

## Failure modes

**Fake consensus.** Five blocks, five discipline names, one voice. Recognisable because every block ends recommending the same action in different vocabulary, and the divergence section is a paragraph about nuance.

**Consensus by shared assumption.** Two lenses agree because they inherit the same premise from upstream, and it is counted as two votes. Symptom: confidence rises when a lens is added, which is backwards, because a genuinely independent lens usually complicates the picture.

**Manufactured divergence.** The opposite failure. Disagreement invented to satisfy the format, where the two positions are actually compatible. Symptom: the tension dissolves in the synthesis without either side conceding anything.

**Stance fabrication.** A lens making a confident claim about a specific market that no published framework covers, with no extrapolation flag. Symptom: the most quotable sentence in the whole debate is the one with the least support under it.

**Roster dumping.** Every lens on every question. Symptom: blocks shrink towards a hundred words, the tactical lenses discuss strategy, and the reader cannot recall which lens said what by the end.

**Altitude mismatch.** Tier 1 lenses on a button, or Tier 3 lenses on a business-model change. Symptom in the first case: no action can start this week. In the second: a detailed plan with no line about whether to proceed.

**Mush synthesis.** "It depends on your context." Symptom: the reader could have written the summary before the debate, and nothing in the action list would change if the recommendation were reversed.

**Framework name-dropping.** The name appears once and nothing depends on it. Test by deleting the name: if the argument survives intact, the framework was never applied.

**Domain overreach.** A lens stretched into a field its framework says nothing about, usually because the roster was short and the block had a word count to fill. Symptom: a specialist lens producing generic business advice.

## What this skill does not do

- It does not represent, quote, simulate or speak as any named individual. The lenses are disciplines and published frameworks, and that is the whole design rather than a caveat.
- It cannot supply the facts a divergence turns on. Where the disagreement is factual it produces a research task, a deadline and a default, and the value then depends entirely on someone running it.
- It cannot resolve a values disagreement. Risk tolerance is handed back with both paths priced, deliberately.
- It has no access to your data, your churn, your pipeline or your costs. Every number in the debate is one you supplied or one it invented for illustration, and it should say which.
- It is not a decision log, a governance process, or a record anyone else is bound by. It produces an argument and a recommendation, not a mandate.
- It is not worth its cost on reversible decisions, where deciding fast and watching what happens is strictly better.
Why import instead of copy

A skill is only as good as what it can read.

These skills all ask your assistant to check things against your actual codebase, your actual schema, your actual design system. Locul keeps that context current on its own, from the files you already have, on your machine. Mac and Windows, free to start.

Start free