# One Release, Many Readers I went looking at how Anthropic communicates Claude's releases and found three changelogs, each written for a different person. The desktop app's What is 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." It is the same product over the same weeks in three registers. The lesson is that they forked the log, one per audience. 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. Before writing any release note, I would ask where the reader is standing when they read it. 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. 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. It is the same discipline as [[The Responsible Roadmap]]: the feature is the headline, and the audience picks the typeface.