Launch Tier

Plenty of teams used to run the same routine for every shipment. Changing the wording on one button meant rewriting the help article, posting an internal announcement, drafting support answers, and collecting sign-off from four teams. A team that ships 200 changes a year did that 200 times.

Two things happen when that goes on. First, people start skipping the process. Pagedeck kept a single release checklist at the beginning, and within two months everyone opened it, ticked every box, and moved on. Nobody was actually checking anything.

The second effect lands outside the company. Email a customer about every trivial change and they learn to ignore that sender. Then the day you ship the feature that took six months to build, they don't open that one either. The value of an announcement drops in proportion to how often you send one.

Launch tiers exist to block both at once. The team declares up front that releases will not be treated equally, and decides by rule rather than by mood which ones get the full treatment. The decision moves out of the week of the release, when whoever built the feature is closest to it and least able to judge how much of the company's attention it deserves, and into a short set of criteria agreed on while nothing is pending.

Pick a small number of grades — usually three — and attach a fixed bundle of activities to each. When a release comes up, the grade gets settled first and the matching bundle comes out as a set.

1. Tier 1 is a release that says the company changed direction. It gets a press release sent to media, a webinar where customers are walked through it live, a dedicated landing page, and fresh material for the sales team. Two or three a year is a lot.
2. Tier 2 is a feature existing customers will notice. In-product notices, a customer email, updated help articles, and internal enablement — getting sales and support to the point where they can explain the feature — all happen here. Expect two or three a month.
3. Tier 3 is everything else. One line in the changelog, the running list of what changed and when, and that's the whole job. Bug fixes, copy cleanups, and speed work live here.

The dividing lines vary by team, but three questions usually decide it. What share of customers this affects, whether customers have to change how they work, and whether anyone would sign a new contract because of it. All three, and it's tier 1. None of them, and it's tier 3. Writing the questions down is what keeps the grade out of the hands of whoever argues hardest in the room, and it also means a newcomer can grade a release on their first week without asking anyone.

Settling the grade first matters, because the grade determines the length of the launch checklist — the list of things that must be finished before shipping. Tier 1 runs past twenty items, tier 3 has two. Open the checklist first instead and every release goes back to weighing the same.

It's the first thing said when release dates get set. Agreeing on the tier before the date is what tells each team who prepares what and by when. Call something tier 1 and marketing needs its four weeks; call it tier 3 and a day's notice is fine.

The grade is also an input to the launch plan, the document that lays out which posts, screens, and emails go out on which day. Without a tier, that document starts from a blank page every time.

Quarterly roadmap reviews use it too. Counting grades is a cheap way to see a problem months before it lands. No tier 1 next quarter means there's no story to tell customers; four of them means marketing can't absorb the load. If one tier 1 costs three weeks of one person's time, two per quarter is the ceiling, and the third arrival pushes one of the others down a grade or into the next quarter.

Pricing decisions pull it in as well. A feature limited to paid plans ships alongside plan descriptions and a notice email, so it can't go out quietly at tier 3. Many teams bump anything that changes what customers pay for up one grade regardless of size.

"What tier are we calling this? I was thinking tier 2."

A question about workload, not about the feature. It sets the schedule and who gets pulled in.

"Tier 1 means a press release, so we need three weeks minimum."

The grade is the marketing lead time. Moving the date earlier means lowering the grade.

"A webinar for a tier 3? Then raise the tier."

Don't bolt on work the grade doesn't include. If it's needed, re-grade the release itself.

At Pagedeck preparation starts when Mia names a grade in the review two weeks out. For the permissions release she called tier 2 and Ravi argued for tier 1, because it was the item that kept stalling enterprise contracts and there were real companies waiting to sign. The grade went up, the date slipped by two weeks, and a press release and landing page came with it.

It runs the other way just as often. When Theo ships a performance improvement at tier 3, one changelog line that day is the end of it, and nobody feels shortchanged. The team already agreed that a low grade doesn't mean low-value work. Mia keeps the running count somewhere visible, so when a fourth tier 1 shows up in the same quarter the conversation starts from what has to move rather than from whether marketing can stretch.

The most common mistake is reading the grade as an importance score. Tier 1 sits above tier 3, so the assumption comes naturally. What the grade actually measures is how much there is to explain to customers. Replacing the entire database and cutting outages in half is still tier 3 if customers have nothing to do about it. Once grades read as importance, engineers start fighting every tier 3 label, and within six months everything is tier 1 and the system is gone.

Treating the grade as unchangeable is the other one. Scope shrinks or grows as a release approaches, and the grade moves with it — all it takes is one scheduled recheck. Teams that believe the first call is final start naming high grades defensively, and then releases that needed no lead time get three weeks of it anyway.