If your team dreads Salesforce go-live weekends, the dread is data. It means the release contains changes whose blast radius nobody has measured and whose rollback nobody has rehearsed. Risk is not a feeling — it is unscored change.
Score every release item, every time
Two questions per item: how many users and processes does this touch if it misbehaves (blast radius), and how hard is it to undo (rollback difficulty)? Score each one to five. Multiply.
The scores are estimates, and that is fine. The act of scoring forces the conversation that matters: what could this break, and how would we know?
Let the risk register run the release
Sort the register by score. The top items get regression coverage, a rehearsed rollback, and a named owner watching them at go-live. The bottom items get waved through — deliberately, on record, so attention goes where the risk is.
The register also becomes the agenda for the go/no-go gate: high-risk items are either mitigated or the release moves.
What changes
In a 5,000-user org shipping monthly, scored risk assessment plus gate sign-off cut defect leakage 40% over two quarters. Emergency weekend rollbacks stopped entirely after the first quarter.
The team did not ship less. They shipped the same cadence with the risk measured instead of felt.
Start with your next release
A risk register is a spreadsheet with five columns: item, blast radius, rollback difficulty, score, owner. Build it for the next release, sort it, and take the top three items seriously. The dread starts converting into a checklist immediately.