Brought to you by ExecReps.ai, AI-powered executive presence coaching for teams.
I have been the gate far more often than I have been the one waiting behind it. Work sat in my queue while a team carried on without an answer, and I could not have told you what that cost. None of it ever appeared on a budget line. The money was real all the same.
"I do not think most of us have a meeting problem. I think we have a decision problem." Kaanti Shetty, writing in Product Coalition
The Queue Nobody Draws
Every product organisation runs a second backlog underneath the visible one. It holds decisions rather than features. It has no board, no owner and no refinement session, so it never gets estimated.
Jack Moore set out the mechanism in Product Coalition six years ago, writing about what being scrappy demands of a company. "Companies that are scrappy do what they can to reduce this cycle time, minimizing unnecessary hierarchical approval processes by creating self-organizing teams." The chain he describes is short. Layers add steps, steps add elapsed time, and elapsed time is what you are buying.
The part I would argue with is the word unnecessary. It suggests somebody put the gate there by mistake, and that removing it is an administrative job. Gates are rarely accidents.
Daniel Bentes wrote the harder version of this in the same publication in March. "Approval gates are not only about risk management. They are authority." That sentence explains why the tidy-up projects fail. Nobody surrenders a signature because a consultant drew a swimlane diagram showing it was redundant.
Bentes is worth reading on the wider point too, because he separates the work of defining intent from the work of moving work between people. "Specification means defining intent, success criteria, quality standards, and judgment boundaries." That first kind of work earns its time. Coordination is everything else, and coordination is where the weeks go.
So the honest question is not how to delete the gates. It is which gate, on which decision, is currently costing more than the risk it was built to catch.
Put a Rate on the Waiting
A delay only costs money when something of value is sitting behind it, waiting. That sounds obvious until you try to name the thing.
J.A. Becker made the case for measuring it in Product Coalition in 2020, writing about weighted shortest job first. He argues that "the cost of delay is critical in determining which feature will make or save the company the most money and which one will take the least amount of time to build." Cost of delay against job duration. It is a ratio, and ratios are harder to argue with than opinions.
Where teams lose the thread is treating cost of delay as a property of the organisation. It belongs to the decision. A pricing change held for six weeks has a rate attached to it. A refactor held for six weeks may have none.
Work it out from whatever is waiting. Contribution margin per week on revenue that cannot start. The penalty exposure per month on a compliance fix. The engineering capacity sitting idle at a known weekly cost. Multiply the rate by the weeks that elapsed, and the meeting invite now has a price beside it.
The arithmetic is deliberately crude, and crude is the point. Say a pricing change would add four thousand pounds of monthly contribution once it ships. That is roughly nine hundred pounds a week of value sitting still while the decision waits. Six weeks in committee cost five and a half thousand pounds, before anyone has argued about whether the change was right.
Nobody needs a model for that. They need the number written down somewhere the people holding the decision can see it.
Senior leaders do believe there is a number there. West Monroe surveyed 214 C-suite executives and 1,000 managers at US companies with at least $250 million in annual revenue, and reported that "across industries, 73% of leaders report losing 1-5% of annual revenue due to slow decisions and delayed execution."
Read that as what it is. Executives self-reporting a feeling in a commissioned survey, fielded in November 2025, at companies far larger than most of the ones I work with. It tells you the belief is widespread and expensive. It proves nothing about your own organisation, and I would not put it in a board pack as though it did.
Your own number is the only one worth defending, and it is available. Take the last significant decision that sat waiting, name what was behind it, and price one week of that wait.
The Bill Arrives From Both Directions
Speed is not free either, and any argument that ignores that is selling something.
Research covered by Harvard Business School's Working Knowledge puts a shape on the downside. Danielle Kost, writing on a study of 13 years of US Food and Drug Administration data in medical devices, reports that "a recall can delay a company's incremental innovations by six months." The failure consumes the same development capacity you were trying to protect. You end up buying the delay anyway, at a worse price and on someone else's schedule.
The same piece carries the other half of the trade. "However, if a medtech firm can bring a new product to the market even one month earlier following a rival's recall, it could bring in an additional $10 million in revenue." One month. Ten million dollars. In that setting, with those competitors, at that moment.
I want to be careful about what this evidence does and does not say. It does not show that a rushed decision caused any of those recalls. It shows that product failure is expensive in exactly the currency the slow organisation thought it was conserving, and that responding faster than a wounded competitor is worth real money.
Which points at the same test from the other side. Match the gate to what the mistake would cost, and to whether you could undo it.
What I'm Hearing on the Podcast
Jurgen Dauk has spent nearly thirty years inside enterprise technology, at Oracle, OpenText and Planview among others, carrying full profit and loss responsibility across regions. He has watched this problem from the seat where the signature actually lives.
His first test is the one I now use myself. He starts by asking whether a decision can be reversed, and reserves the heavier process for the decisions that cannot. Then he takes the part most organisations get backwards.
"So for me, it's not so much about the seniority really, and you can consult people, but the decision ideally has to be made by somebody who really understands the topic."
Seniority is a proxy for judgement, and it is a weak one on a specific technical call. The person closest to the work usually holds the information that matters, and often the least authority to act on it.
Jurgen is firm that this only works with the guardrails written down. Clear rules, documented, with people trained on who must be consulted before a decision is taken. Distributed authority without that scaffolding just moves the anxiety somewhere quieter.
So What Does This Mean for You?
Pick one decision currently waiting. Name what sits behind it, price a week of that wait, and put the figure in the calendar invite for the meeting where it will be decided.
Then check the gate against the mistake. If the decision can be undone cheaply, one informed person should make it today. If it cannot be undone, the process is earning its keep, and the delay is a premium you are choosing to pay rather than a failure.
An approval chain nobody has costed feels like diligence. Put a weekly figure beside it and the same chain becomes a trade, and trades get argued about properly rather than defended on instinct.
So take the decision your team has been circling for the longest. What is it costing you a week, and who needs to be in the room?
Got a product story worth telling? Whether you're an exceptional talent shaping the future of product, or you've got a career journey others can learn from, I want to hear from you. Apply to be a guest on the Product Coalition podcast.
👋 Jay
Product Coalition is a reader-supported publication. Paid subscribers get every issue on the day it lands.