A short guide to post-launch support

We end up explaining this on discovery calls often enough that it deserved writing down. Everything we would tell a client about post-launch support in the time it takes to drink a coffee.

Strategy work is mostly deciding what not to do, and writing it down so it stays decided. Write the reasoning down alongside the decision, because the reasoning is what changes first.

What is actually at stake

Launch is the beginning of the maintenance period. This is the sort of thing that compounds, quietly, in both directions. Budget a little time for it every quarter and it never becomes a project of its own.

Where to start

Decide who owns fixes before you need them. That sounds obvious written down. It is still the thing most often skipped. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

What to watch for

Budget for it or it comes out of goodwill. Small and consistent beats large and occasional here. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

What this looks like day to day

The projects that go badly are rarely the ones with the hardest technical problems. Three things worth confirming about post-launch support before you move on:

• Someone can say what the current setup is without going to look
• Budget for it or it comes out of goodwill — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you want a second opinion on how yours is set up, ask.