Manager Brief

Release communication:
what's likely missing

The problem you're holding: Glean ships every 2 weeks, clients don't absorb what's newly possible, and renewals lose their value story.

The one reframe: sending an update was never the job. Getting the right person to absorb "what's newly possible for me" is. So flip the metric. Stop counting updates sent, start counting % adopted (segmented, since some niche features shouldn't hit high adoption anyway). That gap is your leading health indicator.

(The same failure recurs across every frequent-shipper I looked at, from legal-update binders to Salesforce: the update gets distributed but never consumed.)

What a standard approach (changelog, digest, account-team mentions) misses

Four things. The last is Glean-specific. This is the "on top of what your team already does" value.

AI releases are often invisible

A model, retrieval, or permissions change shifts answers with no feature to announce, and clients feel it before you tell them.

Glean needs an "AI-change" lane: what shifted, what you may notice, the eval bound, and how to flag a bad answer. It also needs a way to talk about the occasional quality dip, because announcing only wins spends trust you'll need.

Caveat: a permissions change that surfaces the wrong document is a security incident, not a feature note. It routes through legal and security, not the comms team.

Comms die on the client's receiving side, not yours

Enterprises take in change through gates: IT change boards, freeze windows, security/legal/procurement review.

A great announcement that doesn't fit their intake never lands. Security and legal aren't audiences to inform. They're gates that can block the whole release. Format the must-act items to drop into their change process, and pre-clear the gates with a standing data sheet.

Plain usage numbers lose renewals

"Glean saved ~Y hours" collapses the moment procurement asks: would that have happened anyway?

The answer that survives is a team measured before vs. after they got a feature, or a department that has it vs. one that doesn't. That second department can also become a directional expansion proof once the numbers are validated.

Honesty point: this measures usage, not business outcome, so "hours saved" needs a number the client agrees to, or it's labeled an estimate.

The 4th is Glean-specific: tell agent owners their agent got better

Glean has the knowledge graph and agent library, so a release could map to the specific agents a person built.

Once the platform traces release→agent (an engineering build, not a feature Glean has today):

Glean could tell an owner: "this update makes your agent X do Y better," across the agents they own.
No champion can do this. Tracing which release touched which agent is a connection only the system can compute.

Two rules keep it safe: every "better" claim carries a real number, and you tell them the bad news too ("this changed your agent, re-check it"), or one over-promise kills trust. (Not unique. Microsoft Copilot has similar plumbing, and it needs an engineering build to trace release→agent, so it's not free.)

Your first move (30 days)

Run the 29-row Self-Audit (≈20 min, one sitting, no prep). Hand it to one CSM (customer success manager) if you'd rather not run it yourself. For each row tick we do / partial / we don't. Expect strength on the standard rows (1–13) and blanks on rows 14–24: the AI-release lane, the receiving-side gates, and the agent-owner notifications. That's the differentiation.
Start measuring adopted-vs-shipped on the top 5 features. Expect real adoption lower than assumed. That number reframes the conversation, and it's your line to your leadership.
Ship one cheap win now: benefit-framed copy ("you can now do X," never "bug fixes & improvements") plus one lead item at the top of each digest. Minimal tooling, a copy and ordering change.

What it costs: the first move is ~30 days, mostly your existing digest. Today's CSM/PMM (customer-success / product-marketing) can run the audit. The one genuinely new role is the Release Editor (the decision below). The AI-change and agent-owner lanes need engineering time, so book that separately (roughly 1–2 engineers for a quarter). How you'll know it's working: the adopted-vs-shipped number.

Open the interactive self-audit →

The one call only you can make

Who owns the curated update each cycle?

Recommendation: fund one person (a "Release Editor") to produce a single artifact centrally; client champions only relay it, never write it. Decide this before building anything else. Unowned, the whole thing silently collapses (the way the loose-leaf legal-binder industry lost its distribution: updates shipped, nobody filed them, the publisher never knew).

Honest caveat: built without Glean's real channels or adoption data. It's analogical reasoning, pressure-tested from several angles, not Glean ground truth. Treat it as a tested-by-Friday starting point, not gospel. The self-audit is the test, and it's fast: it shows what's genuinely new here versus what your team already does well. Several mechanisms also assume platform capabilities worth confirming exist (intent-matching, a release→agent map, historical telemetry) before promising them.