Launch Planning

Why Launches Need a Plan

A launch is the moment a product, or a meaningful change to one, meets the real world. Even a great feature can flop if the launch itself is chaotic: support doesn't know it's coming, the servers fall over on day one, or nobody outside the team can explain what changed. Launch planning is the discipline of making sure the moment of release is boring in the best possible way — predictable, coordinated, and reversible if something goes wrong.

A useful way to think about it: building the product answers "does it work?" Launch planning answers "is the organisation ready for people to use it?"

---

The Launch Readiness Checklist

Before any launch, a PM should be able to answer yes to each of these:

A launch missing even one of these can generate a support fire, a legal headache, or a metric nobody can actually report on.

---

Stakeholder Communication

The PM is usually the single point of coordination across teams that don't normally talk to each other daily. A simple, repeatable pattern works well:

1. T-minus 2 weeks: Share a one-page launch brief — what's shipping, who it affects, key dates, and open risks.
2. T-minus 1 week: Confirm readiness in each area from the checklist above. Escalate anything red.
3. T-minus 1 day: Final go/no-go call with engineering, support, and marketing leads.
4. Launch day: Short status updates at agreed intervals (e.g. every 2 hours for the first day).
5. T-plus 1 week: Wrap-up note summarising what happened and what's next.

For a bank like Access Bank rolling out a new mobile transfer limit, or a startup like Paystack shipping a new checkout flow, the same rhythm applies — only the audience and risk tolerance change. A regulated fintech will add compliance sign-off; a small startup may compress the timeline to days instead of weeks.

---

Rollout Strategies

Not every launch should go to 100% of users at once. Common approaches:

• Big bang: Everyone gets it at once. Simple, but risky — use only for low-risk, well-tested changes.
• Staged rollout: Release to 5%, then 25%, then 100% of users, watching metrics at each step.
• Beta / early access: A small, opted-in group tries it first, often in exchange for feedback.
• Geographic rollout: Launch in one market (e.g. Nigeria) before expanding to others (e.g. Kenya, Ghana), useful when regulation or infrastructure differs by country.
• Feature flags: Ship the code dark, then turn the feature on remotely without a new deployment — the safest way to control blast radius.

Choosing the right strategy is a trade-off between speed and risk. A UI colour change might go big bang; a change to how loan interest is calculated should almost always be staged.

---

Setting a Go/No-Go Bar

Before launch day, agree on the specific conditions that would delay the launch — for example, "if crash rate exceeds 1% in the beta" or "if the compliance review isn't signed off by Thursday." Deciding this in advance, calmly, prevents an emotional last-minute argument when the pressure is highest.