Lesson 36: Release Planning & Launch Management

Lesson 35 addressed how a roadmap's "Now" horizon connects down into actual Sprint work. This lesson addresses the final, and often most consequential, step in that chain: what actually happens when a "Now" item, having been built and tested across one or more Sprints, is ready to reach real users. This step is where a huge amount of otherwise-careful product work can be undone in a single afternoon, because the discipline required to launch something well is genuinely different from the discipline required to build it well.

A large fraction of the most memorable, embarrassing product failures in software are not failures of the underlying feature at all — they are failures of the release: a change pushed to everyone at once instead of gradually, a rollback plan that didn't exist when it was needed, a support team blindsided by a launch nobody told them about, a features flag left in the wrong state. This lesson gives you the vocabulary and tools to avoid that category of failure entirely — treating a launch itself as something to be planned, staged, and monitored with the same rigor this curriculum has already applied to backlog grooming (Lesson 34) and roadmapping (Lesson 35).

Learning Objectives

1
Distinguish a "big-bang" release from a staged (progressive) rollout, and explain the risk trade-offs of each.
2
Explain feature flags and canary releases as tools for controlling exposure, and connect them to this lesson's Blast Radius mental model.
3
Apply a launch tiering system to determine how much cross-functional coordination a given release actually warrants.
4
Design a rollback plan and explain why "we'll fix it in the next release" is not an acceptable substitute for one.
5
Identify the cross-functional stakeholders a launch checklist must include beyond engineering, and explain the risk of omitting any one of them.

This lesson assumes Lesson 32's concept of an Increment meeting a Definition of Done, since release planning begins only once work is genuinely complete by that standard — releasing something that hasn't met its Definition of Done is a distinct and more basic failure this lesson does not re-cover. It also assumes Lesson 35's roadmap vocabulary, particularly the "Now" horizon, since this lesson picks up exactly where a "Now" item's development work ends and its actual path to users begins.

Big-Bang vs. Staged Rollout

A big-bang release ships a change to all users simultaneously, at a single point in time. A staged (or progressive) rollout ships the same change to a small fraction of users first, then progressively larger fractions, pausing to observe real-world behavior at each stage before continuing.

The core trade-off is speed versus exposure. A big-bang release reaches full impact — both the intended benefit and any unintended harm — immediately. A staged rollout reaches full impact more slowly, but any problem is discovered while it's still affecting a small fraction of users, dramatically limiting the damage a bad release can do before it's caught. For most releases carrying meaningful risk (new core functionality, changes to critical infrastructure, anything touching billing or authentication), a staged rollout is the safer default; a big-bang release is more defensible for low-risk, easily reversible, or time-sensitive changes where the cost of a slower rollout genuinely outweighs the benefit of limited exposure.

Feature Flags and Canary Releases

A feature flag is a configuration switch that allows a team to turn a feature on or off (or adjust its exposure percentage) without deploying new code — the feature ships to production in a "dark" or hidden state, and its visibility is controlled independently afterward. This decouples two things that a big-bang release conflates: deploying code and releasing a feature to users. A team can deploy code continuously, with new functionality sitting behind a flag, and release it to users on a completely separate, controlled schedule.

A canary release (named after the historical practice of using canaries to detect dangerous gas in mines) is the specific practice of releasing a change to a small, often randomly selected, subset of infrastructure or users first, explicitly as an early-warning mechanism — if the canary group shows a problem, the release halts before reaching everyone else. Canary releases and feature flags are complementary: a feature flag controls who sees a feature, while a canary release strategy controls how the underlying infrastructure change is validated before wider exposure — both serve this lesson's broader principle of controlling exposure deliberately, rather than accepting whatever exposure a single, undifferentiated deployment happens to produce.

Launch Tiers

Not every release warrants the same level of ceremony. A small copy change and a new core billing flow do not carry comparable risk, and treating them identically either wastes coordination effort on trivial changes or, more dangerously, under-prepares for consequential ones. A launch tiering system classifies releases by potential impact and assigns a proportional level of required coordination:

Tier	Example	Required Coordination
Tier 1 (highest impact)	New core product surface, major pricing change, anything touching authentication or billing broadly	Full cross-functional launch review, staged rollout mandatory, rollback plan required, dedicated post-launch monitoring window
Tier 2 (moderate impact)	A significant new feature within an existing surface, a notable UI redesign	Staged rollout recommended, relevant stakeholders (support, docs) notified in advance, lighter-weight rollback plan
Tier 3 (low impact)	Minor UI tweaks, copy changes, small bug fixes	Standard engineering release process; no special cross-functional coordination required

The specific tier boundaries vary by organization, but the underlying principle — proportional ceremony matched to actual risk — is a direct extension of Lesson 34's Confidence-and-Effort-matching logic applied to launches instead of estimation.

Common Mistakes to Avoid

Treating every release as either maximally ceremonial or minimally so, with no tiering in between

As covered above, applying Tier 1 rigor to a minor copy change wastes organizational effort and creates launch-process fatigue; applying Tier 3 casualness to a major billing change is how large-scale incidents happen.

Conflating "code is deployed" with "feature is released.

Without a feature flag decoupling these two events, a team loses the ability to control exposure independently of deployment timing — meaning any deployment-time issue (a bad deploy window, unexpected interaction with other in-flight changes) directly and immediately affects every user, rather than being contained to a small, controlled group.

Believing "we'll fix it in the next release" is an acceptable rollback plan

For anything beyond the lowest-risk Tier 3 changes, this is not a rollback plan — it's an acknowledgment that no rollback plan exists. A genuine rollback plan specifies, in advance, exactly how to revert the change quickly (flag flip, feature toggle, code revert, database migration reversal) without waiting for a full new release cycle, since a live, actively-harming issue often cannot wait days for a properly tested fix.

Launching without informing support, sales, or customer-facing teams in advance

A support team blindsided by a change they didn't know was launching will be unable to answer user questions, may misdiagnose the change as a bug, and will lose confidence in the product organization's coordination — entirely avoidable simply by including these teams in the launch checklist from the start.

Treating a staged rollout's early stages as a formality rather than genuinely watching for signal

A staged rollout only provides protection if its early stages are actually monitored closely enough to catch a problem before proceeding — a team that mechanically advances from 1% to 10% to 100% on a fixed schedule, without genuinely reviewing metrics at each stage, has adopted the form of a staged rollout without its actual protective function.

Mental Model

The Blast Radius

This lesson's core takeaway tool frames every release decision around a single guiding question: if this goes wrong, how many people does it affect, and how quickly can that be contained?

Use the Blast Radius as your default first question for any release, before deciding on tier, rollout strategy, or rollback plan — the answer to "how big is the blast radius, and how containable is it" should drive every other decision in this lesson, rather than defaulting to habit or to whatever ceremony level the last release happened to use.

Quick Reflection Checkpoint

Key Takeaway: How will you apply "The Blast Radius" when evaluating trade-offs in your product decisions?

Release Planning & Launch Management