Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How a CTO Uses Cost of Delay to Prioritize the Feature Queue
Transcript
- Lucas: There is a question every engineering leader hates: 'Which feature should we build next?' And the honest answer, most of the time, is 'I don't know — let's guess.' Luna: Right — the roadmap by gut feel, or by whoever shouts loudest in the room. Lucas: Exactly. And there is a better way. It's called cost of delay. It comes from lean product development — specifically from Don Reinertsen's work — and it basically puts a dollar figure on what happens if you postpone a feature by a week, a month, or a quarter. Luna: So instead of asking 'is this feature valuable?' you ask 'how much value do we lose per unit of time we wait?' Lucas: That's the whole shift. Let me make it concrete. I talked to the CTO of a Series B fintech — company called Tally, about 80 engineers. They had three big features in their annual planning cycle. Feature A was a compliance dashboard — regulators were breathing down their neck. Feature B was a new API for enterprise customers. Feature C was a UI refresh for their mobile app. Luna: Classic tension: regulatory must-do, revenue opportunity, and user experience. Lucas: Right. Their old approach was to rank by urgency: compliance first, then the API, then the UI. But when they applied cost of delay, they looked at three things. One — the value if the feature ships today. Two — the decay rate: does this feature lose value quickly if delayed, or is it durable? Three — the opportunity cost of not having it. Luna: The decay rate is the key insight, isn't it? Some features have a shelf life. Lucas: Exactly. The compliance dashboard had a huge value if it shipped by the regulatory deadline — call it $2 million in avoided fines. But if it shipped a month late, the fine was the same. So the cost of delay per week was actually low, because the penalty was binary: you either meet the deadline or you don't. The API, on the other hand, had a contract with a big enterprise client that would pay $500,000 per quarter, but only if the API was live by the start of Q3. Every week of delay meant losing about $40,000 in revenue. That's a high cost of delay. Luna: So the API actually had a higher urgency than the compliance dashboard, even though the compliance thing felt more urgent. Lucas: Precisely. And the UI refresh? The mobile app had a 4.2 star rating — good enough. Delaying the UI by a month might cost a few thousand in churn, but not much. So the cost of delay was low. That flipped their entire roadmap. They put the API first, compliance second, UI last. And the CTO told me that decision alone got them an extra $600,000 in revenue that year. Luna: That's a powerful example. But I want to push back a little — doesn't cost of delay break down when you have high uncertainty? Like, what if you don't know the value of a feature, or the decay rate is fuzzy? Lucas: Great question. And the honest answer is: yes, the model is only as good as your estimates. But here's the thing — even rough estimates are better than no estimates. Reinertsen says you can be wrong by a factor of two and still make better decisions than gut feel. The CTO I talked to said they used a technique called weighted shortest job first, or WSJF, which divides the cost of delay by the job size. So a feature with a cost of delay of $100,000 per week and a two-week build time has a WSJF score of 50,000. A feature with a $50,000 cost of delay and a one-week build has a WSJF of 50,000 too — they tie. It forces you to be explicit about trade-offs. Luna: So it's not just about 'what's most valuable' — it's 'what gives us the most value per unit of time.' Lucas: Exactly. And that's where the engineering team often pushes back. Because WSJF tends to favor smaller, faster features over big strategic bets. The CTO told me his product managers were initially resistant — they wanted to build the 'big vision' feature first. But when they compared the WSJF scores, the smaller features kept winning. So they had to adjust: they created a separate pool for strategic bets that weren't evaluated on cost of delay, because the decay rate was different. That's a nuance a lot of people miss. Luna: So you're saying cost of delay isn't a replacement for strategy — it's a tool for sequencing within a strategy. Lucas: Perfectly put. And the CTO I talked to used it to have a very different conversation with the CEO. Instead of arguing about which feature was more important, they argued about the numbers. The CEO could see: 'If we delay the API by two weeks, we lose $80K. Is that worth it to get the compliance dashboard done two weeks earlier?' And the CEO said no. So they funded a small compliance team to meet the deadline and put the main engineering team on the API. Luna: That's exactly the kind of trade-off conversation that most leadership teams avoid because they don't have a common language for it. Lucas: Right. And cost of delay gives you that language. One more thing — the CTO also used it for maintenance work. A common complaint is that refactoring or tech debt never gets prioritized because it has no obvious value. But they assigned a cost of delay to not refactoring: every week they waited, the engineering velocity dropped by a measurable amount. So they quantified it — and suddenly the refactor had a WSJF score higher than most features. Luna: That's brilliant. Because it makes tech debt visible in the same currency as features — dollars per week. Luna: So how do you actually start using it without getting paralyzed by the math? Lucas: The CTO's advice was: start small. Pick one team, one quarter, and three features. Estimate the cost of delay using the simplest method: take the expected revenue or cost savings, estimate the delay penalty — is it linear, fixed, or exponential? For most features, it's roughly linear over a quarter. Then divide by the job size in weeks. Plot the WSJF scores. See if it changes your priorities. If it does, roll it out to more teams. If it doesn't, you probably already had good intuition. Luna: And if the team pushes back on the estimates, you can always say 'it's a model, not a truth — we'll refine it.' Lucas: Exactly. And honestly, that's the same thing we try to do on this show — refine our understanding episode by episode. Speaking of which, quick honest thing: this show is ad-free and listener-supported. A handful of listeners chip in monthly through buy me a coffee dot com slash fexingo, and that's literally what funds making this many of these. Luna: Yeah, it's a small group, but it makes a big difference. Keeps us independent. Lucas: And that independence lets us dig into frameworks like cost of delay without worrying about sponsors. So if today's tech conversation gave you something usable, consider joining that group. But either way, back to the topic — because I want to get into one more thing. Luna: Sure — what's the next layer? Lucas: The CTO also shared a failure. They applied cost of delay to a machine learning feature that required six months of data collection before it could even be evaluated. The cost of delay per week was essentially zero for the first six months because there was no way to ship it earlier. So WSJF told them to deprioritize it. But that feature turned out to be a game-changer once it shipped. The issue was that cost of delay assumes you can ship incrementally, and for some ML features, you can't. So they learned to flag features with 'information deadlines' — where value only materializes after a fixed period. Luna: So the framework itself helped them see which features didn't fit the model. Lucas: Exactly. It's not a silver bullet. But it's a lens. And for most engineering teams, it's a much better lens than the roadmap-by-opinion they're currently using. Luna: Alright — so if someone wants to try this next sprint, what's the one thing they should do differently on Monday? Lucas: Pick the three items that feel most important on your board. Ask: 'If we delay this by one month, what's the cost in dollars?' If you can't answer that, you don't understand the feature well enough. That question alone will surface more insight than any prioritization meeting you've ever had. Luna: I like that — it's a forcing function for clarity. Lucas: It is. And it's the kind of tool that makes engineering leadership less about guessing and more about economics. Which, at the end of the day, is what every CTO is doing — allocating a scarce resource, engineering time, to maximize value over time. Luna: And with that, maybe next episode we look at a case study where cost of delay went wrong — or at least was gamed by product teams? Lucas: That's a great idea. There's a whole darker side to these frameworks — like sandbagging estimates to make your feature look better. We'll cover that. For now, though, I think we've given listeners enough to start experimenting.