Go/no-go decision process: launch readiness decision tree
A go/no-go decision tree template for launch readiness: who answers each question, and the branches to go, conditional go, pilot, no-go and abort outcomes.
How it works
Rename the lanes to your real decision rights
Replace Release manager, Engineering and QA, Operations and support and Executive sponsor with the roles that genuinely hold the answer in your organisation. Keep the lanes to who answers, not who is involved: if three teams contribute evidence to one question but one person decides it, that question sits in the deciding lane. Merge any lane where you cannot name a specific person or role.
Write the thresholds down before you need them
The tree is only as good as its tests. On "Defects within severity thresholds?", record the limit per severity for the released scope, who may override a breach, and whether the count includes known issues carried from earlier releases. Do the same for "Acceptance criteria all met?" by marking each criterion mandatory or desirable at scope freeze, so the gate is not renegotiated on the day.
Define what a tested rollback means
"Rollback tested successfully?" should mean rehearsed against a production-like environment, timed, with a named person able to execute it and a written trigger for calling it. Note the data question explicitly, because a schema or migration change is often what turns the answer to "Is the change reversible at all?" into No, and that branch is the only route to abort.
Make the conditional and pilot outcomes real
A conditional go is only different from a plain go if each condition carries a named owner, a due date and a stated consequence if it is missed. A pilot go needs its cohort defined, the exposure percentage or customer list written down, and the criterion for widening. Add both to the comment field on "What scope is authorised?" so the review cannot end on an unqualified nod.
Separate no-go from abort
No-go means the same release ships later, so it needs a re-scheduled date and a named blocker before the meeting closes. Abort means the release is pulled and the scope goes back for rework or reconsideration. Keeping them as distinct endpoints stops a genuine abort being recorded as a two-week delay that quietly repeats.
Publish it, then review it after each gate
Share the tree where the review actually happens, alongside the evidence pack, and capture sign-off from the people named in the lanes. After each release, check whether any question was answered without evidence and whether an outcome you needed was missing. Keep the earlier versions so you can show when the criteria changed and why.
Frequently asked questions
What is the difference between a go/no-go decision tree and a release process map?
A release process map answers "what happens next, and who does it". It shows tasks in sequence across swimlanes — scope freeze, build, test, deploy, monitor — and treats the go/no-go call as a single node. A decision tree answers "which option do we choose, and who decides". Its spine is a chain of questions rather than tasks, its branches are labelled with answers such as Met, Above, Waivable or Withheld rather than with the next activity, and it terminates in several distinct outcomes instead of funnelling back into one happy path. Use both: the process map for the end-to-end flow, at /templates/software-release-process, and this tree for the gate inside it.
What questions belong in a go/no-go decision?
Seven cover most launches. Are all mandatory acceptance criteria met? Are open defects within the agreed severity thresholds? Are dependencies and third parties ready? Has the rollback been tested, not merely written? Are support and operations trained and staffed for the expected volume? Is the change window clear against the business calendar as well as the technical one? Is executive sign-off in place? Each should be answerable from evidence collected before the meeting, which is why the tree starts with a readiness evidence pack rather than with the first question.
Who makes the go/no-go call?
One named person should chair it, usually the release manager or whoever owns production, but the useful discipline is assigning each question rather than the whole decision. Engineering and QA answer the acceptance and defect questions, operations and support answer rollback and staffing, the release manager answers dependencies and the change window, and the executive sponsor answers sign-off. Written that way, the chair's job is to run the tree and record the outcome, not to arbitrate every question personally. Recording who answered what also matters for evidence: control frameworks such as SOC 2 expect changes to be authorised, tested, approved and documented, and a decision tree with named decision rights is a straightforward way to show it.
When should a go/no-go end in a conditional go rather than a no-go?
When the outstanding item does not put the release at risk and someone will own it after launch. A conditional go is a real outcome only if each condition has a named owner, a due date and a stated consequence for missing it; otherwise it is a plain go with extra paperwork. Reserve no-go for anything that would leave users exposed or unsupported. In this tree, blocking acceptance gaps, an unagreed over-threshold defect, a hard dependency you cannot ship without, an unready support function and a change window clash all route to no-go with a re-scheduled date.
What is the difference between no-go and abort?
No-go means the release is deferred: the same scope ships at a re-scheduled date once the blocker clears. Abort means it is pulled and the scope returns for rework or reconsideration, with no date attached. Keeping them apart matters because a release that cannot be reversed at all, or one where the executive sponsor withholds sign-off on business grounds, is not waiting on a fix — recording it as a delay leads to the same review being held again a fortnight later with the same evidence.
How do I limit a launch to a pilot or canary group?
Treat it as an outcome of the decision, not as a compromise reached in the room. In this tree the final question, "What scope is authorised?", branches Full, Conditional and Pilot only, so a limited release is chosen deliberately after every readiness question has been answered rather than as a way of avoiding a no-go. Before the review, define what a pilot means in your product: which cohort or exposure level, how long it runs, what is monitored, and the criterion that authorises widening it.