The runbook is the feature

Anyone can ship. The team that can operate at 2am wins.

A product is not a thing you launched. A product is a thing that's still working a year after launch, despite the inevitable failures, edge cases, and user growth.

The difference is the runbook.

The runbook is the document that tells the on-call person what to do when the system breaks. Which alerts mean what. Which tools to check. Which queries to run. Which buttons to press in which order. What to escalate and to whom.

Most teams treat the runbook as documentation that should exist eventually, after the launch, when there's time. The serious teams write the runbook before the feature ships. They consider the runbook part of the feature.

If you can't write the runbook for a feature, you don't yet understand the feature well enough to ship it.

Three things I check before any feature ships:

What's the failure mode? When this breaks, how does it break? What does the user see? What does our system show?

What's the diagnosis path? Step-by-step, what does the on-call person do at 2am? In what order? With what tools?

What's the recovery path? How do we get the system back to working? Manually if needed, automatically if possible.

If those three questions don't have written answers, the feature isn't ready to ship.

This sounds slow. It is. The slowness is the point.

The team that ships fast and figures out the operations later builds a maintenance hellscape. The team that ships with the runbook in place builds something durable.

Pick durable.

The runbook is the feature.