Five Questions Your Ops Checklist Should Answer

The checklist isn't the problem. The questions are.

Every founder I know has checklists. Onboarding checklists, deploy checklists, support triage checklists. Some live in docs. Some live in someone's head. Most grow by accretion — a new bullet after every incident, a new sub-step after every mistake.

The result is a long list that technically covers everything and practically covers nothing. Length is not rigor. A 40-item checklist that doesn't answer the right questions is just a longer way to miss the same things.

Here are five questions your ops checklists should answer. If they don't, the list is decoration.

1. Can someone who joined yesterday run this without pinging you?

This is the dependency test. If your checklist requires tribal knowledge — "oh, you have to do step 7 differently on Thursdays" or "ask Jamie about the credentials" — it's not a checklist. It's a treasure map with missing pieces.

The fix isn't more detail. It's rewriting from the perspective of someone with zero context. Hand it to someone unfamiliar with the process. Watch where they stall. Those stall points are the real gaps.

A checklist that passes this test removes you as a bottleneck and reveals whether the process itself is too fragile to survive your absence.

2. What does "done" look like — and who confirms it?

Many checklists describe actions without defining outcomes. "Update the config" is an action. "Config reflects the new value, verified by loading the public settings page" is an outcome with a confirmation step.

The difference matters because actions can be completed incorrectly. You can check the box and still be wrong. When a checklist defines "done" in observable terms, the person running it can self-verify. They don't need a senior teammate glancing over their shoulder.

For every item on your list, ask: if this were done wrong, how would we know? If the answer is "we wouldn't, until something breaks downstream," the checklist has a hole.

3. When this fails at 2 AM, who does what first?

Checklists tend to describe the happy path. The interesting part is what happens when the happy path collapses.

A good ops checklist has a failure branch — not a separate incident runbook buried in a folder nobody remembers, but a clear fork built into the checklist itself. Step 4 didn't work? Here's what to check. Still stuck? Here's who to contact and what information to include.

This matters most for processes that run outside business hours or during high-pressure moments. If the failure response depends on improvisation, you'll get inconsistent improvisation. Build the decision tree into the list.

4. Does this checklist know it's out of date?

Stale checklists are dangerous because they look authoritative. Someone follows one, hits a wall, and now they're debugging a process and a document at the same time.

The question isn't "is this checklist current?" It's "does the checklist have a mechanism that surfaces when it's drifting?" Simple version: put a "last verified" date at the top with the name of who verified it. Set a reminder to re-run the checklist against reality every month or quarter.

Better: tie verification to use. Every time someone completes the checklist, they mark whether any step was confusing, wrong, or unnecessary. After three runs, you have real data on where the list has decayed.

5. What would make this checklist unnecessary?

This is the question most founders skip, and it's the most valuable one.

Some checklists exist because a process is genuinely complex and humans need guidance. Fair. But many exist because a process is broken, manual, or duplicated — and the checklist is a bandage over a wound that should be sutured.

If a checklist has fifteen steps that could be three with a better default configuration, the highest-value move isn't refining the checklist. It's fixing the process. Ask: what would make this entire list irrelevant? Sometimes the answer points to automation. Sometimes to simpler architecture. Sometimes to eliminating the process entirely.

Not every checklist can be killed. But every checklist should earn its existence.

Better questions beat longer lists

The instinct after an incident is to add more steps. More steps feel thorough. But thoroughness without clarity is noise. A ten-item checklist that answers these five questions will outperform a fifty-item checklist that doesn't.

Start with the checklists your team uses most — the ones that run weekly or touch customers directly. Run each through these five questions. Where the checklist can't answer, you've found the gap. Fix the gap, not the list.

Ops hygiene isn't about having processes for everything. It's about having processes that survive contact with reality — and with the people who actually have to follow them.