Kill Criteria Template

When generating kill criteria for a specific project:

1. Replace all [bracketed placeholders] with project-specific values
2. Delete any criteria that genuinely do not apply (with a one-line reason)
3. Add project-specific criteria where the template does not cover the domain
4. All numeric thresholds must be agreed by the team before deployment — do not ship with placeholder numbers
5. Assign a Kill Criteria Owner — a named person whose job is to enforce this framework. This cannot be the same person who built the feature.

Day-0 Setup (Before First Commit)

Before writing any code, complete these:

Tier 1 — Hard Kill Triggers

These are non-negotiable. If any of these conditions are met, the component is shut down immediately. No meeting, no discussion, no “let’s give it another week.”

Enforcement mechanism: Automate where possible. For conditions that cannot be automated, the Kill Criteria Owner checks daily during the evaluation window.

Implementation Requirements for Hard Kills

For each auto-kill trigger, implement:

• Alert: Fires when condition approaches threshold (80% of limit)
• Kill switch: Automated mechanism to disable the component
• Rollback plan: Tested procedure to revert to the previous state
• Post-mortem template: Pre-written, so the post-mortem happens even under pressure

These must exist before the feature ships. If they do not exist, the feature does not ship.

Tier 2 — Review Triggers

These force a mandatory review meeting within 48 hours of being triggered. The default outcome of the review is KILL. The team must argue for continuation, not against shutdown.

Review Meeting Protocol

1. Present the data (5 min). No narrative, just numbers.
2. Kill Criteria Owner states: “The default outcome is shutdown. Who wants to argue otherwise?”
3. Continuation requires ALL of:
   • Clear explanation of why the threshold was missed
   • Concrete plan to meet the threshold within [14] days
   • Named person accountable for the plan
4. If continuation is approved, set a hard follow-up date. If the threshold is still not met at follow-up, kill with no further review.

Tier 3 — Soft-Go Criteria

These define success. The feature must meet ALL of these within the evaluation window to earn the right to continue existing. Failure to meet any one criterion triggers a Tier 2 review with default-to-kill.

Soft-Go Graduation

When all Soft-Go criteria are met for the full evaluation window:

1. The component graduates to “established” status
2. Hard kill triggers (Tier 1) remain permanently active
3. Review triggers (Tier 2) shift to quarterly cadence instead of continuous
4. A 6-month re-evaluation date is set to reassess whether the component still earns its place

The Anti-Vanity Addendum

These criteria specifically target vanity engineering recurrence. Include at least 3 in every kill criteria framework:

Enforcement Calendar

Generate this calendar when creating project-specific kill criteria:

Common Failure Modes of Kill Criteria

These are how kill criteria frameworks fail in practice. Guard against each:

1. Placeholder numbers that never get filled in. Ship with real thresholds or do not ship.
2. Kill Criteria Owner is the feature’s builder. They will never kill their own creation.
3. “Let’s give it one more sprint” syndrome. The review protocol above exists to prevent this.
4. Metrics that cannot actually be measured. Every threshold must have a working dashboard or query on Day 0.
5. Auto-kills that are never tested. Run a drill before the feature ships. Trigger the kill switch intentionally. Verify it works.
6. Graduated features that are never re-evaluated. The 6-month review exists for a reason.
7. Kill criteria written after the feature ships. At that point, anchoring bias has set in. Kill criteria must be written before the first commit.