A retailer's new product category launches on schedule for the seasonal peak. The software works. Within two weeks, returns processing is a month behind, finance cannot reconcile settlements, and support handling time has doubled. What went wrong, and what does it say about time to market?

The trigger

"Ready" was defined as the software being deployable, and that definition belonged to the engineering plan rather than to the business. The category shipped with working checkout and without the operational capabilities that its particular economics require: a returns flow for a product type with a much higher return rate, a settlement format the finance system had never seen, and support material for a category the agents had not been trained on.

Why it propagated

The three symptoms share a cause. Each depends on a downstream process whose owner was not in the launch plan, and each has a lag: returns surface 2 to 3 weeks after sales because that is the returns window, reconciliation breaks at the first month-end, and support load builds as the installed base grows. A category with a 25% return rate against a catalogue average of 6% puts four times the expected load on a process sized from the average. The failure was invisible on launch day and inevitable from the start, which is the signature of a readiness gap rather than a defect.

Why detection lagged

Launch dashboards measure what the launch team built: orders, conversion, error rate, latency. Nothing on the dashboard belonged to returns, reconciliation or support, so the first signal was a person complaining, not a metric crossing a threshold.

The structural fix versus the tempting local fix

The tempting fix is to add people to returns and support, which is right for this quarter and changes nothing about the next launch.

The structural fix is to define go-live from the value stream rather than from the deployment. Concretely:

• A readiness checklist owned by each downstream process, with a named owner who says yes: returns, finance, support, tax, legal, partner operations.
• Launch metrics that include the lagging processes. Returns rate against plan, unreconciled settlement value, average handling time, all visible from day one even when they are empty.
• A pilot with real volume — one region, one week, a few hundred orders — which exercises the downstream processes before peak. A pilot sized to test the software only tests the software.
• Sequencing the launch inside the peak window rather than at its edge, so there is time to correct. Launching the week before the peak removes every correction opportunity, and the cost of that choice is paid by people rather than systems: overtime, manual reconciliation and goodwill refunds.
• Choose the launch date from the slowest downstream process, not from the engineering estimate. Since retail peak trading has concentrated an ever-larger share of annual margin into a few weeks — a pattern visible in published retail results every year since 2015 — the cost of getting this wrong is concentrated too.

The general lesson

Time to market is measured to the point where the business can run the thing, not to the point where the code is live. The common failure is not late software; it is software that is on time and a value stream that is not, and the architect is usually the only person with visibility across all of it.

When this is the wrong analysis

If the downstream processes were genuinely in the plan and simply failed under real volume, this is a capacity problem rather than a readiness one, and the fix is load-testing the human process: how many returns an hour can be handled, and what happens at twice that. The two failures look identical from the outside for the first week and have completely different remedies.