The Sunk Cost Problem Nobody Talks About in Tech

Published 2025-11-04 · Updated 2026-06-23 · By Alan Wizemann

Topics: Digital Transformation, Product Strategy & Development, Growth Leadership

At a company I worked with earlier in my career, someone made an observation in a meeting that I have genuinely never been able to forget. If you added up the revenue projections on the last slide of every business case that had been presented to leadership over the prior few years, the company would be roughly ten times the size it actually was (and this was not a small company to begin with). Nobody in the room disputed it, and what struck me even then was that nobody felt they needed to. Everyone understood that those numbers were never really meant to be accurate in the first place – they are part of the process of getting things funded. You need a number on the slide, so you make it plausible and optimistic and you move along, and the actual work happens later. Whether it ever delivers anything close to slide fourteen is a separate conversation that, in my experience, very rarely takes place.

What bothers me about this is not the optimism, exactly, because some amount of optimism is simply how anything ambitious gets started. It is the consequence. Those inflated projections turn out to be the same numbers that make it nearly impossible to stop something once it has started. When a project has been running for three years on the strength of a compelling business case, the argument for continuing quietly becomes that we have invested too much to stop now. What gets lost underneath that argument is the more useful question, which is whether the world has changed enough that the thing we are building no longer fits what we actually need. In my experience, when a project has been running for three years, the answer to that question is almost always yes. The value has been erased, and not because the team did not work hard and not because the original problem was not real. It happens because the technology landscape shifts, customer needs shift, and the assumptions baked into a business case from three years ago have a way of going quietly outdated while everyone is still earnestly trying to execute against them. By the time the thing finally ships, the people who have to use it are often looking at something that was designed for conditions that no longer exist.

The prioritization approach we use at Southern Glazer's is built around what I think of as time to value, and the reframe is more important than it sounds. The question is not which project has the biggest projected return. The question is what we can actually get done and in front of customers the fastest, in a way that proves whether the value is real or not. About eighty percent of our prioritization decisions come down to exactly that. The other twenty percent goes toward foundational work – the infrastructure changes that do not deliver customer-facing value immediately but that unlock faster delivery of everything coming after them. We relook at priorities every quarter across all of our digital products, and not as a formality that gets penciled into a calendar but as an actual operational discipline: every quarter we ask whether what we are working on is still the right thing, whether the metrics we are tracking against these teams are still the right ones, and whether something has changed in the market or in our data that ought to move something else up the list. When the answer to any of those is yes, we move. The model has enough flexibility built into it to absorb that movement precisely because the teams are organized around outcomes rather than around a project plan that was locked in at the start of the year.

The hardest conversation that comes with this approach, and I have had it dozens of times now, is the one about stopping something that has already consumed significant time and resources. The instinct in the room is always to protect the investment, to find some path to the finish line that justifies what has already been spent. What I try to redirect that energy toward is a different posture entirely: ignore what you have spent, look instead at what you were originally trying to accomplish, and ask whether there is a faster path to that outcome now and whether the work can be broken into parts, some of which have real near-term value and some of which can be deprioritized or simply cut. Most of the time, when you do that analysis honestly rather than defensively, the core value turns out to have been achievable in a fraction of the original scope. The project grew the way these things tend to grow, because business cases get padded, requirements accumulate, and every stakeholder wants their particular piece included. The original problem was real and solvable, but what got built up around it was three years of organizational accretion, and nobody along the way was responsible for saying no.

The other discipline I hold onto, and I mean it as an actual practice rather than a philosophy, is starting small. Before a new initiative turns into a headcount request and a full project plan, the question worth asking is whether you can build a smaller version with a few people and test it with a handful of real customers or users. Most of the time you can. When you do, you tend to learn two things quickly – whether the idea actually works, and who the right people are to scale it if it does – and both of those are very much worth knowing before you have spent two years finding out. There is also a warning sign I have learned to watch for at the very beginning of any new initiative, which is when the team already knows exactly what they are going to build before they have talked to a single user. That certainty at the start is usually inversely correlated with how well things end. The initiatives that have worked best for me started from a clear direction rather than a predetermined answer, and then changed substantially based on what the first small version actually revealed. In the end, the business case game is really just a symptom of a deeper structural problem. When the only path to funding runs through a projected return you cannot actually measure in advance, you inevitably end up selecting for the things that look compelling on a slide rather than for the things that create value – and time to value is the reframe that gets you out of it, trading the question of what this will be worth if everything goes right for the far more honest one of how fast we can find out whether it is worth doing at all.