Kill thresholds in 2026: pre-register week-6 gates for your 4 pilots

This guide shows how to pre-register kill and scale thresholds for a four-pilot portfolio before week one.

It explains how to enforce a week-six review whose kill and scale cutoffs are fixed before week 1 — typically targeting two kills and two scale decisions, though the actual mix depends on results.

How week-6 kill thresholds actually work

A kill threshold is a pre-registered decision gate, not a post-hoc judgment. It is a numeric cutoff on one primary metric, written before week 1 and enforced at the fixed week-6 review. If the pilot is at or below that cutoff at week 6, the pilot is killed and its budget is reallocated, per Bluemorrow's pilot-testing guide (bluemorrow.com, 2026-07-27). The cutoff must be a number, not a sentiment: "improve engagement" is not a threshold.

The scale threshold is the paired upper cutoff on the same metric and the same named data source. At or above it, the pilot graduates to a scale decision. Between the kill and scale cutoffs, the pilot receives one bounded extension with a new checkpoint, not an open-ended continuation. The extension needs its own date and cutoff; otherwise it is just a continuation with better branding.

The mechanism is capital allocation discipline. Bluemorrow frames pilot testing as a capital allocation discipline rather than a research stage, and the week-6 gate applies that frame by forcing a build-or-kill call before the next dollar is authorized.

To make the gate enforceable, write one falsifiable kill threshold and one scale threshold per pilot before week 1, tie both to a single primary metric, and name the data source that will be used at week 6. Name the export, dashboard, or table and the owner who will pull it. Use the same record that established the pilot's baseline, so the week-6 comparison is like-for-like rather than a new interpretation.

At the week-6 review, apply the cutoffs as written: at or below the kill threshold, stop and reallocate; at or above the scale threshold, graduate; in between, grant one bounded extension with a new checkpoint. The decision is then made by the pre-registered rule rather than by the most persuasive stakeholder in the room.

Keeping the metric, data source, and review date fixed makes build-or-kill calls comparable across pilots and prevents a weak result from being reframed after the fact.

The evidence on thresholds and pilot failure

Bluemorrow's corporate innovator's guide (bluemorrow.com) names the failure mode that quietly sinks programmes: "Internal stakeholder approval feels like validation, so the project gets funded. Six quarters in, nobody can produce behavioural evidence that customers want the thing at a price that clears margin." The warning is not about enthusiasm; it is about funding a project before customers have demonstrated willingness to pay at a margin-clearing price.

Bluemorrow's prescribed remedy is sequencing rather than a single large bet: "It turns a bet on a hunch into a sequence of smaller, decidable investments, each one earning the right to make the next." That is the logic behind a pre-written cutoff: each pilot must earn continuation with observed behaviour, not with internal approval.

Tailor AI (tailorhq.ai) splits method by traffic: "High traffic gets rigorous A/B tests. Low traffic gets direction." The practical implication is that the test must fit the available evidence. A pilot with sparse traffic cannot carry the same evidentiary burden as a high-traffic one, so the threshold and method should be chosen for the named data source rather than copied from another pilot.

Together, the two sources support a simple discipline for a multi-pilot portfolio: write the kill and scale thresholds before the pilot starts, tie each to one primary metric and one named data source, and require behavioural evidence at a price that clears margin. Stakeholder approval is a funding signal, not customer evidence.

Kill, extend, or scale: options compared

At the week-6 review, a multi-pilot portfolio does not need more discussion; it needs a decision rule chosen before the data exists. The three realistic governance options are a pre-registered gate, a post-hoc committee review, or an open-ended extension. They differ not in how much data they use, but in who gets to redefine success after the data arrives.

Option A, the pre-registered week-6 gate, wins because the decision rule exists before data arrives and cannot be renegotiated by the pilot sponsor. The sponsor can add context, but cannot move the threshold after seeing the result; the review becomes an execution step rather than a funding negotiation. That is the only option that makes a kill decision reversible by evidence instead of by advocacy.

