How to get post-launch support right
Most teams know this matters. Fewer have decided who owns it. The short answer to post-launch support is that it is mostly a sequence of small decisions, not one big one.
The projects that go badly are rarely the ones with the hardest technical problems. Budget a little time for it every quarter and it never becomes a project of its own.
Why this earns attention
Launch is the beginning of the maintenance period. The teams that handle this well are rarely the ones with the biggest budgets. The version that survives contact with a real deadline is the simple one.
The steps
- Establish what you have today before changing anything
- Decide who owns fixes before you need them
- Budget for it or it comes out of goodwill
- Write down the decision so the next person does not re-litigate it
Budget for it or it comes out of goodwill. That sounds obvious written down. It is still the thing most often skipped. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.
A reasonable first step
The short version
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 want a second opinion on how yours is set up, ask.