Facilitation, Consensus Building and Decision Driving Questions

Direct answer

The goal of the half-day (240 minutes) is to leave with one written definition, one canonical query and one named owner for each contested metric, plus a lightweight process for changing them later. I would make the disagreement concrete before debating it: have all 8 teams compute the metric on the same handful of sample accounts and compare answers. Definitions argued in the abstract produce vague compromises; definitions tested against real cases expose exactly where teams differ. A canonical query is the one agreed piece of code or logic that every report must reuse for that metric.

Structured elaboration

Pre-work (one week before): each team submits the definition and query it uses for its top 3 metrics and nominates one person with authority to agree for that team. The facilitator then groups the up to 24 submissions (8 teams x 3 metrics) by metric name and picks the six to resolve live: the ones where at least two teams give different definitions and the number reaches executives or customers. The rest are settled in writing afterwards, using whatever the session decides.

The blocks sum to 240 minutes.

Worked example: "churned customer" on six sample accounts, as of 31 March

Three definitions are in use: Finance counts a customer as churned if the subscription ended in March; Product counts a customer as churned if there has been no login for 30 days or more; Customer Success counts customers who gave notice in March.

Finance counts 3 (A, D, E), Product counts 2 (A, C), CS counts 3 (A, B, D). Totals alone hide that the sets differ. The agreed outcome: churn = subscription end date within the month, owned by Finance; "dormant" (no login 30 days) and "notice given" become separately named leading indicators owned by Product and CS. The disagreement is resolved by giving each idea its own name.

Escalation policy: if a metric is not agreed within its 10 minutes, the named metric owner decides at the end of the session; if the owner is contested, the head of data governance (the person accountable for company-wide data rules) decides within 48 hours.

Governance so decisions stick

• Every metric has one owner, a version number and a change request (a short form asking to change a definition). A filled-in example:

Metric: churned customer          Current version: v1.0
Requested change: count a customer as churned when the subscription end date falls in the month (v2.0)
Why: Finance and Product report different churn counts for the same month
Affected: board dashboard, CS weekly report, 2 forecasting models
Expected effect: March count moves from 2 (login-based) to 3
Owner: Finance      Decision date: 15 April

• Changes are reviewed on a fixed monthly cadence. A breaking change is one that moves a number people already publish (like the churn example above), so it gets a notice period and the old name is kept as a labelled alias: the old metric name still works but is tagged "deprecated, now means v2.0" until dashboards are migrated.
• Enforcement in the pipelines: dashboards read from the canonical query or a shared metrics layer (one governed place where each metric is defined once, so every dashboard asks that place instead of writing its own query). An automated reconciliation test recomputes the metric from the canonical query each night and compares it with the number each report shows. Example result: canonical churn for March is 3; the Product retention dashboard shows 2 (it uses the login-based definition, which the six-account table counts as A and C), so the test flags that dashboard as drifted and names its owner. The CS report, which counts notices given, also shows 3, the same total as canonical churn, so a test that compares only the totals would pass it even though its set (A, B, D) differs from the canonical set (A, D, E). That is why the test should also compare the account lists (which accounts are counted), not just the totals: it would then flag the CS report as measuring a different thing and it would be renamed to the "notice given" indicator.
• The glossary lives next to the code, with the six-account table above kept as the worked example.

Trade-offs and pitfalls

• Eight teams means eight vetoes. Pre-agree the decision rule or the day becomes a negotiation.
• Do not redefine metrics silently afterward; restated history needs an announcement.
• Skipping the sample-case step produces definitions that read fine and still disagree on edge cases.

Direct answer

I would run it as a learning review with two jobs: find out where the gap came from, and find out which decisions and assumptions were wrong. I would bring a decomposition of the miss, a record of the key decisions, and an honest question about whether the target itself was sound. Attendees are the people who made decisions and the people who executed them, across functions. It ends with two or three changes, each with one owner and a date, written before people leave.

Who attends

Product, engineering, marketing, sales, support and analytics, each represented by someone who was in the work, plus an executive sponsor who listens first and speaks last (leadership talking early shapes everything). Keep it to about 8 to 10 people so everyone is heard.

Evidence I bring

• The original target and how it was derived, plus the assumptions behind it.
• A funnel breakdown: the path customers take, step by step (visit, sign up, activate), with the count at each step, showing where the shortfall arose.
• The decision log: what was decided, by whom, with what information.
• Customer evidence (support tickets, interview notes), not only the dashboard.

Worked example (illustrative): decomposing a 40% miss

Plain terms: a visit is someone arriving on the site, the sign-up rate is the share of visitors who create an account, and an activation is a new account that completes the first meaningful action (say, creating a first project). Target: 10,000 activations. Actual: 6,000, which is a 40% miss ((10,000 - 6,000) / 10,000 = 0.40).

