Time to Market

Definition

Time to market is the elapsed time from deciding to do something to a customer experiencing it. It is frequently the dominant business concern, and it is substantially determined by architecture.

What architecture controls

• How many teams must coordinate to deliver one change. This is usually the largest term, and it is a direct consequence of where boundaries were drawn.
• Whether teams can deploy independently, or wait for a release train.
• How long the pipeline takes, and whether it is trusted.
• Whether changes can be released in small increments, or must be batched until a feature is complete.
• How much of the elapsed time is waiting — for review, for an environment, for an approval, for another team. Frequently over 90%.

None of that is about how fast people write code, which is where the attention usually goes.

The measurement

Trace one change from decision to production and record where the time goes. The waiting is nearly always concentrated in one or two places, and it is usually somewhere nobody suspected — a fortnightly approval board, a shared environment queue, a manual migration process, a day of review latency.

This exercise settles arguments faster than any general discussion, and it produces a specific target rather than an aspiration.

The trade against maintainability

Speed can be bought with debt, and that is a legitimate instrument when it is deliberate and recorded. The failures are borrowing unknowingly and never repaying, and the categories where it should be refused are the foundations — data models, security boundaries, tenancy, identity — where shortcuts compound.

What frequently gets it wrong

Optimising the wrong stage. Making the build 20% faster when the change waits three days for approval improves nothing. Find the constraint first.

Confusing speed with productivity. More output through the same bottleneck does not reduce time to market; it increases work in progress, which usually makes it worse.

Treating it as an engineering concern. A significant share of the elapsed time is typically in decision-making, approval and specification, which are not engineering stages at all.

Failure scenarios

• Six teams needed for one customer outcome.
• A release train, so a change completed on day two ships on day thirty.
• Approval gates adding latency and no information.
• Deployment coupled to release, so nothing ships until the slowest feature is done.

Interview question

"Your time to market is eight weeks. How would you find out where it actually goes?"