Anatomy of a board appendix

A board appendix is not a product review. It is not a data dump. It is a dated decision document that should still make sense if the live dashboard is down. We keep seeing forty-slide packs that fail that test.

Page one: the spine

One paragraph. What changed, what you want the board to notice, and whether you are asking for a decision or only filing a watch. If this paragraph needs a screenshot to be intelligible, rewrite it. The spine is also where you date the data: “Week 32, through Sunday 23:59 ICT.” Undated charts are how quiet disagreements start.

Pages two and three: health with grain

Seven numbers, not twenty. Each with a window and a comparison (prior four weeks, or same week last year if seasonality matters). Split by platform only when a platform actually moved. A blended “app health” index is almost always a way to hide an iOS checkout problem under Android volume.

Page four: exceptions

This is usually where honesty starts. Three items, each with an owner and a next check date. “Checkout conversion on iOS 18.5, −11 points, owner: Pim, recut Friday.” If nothing exceptional happened, write that sentence. Empty exception logs are more trustworthy than invented amber tiles.

Page five: commercial bridge

How the product numbers relate to contribution margin or another money metric the CFO already believes. This page is short on purpose. If you cannot draw the bridge, do not invent one; say the commercial translation is not ready. Pretending every engagement lift is revenue is how product and finance stop speaking.

What we delete

Raw funnel screenshots with no commentary. Heatmaps. A/B test galleries that belong in a product forum. Staff NPS. Any chart whose title is a tool name (“Mixpanel — Overview”). Tool names are not metrics.

The Board-Ready App Metrics studio spends two modules on this anatomy and one live critique on your actual pack. Bring a redacted version if your legal team insists. The deletions are the same either way.

All field notes