What a good executive feedback memo looks like

Most feedback readouts fail in a specific and avoidable way: they optimise for completeness when the reader needs a decision. The author, having done real work, wants to show the work. The executive, having eleven minutes, wants to know what to do.

These are not the same document, and trying to make one document serve both produces the thirty-slide deck that gets skimmed to slide four and never opened again.

Rule one: one page, and mean it

A page forces a ranking. That's not a formatting preference — the constraint is doing the analytical work. If everything fits, nothing had to be judged more important than anything else, and judging is the value you're adding.

This is genuinely painful, and worth naming as a cost rather than pretending otherwise. You will cut real findings. Some of them will matter later, and someone may point out that you left them out. Keep the long version; it's a useful appendix and a fine thing to link. Just don't lead with it, and don't let its existence talk you into a second page.

Rule two: open with what changed

The most common opening is the biggest theme. It's the wrong one, because the biggest theme is usually the one the reader already knows about. Opening there spends your best paragraph confirming something and teaches the reader that this document contains no news.

Open with the delta. What's new since last time, what grew, what went away. A memo that begins "two problems are new this month and one we shipped a fix for has stopped appearing" earns the rest of the page immediately.

The honest caveat: your first memo cannot do this. There's no previous run to compare against, so run one is a baseline and will feel less impressive than run two. Say so in the memo rather than padding it.

Rule three: every claim traceable

Any assertion in the memo should be one click from the evidence behind it. Not a footnote pointing at a methodology section — the actual customer sentences that produced the claim.

This matters more than it sounds, because the failure mode of feedback analysis is confident summary. Once feedback has been grouped and counted, it acquires an authority the underlying data may not support. Traceability is the thing that lets a sceptical reader check you instead of either believing you wholesale or dismissing you wholesale.

It also changes how you write. Claims you can't trace tend to be the ones you were least sure of anyway.

Rule four: exactly three actions, each with an owner

Three is small enough to be real. A memo ending in nine recommendations is a memo ending in zero, because nobody sequences nine things and the reader knows it.

Each action needs a name attached and needs to be specific enough to become a ticket without a follow-up conversation. "Improve checkout reliability" is a sentiment. "Instrument the CVV rejection path and reproduce the failure before the next checkout release" is an action. The test is whether an engineer could start on Monday without asking what you meant.

Rule five: say what you don't know

This is the rule people skip, and it's the one that buys the most credibility. If the feedback doesn't support a conclusion, write that the feedback doesn't support it.

If someone asks whether fixing the checkout bug will cut churn, and your data is a pile of support tickets, the correct answer is that you can't tell from this evidence. Reaching for a number there is the single fastest way to lose a room, because the one person who checks will find nothing underneath it.

A memo that admits its limits gets believed on the things it does claim. A memo that answers everything gets believed on nothing.

What to leave out

• Sentiment scores. They compress away the part you could act on — the specific failure, and who hit it.
• Volume charts. Ticket counts move with traffic and campaigns, not just with product quality.
• Methodology. Link it. An executive reading how you grouped things is an executive not reading your recommendation.
• Every theme you found. The ones that didn't make the ranking are the appendix, not the memo.
• Hedging language. "Some users may possibly be experiencing" is a sentence that survives review and helps nobody.

The test

Hand the page to someone who wasn't in any of the conversations. If they can tell you what's broken, what's changed, and what happens next — without asking a clarifying question — it works. If they ask "so what do you want us to do?", the memo failed, regardless of how good the analysis underneath it was.

This format is what GliddeSignal produces at the end of a run, which is not a coincidence — the product was built around the observation that the analysis was rarely the bottleneck. The bottleneck was the hour nobody had to turn it into one page somebody would read.