Stop announcing features, announce what changed for the reader
An announcement that names a feature is a press release. An announcement that names what changed in the reader's day is a useful one. A short field note on what we'll publish under 'shipped' from now on.
We have a category convention that I want to argue against, and I want to argue against it on this blog because I am going to start violating it on this blog.
The convention is: when a vendor ships a feature, the announcement is structured as we shipped X. The headline names the feature. The body describes how the feature works. There is a screenshot. A “learn more” link points to the marketing page. Done.
The structure is wrong. It treats the feature as the news. The feature is not the news. The news is what changed in the reader’s day.
Here is the test I want to apply, going forward, to every “shipped” post we publish under the PursuitAgent byline.
Before I publish, I read the post and ask: if a reader does not use PursuitAgent, did they get anything from this post?
If the answer is “no,” the post is a press release. It does not belong on a blog that purports to be useful.
If the answer is “yes,” the post belongs on the blog. The reader who doesn’t use PursuitAgent got a description of a workflow problem and one specific way to address it. They learned something they can use, even if they don’t buy from us. The reader who does use PursuitAgent got the same thing, plus the news that they don’t have to do that workflow manually anymore.
That second reader is well-served by both versions. The first reader is well-served only by the version that names the workflow problem first.
The two versions look like this in practice.
Version one (press-release shape, what I’m going to stop writing):
We shipped the inline verify button. Hover any drafted sentence and a verify icon appears. Click it for a side panel with the source and the entailment trace. Live now. [Learn more.]
Version two (problem-first shape, what I want us to write):
Reviewers reading a drafted proposal need to confirm that each sentence is grounded in a real source before they approve it. The standard workflow is to keep two browser tabs open and toggle between them — slow, error-prone, and ungenerous to the reviewer. We shipped a hover-and-click affordance that surfaces the source and the verifier’s trace inline. The reviewer’s job stays in one tab. [Engineering writeup of the entailment trace.]
The first version assumes the reader cares about us. The second version assumes the reader cares about the work. Only the second one earns an outside reader.
This is not a stylistic preference. It is the core of why our blog exists. The voice doc is explicit on this — vendor blogs sell, and we are not interested in writing one. But the temptation to slip into press-release shape is constant, especially for short shipped-X posts that feel like they don’t deserve much editorial work. They do.
Two operating rules I’ll hold us to going forward.
The headline names the change in the reader’s work, not the feature. Not “Shipped: inline verify button.” Closer to “Shipped: reviewers no longer toggle tabs to verify a citation.” Sometimes the feature name is the right headline because the feature name is itself a workflow change. Most of the time it isn’t, and the test is whether the headline reads as useful out of context.
The body describes the workflow problem before it describes the feature. One paragraph minimum. If the workflow problem is too small to fill a paragraph, the feature is too small to announce. (Both are fine. Some shipped things don’t need a blog post.)
This applies to us. It also applies to how I read other people’s announcements. When I read a vendor’s “we shipped X” post and learn nothing about what changed in someone’s day, I have learned something about the vendor — they think the feature is the news. It usually isn’t.