Getting changes to users.
WHAT A LAUNCH REQUIRES
The feature working People knowing it exists People understanding what it is for Support ready A way to measure it
WHY THE SECOND TWO MATTER MOST
Features nobody knows about are indistinguishable from features that do not exist.
WHAT TO PREPARE
An announcement, in terms of the problem it solves Documentation Briefing for support staff
WHAT TO LEAD THE ANNOUNCEMENT WITH
What it lets people do, not what was built.
WHAT PHASED RELEASE PROVIDES
Exposure to a small group first, limiting the damage of problems.
WHAT TO WATCH DURING IT
Errors Support volume Whether people use it Whether anything else broke
WHAT TO PREPARE
A way to disable it quickly.
WHY
It is the difference between an inconvenience and an incident.
WHAT TO DO ABOUT SIGNIFICANT CHANGES TO EXISTING BEHAVIOUR
Warn people in advance.
WHY
Unannounced changes to familiar things generate more complaints than failures do.
WHAT TO OFFER WHERE PRACTICAL
A period where both old and new are available.
WHAT TO DO AFTERWARDS
Measure against what you expected Gather feedback Decide whether it is finished
WHAT TO AVOID
Launching and moving on immediately.
WHY
Most features need adjustment after real use.
