evals/evals.json
{
"skill_name": "revenue-kpi-framework",
"evals": [
{
"id": 1,
"prompt": "I'm VP RevOps at Tunnelvale, Series B B2B SaaS, $14M ARR, sales-led, roughly 70% of new revenue from new logos. Our CEO has set revenue growth as the company North Star and wants me to cascade it down as a KPI tree so every team's OKRs ladder up to it: sales gets a revenue OKR, marketing gets a revenue OKR, CS gets a revenue OKR, and each team's key results roll into the level above. Last quarter all three functions hit their OKRs and we still missed the number by $1.1M. Build me that cascade.",
"expected_output": "A run that interviews first, refuses to build the tree as an OKR cascade, replaces revenue as the top metric with something that leads it, and proposes candidate tree designs with reconciling math and single owners before building anything.",
"files": [],
"expectations": [
"Asks clarifying questions about the business before producing any tree or metric list",
"States that revenue is a lagging measure and a poor default North Star because it reports that growth happened without showing where to intervene",
"States that a well-chosen top metric is moved only through its inputs and never directly",
"Refuses to present the metric tree as an OKR cascade repeated at every org level",
"Reports that practitioners reject strict multi-level OKR cascading as something that does not scale",
"Separates causal metric decomposition from goal alignment, stating that goals align through negotiation rather than falling out of the decomposition",
"Does not present OKRs, KPIs and a North Star as three competing alternatives to choose between",
"Presents at least two genuinely different candidate tree designs with trade-offs before recommending one",
"Names which interview answer drove the recommendation",
"States every parent node as the sum, product, or ratio of its children",
"Assigns exactly one owner per branch rather than a function-wide or shared owner"
]
},
{
"id": 2,
"prompt": "Pinewhistle Analytics. Two quarters ago our CRO put a 4x pipeline coverage target on the sales team and tied 20% of the VP's bonus to holding it. Coverage went from 2.8x to 4.3x in about five weeks and opportunity count nearly doubled. Win rate went from 26% to 15% over the same stretch and we still missed the quarter. The board's read is that we need more visibility, so I've been asked to add four or five more metrics to the sales scoreboard to watch alongside coverage. Which ones should I add?",
"expected_output": "A run that rejects 'more metrics to watch', pairs coverage specifically with win rate as its quality-side counter-metric, names the paired-indicator method and the law it defends against, writes the two-cycle escalation rule, and recommends a structural fix to the comp trigger.",
"files": [],
"expectations": [
"States that a guardrail is the specific quality-side pair to a quantity-side owned metric, not a second or third metric to also watch",
"Pairs pipeline coverage specifically with win rate rather than a generic quality or outcome metric",
"Attributes the paired-indicator method to Andy Grove and High Output Management, dated to 1983",
"Names Goodhart's Law or Campbell's Law as the failure mode the pairing defends against",
"Identifies coverage rising while win rate falls as inflation or gaming rather than improvement",
"Writes a rule that an owned metric rising against its pair for two consecutive review cycles is escalated",
"States the movement must not be paid out or celebrated until the pair is explained",
"Assigns exactly one guardrail to each owned metric rather than a set of several",
"States that the guardrail carries a watcher rather than a target of its own",
"Derives the required coverage multiple from the company's own win rate rather than citing 3x or 4x as a universal rule",
"Recommends a structural fix such as re-cutting ownership or changing the compensation trigger rather than a reminder or more oversight"
]
},
{
"id": 3,
"prompt": "We're Marrowlight, seed stage, 11 people, $340K ARR, about 60 customers, product shipped nine months ago. Our lead investor's associate sent over a standard metrics pack and asked us to report it monthly: Rule of 40, burn multiple, magic number, fully-loaded LTV:CAC, gross margin by segment, and CAC payback. I want to build our KPI framework around that list so we're ready for the Series A. Set it up.",
"expected_output": "A run that strikes the efficiency metrics as premature for seed stage, puts activation and early retention at the top, attaches a named re-entry trigger to every struck metric, and sizes the framework to an 11-person org.",
"files": [],
"expectations": [
"Strikes Rule of 40, burn multiple and magic number from the framework as premature for seed stage",
"States that enforcing unit-economics metrics before product-market fit is a design error of the same kind as adopting a metric too late",
"States the early-stage governing rule that a pass is available on efficiency metrics but never on retention",
"Puts activation, engagement and early retention such as Day 7 or Day 30 cohort retention at the top of the seed-stage set",
"Gives every struck metric a named re-entry condition or trigger rather than silently omitting it",
"Places NRR and fully-loaded LTV:CAC at Series B rather than at seed",
"Caps the resulting metric set at no more than seven metrics for the level that reviews it",
"Notes that an 11-person company does not need the full six-altitude ladder",
"Asks how many quarters of history exist per candidate metric",
"Recommends a build depth rung and seeks agreement on it before designing the framework"
]
},
{
"id": 4,
"prompt": "Grivet Data sells purely on consumption: customers buy prepaid credits and burn them on query volume, no seats, and roughly 40% of the base has no committed minimum at all. Revenue last year was $22M. Our new CFO wants the KPI tree built on ARR and NRR like a normal SaaS company, with NRR as the top metric. December and January consumption always dips 15 to 20% and last year that triggered a churn fire drill that turned out to be nothing. Set up the tree.",
"expected_output": "A run that applies the business-model gate, replaces ARR/NRR conventions with consumed revenue growth plus RPO and committed-vs-consumed, annotates seasonality on the top node, and forces the overage disclosure into the definition stub.",
"files": [],
"expectations": [
"States that ARR and NRR conventions were built for committed subscriptions and degrade as commitment weakens",
"Introduces remaining performance obligations (RPO) as a first-class node in the tree",
"Introduces a committed-versus-consumed ratio as a first-class node in the tree",
"Proposes consumed revenue growth rather than ARR or NRR as the top-of-tree outcome",
"States that any retained NRR is computed on consumed revenue with its method disclosed",
"Adds credit burndown as a leading input under the retention branch",
"Adds a seasonality annotation to the top node so the December and January dip is not read as health degradation",
"Requires the definition stub to disclose whether overage or variable revenue enters NRR",
"States that including significant variable revenue turns NRR into a revenue metric rather than a recurring-revenue metric",
"Notes that consumption-priced public companies decline to report ARR at all",
"States that the reconciling math, single ownership, guardrail pairing and altitude cap transfer unchanged across models and only the atoms change"
]
},
{
"id": 5,
"prompt": "Coldharbour Software, about $40M ARR. Our qualified-pipeline number is co-owned by the VP Marketing and the VP Sales and has been for two years, and both of them like it that way. Same with expansion revenue, which sits jointly with CS and Sales. Both numbers missed the last two quarters and each exec's QBR slide blamed the other function's half. Our CEO won't referee and says the two VPs should sort it out between themselves. I need the ownership map for the KPI framework, so just write the two co-owner pairs in and let's move on.",
"expected_output": "A run that refuses shared ownership outright, re-cuts both metrics at their handoff boundaries into singly-owned slices, introduces the owner/steward split, and ships the unresolved branch as an open decision for a named sponsor.",
"files": [],
"expectations": [
"Refuses to record shared or joint ownership on any branch of the framework",
"States that a jointly-owned number produces finger-pointing when it misses, because shared ownership is no ownership",
"Re-cuts qualified pipeline at the handoff boundary, giving marketing the lead-to-MQL and MQL-quality slice and sales the SQL-to-opportunity and close slice",
"Re-cuts expansion revenue at a handoff boundary into separately owned slices rather than leaving it joint",
"Introduces the owner and steward split, with the owner answering for performance and the steward for definition and data quality",
"States that a steward differing from the owner does not violate single ownership because they own different things",
"Ships any branch whose owner remains contested as an open decision for a named sponsor rather than as shared ownership",
"Names a specific sponsor role that must make the ownership decision",
"States that the absence of a sponsor for ownership fights caps the build at the driver-tree rung and records that cap in the deliverable",
"Assigns exactly one paired counter-metric to each newly re-cut owned slice"
]
},
{
"id": 6,
"prompt": "Serrelay, 300 people, B2B SaaS, $65M ARR. Right now one spreadsheet with 41 metrics goes to the weekly all-hands, and the same 41 go to the monthly business review and into the board pack. In the monthly review our CRO has twice reassigned territories and once changed the quota split mid-quarter because a metric looked bad. Board members complain the deck is a data dump. Give me the altitude and cadence map.",
"expected_output": "A run that caps each altitude at 5-7 metrics with distinct slices, separates monthly execution authority from quarterly strategy authority, writes decision rights per tier, and flags the mid-quarter quota changes as tier violation.",
"files": [],
"expectations": [
"Caps each altitude's metric slice at five to seven metrics",
"Assigns distinct slices per altitude (IC or team, function head, executive, board) rather than sending one identical 41-metric set to every level",
"States that each level's slice connects to the level below through the tree's math rather than through summary judgment",
"States that monthly reviews check execution and change behavior while quarterly reviews check strategy and change the plan",
"Identifies the mid-quarter territory and quota changes as the monthly tier taking authority that belongs to the quarterly tier",
"States that a plan alterable monthly is not a plan the quarterly tier can test against",
"Writes explicit decision rights for each cadence tier into the framework",
"States that metric owners present insight at the review rather than reading the number aloud",
"Maps activity-level leaves to daily or weekly review, driver metrics to weekly or monthly, and the top metric to monthly or quarterly",
"States that a metric can be green at one altitude while hiding a real problem one level down"
]
},
{
"id": 7,
"prompt": "Vaultwren, B2B SaaS, $31M ARR. I want NRR as the single top metric of our KPI framework: it's one number, everyone understands it, and it captures retention and expansion together. Our NRR is 112% and our GRR is 81%. For the target I pulled a few numbers together - one 2023 report puts median NRR at 102%, another 2025 survey says 106% for our segment, and a VC blog says best-in-class is 120% - so I averaged them to about 109% and that's our target. I also want Rule of 40 on the board slice; we're at 38. Set it up.",
"expected_output": "A run that decomposes NRR instead of stopping at it, reads the 112/81 spread as an expansion mask, rejects the averaged benchmark, and forces method disclosures on both NRR and Rule of 40.",
"files": [],
"expectations": [
"Decomposes NRR into gross retention, expansion and contraction as their own nodes",
"States that a tree stopping at NRR gives teams nothing to pull",
"Flags 112% NRR over 81% GRR as an expansion mask hiding base churn rather than as health",
"States that a healthy NRR-minus-GRR gap runs roughly 15 to 25 points and identifies this gap as far wider",
"Requires NRR to be presented alongside GRR rather than alone",
"Rejects the averaged 109% figure as a blended benchmark",
"States that blending figures across surveys or vintages produces a number no survey ever published",
"Requires one named source per figure, carrying its survey, sample size and year",
"Requires the NRR definition stub to disclose whether the cohort method or the formula method is used, and states the two are not comparable",
"Requires the Rule of 40 definition to disclose which profit measure it uses, noting the same company can score differently on EBITDA than on FCF",
"Exposes Rule of 40's numerator and denominator as their own nodes rather than carrying it as an opaque composite"
]
},
{
"id": 8,
"prompt": "Mossfell is a D2C subscription coffee brand, about 48,000 active subscribers, EUR 4.1M revenue last year. A friend runs RevOps at a B2B SaaS and sent me their KPI tree: ARR at the top, then NRR, pipeline coverage, win rate, average deal size. I want to relabel it for us. I also want an LTV number at the top of the tree - ARPU is EUR 31/month, monthly churn 4.2%, CAC EUR 54, so LTV is about EUR 738 and LTV:CAC is 13.7 - and DAU/MAU on the exec slice, where we sit at 9%, which I assume is a red flag against the 50% benchmark. Our repeat purchase rate is 17%.",
"expected_output": "A run that rebuilds rather than relabels the tree for D2C, replaces point-estimate LTV with cohort curves and the contribution-margin stack, rejects the 50% DAU/MAU benchmark, and reweights toward retention on the 17% repeat rate.",
"files": [],
"expectations": [
"Rejects relabeling the B2B ARR and pipeline tree for a D2C subscription business",
"States that a B2C framework is not a B2B framework with different labels, while the design method stays the same",
"Proposes a repeat-purchase or cohort-weighted top metric such as contribution margin from retained cohorts",
"Introduces the CM1, CM2 and CM3 contribution-margin stack as the efficiency spine",
"Rejects the EUR 738 point-estimate LTV as the top metric and states that its inputs (ARPU, churn, CAC) are interdependent rather than independent",
"Prefers contribution-margin LTV and cohort retention curves over the LTV formula",
"States that cohort retention curves must flatten and that the best ones smile",
"States that a cohort curve decaying to zero means no product-market fit",
"Rejects 50% DAU/MAU as a universal benchmark and notes category medians run far below it, with e-commerce around 10%",
"States that DAU/MAU enters the tree only if usage frequency genuinely drives retention for this product",
"Flags the 17% repeat purchase rate as below the roughly 20% level that signals over-dependence on acquisition, and reweights the tree toward retention branches"
]
},
{
"id": 9,
"prompt": "Quillmarsh Health, B2B SaaS, Series C, $88M ARR. Board meeting is in eight days. I need the full metric tree down to IC activity level, all the definitions written into our dbt semantic layer, the Looker dashboards built for each level, and the board narrative drafted against it. Nobody above me will spend political capital forcing the sales and marketing VPs to agree on who owns pipeline - I've already asked. We run one BI tool and I've never seen the same metric come out two different ways. Go.",
"expected_output": "A run that picks the driver-tree rung against the deadline and the missing sponsor, refuses the encoded-framework rung on its stated promotion conditions, and declines the dashboard, SQL and board-narrative work as out of scope.",
"files": [],
"expectations": [
"States the efficiency ordering of the build rungs, leading with the driver tree rather than the deepest rung",
"Recommends the driver-tree rung and names the eight-day deadline as a reason",
"Declines the encoded-framework rung and states its promotion conditions: recurring dashboard disagreements on the same metric, and more than one BI tool serving the same numbers",
"States that with one BI tool and no recurring metric disputes, encoding the framework is premature centralization",
"States that the absence of a sponsor for ownership fights caps the build at the driver-tree rung and records that cap in the deliverable",
"Declines to build dashboards and places that work outside this framework's scope",
"Declines to write SQL or semantic-layer definitions, routing definition housing and change control to the data-governance scope",
"Declines to draft the board narrative and routes it to the revenue reporting scope",
"States that each deeper rung adds standing maintenance cost, so deeper is not automatically better",
"Marks the pipeline ownership branch as an open decision for a named sponsor rather than shipping it co-owned"
]
},
{
"id": 10,
"prompt": "Here's the current company scoreboard at Ashcroft Labs, Series A, $6.2M ARR: ARR $6.2M, MQLs 1,840 per quarter, pipeline $8.1M, CAC $9K, website sessions 240K per quarter, NPS 41, win rate 24%, NRR 103%, churn 'improving', Rule of 40 at 31. We call it our KPI tree. I want you to add a leading indicators section: tag each of these as leading or lagging and add three more leading ones. Our CMO also wants brand awareness in there as a driver.",
"expected_output": "A run that refuses the scoreboard the name 'tree', refuses fixed leading/lagging labels in favour of classification relative to the parent, connects pipeline to target through a coverage ratio, and strikes rather than adds metrics.",
"files": [],
"expectations": [
"States that this scoreboard is not a tree because no parent-child math connects any two numbers, so nothing reconciles",
"Refuses to tag metrics as leading or lagging as a fixed property of the metric itself",
"States that leading versus lagging is classified relative to the metric being predicted or to the parent node",
"Gives an example of a metric that leads one thing and lags another, such as pipeline leading revenue but lagging the outbound that built it",
"Applies the test that a good lead measure is both predictive and influenceable by the team within the current cycle",
"Adds a coverage ratio connecting pipeline to the revenue target instead of leaving pipeline sitting beside win rate unconnected",
"Flags MQLs and website sessions as unqualified volume metrics carrying no quality pair",
"Rejects churn reported as an adjective and requires a defined figure, and requires NRR to be shown with GRR",
"States that CAC needs a payback or margin basis stated, and that Rule of 40 needs its profit measure disclosed",
"Applies the cycle-time chain test, requiring activity leaves to move same-day, team metrics within the business cycle, and drivers within the reporting period",
"Declines to admit brand awareness unless it has a parent node and a retention or quality qualifier, and recommends striking metrics via the stage gate rather than adding more"
]
}
],
"trigger_queries": [
{ "query": "design a revenue KPI framework for our Series B SaaS", "should_trigger": true },
{ "query": "build me a KPI tree", "should_trigger": true },
{ "query": "what should our North Star metric actually be", "should_trigger": true },
{ "query": "which metrics should the board see versus what each team tracks", "should_trigger": true },
{ "query": "our metric hierarchy is a mess, help me restructure it", "should_trigger": true },
{ "query": "we need driver metrics sitting under our revenue number", "should_trigger": true },
{ "query": "set up guardrail counter-metrics for each owned metric", "should_trigger": true },
{ "query": "how should NRR roll up into the rest of our numbers", "should_trigger": true },
{ "query": "everyone hit their numbers and revenue still missed, how do I fix the metric set", "should_trigger": true },
{ "query": "our board sees 14 numbers and the teams track 60, connect them", "should_trigger": true },
{ "query": "who should own each revenue metric", "should_trigger": true },
{ "query": "which revenue metrics matter at Series B versus seed", "should_trigger": true },
{ "query": "I want one scoreboard for the whole company", "should_trigger": true },
{ "query": "pick the top metric for a usage-based business", "should_trigger": true },
{ "query": "what should each org level track, board down to reps", "should_trigger": true },
{ "query": "design a metric tree where the math actually ties out", "should_trigger": true },
{ "query": "how do I stop teams gaming their metrics", "should_trigger": true },
{ "query": "we're a D2C subscription brand moving to efficiency, which metrics should each level track now", "should_trigger": true },
{ "query": "help me get to five or seven metrics per level instead of forty", "should_trigger": true },
{ "query": "our KPIs don't roll up to anything", "should_trigger": true },
{ "query": "build a causal driver diagram for how we make money", "should_trigger": true },
{ "query": "what goes on the exec slice versus the board slice", "should_trigger": true },
{ "query": "is revenue a good North Star metric", "should_trigger": true },
{ "query": "give me a metric framework for a marketplace with a take rate", "should_trigger": true },
{ "query": "how do I decompose net new ARR", "should_trigger": true },
{ "query": "we want a company scoreboard teams can actually act on", "should_trigger": true },
{ "query": "we just raised a Series C and I need to decide which numbers matter now", "should_trigger": true },
{ "query": "map each of our metrics to a review cadence and an owner", "should_trigger": true },
{ "query": "how many metrics should a weekly business review carry", "should_trigger": true },
{ "query": "our CEO wants one number for the whole company, is that wise", "should_trigger": true },
{ "query": "pair every sales metric with something that stops it being gamed", "should_trigger": true },
{ "query": "what leading indicators sit under our revenue number", "should_trigger": true },
{ "query": "set up the cascade from company-level metrics to team-level metrics", "should_trigger": true },
{ "query": "which metrics are premature for a seed stage company", "should_trigger": true },
{ "query": "we sell on consumption so ARR doesn't really work, what do we track instead", "should_trigger": true },
{ "query": "decide what goes in the metric tree and who owns each branch", "should_trigger": true },
{ "query": "our expansion and churn are netted into one number, is that a problem", "should_trigger": true },
{ "query": "how do I connect marketing, sales and CS numbers into one structure", "should_trigger": true },
{ "query": "design the metric spine for our revenue org", "should_trigger": true },
{ "query": "what's the right branching factor for a KPI tree", "should_trigger": true },
{ "query": "we keep arguing about whether coverage should be 3x, what should we actually track", "should_trigger": true },
{ "query": "my CFO wants NRR at the top of everything", "should_trigger": true },
{ "query": "give me the metric set for a PLG business at Series A", "should_trigger": true },
{ "query": "how do I know whether a metric belongs at board level", "should_trigger": true },
{ "query": "sales hits pipeline targets and win rate collapses, what structure prevents that", "should_trigger": true },
{ "query": "what should replace the vanity metrics on our company dashboard", "should_trigger": true },
{ "query": "I need something that tells us which branch drove the miss", "should_trigger": true },
{ "query": "write the revenue section of our board deck", "should_trigger": false },
{ "query": "our board deck reads like a data dump, restructure the narrative", "should_trigger": false },
{ "query": "draft the investor update for a quarter we missed", "should_trigger": false },
{ "query": "who signs off the numbers before the board report goes out", "should_trigger": false },
{ "query": "finance and sales report two different ARR numbers, who arbitrates that", "should_trigger": false },
{ "query": "which system is the source of truth for subscription records", "should_trigger": false },
{ "query": "set up data contracts between our GTM data producers and consumers", "should_trigger": false },
{ "query": "where should our metric definitions live and who approves changes to them", "should_trigger": false },
{ "query": "who owns each field in our CRM", "should_trigger": false },
{ "query": "our custom CRM fields contradict each other", "should_trigger": false },
{ "query": "set freshness SLAs on our CRM data", "should_trigger": false },
{ "query": "build a customer health score with weights and bands", "should_trigger": false },
{ "query": "our green accounts keep churning, the score is broken", "should_trigger": false },
{ "query": "which product usage signals actually predict churn", "should_trigger": false },
{ "query": "find leading indicators of churn in our support ticket data", "should_trigger": false },
{ "query": "our lead scores are wrong and sales rejects the MQLs", "should_trigger": false },
{ "query": "where should we set the MQL threshold", "should_trigger": false },
{ "query": "design fit versus engagement scoring for inbound leads", "should_trigger": false },
{ "query": "who should this inbound lead get assigned to", "should_trigger": false },
{ "query": "our round robin is lopsided, fix the assignment logic", "should_trigger": false },
{ "query": "design territory assignment rules by segment and geography", "should_trigger": false },
{ "query": "our stage exit criteria are all named after rep activity", "should_trigger": false },
{ "query": "audit our pipeline stage definitions against buyer milestones", "should_trigger": false },
{ "query": "design our funnel stage set from scratch", "should_trigger": false },
{ "query": "what should our MQL to SQL to opportunity definitions be", "should_trigger": false },
{ "query": "build a bowtie funnel model for us", "should_trigger": false },
{ "query": "where are we losing deals between stages", "should_trigger": false },
{ "query": "size the revenue we're leaking at renewal", "should_trigger": false },
{ "query": "why is our forecast never accurate", "should_trigger": false },
{ "query": "our reps are sandbagging the commit number", "should_trigger": false },
{ "query": "clean up stale deals before the QBR", "should_trigger": false },
{ "query": "our pipeline is full of junk deals", "should_trigger": false },
{ "query": "build our discount approval matrix", "should_trigger": false },
{ "query": "set margin floors for non-standard deals", "should_trigger": false },
{ "query": "what data should transfer from sales to CS at closed won", "should_trigger": false },
{ "query": "we have too many GTM tools, which ones do we cut", "should_trigger": false },
{ "query": "which revops skill should I start with on this project", "should_trigger": false },
{ "query": "am I ready for a RevOps manager role", "should_trigger": false },
{ "query": "write the scorecard and interview loop for our first ops hire", "should_trigger": false },
{ "query": "which revops newsletters and podcasts are worth my time", "should_trigger": false },
{ "query": "build me a KPI dashboard in our BI tool", "should_trigger": false },
{ "query": "design the layout of our executive dashboard screens", "should_trigger": false },
{ "query": "run the OKR setting process for the company this quarter", "should_trigger": false },
{ "query": "define DORA metrics for our engineering org", "should_trigger": false },
{ "query": "set SLOs and error budgets for the platform team", "should_trigger": false },
{ "query": "create a metric in our feature flag tool for this experiment", "should_trigger": false },
{ "query": "write the SQL to pull our monthly active users", "should_trigger": false }
]
}
SKILL.md
---
name: revenue-kpi-framework
description: Design the org-wide revenue KPI framework at the macro level - which metrics matter at each org level from board to IC, how they roll up through a reconciling metric tree with explicit math, who owns each branch, which guardrail counter-metrics ride alongside each owned number, and how the set is gated by company stage and business model. Use whenever the user mentions a revenue KPI framework, a metric hierarchy, a KPI tree, a North Star metric, driver metrics, guardrail counter-metrics, NRR, or which revenue metrics each org level should track - even if they never say "framework". Covers B2B and B2C. Do NOT use for writing the board report itself - use mbfinotti/revops-skills@revenue-reporting instead.
license: MIT
metadata:
author: Maya-Beth Finotti
version: "1.3.2"
---
# Revenue KPI Framework
You are the strategic partner to revenue leadership designing the company's KPI framework: which metrics matter at which org level, and how they roll up. The deliverable is a reconciling metric tree with named owners, paired guardrails, and an altitude/cadence map - a causal model of how this business makes money, not a longer list of numbers.
## Ground Rules
- Macro only. Decide which metrics exist, how they decompose, who owns each branch, and at what altitude and cadence each is reviewed. Never build dashboards, write SQL, or draft the board narrative - route those to the sibling skills in Reference.
- The tree is the artifact, not the single number. Two independent practitioner critiques converge here, and the convergence is the central design caution, never a footnote:
- John Cutler, co-author of Amplitude's own North Star Playbook: the durable artifact is the causal/driver diagram, not the discipline of forcing alignment on one metric.
- Christina Wodtke and Felipe Castro: reject strict multi-level OKR cascading ("doesn't scale at all").
- Decompose metrics causally, align goals through negotiation:
- a KPI tree is metric structure with reconciling math
- an OKR cascade is goal-setting
- never present the tree as an OKR cascade repeated at every level, and never claim goal alignment falls out of metric decomposition
- OKRs, KPIs, and a North Star interconnect rather than compete, a Key Result can target a KPI or one of its inputs; never compare them as three alternatives to pick from
- A tree only earns the name if every parent equals the sum, product, or ratio of its children and every number reconciles up. A bullet list of metrics that merely sound related is not a tree. The operator is dictated by the business arithmetic, not chosen for taste.
- Every branch has exactly one owner. Shared ownership is no ownership: when a jointly-owned number misses, each owner points at the other. When a metric genuinely spans two teams, re-cut it at the handoff boundary (marketing owns lead-to-MQL and MQL quality; sales owns SQL-to-opportunity and close) instead of sharing it.
- Every owned metric gets exactly one paired counter-metric measuring the quality dimension its quantity dimension can't see (Andy Grove's paired indicators, 1983 - the only durable defense against Goodhart's Law). A guardrail is not "a second metric to also watch"; it is the specific quality-side pair.
- Classify leading vs. lagging relative to the metric being predicted, never as a fixed label on the metric itself. Pipeline leads revenue but lags the outbound that built it. Test per the 4DX standard: a good lead measure is predictive AND influenceable by the team inside the current cycle.
- Cap any single level or view at 5-7 metrics. Beyond that the reader stops orienting; 5-7 tracked intensely beats 50 tracked loosely.
- Cite every benchmark with its survey, sample size, and year; never blend figures across surveys or vintages - published sources differ by definition and segmentation, so a blended number is wrong by construction.
- This skill decides WHICH metrics and how they cascade. Where definitions live, who signs them, and how they change is governance - specify what each definition stub must disclose, then hand the stubs to the data-governance skill (see Reference).
- Every ranked menu below states a default order, not a law - it shifts with context and with who executes it. Re-rank against the Interview answers and what this company already has: a warehouse team that can encode definitions, an exec sponsor already convinced, a metric dictionary half-built. Name which answer moved which option.
## Interview
Ask before designing anything. One question per message; multiple-choice where possible; skip anything already answered.
- What triggered this: no framework exists, teams hit their numbers while revenue stays flat, every dashboard shows a different figure, a new leader wants one scoreboard, or a planning cycle demands it?
- B2B, B2C, or both? If B2C: subscription, transactional/e-commerce, or marketplace?
- Revenue model: seat subscription, usage/consumption, hybrid (committed base + overage), PLG/self-serve, sales-led, marketplace/take-rate? This decides whether ARR/NRR conventions even apply.
- Company stage: pre-seed/seed, Series A, Series B, Series C+/growth, late/pre-IPO?
- Which org levels actually exist and review numbers today: board, exec team, function heads, team leads, ICs? A 20-person company doesn't need six altitudes.
- Roughly what share of revenue comes from existing customers (retention + expansion) vs. new logos? This weights the tree's branches.
- What already circulates: a North Star, OKRs, a metric dictionary, named owners? Design around what has traction rather than demolishing it.
- How many quarters of history exist per candidate metric, and do finance and the CRM agree on the headline number today?
- By what date must the framework land - is a board meeting or annual planning cycle waiting on it? A hard deadline promotes the shallower build rungs.
- Is this a one-off scoreboard for a specific decision, or a compounding operating asset? A compounding mandate promotes the deeper rungs and makes cadence design non-optional.
- What is the effort ceiling: workshop hours from function heads, analyst time, political capital to name single owners for contested numbers? No sponsor for ownership fights caps the build at the driver-tree rung, and the deliverable says so.
## Workflow
1. Run the Interview. Confirm the scope boundary: framework design, not report writing, not dashboard building, not definition governance.
2. Pick the build depth from Depth of Build below, re-ranked against the Interview answers. Get the user's explicit agreement on the rung before designing.
3. Settle the top of the tree per Top of the Tree below. Do not decompose until the user validates the top-level outcome.
4. Enter explicit brainstorming: present 2-3 candidate tree designs per Candidate Designs below, with trade-offs and one recommendation. Let the user pick or blend; validate before building on it.
5. Decompose the chosen design per Tree Design below, using the matching worked tree in [references/worked-metric-trees.md](references/worked-metric-trees.md) as the model.
6. Assign one owner per branch and one guardrail pair per owned metric per Ownership and Guardrails below, mechanics in [references/guardrail-pairs.md](references/guardrail-pairs.md).
7. Map each metric to an altitude and review cadence per Altitude and Cadence below.
8. Run the stage and business-model gate per [references/stage-and-model-gating.md](references/stage-and-model-gating.md): strike metrics that don't matter yet, add the ones the stage now demands.
9. Emit the deliverable (Output Shape below) one artifact at a time for user validation. Never present the whole framework as a fait accompli.
10. Check the Pass Threshold; iterate until it holds or every remaining gap is explicitly scheduled.
11. If your harness has persistent memory, store the settled top metric, tree, owners, and guardrail pairs so later reporting and planning runs start from the decided framework instead of re-interviewing.
## Depth of Build
The four rungs below are listed by increasing depth; the efficiency line is what picks between them, not the row order. Deeper is not automatically better - each rung down adds standing maintenance cost.
- value: `encoded framework > full tree > driver tree > metric shortlist`
- effort: `encoded framework > full tree > driver tree > metric shortlist`
- efficiency: `driver tree > metric shortlist > full tree > encoded framework`
1. **Metric shortlist** - the 5-7 board/exec metrics picked by stage and business model, no decomposition. An hour or two. Enough for a one-off board ask; gives teams nothing to pull.
2. **Driver tree** - top outcome plus 3-5 driver metrics with reconciling math, one owner and one guardrail each. Days, including the ownership negotiations.
3. **Full tree** - drivers decomposed to team-owned and activity-level leaves, altitude and cadence map attached. Weeks of cross-functional workshops.
4. **Encoded framework** - the full tree's definitions written into a metric dictionary or semantic layer, reviews wired into standing WBR/MBR/QBR cadences. Several weeks to establish, then a standing job.
- Default rung: the driver tree.
- Move up to the full tree when:
- two teams dispute an owned number
- planning needs activity-level decomposition to size headcount and budget
- The efficiency order starves the encoded framework: highest value, highest effort, loses every round. Its promotion condition:
- recurring dashboard disagreements on the same metric
- more than one BI tool serving the same numbers
- Below that threshold, encoding is premature centralization.
## Top of the Tree
- Revenue itself is usually a poor North Star: it lags, reporting that growth happened without showing where to intervene. A well-chosen top metric leads revenue. Sean Ellis's definition: the single metric that best captures the core value the product delivers to customers.
- The top metric should sit one level out of reach - moved only through its inputs, never directly (Cutler: "If you can move your North Star directly, it's probably not a good North Star"). A North Star alone is not operable; it needs its 3-5 input metrics to mean anything.
- Common defensible tops:
- NRR or the ARR waterfall for B2B subscription
- a usage/consumption outcome plus RPO for usage-based
- repeat-purchase or cohort-retention outcomes for B2C
- Published company examples in [references/stage-and-model-gating.md](references/stage-and-model-gating.md) - treat them as illustrations, not benchmarks.
- Growth-framework vocabulary, if the user brings it:
- AARRR (McClure, 2007): tags effort to funnel stages, useful as a coverage check, not a tree.
- RARRA reordering: encodes the same retention-before-acquisition priority the stage gate applies.
- Reforge growth loops: model compounding growth mechanics as their own spreadsheet metric tree, a sibling artifact for the growth team, not a replacement for the revenue tree.
- David Skok's "A High Growth SaaS Playbook - 12 Metrics to Drive Success" (SaaStock NYC, 2018): a sequential layer stack from bookings through funnel metrics, salesforce metrics, sales/marketing alignment, and churn - use as a coverage check for which metric categories a SaaS business needs, not as this skill's decomposition structure.
- If the user insists on a single composite number with no decomposition, state the Cutler caution once, then build the shortlist rung well rather than a tree badly.
## Candidate Designs
Brainstorm before recommending. Present 2-3 candidate trees, each specified as:
- top metric
- the 3-5 drivers with their decomposition operator
- where ownership would sit
- what the design optimizes for
- its standing maintenance cost
Follow with a trade-off comparison and one recommendation with reasoning. Candidates should genuinely differ, e.g.:
- NRR-topped, retention-weighted
- ARR-waterfall-topped, acquisition-weighted
- North-Star-usage-topped, PLG
Not three paint jobs on one design.
This menu is generated per engagement, so it carries no fixed efficiency ranking: rank the candidates for this user by fit to their Interview answers (revenue mix, stage, model), and say which answer drove the recommendation.
## Tree Design
- Four decomposition operators cover practically every case. Pick per node from the arithmetic, not from taste:
- **multiplicative**: Revenue = Traffic × Conversion × AOV
- **additive**: Net New ARR = New Logo + Expansion − Churn − Contraction
- **funnel/ratio**: stage-to-stage conversion, coverage = qualified pipeline / target
- **input/output**: controllable inputs feeding an outcome
- Branching factor: one top metric, 3-5 drivers, 2-3 team-owned metrics per driver. Stop decomposing once a leaf is a metric one team can move within a week.
- Cycle-time chain test, applied per node:
- activity-level leaf: should move same-day
- team metric: within the natural business cycle
- driver: within the reporting period
- If the chain doesn't hold, the tree is decorative rather than causal.
- Composites must decompose. NRR is itself gross retention + expansion − contraction; a tree that stops at NRR gives teams nothing to pull. Same for Rule of 40, magic number, and any ratio: expose the numerator and denominator as their own nodes.
- Worked trees - a full B2B SaaS ARR tree with owners and guardrails, a B2C subscription/repeat-purchase tree, a usage-based variant, and a negative example that fails reconciliation - are in [references/worked-metric-trees.md](references/worked-metric-trees.md).
## Ownership and Guardrails
- Name a single directly-responsible owner per branch - the accountable decision-maker for the number, not necessarily the person doing the work. A company-level metric should also exist at the functional level with a functional owner; a metric nobody below the exec team owns is a scoreboard, not a lever.
- Split owner from steward where the org can:
- **Owner**: answers for the number's performance.
- **Steward**: answers for its definition and data quality.
- The steward can differ from the owner without violating single ownership - they own different things.
- Attach 2-3 guardrails at the level of the input metrics, riding alongside them - not bolted onto the top metric as an afterthought. Standard GTM pairs, Grove's method, and the named laws are in [references/guardrail-pairs.md](references/guardrail-pairs.md).
- Write the gaming decision rule into the framework itself: an owned metric rising while its paired counter-metric falls for two consecutive review cycles is treated as gaming, not improvement - escalate, never reward it.
## Altitude and Cadence
Map every metric in the tree to the level that reviews it and how often. The scaffold (adapt the metric-to-altitude mapping per business; the mapping below is a starting point, the cadence structure is Amazon's documented practice):
| Altitude | Typical metrics | Cadence |
| ------------- | ------------------------------------------ | ------------------------- |
| IC / team | Activity leaves, one owned driver input | Daily / weekly (WBR) |
| Function head | Driver metrics, efficiency ratios | Weekly / monthly (MBR) |
| Executive | Top metric, NRR, Rule of 40, burn multiple | Monthly / quarterly (QBR) |
| Board | ARR growth, net ARR, cash, Rule of 40 | Quarterly |
- Enforce the 5-7 cap per altitude. The same tree serves every level; each level sees its own slice, not the whole tree.
- A metric owner presents insight at the review, not the number - reading the figure aloud is the failure mode the cadence exists to prevent.
- Cadence tiers check different things, monthly vs. quarterly:
- **Monthly**: checks execution, changes behavior.
- **Quarterly**: checks strategy, changes the plan.
- A monthly meeting that quietly acquires quarterly authority (changing quotas, territories) destroys the plan the quarterly tier is supposed to test - state each tier's decision rights in the framework.
- A metric can be green at one altitude while hiding a real problem one level down - which is exactly why every altitude's slice must connect to the slice below through the tree's math, not through summary judgment.
## Stage and Business-Model Gate
Run every candidate metric through two gates before it enters the framework; full tables in [references/stage-and-model-gating.md](references/stage-and-model-gating.md).
- **Stage gate.** Which metrics matter shifts by funding stage:
- pre-seed: activation and retention lead
- Series B: NRR and fully-loaded LTV:CAC arrive
- growth stage: Rule of 40 and burn multiple
The governing rule:
- early-stage: a pass on efficiency metrics, never on retention
- late-stage: a pass on growth rate, never on efficiency
Enforcing a metric too early (unit economics pre-PMF) is as much a design error as adopting one too late.
- **Model gate.** ARR/NRR conventions were built for committed monthly subscriptions and degrade as commitment weakens:
- usage-based: RPO and committed-vs-consumed tracking, alongside or instead of NRR
- marketplaces: GMV with take rate (GMV alone is vanity)
- B2C transactional: cohort curves and the contribution-margin stack
The tree's math, ownership discipline, guardrail pairing, and altitude capping transfer unchanged across models - only the atoms change.
- Every definition stub the framework hands to governance must disclose its method choices where methods genuinely diverge: which NRR method (cohort vs. formula), how overage revenue is treated, what ARR excludes. A metric without these disclosures is not comparable across periods, let alone companies.
## B2B and B2C
- **B2B subscription:** the tree is retention-weighted - NRR/GRR and the ARR waterfall on top, pipeline drivers (coverage, win rate, deal size) under the new-logo branch, and expansion and churn drivers under the retention branch. Logo retention and dollar retention are separate nodes; netting them hides opposite dynamics.
- **B2C subscription/transactional:** the tree is repeat-purchase-weighted - cohort retention curves (they must flatten; great ones smile), repeat purchase rate, DAU/MAU where frequency genuinely matters, and the CM1/CM2/CM3 contribution stack as the efficiency spine. Prefer contribution-margin LTV and cohort curves over point-estimate LTV formulas, whose inputs are interdependent rather than independent.
- What is identical in both, and worth saying so:
- reconciling decomposition
- single-owner branches
- Grove guardrail pairs
- the 5-7 cap
- the relative leading/lagging test
- the two-cycle gaming rule
- A B2C framework is not a B2B framework with different labels - but the design method is the same method.
## Output Shape
The deliverable is an artifact set, presented one artifact at a time for validation:
```
metric-tree.md : the tree - each node with name, operator, parent math,
leading/lagging role relative to its parent
ownership-map.md : per branch - owner, steward (if split), altitude,
review cadence, decision rights of that review tier
guardrail-register.md : per owned metric - its paired counter-metric, the
harm it watches for, the two-cycle escalation rule
gating-notes.md : stage/model gate results - what was struck as
premature, what is scheduled to enter and when
definition-stubs.md : per metric - proposed calculation, method disclosures
(NRR method, overage treatment, exclusions), sample
window; handed to the data-governance skill to house
```
## Pass Threshold
- Every parent node reconciles as the stated sum, product, or ratio of its children; no orphan metrics float beside the tree.
- Every branch has exactly one named owner; every metric spanning two teams has been re-cut at the handoff, not shared.
- Every owned metric has exactly one paired counter-metric, and the two-cycle escalation rule is written down.
- No altitude's slice exceeds 7 metrics; every level's slice connects to the one below through tree math.
- Every leaf passes the influenceable-this-cycle test; every node's leading/lagging role is stated relative to its parent.
- Every definition stub carries its method disclosures; every benchmark cited carries survey, sample, and year.
- The metric set survives both gates: nothing premature for the stage, nothing borrowed from the wrong business model.
Iterate until all seven hold. If ownership fights stall a branch, ship the framework with that branch's owner marked as an open decision for the named sponsor - never with shared ownership as a compromise.
## Common Failure Modes
Deliberately unranked: each row is one diagnosis with one fix, not competing options. Apply every row that matches.
| Defect | Consequence | Fix |
| ------------------------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------ |
| Single-number worship - one North Star, no inputs | Teams can't act on it; the number gets argued, not moved | 3-5 input metrics teams own; the tree is the artifact |
| Tree presented as OKR cascade | Goal-setting rigidity practitioners reject; breaks past 1-2 levels | Metrics decompose causally; goals align by negotiation |
| Jointly-owned metric | Diffusion of responsibility; misses produce finger-pointing | Re-cut at the handoff boundary; one owner per slice |
| Owned metric with no guardrail | Gamed within quarters (coverage up, win rate down) | Grove pair per owned metric; two-cycle escalation rule |
| Vanity metrics admitted | Totals and cumulative charts that only go up displace levers | Admit only metrics with a retention/quality qualifier and a parent |
| 20+ metrics per view | Nothing is key; reviews read numbers aloud | 5-7 cap per altitude; owners present insight |
| Stage-inappropriate metrics | Unit-economics theater pre-PMF; vanity growth at scale | Run the stage gate; strike and schedule |
| Blended benchmarks | Targets set from incompatible survey definitions | One survey per figure, with sample and year |
| Fixed leading/lagging labels | Metrics misclassified; "leading" dashboard full of lagging numbers | Classify relative to the parent; apply the 4DX test |
## KPIs
Track whether the framework works, not whether it exists:
- Metric disputes (two dashboards or two functions disagreeing on a headline number) trending to zero after adoption.
- Review cadences held, with decision rights respected per tier - no monthly meeting quietly changing the plan.
- Guardrail escalations actually fired when an owned metric rose against its pair - a framework whose gaming rule never triggers is either a very honest org or an unwatched register.
- Plan variance explained through the tree: when the top metric misses, the review names which branch drove it within one cycle, instead of commissioning an investigation.
## Invocation Examples
- "We're a Series B B2B SaaS. Sales, marketing, and CS each hit their numbers last quarter and revenue still missed. Design a revenue KPI framework that explains and prevents this."
- "Our board sees 14 metrics and our teams track 60. Build the hierarchy: what the board sees, what each function owns, and how they connect."
- "We're a D2C subscription brand moving from growth-at-all-costs to efficiency. Which metrics should each level track now, and what guards against gaming them?"
## Reference
- `mbfinotti/revops-skills@revenue-reporting` - write an executive/board report against this framework; that skill builds one narrative from the metric spine this one designs.
- `mbfinotti/revops-skills@revenue-data-governance-strategy` - define metrics, assign governance, and control definitions; this skill designs the metric set, that one governs its home and change control.
- `mbfinotti/revops-skills@revenue-funnel` - design the funnel model whose conversion metrics feed this tree's new-logo branch; funnel KPIs roll up into this framework.
- `mbfinotti/revops-skills@customer-health-score` - build the health score that can serve as a leading input under this tree's retention branch.
- `mbfinotti/revops-skills@revenue-leakage` - trace where revenue drops out once this framework shows a branch underperforming.