Sunk Cost Fallacy: Pulling the plug on a feature.
We build software to achieve certain results. That report generator's purpose isn't to create pretty spreadsheets. It's there to give our customers insights into their data, anchoring them further to our product. We don't migrate that front end to Vue 3 because it looks cooler. We invest this effort, hoping it pays off in security, maintenance, hiring, and retention.
Projects have a clear business case. By doing X, we expect a list of outcomes so we can reap certain benefits. That's basically what a business case is: an action that creates an effect that results in benefits. If the cost of the action is lower than the value of the benefits, the business case is positive. Calculating the cost of the action is straightforward. Calculating the value of the benefit is often black magic.
If we discover that these results will not be what we projected, the business case is bust, and we should stop the project. That is Project Management 101.
Features also have a business case, albeit an implicit one. Few companies keep track of the ROI of each feature. Yet, we all have expectations. Let's revisit the example of the report generator. We probably don't have hard numbers of how many customers would decide to leave if we didn't release the feature. Through conversations with our clients, however, we understand they're frustrated by a lack of insights. That gives us an implicit, gut-feeling-based business case.
"If we give them better insights, we take away frustration, making them stay."
It's action + effect + benefit.
We dedicate a 2-week timebox to this problem. That's the cost of the action. Calculating the value of the benefit remains black magic, but we can do some ballpark estimates based on the monthly revenue each frustrated customer brings.
Now, let's say the team uncovers some bad news halfway through the timebox. The insights they thought they could provide, require more data than is available. They would need to enrich the dataset or pull from external sources. Anyway, it's going to take longer than two weeks to build something valuable.
If developing a more basic report doesn't provide insights, the value of the benefits has just dropped to near zero. Developing a more elaborate solution will increase the cost of action. Both of these options break the business case.
It either fails to deliver or becomes too expensive. The best move here is to stop the development.
Yet what I see over and over again are teams doubling down on what they started. They are now in week four of their two-week timebox, and there still isn't a tangible result. The same sunk cost fallacy that drives gamblers to ruin, takes hold of engineers.
It's easy to see why. Finishing the work you started is the definition of getting things done. Giving up is the polar opposite of problem-solving!
This leads to the painfully predictable scenario where a solution gets delivered that is of little value to users and stakeholders.
Now, it's pretty common for an iteration to end with an appetite for more. Valuable problems are never completely solved. When we ship an insightful report, users often demand another one. Good work creates more good work. It never ends. That's a good thing.
But when the business case breaks, we enter another scenario. In this case, we ship something just because we started building. The solution we deliver doesn't really solve the problem. It offers so little value that it feels like the teaser to a solution rather than the solution.
That infuriates users.
It's the kind of iteration that's not worth shipping.
When the business case breaks, it's time to stop development and return to the drawing board.
Whatever solutions we can come up with won't be happening in the current timebox. So stop development and plan a new timebox for the same problem. Cut your losses.
Canceling ongoing work feels bad, and a lot of us are inclined to "fix it". Yet when the business case breaks, continuing is madness. It's burning more resources to get fewer results. At that point, we need to ask ourselves whether it's still worth building and stop when the answer is No.
While that can feel like a waste, it's the responsible way of allocating resources.
Cut your losses when it's no longer worth it.
PS: This is edition 52 of the Planned Attention newsletter, which means we are one year in! Thank you for all your attention, feedback, and support! It means the world to me.