Four weeks is the shortest honest test of alive

Two words get used as if they were the same, and the confusion costs projects their evidence: launched and alive. A launch is a date. Alive is an observation with a duration and a threshold.

The rule

A feature is alive when it is still in use for four consecutive weeks after going live. When that window closes, any feature whose disable rate exceeds thirty percent goes on the not-alive list. The list is a required output of the delivery stage, not an admission of failure.

Two operational details make the rule work. The observation window cannot be closed early, even when the customer is happy and the next project is waiting. And the not-alive list has to be written down, because a death that is not recorded cannot be turned into a lesson; the sixth section of the six-section anatomy cannot be left empty or filled with the word "none", and "the process went smoothly" is not evidence that nothing died.

Activation is not go-live

Activation means the target group of users has formed a stable habit of use inside their ordinary working day. It is not applause at the demo. It is three months later, with nobody chasing, still in frequent use. Three things block it, and none of them is a missing feature: the tool is not handy, it is not trusted, or it is not about the user's actual job.

That definition makes activation a behavioural measure rather than a stated one. People say the tool is useful in the review and then keep the spreadsheet open in another window; the spreadsheet is the data. A useful test follows from it: if the system only gets used while the vendor's team is on site, what exists is accompaniment, not activation.

Ordering the go-live trade-off

When the deadline arrives and the full scope is not ready, the decision is rarely go or no-go. It is which slice goes. A recorded final QA pass makes the split concrete: of fifty-seven checks, thirty-six passed, eighteen failed and three were skipped. The reading was not "ship it anyway" but a split verdict — the minimum demo slice could go live, the complete version could not. A vague verdict, in either direction, hands the unverified risk to production.

Four rules order the trade-off:

1. The slice that goes live contains the top-priority metric from the metric table.
2. The evidence for that slice reaches the business endpoint, not just the system boundary.
3. The slice can be observed for four weeks without the FDE standing in the loop.
4. Everything excluded goes on a written out-of-scope list, not into a verbal promise.

Rule two is where most launches fail quietly. A 200 response proves the system accepted the request. It does not prove the action completed, and it certainly does not prove the business endpoint received the result. Evidence has to travel from acceptance through processing and action to the place where the work actually lands, and only the last of those four is the launch criterion.

The number worth putting on a wall

If one number has to be visible to everyone, make it the four-week survival rate: features still in use in the fourth full week divided by features shipped in that release. Put the disable rate beside it, since the thirty-percent line is what turns the rate into a decision.

The reason to put it on a wall rather than in a dashboard is behavioural. Health scores earn their keep less through the score than through the weekly obligation to walk every customer, one by one. A metric that nobody argues about every week is decoration.

What the rule refuses to accept

It refuses "it's in use" as a sentence without a number and a window. It refuses a launch celebrated the week it ships and reviewed long after, because by then everyone remembers the launch and nobody remembers the week the usage stopped.

It also refuses the opposite error, treating a death as a scandal. One recorded deployment ended with no dead subsystem at all: the waste number fell by more than half across twenty-three stores, with no rework and no interruption, and the thing that died was the practice of guessing delivery volumes. That is a legitimate outcome and it belongs in the same section as the failures. A teaching case from the same method shows the other pattern: three deliverables, all three dead, for three different reasons — an unstable data source, a workflow change whose daily cost exceeded its benefit, and a sign-off from an IT sponsor with no business owner behind the decision. One project can die three ways at once, which is why the review has to name causes rather than count bodies.

The closing test

Ask two questions at the end of the fourth week: which features are still in use, and what is the disable rate for each of the rest. Anything above thirty percent is not alive, whatever the customer says about it in the meeting. Then carry the list into extraction, because a feature that is not alive should not be handed to a successor as if it were. The window itself is defined in the delivery stage, and what gets measured in it comes from the metric table.