What Changed After the Release Playbook 2026

Do this in the week before the ship date:

1. Accounts it should touch: in the segment the change was built for, where your successful customers already do this kind of work, or where the account does it by hand today. Skip accounts that already meet the measure.
2. Their usage before: core usage and the success measure, over the four weeks before ship.
3. Agreed success measure: one per change, agreed by the PM and CS lead. Defaults: for a feature, used in three of the four weeks after ship; for a price change, stayed on plan or moved up; for a campaign, took the action it asks for.
4. Held back from the launch: your comparison group. Default: hold back a random one in five intended accounts from the optional announcement and guide for four weeks. Both groups keep access to the change, so this measures the announcement and guide, not the release itself. To test the feature itself, randomize access behind a feature flag and treat both groups the same otherwise. Required notices (a price or terms change, a removed or changed feature, a deprecation, a security fix they need to act on, a change to how you handle their data) go to every affected account on time, held-back accounts included. With under 20 held back, or no holdback, label the result low confidence. A comparison with the same weeks last year is descriptive: report the observed change without claiming it caused anything.

Run it as a saved query in PostHog, Amplitude or Mixpanel, or a spreadsheet. Under about a hundred accounts, do it by hand. Moving accounts onto new pricing is the pricing-migration play; this one measures the change.

Announce in-product to the told accounts only. An announcement that isn't for them is one more reason to skip the next. A campaign message goes to the same list. A price change goes to every account it applies to, with the notice your terms require.

Three steps or fewer, ending on the result the change exists for, with the customer's own data. Stop after one completion or dismissal. Skip it when there's nothing to use.

Sort the told accounts and the comparison group the same way. Check the records first: a flat line can be a broken event, and a renewal in procurement, a budget cut or a departed champion explains a drop better than the change does. Those get No move with the reason.

Each account lands in the first class that fits (defaults to tune):

• Moved the wrong way: core usage down 20% or more, a downgrade, or a complaint about the change.
• Moved as expected: met the success measure.
• Tried and dropped: started, but didn't meet the measure. Note the step where it stopped.
• No change: never started, or core usage within 10% of before.

Say you told 60 accounts and held back 15. Of the 60, 24 moved as expected (40%); of the 15, 3 did anyway (20%). (The numbers are illustrative.) Report 24 of 60 against 3 of 15: a 20-point observed gap, from the launch (the announcement and guide), not the change. With 15 held back, that doesn't show a reliable lift, so call it low confidence. A before-and-after change alone doesn't show the change caused it. Now tell the held-back accounts too. From here the comparison measures an earlier launch against a later one, so keep every account in the group it started in.

Set Recommended move to No move, reason "moved as expected", review date eight weeks after ship. No survey, no nudge – their reward for adopting is being left alone (more in the leave-it-alone play).

• Dropped: tried and dropped. Drop-off question.
• Call: no change with ARR above the segment median (default), or moved the wrong way at any ARR. CSM conversation.
• The rest: no change, below the median. The guide again, if your team has chosen to automate that move; otherwise No move with the reason.

Tried and dropped: check where and why use stopped. No change: check exposure, relevance, timing and tracking. Use those checks to choose the next move.

Shown in-product at the step where usage ended, to the users who stopped there. When three people name the same blocker, the PM has a lead: watch a few sessions at that step, or ask on the calls, before deciding the fix.

A task for the account owner with the class, usage before and after, and the matching note below. The CSM decides whether to send it. The PM joins up to five calls with no-change accounts (default), so the review isn't limited to people who answer the in-product question.

A second pass with rewritten copy, logged on the record so the review sees what went out.

At four weeks, one meeting over the change result (template below) and the call notes. Decide: fix the drop-off step, relaunch to the accounts that didn't move, or stop, and write down what evidence the decision rests on.

On each account's review date, keep three things apart. Activity: they saw it. Progress: they met the success measure. Business result: a renewal, an upgrade or a paid expansion. Compare the rate of each in the two groups, with every account in the group it started in. The held-back accounts were told at four weeks, so report the gap as the estimated effect of announcing earlier rather than later, with how uncertain it is. For a single account, use the rule in the eight-week review, and say so when you can't tell. Then feed the adopters' pattern into the benchmark the weekly check uses.