Every product team measures output. Stories completed. Features shipped. Bugs closed. Sprints delivered on time.
Almost nobody measures decision throughput. How many decisions were made this week? How long did each one take? How many are still stuck in limbo?
Why this matters
A team that ships fast but decides slowly is just efficiently building the wrong things. Speed of execution means nothing if the decision that triggered the work was made with stale context, or worse, never made at all.
Most product delays aren't engineering delays. They're decision delays disguised as engineering delays.
What to audit
Pick any feature your team shipped in the last quarter. Now trace it backward. When was the decision to build it actually made? Not when the ticket was created. When someone said "yes, we're doing this."
Now measure the gap. How long between "this is a good idea" and "yes, we're doing this"? For most teams, it's weeks. Sometimes months. All that time, context was decaying.
The three metrics
Track these for a month. Decision cycle time: how long from proposal to yes/no. Decision backlog: how many items are waiting for a decision right now. Decision reversals: how many times you changed your mind after committing.
High cycle time means your process is slow. A large decision backlog means things are piling up. Frequent reversals mean you're deciding with bad information.
How to start
At the end of each week, ask your team one question: what decisions are still unmade? Write them down. If the same decision shows up three weeks in a row, that's your bottleneck. Not the sprint. Not the engineers. The decision.
You can't fix what you don't measure. Start measuring decisions.
Tom Pinder