Launch planning for small teams

It is rarely the thing that gets a project approved, and often the thing that decides how it goes. Most advice about launch planning assumes a team that does not exist at your size. Here is the version that does not.

The projects that go badly are rarely the ones with the hardest technical problems. If it only works because one person remembers to do something, it does not work yet.

What to keep

Never launch on a Friday afternoon. There is a version of this that is over-engineered, and it is worth avoiding. Write the reasoning down alongside the decision, because the reasoning is what changes first.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. Where this goes wrong is almost never a lack of knowledge.

How we handle it

Announce it once the thing is verifiably working. There is a version of this that is over-engineered, and it is worth avoiding. Write the reasoning down alongside the decision, because the reasoning is what changes first.

In practice

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

• Someone can say what the current setup is without going to look
• Announce it once the thing is verifiably working — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Most of the value here comes from doing the first two things, not all of them.