BUILD CULTURE
Menu
Close
BUILD CULTURE
Menu
Close
The 3 Checklists That Changed How We Ship Software
The 3 Checklists That Changed How We Ship Software
Three lightweight checklists helped one engineering team reduce incidents, improve handoffs, and ship with more confidence. Here's how they replaced ambiguity with clarity — and made onboarding, QA, and releases smoother across the board.
Oct 15, 2025
Featured
For a long time, shipping at our company felt like a coin toss. Sometimes it went smoothly — sometimes it didn’t. We weren’t building experimental hardware. We were shipping a pretty standard SaaS platform. But even with sprint planning, QA cycles, and retros, we were still getting hit by surprise bugs, rushed handoffs, and launch-week fire drills.
We didn’t need more meetings. We needed more clarity. That’s when we introduced three simple checklists that changed everything.
The Problem Wasn’t Velocity — It Was Ambiguity
Before we added checklists, we had:
Engineers writing great code… but not checking for cross-team impact.
QA missing edge cases… because the specs weren’t complete.
Features going live… without comms or support teams even knowing.
We weren’t short on talent or effort. We were short on shared expectations.
Checklist 1: Pre-Merge (Developer-Owned)
This is the checklist every engineer runs through before merging a PR:
Did I write/update tests?
Have I confirmed this change doesn’t affect shared components or downstream services?
Have I tagged or looped in any teams affected by this change?
Have I updated docs or flags as needed?
We weren’t short on talent or effort. We were short on shared expectations.
Why it matters: This isn’t about hand-tying devs — it’s about protecting their time. T
his checklist drastically reduced rework and questions after code was merged.
Checklist 2: Pre-Release (Squad-Owned)
Once a feature is dev-complete, we review it as a squad with this list:
Has QA signed off?
Are product requirements met — not just implemented, but understood?
Are comms, docs, and internal tools ready?
Do we have a rollout plan (full deploy vs flag, percentage rollout, etc)?
Has support been briefed?
Why it matters: This is where we catch most of the “oh wait…” moments. It forces us to look beyond our terminal and see the full feature lifecycle.
Checklist 3: Post-Release (Team-Owned)
After the release, we close the loop:
Did anything break or spike in metrics?
Have we reviewed logs or feedback channels?
Are follow-ups or fixes needed?
Is there anything worth retroing — and sharing with the broader org?
Did we learn anything that should be added to a future checklist?
Why it matters: This makes sure we actually learn from launches. It also creates a feedback loop between engineers and PMs, helping us refine how we define “done.”
What Changed After We Introduced Checklists
Production incidents dropped 36% in the first quarter
Support tickets tied to new features decreased
Confidence increased — PMs, EMs, and QA now know exactly what “ready to ship” means
The most underrated outcome? New engineers onboard faster. They see our process in action from day one — and can contribute without second-guessing expectations.
Why These Work (When So Many Process Changes Don’t)
They’re written by engineers, for engineers. These weren’t handed down by management. They came from pain points the team actually felt.
They’re visible and accessible. Each checklist is embedded in our Notion playbooks, linked in our PR template, and occasionally pasted into Slack by leads to reset expectations.
They’re short. We’re talking 4–6 items each. If a checklist becomes a bureaucratic mess, it dies. Fast.
Final Thoughts
Checklists aren’t magic. They don’t fix bad specs or broken culture. But in our case, they became a simple, shared tool to reduce stress, protect quality, and raise the bar across teams.
If you’re tired of hearing “I thought someone else handled that” — start here. One checklist at a time.
For a long time, shipping at our company felt like a coin toss. Sometimes it went smoothly — sometimes it didn’t. We weren’t building experimental hardware. We were shipping a pretty standard SaaS platform. But even with sprint planning, QA cycles, and retros, we were still getting hit by surprise bugs, rushed handoffs, and launch-week fire drills.
We didn’t need more meetings. We needed more clarity. That’s when we introduced three simple checklists that changed everything.
The Problem Wasn’t Velocity — It Was Ambiguity
Before we added checklists, we had:
Engineers writing great code… but not checking for cross-team impact.
QA missing edge cases… because the specs weren’t complete.
Features going live… without comms or support teams even knowing.
We weren’t short on talent or effort. We were short on shared expectations.
Checklist 1: Pre-Merge (Developer-Owned)
This is the checklist every engineer runs through before merging a PR:
Did I write/update tests?
Have I confirmed this change doesn’t affect shared components or downstream services?
Have I tagged or looped in any teams affected by this change?
Have I updated docs or flags as needed?
We weren’t short on talent or effort. We were short on shared expectations.
Why it matters: This isn’t about hand-tying devs — it’s about protecting their time. T
his checklist drastically reduced rework and questions after code was merged.
Checklist 2: Pre-Release (Squad-Owned)
Once a feature is dev-complete, we review it as a squad with this list:
Has QA signed off?
Are product requirements met — not just implemented, but understood?
Are comms, docs, and internal tools ready?
Do we have a rollout plan (full deploy vs flag, percentage rollout, etc)?
Has support been briefed?
Why it matters: This is where we catch most of the “oh wait…” moments. It forces us to look beyond our terminal and see the full feature lifecycle.
Checklist 3: Post-Release (Team-Owned)
After the release, we close the loop:
Did anything break or spike in metrics?
Have we reviewed logs or feedback channels?
Are follow-ups or fixes needed?
Is there anything worth retroing — and sharing with the broader org?
Did we learn anything that should be added to a future checklist?
Why it matters: This makes sure we actually learn from launches. It also creates a feedback loop between engineers and PMs, helping us refine how we define “done.”
What Changed After We Introduced Checklists
Production incidents dropped 36% in the first quarter
Support tickets tied to new features decreased
Confidence increased — PMs, EMs, and QA now know exactly what “ready to ship” means
The most underrated outcome? New engineers onboard faster. They see our process in action from day one — and can contribute without second-guessing expectations.
Why These Work (When So Many Process Changes Don’t)
They’re written by engineers, for engineers. These weren’t handed down by management. They came from pain points the team actually felt.
They’re visible and accessible. Each checklist is embedded in our Notion playbooks, linked in our PR template, and occasionally pasted into Slack by leads to reset expectations.
They’re short. We’re talking 4–6 items each. If a checklist becomes a bureaucratic mess, it dies. Fast.
Final Thoughts
Checklists aren’t magic. They don’t fix bad specs or broken culture. But in our case, they became a simple, shared tool to reduce stress, protect quality, and raise the bar across teams.
If you’re tired of hearing “I thought someone else handled that” — start here. One checklist at a time.