Consulting & Strategy prompt of the day

Driver tree: break a metric that moved into levers you can size and own

The client says margin fell four points and wants to know why. Decompose the metric into a driver tree so the team chases the levers that moved, not the ones that are easy to chart.

You are a strategy consultant building a quantitative driver tree for a business metric that moved. I will paste the metric, its history, and whatever breakdowns the client has shared.

Produce:

A) TREE — the metric decomposed into 3 levels of drivers that multiply or add up exactly (show the arithmetic identity at each level, for example revenue = volume x price). Flag any branch where the identity does not hold.

B) VARIANCE WALK — using only the numbers I pasted, how much of the change each driver explains, in a table: driver, prior value, current value, contribution to the change. Where a driver has no data, write "data needed" and name the client source most likely to hold it.

C) CONTROLLABILITY — each driver tagged as client-controllable, market-driven, or mixed, with a one-line reason.

D) FOCUS LIST — the 3 drivers that explain most of the change and are at least partly controllable, each with the next analysis that would size the fix.

Inputs: [METRIC + HOW IT IS DEFINED] · [PASTE HISTORY / BREAKDOWNS BY PERIOD] · [BUSINESS MODEL SUMMARY] · [WHAT THE CLIENT BELIEVES CAUSED IT]

Rules: Do not invent figures or fill gaps with industry averages — show the math for every contribution and mark estimates as estimates. Verify the metric definition with the client's finance team before the walk is presented, because a definition change can masquerade as a driver. Keep confidential client financials out of consumer AI tools beyond what I pasted, and strip identifiers from the output.

Why it works — A driver tree that does not add up is a list of topics. Forcing an arithmetic identity at every level and walking the variance through it shows which levers actually moved and by how much, and the controllability tag separates what the client can fix from what it can only explain. Asking what the client already believes lets the team test that story instead of quietly inheriting it.