Option B, post-hoc committee review at week 6, loses because the criterion is set after the fact. Bluemorrow's failure mode is the warning here: internal stakeholder approval can feel like validation, so a project keeps funding without behavioral evidence that customers want the thing at a price that clears margin. A committee can always find a reason to continue; that is the defect, not a safeguard.

Option C, open-ended extension until "the signal is clear," loses because it has no terminal condition. It converts a six-week test into the six-quarter unfalsified funding pattern Bluemorrow describes, where nobody can produce behavioral evidence but the program still consumes capital and strategic attention. "Clear signal" is not a rule; it is permission to wait.

The practical rule is simple: if a pilot cannot be killed or scaled by a rule fixed in advance, it is not being tested; it is being funded. Pre-register the gate, enforce it at week 6, and treat any request to extend or reinterpret as evidence that the pilot has already failed its governance test.

Costs and numbers that matter

The portfolio arithmetic is simple and unforgiving: four pilots run for six weeks each, so the first portfolio-level decision is made after 24 pilot-weeks of run cost, and a two-kill, two-scale outcome terminates 12 of those 24 pilot-weeks—50%—at the week-6 gate.

A missed kill is the expensive error. A pilot that survives past week 6 without a scale threshold keeps consuming its full run cost and blocks the pilot that would have replaced it; Bluemorrow's corporate innovator's guide (bluemorrow.com) puts the outer limit of that leak at six quarters, the point at which a program can still lack behavioral evidence that customers want the thing at a price that clears margin.

A false kill has the opposite cost profile. One pilot killed at week 6 that had not yet reached its scale threshold forfeits the six weeks already spent, but it stops consuming run cost at the gate instead of carrying a non-scaling pilot forward.

The two errors are not symmetric: a missed kill compounds because it keeps spending and crowds out a replacement, while a false kill is bounded by the six weeks already spent. That asymmetry is why the week-6 gate should be treated as a hard stop rather than a review that can be reopened.

If the gate is enforced, the portfolio's maximum exposure is 24 pilot-weeks; if it is not, exposure is unbounded because a non-scaling pilot can absorb the slot indefinitely.

The cost of a false kill is therefore not zero, but it is capped: six weeks of run cost and the possibility that the pilot would have crossed its scale threshold later. The cap is what makes a false kill cheaper than a missed kill.

The 24 pilot-week figure is a floor, not a ceiling: it assumes every pilot reaches week 6. A pilot killed earlier would reduce run cost, but the week-6 gate is what makes that reduction predictable.

What the evidence does NOT establish

The evidence does not establish a universal numeric kill rate for corporate pilots. The 2-of-4 target is a portfolio design choice, not an empirically derived constant, so it should not be read as a requirement to kill exactly two pilots. Check: if three pilots clear their cutoffs and one fails, the gate says scale three and kill one; if all four fail, it says kill four. The portfolio mix is a planning assumption, not a result the evidence guarantees.

The evidence also does not establish that six weeks is the correct horizon for every pilot type. Bluemorrow’s failure mode is measured in quarters—six quarters before behavioral evidence is missing—so a week-6 gate can be too early for pilots whose value appears later. Tailor AI’s traffic split adds the opposite constraint: high-traffic pilots can support rigorous A/B tests, while low-traffic pilots may need directional rather than statistical thresholds. Check: match the threshold to traffic level and sales cycle before week 1; do not import a six-week precision standard into a low-traffic or long-cycle pilot.

Nor does the evidence establish that pre-registration alone prevents failure. Fixing the rule before data arrives does not repair a weak primary metric, a noisy data source, or a threshold that ignores implementation lag. Check: if the metric can improve while customer behavior does not, the gate can produce a false scale; if the metric is flat because traffic is too low, it can produce a false kill. Pre-registration protects the decision from post-hoc rewriting, not from a poorly chosen measurement.

