The Cascading Metrics Review
One hour a week of public metric probing that forces every leader to actually know their business
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 88%
Amazon's Weekly Business Review is not primarily a reporting meeting — it is a mechanism for manufacturing operational rigour. Because any leader might be asked to explain a variance in front of a hundred people, everyone prepares; because they prepare, they build the muscle; and because they build it, they run the same drill with their own teams. The behaviour cascades down the org from a single weekly hour.
Origin
Amazon's Weekly Business Review (later the Consumer Business Review), led by Jeff Wilke. McAllister presented Amazon Smile in it and credits Wilke with creating the environment in which such mechanisms were developed and propagated throughout Amazon.
Core principles
- 01A mechanism is a structure that produces a behaviour without anyone having to enforce it.
- 02Public accountability for variances is what makes people know their numbers — not the numbers themselves.
- 03Speed is a feature: the entire North American retail business, one hour.
- 04The effect cascades — leaders who get probed replicate the probe one level down.
- 05Product leadership is not just building new things; it is how well you operate what you've already built.
How to run it
- 1
Define one fitness function per business area
For each part of the business, identify the single metric or fitness function that defines success. The job then becomes making that number go up and to the right — not hitting a target, but going as far and as fast as possible.
Pro tip Working backwards from a fitness function is what makes prioritization tractable — it tells you what leverage means.
- 2
Run a single weekly forum covering all of them
Convene one meeting a week where metrics for every part of the business — fulfilment, support, traffic, category teams, programs — are reviewed in sequence, fast, in one hour.
Pro tip Ruthless pace is what makes the coverage possible. The meeting is a scan, not a deep dive.
Watch out Without a leader who can run it at pace, the format degrades into a multi-hour status readout and dies.
- 3
Probe variances and trends, publicly
The leader running the meeting asks about the variances and trends: why did this move, what are you doing about it. Anyone in the room might be asked.
Pro tip The value comes from the possibility of being asked, not from actually asking everyone.
- 4
Cascade the same drill to your own team
Having been probed, run the identical review with your own team so that they build the same muscle — bringing insights, understanding, and actions, not just numbers.
Pro tip This is what makes it a mechanism rather than a meeting: it reproduces itself downward without central enforcement.
- 5
Mine the operating data for the next bet
Use what the review surfaces to find things to double down on and bad things to prevent. Paying close attention to the product you already operate is a generative source of ideas, not just a defensive one.
In the wild
Jeff Wilke led a weekly forum reviewing metrics across the entire North American retail business — fulfilment, customer support, traffic, category teams, programs — in a single hour, with perhaps a hundred people in the room. McAllister presented Amazon Smile in it. Every leader arrived prepared to speak to their variances and trends because any of them might be asked.
→ The forum manufactured an operator's mindset across the whole company. McAllister then ran the same drill with his own team, and says this cascading effect is a key reason for Amazon's scale — and one of the things that visibly separates Amazon PMs from those who haven't worked in that environment.
McAllister singles out Wilke's habit of not merely announcing a decision in a meeting but spending ten seconds explaining the mental model behind it — the pattern that made it the right call.
→ Teaching the abstraction rather than the ruling means the person can apply it to future situations, understands the reasoning, and can disagree-and-commit more genuinely than someone handed prescriptive advice.
Common mistakes
Treating the review as reporting
If the meeting is a status readout, it produces nothing. The output is not the numbers — it is the preparation, and the operational muscle that preparation builds across the org.
Announcing decisions without teaching the model behind them
As you get more experienced you increasingly just know the right answer. Handing down the answer produces compliance; spending ten extra seconds on the why produces someone who can make the next call themselves.
Treating product leadership as only building new things
How well you run what you've already built is half the job, and the operating data is where ideas for the next thing come from.
Is it for you?
Best for
Product and business leaders who want operational rigour and metric ownership to propagate through an org without policing it personally
Not ideal for
Very small teams or early-stage startups where the metrics are too few and the org too flat for a cascade to have anything to cascade through
From the transcript
“all those leaders to build these muscles because you wanted to be prepared to speak to the variances or Trends in your business in a…”
“so that was a mechanism which is another really big thing at Amazon that led to all these like amazing behaviors”
“being a product leader is not just about building new things it's about you know how well you run which you've already built”
From the episode
What it takes to become a top 1% PM
Ian McAllister (Uber, Amazon, Airbnb)