Adapt an output to its audience and compare versions with criteria

A customer success manager receives the release notes written by the engineering team: ticket numbers, database terms, bug fixes. She has to send an update to receptionists and practice managers at three hundred clinics, who aren’t technical. She asks Claude to rewrite it “more formally and polished for customers.” The result is elegant and just as technical.

Adapting isn’t polishing. It’s changing what is said depending on who reads it.

Adapt: say who reads and what they need

To adapt an output, the request has to describe the intended audience and what that audience needs to get from the text:

• Who they are: “clinic receptionists and practice managers, with no technical background.”
• What matters to them: “what will look different on screen, whether they need to do anything and from when.”
• What to leave out: “no ticket numbers or internal system names.”

With that, the request becomes: “Write an update for non-technical clinic staff: what changes on screen, whether they need to do anything and when. Ten lines maximum. Leave out the ticket numbers.”

Cutting it in half while keeping the technical terms, or sending the original with a glossary, doesn’t solve the problem: the reader still has to translate.

After adapting, check the meaning

Simplifying is where meaning changes most easily. A fix that “prevents duplicate appointments in certain cases” can turn into “appointments no longer get duplicated.” Before sending:

• Compare each statement in the adapted version with the original.
• Make sure nothing the reader needs was lost (a required action, a date).
• Make sure nothing was added that the original didn’t say.

To refine afterwards is to ask for targeted adjustments: “the second point is too general; make clear it only changes in the weekly view.”

Compare: criteria before taste

Sometimes there are two versions: one written by a person and another by Claude, or two Claude drafts. A strategy lead has to send the board a one-page summary of a market study. A colleague’s version is more cautious and a bit longer; Claude’s reads better and opens with a bold recommendation. The board chair asked for three things: the main risks, the investment required and a clear recommendation.

To compare outputs, use explicit criteria:

1. What the audience asked for. Does each version include risks, investment and a recommendation?
2. Accuracy. Do the figures match the study?
3. The requested format. Does it fit on one page?

With that grid, one version may win, or it may make sense to combine: the better-developed risks from one with the clearer recommendation from the other, all checked against the study.

Criterion for choosing	Useful?
What the reader needs	Yes
Accuracy against the source	Yes
Which sounds better or more confident	No: style doesn’t say whether it’s right
Who wrote it (person or AI)	No: both can have errors
Having Claude score both	No: it doesn’t replace your check against the source

Common traps

• Asking for “more formal” or “more polished” when what changes is the reader.
• Shortening without saying for whom.
• Not checking the meaning after simplifying.
• Choosing the version that reads better or the one that opens most confidently.
• Assuming the human version is always more reliable, or the reverse.

On the exam

If the scenario asks to take a text to another audience (technical to customers, detailed to the board), look for the option that says who reads and what they need, and that includes checking the result against the original. If there are two versions to choose from, look for the one that measures them against what the audience asked for and against the source, and that allows combining parts. Rule out the ones that decide by style, by author or by the model’s own score.