These limits are boundary conditions, not reasons to abandon the gate. The gate still wins when the edge case is handled before week 1: choose a directional threshold for low traffic, a longer review for long-cycle pilots, or a different metric when the first one is not behavioral. After week 6, the only question is whether the pre-registered cutoff was met.

4 pilots, week-6 gate

This section is the worked example: four pilots, one worksheet, two checkpoints, and a target portfolio outcome of two kills and two scale decisions. It assumes the threshold rule and evidence base are already settled; its job is to make them executable for a portfolio manager.

The inputs are fixed before week 1. Pilot A is high traffic and uses weekly active usage rate from product analytics. Pilot B is low traffic and uses qualified leads per week from the CRM. Pilot C is high traffic and uses conversion rate from the billing system. Pilot D is low traffic and uses a pilot-specific task completion rate from the usage log. Each pilot gets exactly one primary metric and one named source; no secondary metric can override the gate.

Checkpoint 1 happens at week 0. For each pilot, the owner writes the kill threshold and scale threshold into the worksheet, ties each to the single primary metric and named source above, and signs the row. The signature records that the cutoff was fixed before any week-6 data existed; the review later applies that cutoff with no extension.

Checkpoint 2 happens at week 6. The reviewer compares each pilot's actual primary-metric value against its two pre-registered cutoffs and records kill or scale in the worksheet, with a one-line rationale tied to the same metric and source. A pilot at or below its kill threshold is killed; a pilot at or above its scale threshold is scaled; the worksheet keeps the decision and evidence in one place.

The output is a portfolio record, not a narrative: every kill or scale decision is traceable to a row, a metric, a source, a cutoff, a signature, and a week-6 value, whether the mix turns out to be two-and-two or otherwise.

That row-level audit trail is what makes the portfolio outcome defensible after the fact.

Decision rules for the week-6 gate

If a pilot's week-6 primary metric is at or below its pre-registered kill threshold, then kill the pilot and reallocate its budget in the same review cycle. The kill is recorded against the pre-registered number, not against a revised story, and the reallocation is entered before the review closes so the budget does not stay attached to a stopped pilot.

If a pilot's week-6 primary metric is at or above its pre-registered scale threshold, then move it to a scale decision with a named owner and a dated next step. The owner and date are written into the decision record before the review closes, so the scale path has an accountable next action rather than an open-ended approval.

If a pilot's week-6 primary metric falls between the kill and scale thresholds, then grant exactly one bounded extension with a new checkpoint date and a new pre-registered threshold. The extension is bounded because it carries both a new date and a new cutoff; without both, the review would be reopening the decision instead of deferring it.

If a pilot has already used its one bounded extension and its week-6 primary metric is still between the thresholds, then kill the pilot and reallocate its budget in the same review cycle. The second review does not create a second extension; the rule converts an unresolved middle result into a stop.

If a pilot's week-6 primary metric cannot be verified from its named data source, then record no scale decision and require verification before any further funding. The pilot is not advanced on unverified data, and the missing verification becomes an action item with an owner rather than an implicit pass.

What to do next

Frequently Asked Questions

What happens if a pilot is at or below its kill cutoff at week 6?

The pilot is killed and its budget is reallocated.

When must each kill threshold be fixed?

Each kill threshold is fixed before week 1.

Are extensions or post-hoc judgments allowed at the week-6 review?

All 4 pilots are reviewed at week 6 with no extensions or post-hoc judgments.

How is each scale threshold connected to its pilot's primary metric?

Each pilot also has a scale threshold tied to the same single primary metric and named data source.

What outcome mix is targeted for the four-pilot portfolio?

The portfolio targets 2 kills and 2 scale decisions from 4 pilots, though the actual mix depends on results.

What form must a kill cutoff take?

The cutoff must be a number, not a sentiment, so "improve engagement" is not a threshold.

Quick answers

Also worth reading: How to kill failing ventures: 60% kill by second gate vs double down: How to kill failing ventures: · How to kill failing pilots: 21 days vs 84 days kill decision in 2026: How to kill failing pilots: