The go/no-go meeting is where a lot of pressure lands at once. The date is set, people have worked hard, and nobody wants to be the one who says "not yet."
When I ran the QA and release pipeline for the Travelxp OTT launch, I learned that a good checklist makes this conversation much less emotional. If everyone agreed in advance what "ready" means, the meeting is mostly about checking boxes. The hard calls are still hard, but at least they're about the right things.
This is the checklist I'd start from. Adjust it for your product and your organisation's own release process.
Before the meeting
| Area | Question | Who usually answers |
|---|---|---|
| Scope | Is everything in this release meant to be there? | Product |
| Open bugs | Are any open issues release blockers by our own definition? | QA and engineering |
| Testing | Has the release been tested on the platforms and devices we support? | QA |
| Rollback | Can we undo this, and how long would it take? | Engineering |
| Monitoring | Will we know quickly if something goes wrong? | Engineering |
| Data | Are analytics events firing so we can measure the change? | Product and analytics |
| Support | Does support know what's changing and how to answer questions? | Product and support |
| Dependencies | Are partner APIs, content or configuration ready? | Product |
| Communication | Is any user or stakeholder communication ready to go? | Product and marketing |
Agree what a blocker is beforehand
The worst go/no-go meetings are the ones where people argue about whether a bug is serious. Decide in advance what counts as a blocker. For example:
- Any issue that causes data loss, a security problem or a payment error.
- Any issue that blocks a core task on a supported platform.
- A significant regression in a key quality metric.
Everything else is a known issue to log and fix later. This is similar to the incident thinking in bugs vs features, just applied before release instead of after.
Rollback is the most important line
If something goes wrong and you can roll back in minutes, a lot of risk becomes acceptable. If rollback is slow or impossible, you need much more confidence before shipping.
This varies hugely by platform. A web release can usually be reverted quickly. A Smart TV build that's passed certification and been installed is much harder to take back. I wrote about those differences in the multi-platform release post.
Who decides
Name the person who makes the final call. Usually that's a product or engineering lead, sometimes jointly. Everyone else gives input.
Without a named decider, the meeting ends in "let's see how it goes" or a decision by whoever talks loudest. Neither is great when real users are about to see the change.
Saying no-go
Sometimes the answer is not yet. When that happens, I'd be specific about why, what needs to change, and when we'll check again. "We're holding the release because playback fails on one TV platform. Engineering is investigating and we'll review again tomorrow afternoon."
It's an uncomfortable call to make, but a delayed release is almost always easier to explain than a broken one.
After release
The checklist doesn't end when the release goes out. Watch the key metrics closely for the first hours or days, depending on the change. Have someone clearly responsible for that watch, and agree in advance what would trigger a rollback.
Then, a week or so later, look back. What did the checklist catch? What did it miss? Add one line for anything that surprised you. Over time, the checklist turns into a record of everything your team has learned the hard way.