Ask a product team when its launch is and you’ll get a deployment date. For leadership, that date is one of the least interesting points on the line. Launches usually fail well before it, because an early stage was rushed, or well after it, because nobody checked whether the product did what it was supposed to do.
This is the sequence we use, with the question leadership should be asking at each stage.
1. The problem
Before any design or build, someone should be able to write down the problem, who has it, the evidence that it’s real, and what success looks like as a number. Revenue, conversion, retention, cost to serve, time saved.
The leadership question: can the team describe success in one sentence that contains a number? If not, nothing that follows will be measurable, and the launch will be judged on opinion.
2. Testing the risky assumptions
Every launch rests on a few assumptions that could sink it. Customers want this. They’ll pay for it. The platform can support it. The regulator will accept it. The goal of this stage is to find out cheaply which ones are wrong, using data you already have, conversations with customers, a prototype, and an early feasibility check with engineering and compliance.
The leadership question: what did we learn that changed the plan? If the answer is nothing, the team probably didn’t test the assumptions that matter.
3. Scope
This is where launches get bloated. Every stakeholder sees a chance to add their feature. The first release should be the smallest thing that delivers the core value and lets you measure the result. Everything else goes on a list for later.
This stage also needs a measurement plan. Which events get tracked, which dashboard shows the result, and what the baseline is. If tracking isn’t in scope from the start, it becomes a ticket after launch, and you lose the first weeks of data, which are the most useful ones.
The leadership question: does everyone agree on what’s out of scope, in writing?
4. Build
Delivery runs in whatever rhythm suits the team. What matters more during a launch is that progress is visible early. Partial work shown to stakeholders in week two surfaces surprises while they’re still cheap to fix. Dependencies on other teams and external vendors get checked every week, because that’s where launch dates usually slip.
The leadership question: what’s the biggest risk to the date right now, and what’s the fallback?
5. Readiness
Most of this stage has nothing to do with code. Support needs to know what’s changing and how to escalate. Compliance and legal need to have signed off where required. Marketing needs final messaging that matches what’s actually being shipped. Someone needs to have written down how to roll back, and who decides to do it.
A launch is ready when every one of those has an owner and a tick. Engineering saying the code is done is just one of the ticks.
6. Release
Roll out gradually where you can: one market, one segment or a percentage of customers first. Keep new features behind a switch, so a problem can be contained without a new deployment. Have the right people available for the first hours. Watch business metrics as well as error logs, because a feature can be technically healthy and commercially broken.
Release when the work is ready, whatever date the plan said. If there’s a fixed business date, ship the code early behind a switch and turn it on when the date arrives.
7. Measure and decide
This is the stage most launches skip. The feature ships, the team moves to the next thing, and nobody checks whether the number moved.
Set the review date before launch, usually two to four weeks out. At the review, compare the result with the success measure from stage one, look at what customers and support are saying, and make a decision: scale it, change it, or stop it.
The leadership question: did it work, and how do we know?
Where it usually breaks
In our experience the stage that gets skipped most is the last one, and the one that causes the most damage is the third. Unclear scope turns every week of the build into a negotiation, and missing measurement turns the final review into a debate about opinions.
Get those two right and launch day becomes the least dramatic part of the process. That’s how it should be.
