Reading a Velocity Heat Map Live

Case study in the series behind How I Whiteboard Product Interviews Live. Method: The Live Whiteboard Method.

Want the metrics themselves? The companion reference Five Engineering Velocity Metrics, and What to Actually Do About Them breaks down each one and the fix that moves it.

This one was not an interview. It was a live value-advisory session I ran for an engineering-intelligence platform, conducted like a real fifty-minute client call, with the end client anonymized here as "ACME Health." The goal they gave me, in their own words, was: "We want our Patient Experience teams to release higher quality work even faster." On the table was a grid of engineering-velocity data: five metrics across three teams. Fifteen numbers, and one question underneath all of them: which problem do we solve first?

Here is how I read it live.

I turned a table of numbers into a picture

Fifteen numbers in a grid is a spreadsheet, and a spreadsheet does not make an argument. So the first move was to turn the five-metric by three-team table into a colored heat map: hot cells for the painful numbers, cool cells for the healthy ones. The instant you color the grid, the eye goes straight to the trouble. The diagnosis arrives before anyone says a word.

I also refused to leave the metrics in their technical names, because the people who need to act on them do not think in them. So each metric got a plain-English nickname right on the board:

• Cycle Time became Ship Faster.
• PR Success Rate became Waste Less Work.
• PR Review Cycles became Avoid Approval Pong.
• Rework Rate became Fix and Adjust Less.
• Traceability became Stick to the Plan.

"Avoid Approval Pong" tells a room what the metric means and why they should care, in three words. The technical name does neither. Memorable beats precise when the job is to align people, and aligning people was the whole job here.

I put my thinking in the margins

As I read the hot cells, I did not keep my reactions in my head. I dropped small margin stickies next to the data as I went: "why is this taking so long?" next to a slow cycle-time cell, "this feels borderline KTLO" next to a team whose effort looked like keeping-the-lights-on rather than progress, "surprising" next to a number that did not match the story I expected.

That is the visible-cognition move, and it does real work in a client session. Hidden reasoning reads as a magic trick. Visible reasoning reads as judgment. The stickies also invite the client in: a "surprising" tag is an opening for them to say "oh, that is because of the migration," and now we are diagnosing together instead of me presenting at them.

I prioritized on a 2x2 with axes spelled out in plain language

From the heat map, I built a 2x2 to make the tradeoff legible. The vertical axis ran from Higher Pain and Impact down to Lower. The horizontal axis ran from Less Feasible to More, where "more feasible" meant something specific and unglamorous: we can begin solving this tomorrow. Not "is it easy." Can we start now, with what we have.

Spelling the axes out matters because "feasibility" is the kind of word people nod at and interpret five different ways. Defining it on the board as "we can begin solving this tomorrow" forces an honest answer.

Each metric became a How-Might-We, and one won

To move from diagnosis to action, I reframed each painful metric as a How-Might-We, so a problem became an opening: "how might we cut the review cycles a PR goes through?" Placed on the 2x2, one rose to the top: PR Review Cycles, our "Avoid Approval Pong." It was both the highest pain and the most feasible. Highest pain because it was dragging every team's throughput. Most feasible because we could start on it tomorrow without waiting on a platform migration or a hiring plan.

The pick was not a matter of taste. The board made it for me. A stakeholder could see why it beat the others before I argued for it.

I sequenced it as Now / Next / Later, with a hypothesis I could be wrong about

The plan took the shape of a Now / Next / Later roadmap, anchored to a falsifiable hypothesis: "we believe doing some of the below leads to faster releases with higher quality." That word "believe" is deliberate. It is a bet we can check, not a promise we have to defend. If the review-cycle work ships and releases do not get faster, the hypothesis was wrong and we learn something, which is exactly what you want from a first experiment.

The oversized sticky that steered toward the truth

One sticky on the board was deliberately bigger than the rest: "What hasn't worked?" I sized it up on purpose, because in a client session the most valuable answers hide behind the most uncomfortable question. Teams will happily tell you their wins. The signal is in the things they have already tried that failed, and an oversized sticky gives a client permission to go there. The size of a sticky is a way of steering the conversation without saying a word.

What the board was really showing

No proprietary framework, just a way of reading data that someone else can follow:

• Turn a table into a picture so the diagnosis is visible, not asserted.
• Rename metrics into things a room remembers and repeats.
• Put your reasoning in the margins so people can argue with it and join in.
• Define your prioritization axes in plain language instead of nodding at "feasibility."
• Sequence into Now / Next / Later with a hypothesis you are willing to be wrong about.

Fifteen numbers are a table. A heat map is a decision. Color did the arguing for me.

If you want to see this live, bring me a real product problem and watch me whiteboard it end to end: that is the Watch Me Think offer. To practice the method yourself, the Whiteboard Prompt Translator scaffolds the six frames from any prompt.