# One Release, Many Readers I went looking at how Anthropic communicates Claude's releases and found not one changelog but three, each written for a different person. The desktop app's What's New narrates every fix as the user's lived symptom: "Fixed the app quitting on macOS when the disk was full or when stopping dictation." One entry even repairs a promise in the same breath: schedules "now run on either day, as their schedule description says." The consumer release notes flip the camera around to capability: "Claude can now create custom charts, diagrams and other visualizations in-line in its responses." And the developer changelog compresses to fluent shorthand: "Added `PreModelSwitch` and `PostModelSwitch` hook events," "Fixed file tools following a symlink swapped inside the working directory." Same product, same weeks, three registers. The lesson is that they did not pick an audience. They forked the log. The engineer integrating Claude will go over every bullet and wants exact nouns. The enterprise buyer reads a fix-heavy log as a stability signal, proof somebody sweeps the floors. The consumer wants the new and shiny in one active sentence. A single register pretending to serve all three would serve none of them. The core questions I would ask before writing any release note: Where is the reader standing when they read this? The in-app log reaches someone who already updated and needs reassurance; the marketing page reaches someone deciding; the repo changelog reaches someone debugging at 2am who needs precision. Is the unit of change the symptom or the system? Name what the reader experienced, not what the code did. What does this reader do next, and does the note hand them that action? And does this reader need confidence or capability? Fixes sell trust, features sell appetite, and the ratio you publish is itself a message. Write the change once as fact, then render it per reader. Same discipline as [[The Responsible Roadmap]]: the feature is the headline, and the audience picks the typeface.