Post-launch support: what to get right first

The gap between knowing this and actually doing it is where most teams lose ground. If you only fix one thing about post-launch support this quarter, make it the first item below.

The projects that go badly are rarely the ones with the hardest technical problems. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

Start here

Launch is the beginning of the maintenance period. There is a version of this that is over-engineered, and it is worth avoiding. Assume whoever inherits this will have half your context and none of your patience.

Then this

Decide who owns fixes before you need them. Small and consistent beats large and occasional here. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Eventually

Budget for it or it comes out of goodwill. In practice this is a scheduling problem more than a technical one. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

How to tell if yours is fine

Strategy work is mostly deciding what not to do, and writing it down so it stays decided. Three things worth confirming about post-launch support before you move on:

• Someone can say what the current setup is without going to look
• Launch is the beginning of the maintenance period — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you are not sure where your systems currently stand on this, it takes us about an hour to find out.