Predictability is a lagging indicator. A say/do ratio tells you how well a team kept last quarter's promises, and the outcome those promises were meant to move usually shows up one or two quarters after the work ships. Leaders who run on predictability are grading the half of the feedback loop that closes fastest, and it happens to be the half that says least about whether the work mattered.
Marty Cagan made the bigger version of this argument a week ago. In Predictability vs Outcomes (SVPG, October 12, 2026) he says the output-versus-outcomes debate has the wrong opponent. Output is a symptom. The cause is how much an organization wants to know what will ship and when. He quotes Henrik Kniberg's line that "100% predictability = 0% innovation," and he admits he underestimated how deep that desire runs. I agree with all of it. What I want to add is the timing problem, because it explains why the desire is so hard to dislodge even in companies that say they care about outcomes.
Why does predictability win the argument in most companies?
Because it reports first. A predictability number is ready at the end of the quarter: we committed to twelve items and shipped ten. It is clean, it has a denominator, and it closes inside the planning cycle that produced it. An outcome number, such as retention for the cohort that got the new onboarding or expansion revenue from the accounts that got the new admin features, is not ready then. It needs a cohort to age or a renewal cycle to pass.
Lay the calendar out and the problem is plain. Work committed at the start of the first quarter ships during it or early in the second. A retention or expansion signal that you would trust enough to act on is readable somewhere in the third. By then the second and third quarter plans have already been committed, on the strength of the only number that was available, which was whether the first quarter's dates held. That is the two-quarter feedback lag. Nobody chooses predictability over outcomes in a meeting. The calendar chooses it, because only one of the two numbers is on the table when the next plan gets made.
What does a training plan teach about this?
Endurance training has the same structure, and athletes learn it the hard way. A training plan produces a compliance number every day: did you do the session as written. Fitness, the thing the plan is for, shows up weeks later, and the real verdict comes on race day, months after most of the sessions that produced it. An athlete who judges a block by compliance alone will finish every interval exactly as prescribed and still race badly if the plan was aimed at the wrong thing.
Compliance is still worth tracking. A sudden drop tells you something is wrong with recovery, motivation or the plan itself. It is a diagnostic. The mistake is treating it as the score. Goodhart's law names the failure: once the measure becomes the target, it stops measuring the thing. A say/do ratio turned into a target produces smaller commitments, padded estimates and roadmaps full of work that is easy to finish on time. The number improves and stops telling you anything.
Why does AI make this worse?
Cagan ends his piece by separating companies that use AI to get better results from companies "just running faster in the wrong direction." The feedback lag is how the second group happens. AI makes output cheaper, so hitting committed dates gets easier. The predictability number goes up across the board, which means it carries less information than it did, while the outcome readout still takes as long as a cohort takes to age. Faster delivery against the same lag means more work shipped before anyone learns whether the first batch did anything.
I made a version of this point about engineering productivity in the future of software engineering: when a measure reads high for everyone, it stops separating good from bad. Delivery predictability is heading the same way.
What should engineering leaders do about the lag?
The lag can't be removed, because the cohort takes the time it takes. What a leader controls is which numbers sit on the table when decisions are made. Four changes do most of the work:
- Give every roadmap item a readout date. Set it at the point where its outcome can actually be measured, usually one or two quarters after ship, and write down the metric it is meant to move before work starts.
- Review readouts in the same meeting as delivery. If the quarterly review covers only what shipped, the calendar keeps choosing predictability. Put the readouts from two quarters ago next to this quarter's delivery.
- Keep predictability where it is legitimately required. Contracts, regulatory dates and launches tied to an event need it, and Cagan accepts that. Mark those items explicitly, so date-driven work is the labeled exception.
- Use the say/do ratio as a diagnostic. When it drops, ask why. When it is perfect for several quarters running, ask whether the team has stopped committing to anything uncertain.
Look for leading proxies too, but stay honest about them. An activation rate in the first week can stand in for retention, if you have checked that the two move together in your product. A proxy you have never validated is just another output metric.
What does this ask of the person running the team?
Mostly, patience in public. A leader judged on readouts has to defend a plan whose results will not be known for two quarters, and accept that some items will read out flat. Cagan's line that "many, if not most, of the product ideas on your roadmaps are simply not going to work" is uncomfortable to repeat to a board, and it is also the reason readouts matter. If most ideas fail, the team that learns which ones failed fastest wins, and it does that by reading outcomes, whatever its delivery numbers say.
For the metric side of this, ctaio.dev has a practical comparison of DORA alternatives and a breakdown of predictability metrics like the say/do ratio. If you are a CTO trying to make this change with a board that reads only delivery numbers, it is the kind of problem I take on as a fractional CTO and in executive coaching. More essays and guides for technology leaders are in the guides library.
Sources
- Marty Cagan, Predictability vs Outcomes, Silicon Valley Product Group, October 12, 2026. Includes the Henrik Kniberg quote.
- Charles Goodhart, "Problems of Monetary Management: The U.K. Experience," 1975, the origin of what is now called Goodhart's law.
Frequently Asked Questions
What does Marty Cagan mean by predictability vs outcomes?
In his October 2026 SVPG article, Cagan argues that the real trade-off behind the output-versus-outcomes debate is predictability versus outcomes. Output is a symptom. The cause is an organization that wants to know what will ship and when, and treats outcomes as a hoped-for side effect of delivering what was promised.
Why is predictability a lagging indicator?
A predictability metric such as a say/do ratio only tells you how well last quarter's commitments were kept. It describes the past and says nothing about whether those commitments were worth making. The outcome a roadmap item was meant to move usually reads out one or two quarters after it ships, which is later still, so neither number is available when the next plan is set.
Should engineering teams stop tracking predictability?
No. Some work needs a date: a contract, a regulatory deadline, a launch tied to an event. Cagan says as much. Keep the say/do ratio as a diagnostic that prompts a question when it drops, and stop using it as the main score a team or its leader is judged on.
What is the two-quarter feedback lag?
It is the gap between committing to a piece of work and learning whether it changed anything. Work committed at the start of one quarter ships during it or the next, and outcomes like retention or expansion need a full cohort or renewal cycle before they can be read. By then two more planning rounds have already been committed without that answer.
How should engineering leaders measure outcomes instead?
Put a readout date on every roadmap item, set at the point where its outcome can actually be measured, and review results at that date in the same forum that reviews delivery. Name the metric each item is meant to move before work starts. Judge the leader on the readout and on what the team did with it.
Need Expert Technology Guidance?
20+ years leading technology transformations. Get a technology executive's perspective on your biggest challenges.
