If you have to think about it for more than a few seconds, that number is probably not being tracked.
Digital and product teams measure win rate, test volume and conversion rate carefully. Time-to-launch rarely makes that list, and slow delivery is one of the most common reasons experimentation programmes produce less than they should.
Based on our work with digital and product teams, and consistent with published industry practice, the benchmark bands for standard A/B tests and content experiments look like this.
Under two weeks from hypothesis to live is a well-functioning programme. Tooling is being used to its potential, governance is proportionate, and the team is learning at a pace that allows meaningful improvement within a normal quarterly cycle.
Two to four weeks suggests friction exists somewhere. The programme is functional, but something is slowing delivery, whether that is a development dependency, a QA bottleneck, or a sign-off process with too many steps. At this pace, a team planning weekly tests in theory may only deliver up to six experiments in a quarter in practice.
Consistently above four weeks for standard tests means the team is probably working hard on the wrong things. An experiment that could have informed a January roadmap decision is still generating results in March, and the learning cycle that should be accelerating commercial performance is arriving too late to change anything.
VWO's Experimentation Maturity Benchmark Report 2025-2026, drawing on surveys across hundreds of organisations, found that over half of teams are bottlenecked at a low monthly test volume. In most cases the constraint is not ideas or ambition but the process between having an idea and getting it live.
Three causes account for the majority of slow delivery.
The first is development dependency.
Optimizely's own analysis of 127,000 experiments, published in February 2026, identified getting ideas built as the single biggest bottleneck in experimentation. Tests that make a real impact typically need custom code, and custom code means a dev ticket, a queue, a sprint cycle and a lead time just to get prioritised. Optimizely's experimentation tooling is built to remove exactly this dependency, allowing marketing and product teams to build and launch straightforward tests without writing code. If standard tests are still routed through development sprints, the platform is not being used to its potential.
The second is a QA process that treats every experiment like a product release.
A content change on a landing page and a significant feature experiment carry different levels of risk, and a proportionate QA process reflects that distinction. When every test goes through the same review cycle regardless of complexity, low-risk experiments queue behind high-risk ones and the average time to launch rises.
These three fixes come from direct experience working with digital and product teams on Optimizely. Each produces a visible improvement quickly, without requiring a significant process overhaul.
1. Separate your test tiers formally. Define what counts as low, medium and high complexity and document the approval requirements for each. A copy change on a CTA button and a multivariate test on a checkout flow are not the same decision. Once you formalise that distinction, low-complexity tests move to a faster track immediately, without waiting for a sprint allocation or a governance review.
2. Move QA earlier in the process. Most QA delays happen because review only begins once a test is built. Involving a QA resource at the brief stage, to check the hypothesis, the success metric and the technical approach before build begins, means problems surface earlier and the build-to-live step becomes faster and more predictable.
3. Track the number and review it weekly. Time to launch only improves when the team can see it. Add it to your regular stand-up as a single figure: the average days from backlog to live across the current quarter. Visibility alone shifts behaviour, because it makes the friction visible to everyone in the room rather than just the people experiencing it.
Time to launch is a leading indicator. It tells you whether your programme is set up to improve before you see it in the conversion rate. A team moving from hypothesis to live in under two weeks will always outlearn a team that takes four, even with equally sharp hypotheses and equal traffic.
If your programme has strong data and a healthy backlog but performance has plateaued, time to launch is one of the first places to look. Our Optimise service works with digital and product teams on exactly this kind of structural improvement, on an ongoing retained basis rather than as a one-off intervention.
If this sounds like your programme right now, we would love to talk.