Trace the actual column: 150,000 x 8% = 12,000 sign-ups, and 12,000 x 50% = 6,000 activations. Plan: 200,000 x 10% = 20,000 sign-ups, and 20,000 x 50% = 10,000.

Traffic alone would have given 7,500, and the sign-up rate alone 8,000, but the two shortfalls multiply (0.75 x 0.80 = 0.60), which explains the 40% miss. Activation behaved as planned. So the review spends its time on why traffic and sign-up fell short (campaign timing? pricing page? the target assumed 10% from a different audience?), not on onboarding.

Running it (90 minutes)

These sum to 90.

Avoiding finger-pointing

Describe decisions in terms of the information available at the time ("given what we knew then"), ask each function "what did you see that others did not?", and separate learning from performance review, which happens elsewhere.

Trade-offs and pitfalls

• Outcome bias (judging a decision by how it turned out rather than by how sound it was given what was known at the time): a bad result makes every decision look bad. Ask whether the decision was reasonable when taken.
• The target may have been the error. Say so if the evidence shows it.
• Share a short written summary and follow up on the changes at 30 days, or the review is theatre.

Direct answer

Pre-work decides most of the outcome. Before the meeting I interview both stakeholders, ask each to define their metric precisely and bring a sample query or demo on the same data, and agree a decision rule. In the 30 minutes I compare the candidates against that rule, decide, and publish the agreed definition as a short written artifact both can see themselves in. (The lead metric is the one headline KPI, a key performance indicator, that the team is judged on; other metrics play supporting roles.)

Pre-work

1. 1:1 with each stakeholder: what decision does your KPI drive, and what would convince you the other metric is better?
2. Write the candidate definitions in the same format: name, formula, time window, data source.
3. Evidence on the same data: each brings a sample query or dashboard demo. For retention, a historical check is useful: which candidate best predicts customers still active 90 days later? To run it, take customers who joined six months ago, compute each candidate for their first 30 days, and compare against whether they were still active at day 90. Illustratively, if 150 of 200 customers with 3 or more active weeks in month one were still active at day 90 (75%) versus 30 of 100 with fewer (30%), that candidate separates retained customers well.
4. Decision rule (proposed in advance): the lead metric must be (a) tied to retention, (b) movable by the team within a quarter, and (c) hard to game (it cannot be pushed up by actions that do not help customers, such as discounting or relabelling accounts). Each criterion needs a minimum score of 2 out of 5, and then the higher total leads; where a candidate scores low on one criterion, the other metric covers the gap (for 90-day retention, which reads out late, weekly usage is the early signal). The other metric becomes a guardrail (a metric that must not get worse) instead of being dropped.

Agenda (30 minutes)

Total: 30 minutes.

Illustrative scoring during the 8 to 20 slot, each criterion scored 1 to 5 aloud, with the stakeholders agreeing each number:

The totals are close, so the group reads the result as: retention is the lead metric because it measures the outcome itself, and weekly active usage becomes the guardrail and the early-warning signal.

Facilitation techniques: "say it back" before rebutting; scoring each candidate against the three criteria aloud; naming what each person gains (their metric becomes the guardrail).

Example conflicts and how the data decides

• Revenue versus long-term engagement as the lead KPI: revenue moves fast but can rise by discounting and lose customers later; engagement moves slower but tracks retention. A common outcome is engagement or retention as the lead metric with revenue retention as a guardrail.
• Last-click versus first-touch conversion: suppose a customer clicks an ad on Monday, an email on Wednesday and buys on Friday. Last-click credits the email; first-touch credits the ad. Run both definitions on the same quarter's data, show how credit shifts between channels, and pick one for the stated purpose (acquisition decisions favour first-touch; closing-funnel optimisation favours last-click), keeping the other as a reported secondary.

Documenting the decision

A one-page definition. A filled example: Name: 90-day customer retention rate. Meaning: the share of customers who are still active 90 days after they sign up. Formula: customers active on day 90 / customers who signed up in the cohort (for example 180 / 300 = 60%, a cohort in which the 200 customers with 3 or more active weeks in month one and the 100 with fewer were pooled). Window: day 90 after signup, cohorts by signup month. Source: the billing and product events tables. Owner: named person. Known limits: ignores customers who left and returned. Review date: next quarter. In general the page holds: metric name, plain-English meaning, exact formula, time window, data source, owner, known limits, and review date. Both stakeholders get a line recording what they contributed and the guardrail they own.

Trade-offs and pitfalls

• Choosing a metric without agreeing a rule first becomes a vote on personalities.
• A lead metric that no team can influence invites gaming or apathy.
• Skipping the written definition lets each team compute it differently.