Knowing the audience for an analysis

Why this matters

An analysis that nobody understands changes nothing. The same result, say that customer churn rose in one segment, needs to be told differently to a chief executive deciding on budget, a marketing manager planning a campaign, a data engineer checking the pipeline, and a regulator reviewing a process. Each needs a different level of detail, different language and a different starting point.

The exam's objective is to communicate results by selecting methods for different audiences. This lesson covers the main audiences, what each needs to decide, leading with the answer, handling technical language, and anticipating questions.

The lesson

Executives, managers, technical peers and the public

Audiences differ in what they know, what they need and how much time they have.

Executives make strategic decisions with little time. They need the conclusion, its impact on the organisation, and what is being asked of them, usually on a single page or in the first minutes of a meeting. They rarely need method, and they will want to know how confident the finding is.

Managers and business stakeholders make operational decisions in their own area. They need results broken down by the dimensions they manage, such as region, product or team, with enough detail to act on, and they know their domain better than the analyst does, so they will spot results that do not match their experience.

Technical peers, such as other analysts, data scientists and engineers, need the method, the data sources, the assumptions and the code, so they can check, reproduce or build on the work. They are the audience for detail.

The public and external audiences, including customers, regulators and the press, need plain language, careful claims and context, and anything published externally needs the most careful review, because it cannot easily be taken back.

Most analyses have more than one audience, which is why the same work is often delivered in layers: a summary for decision-makers and a technical appendix for reviewers.

What each audience needs to decide, and how much detail helps

The most useful question to ask about any audience is: what decision will they make with this? The answer sets the content.

A regional manager deciding where to focus next quarter's sales effort needs results by region, with the size of the gap and some sense of whether it is growing. A detailed description of the cleaning steps does not help that decision, and may bury the part that does.

Detail should be proportionate to the decision. Too little, and the audience cannot trust or act on the result. Too much, and the conclusion is lost. The practical approach is to include what the decision needs in the main message, put supporting detail where those who want it can find it, and leave out what serves neither.

The same principle applies to precision. An executive needs "about 12%", not "12.347%". False precision implies certainty the data does not have, and it distracts from the conclusion.

Leading with the answer, then the evidence

Many analysts present in the order they worked: the question, the data, the method, the results, and finally the conclusion. For most audiences this is backwards. Busy readers stop before the end, and the conclusion is the part they needed.

The alternative is to lead with the answer: state the conclusion first, then the evidence that supports it, then the detail for those who want it. This is sometimes called the pyramid principle or bottom line up front. An executive summary works this way: three or four sentences that could stand alone.

A good opening states the finding, its size and its implication in one sentence: "Customer churn in the Business segment rose from 8% to 13% this quarter, concentrated in the North region, and is likely to reduce annual revenue by about £400,000 if it continues." The evidence follows, and the reader can stop at any point having learned the most important thing first.

Technical language and when to translate it

Technical terms are precise and efficient among people who share them, and opaque to everyone else. "The difference was statistically significant at the 5% level" is exact for an analyst and meaningless, or misleading, to many managers, who may hear "significant" as "large".

Translating means replacing jargon with plain statements of what it means for the audience: "a difference this large would be very unlikely if there were really no difference between the regions". Where a term is necessary, define it once. Acronyms should be spelled out on first use.

Translation must not change meaning. Simplifying "correlated with" into "caused", or "the forecast range is 900 to 1,300" into "we will sell 1,100", makes the message clearer and wrong. The test of good translation is that a technical reviewer would agree the plain version is true.

Anticipating the questions an audience will ask

Every audience asks questions, and the most predictable ones should be answered before they are asked, or at least prepared for.

Common questions include:

• Compared with what? A number alone means little; last year, target or another region gives it meaning.
• How sure are you? The confidence in the result and the main uncertainty.
• Where did the data come from, and is it complete? Sources, coverage and known gaps.
• Why? For any change or difference, the explanation, or an honest statement that it is not yet known.
• What should we do? The recommendation, if one is appropriate.

Managers in particular will test results against their own experience. A finding that contradicts what they believe needs stronger evidence and a clear account of why the data shows it, and when a domain expert says a number looks wrong, that is often worth investigating before presenting, not after.