From Insights to Actions: Closing the Execution Gap
- Count your open findings with the date each one was made, so the backlog becomes a number.
- Measure action rate: findings shipped divided by findings produced, every quarter.
- Assign a half-life per kind of finding, because seasonal and structural ones decay differently.
- Cap research intake to what the team can ship, rather than raising research output.
- Close expired findings in writing, instead of leaving them where they look like assets.
- Spend the released research time making each finding cheaper to act on.
- Treat a shipped change as the only evidence that the organisation learned anything.
Last updated: November 2026
Closing the execution gap is usually framed as a prioritisation problem, and after thirteen years of watching growth teams I think that framing is why it never closes. Every team I meet has a list of things it knows and has not done. The list is rarely badly ordered. It is simply far longer than anything the team could ship in a year, and the items at the bottom of it stopped being true some time ago. That is not a decision failure. It is a capacity failure with a depreciation problem attached. Omniconvert has run 70,000+ experiments across 2,500+ Shopify stores over 13 years in eCommerce, and the teams that compound are not the ones that learn fastest.
I want to be precise about the claim, because it cuts against how most growth functions are staffed. The output of a growth team is shipped changes. Research is an input. A finding that nobody acts on has produced nothing, and it has consumed the hours that made it. So a team whose research output exceeds its shipping capacity is not building an asset. It is building a queue.
Closing the execution gap is a capacity problem
Here is the arithmetic that convinced me. Suppose a team produces thirty findings a quarter from analytics, session recordings, surveys and competitor work, and ships six changes. The gap is twenty-four findings a quarter, compounding. After a year the list holds roughly a hundred items and the team is shipping six.
Now apply any prioritisation framework you like. It will reliably select the best six, which is a real improvement over selecting six at random. What it cannot do is make the other ninety-four worth anything, and that is where almost all of the research investment went.
The uncomfortable corollary is that hiring another analyst makes this worse. More findings against the same shipping capacity lowers the share of research that ever becomes a change, which is the ratio that actually matters. I have watched teams respond to a visible execution gap by adding research capacity, which is the one intervention guaranteed to widen it.
Insight half-life, and why a backlog is not inventory
An insight half-life is defined as the period after which acting on a finding is worth half what it was worth when the finding was made. I use the term because the alternative mental model, that findings sit in a backlog retaining their value until somebody gets to them, is the belief that keeps these lists growing.
Different findings decay at very different rates, and the distinction is easy to make and almost never made. A seasonal observation about checkout behaviour during a promotional peak is close to worthless eleven months later. A structural finding about a missing product attribute is good for years. Both sit in the same list, undated, looking equally actionable.
Shopify's merchant guidance has pushed complete and consistent product data across sales channels for years, which is a fair example of the durable end of the spectrum [Shopify, 2026]. At the other end, the share of shoppers abandoning a cart for a given reason moves with the traffic you bought that month, even though the long-run average that Baymard Institute reports holds at around 70% [Baymard Institute, 2025].
| Kind of finding | Decays | What to do with it |
|---|---|---|
| Structural data gap | Very slowly | Keep, schedule properly |
| Broken or missing flow | Slowly | Ship, it rarely improves alone |
| Pricing or margin finding | Moderately | Act this quarter or re-check |
| Creative fatigue signal | Fast | Act now or discard |
| Seasonal behaviour note | Fast, then annually | Date it, revive next season |
| Competitor observation | Fast | Discard once stale |
Dating the list and assigning a half-life per kind changes the conversation in a specific way. The question stops being which finding is most valuable and starts being which findings are about to become worthless. That is a far easier question to answer and it produces a different, better sequence.
Measure action rate, not insight volume
Action rate is defined as the proportion of findings produced in a period that resulted in a shipped change, and I would rather know a team's action rate than its experiment velocity or its research output.
It is worth measuring for a reason beyond diagnosis. Insight volume is easy to grow and feels productive, so it attracts effort. Action rate can only be improved two ways: ship more, or produce less of what you will not ship. Both are useful, and neither is available as a way of looking busy.
The specific failure I see most often is the research review that functions as a storage system. A team meets fortnightly, walks the list, discusses three items, agrees they are important, and adds four more. Everybody leaves feeling the meeting was substantive, because it was full of real findings and genuine analysis. Nothing was closed and nothing was shipped. The meeting has quietly changed purpose from deciding what to do into confirming that the team is still clever, and it will run in that form for years because nobody is doing anything wrong in it.
AliveCor used Omniconvert to run a structured A/B testing programme and achieved +21% conversion rate, +5% revenue per visitor, and 94% statistical relevance across their experiments. [Omniconvert, AliveCor case study] What I take from that is the structure rather than the uplift: the programme shipped and read a sequence of changes, which is what turns findings into a result.
Cap intake to capacity, deliberately
This is the part teams resist, and I understand why. Capping research sounds like choosing to know less, and in a culture that values being data-driven it reads as a retreat. It is the opposite. It is choosing to know less that you will never use.
In practice it means three moves, none of them complicated. Write down the number of findings you shipped last quarter. Set your research intake near that number. Then go through the backlog and formally close every item older than its half-life, with a line saying it expired rather than that it was rejected.
That last step matters more than it sounds. An expired finding left in a list is a standing claim that the team knows something valuable it has not done, and that claim is corrosive: it makes the backlog feel like an obligation and the team feel permanently behind. Closing it honestly is a release rather than an admission.
Spend the released time making findings cheaper to ship
This is where the loop closes, and it is why the capping argument is not austerity. Shipping capacity is not fixed. It is a function of how much work each change takes, and most of that work is avoidable: data that has to be re-assembled, a test that has to be configured from scratch, a hypothesis that has to be re-argued because nobody wrote down why it mattered.
Where this leads, for us, is a layer that does more than report. Omniconvert Commander (formerly Nexus) unifies commerce data, prioritises experiments by True Profit and generates campaigns and creative you approve before they go live. The part that matters to this argument is not the generation, it is that the queue arrives already ranked and already carrying its data, which removes a large share of the per-change cost. Omniconvert Explore is where the chosen change gets proved rather than asserted.
The adjacent argument, about what has to be attached to a metric before it produces a decision at all, is in why dashboards do not drive decisions. The case for treating conversion, creative and visibility as one system rather than three queues is in how CRO, creative & AI visibility tie into one growth system, and the market context for all of it is in the state of DTC growth in 2026.
One caution, because this argument can be misread as an excuse to stop looking. A team with a high action rate and a small backlog is in a good position to raise its research intake, and should. The sequence is what matters: raise capacity first, then intake. Doing it the other way round is how every one of these lists got long in the first place.
FAQ: insights, actions and the execution gap
The distance between what a growth team knows and what it has shipped. It is usually described as a prioritisation failure, and it is more often a capacity failure: the team produces findings faster than it can act on them, so the backlog grows and the oldest items quietly stop being true.
The period after which acting on a finding is worth half what it was worth when the finding was made. The traffic mix moves, the catalogue changes, a competitor repositions, the season turns. A finding is not a durable asset, and treating a research backlog as inventory overstates what the team owns.
Because research is not the constraint. Adding insight to a team that cannot ship what it already knows lengthens the queue and lowers the share of findings that ever get used. The output of a growth team is shipped changes, and research only counts once something changed.
Higher than yours, almost certainly, and the number matters less than the direction. Measure findings shipped against findings produced each quarter. Most teams are surprised by how low it is, and a team that raises it without raising research output has genuinely improved.
No, it means learning less that you will never use. A finding that sits unused for two quarters taught the organisation nothing, because nothing changed because of it. Capping intake converts research hours into shipped changes, which is where the learning actually happens.
Prioritisation decides the order of a queue. This decides the length of it. A perfectly prioritised backlog of forty findings in a team that ships four a quarter still wastes most of what it knows, so the ordering problem and the capacity problem need separate answers.
Open whatever list your team keeps of things it has learned and not done. Count the items, and write the date each one was made next to it. Then count how many findings you shipped last quarter. Those two numbers are your backlog and your capacity, and the ratio between them is the only honest description of your execution gap.
Most teams find a backlog many times larger than a quarter of capacity, which means most of what they know will never be used and some of it is already untrue. The useful response is not a better prioritisation framework. It is to close the expired items in writing, cap what comes in to roughly what goes out, and put the released hours into making each remaining finding cheaper to ship.
Insight depreciates while it waits
Count your open findings, measure your action rate, and cap intake to what you can actually ship.