Published Nov 9, 2025

Failure demand is a tax on software development

A failure demand¹ - happens when a customer thinks you’ve failed them, and now you need to go above and beyond to satisfy them. It’s a demand beyond your normal service agreement. It’s a bit like compensation for the failure itself. A failure demand is the enemy!

How failure demand manifests

In software products, failure demand can look like…

Custom reports to “prove” the system works correctly because something is hidden or confusing
Handholding through basic workflows because trust has eroded
Emergency calls or escalations that require leadership involvement
Extra meetings, status updates, and reassurance rituals
Overtime spent managing upset stakeholders

At Tradeshift, I was in charge of data and analytics. I spent time on many such reports. A customer would be confused about an integration or the performance of some part of the system, so they’d demand a report to verify the data. Then they’d want it permanently in the product “just in case.” An exec would get involved, promise it, and suddenly you’re building features to compensate for fuck-ups you never should’ve made in the first place.

This happens with colleagues too. Customer-facing teams aren’t excited about new features. They ask… “Does it actually work?”

The uncharitable assumption problem

Persistent failure demand changes how customers approach problems. Instead of assuming the best, they start making uncharitable assumptions.

When something goes wrong, they don’t think “I might have made a mistake” or “let me check the settings.” They think “the system is broken again.”

This loop is painful to escape. A bad data migration means customers assume all data is wrong, even when their own inputs are the problem. They stop debugging on their end. They stop trusting their eyes. Every issue becomes your issue.

The cognitive overhead they’re willing to spend debugging drops to zero. Why would they waste time investigating when the system is “always broken”?

Failure demand is systemic

A 2017 NHS study showed that primary care systems are not performing well, which often generates demand that gets sent to emergency departments. The initial system failed, so now a more expensive system has to compensate.

Poor quality and craftsmanship on product and engineering teams creates problems for customer success and support teams. One team’s failure becomes another team’s demand. It’s a negative externality that’s easy to miss.

Here’s the hard part: you can’t eliminate failure demand without changing how your organization is incentivized.

Leadership creates failure demand when they measure the wrong things. When you reward teams for shipping new features instead of improving existing ones. When quarterly goals incentivize rushing half-baked work out the door. Unfortunately, and perhaps unfairly, I’ve come to associate these issues with VC-backed companies.

It’s easy to treat the symptom instead of the cause. Hire more support staff. Build escalation processes. They add customer success managers. All of these are responses to failure demand, not solutions to it.

It’s not possible to fix this by cutting corners - the reason you’re in this mess is because culturally… you cut corners! Skip proper error messages and the complexity moves to support tickets. Skip documentation and it moves to customer success. Ship a half-baked feature and it moves to escalations and emergency calls. The complexity doesn’t disappear. It just shows up somewhere - often somewhere more expensive.

Addressing failure demand

Stop shipping things that suck. Failure demand is a tax on poor quality.

Go above and beyond in your product building, craftsmanship, documentation, and training. Bonus points: these are energizing activities to excel at. Your team will enjoy it! Be proactive instead of reactive.

It feels, to a certain kind of management, like you’re wasting time on details. I think to a certain extent that’s been a reasonable take in the past. But that has changed with the rise of AI. Given it is now possible to do more work more quickly, we have the opportunity to perfect that flow, handle all the edge cases, and ship fewer bugs. If you’re using speed to ship more slop, you’re working in the wrong place.

Most companies keep paying the tax because fixing things is hard and unsexy. They hire more support staff, more customer success managers, more implementation consultants. They build elaborate escalation processes and customer health scores. It’s nonsensical.

In most B2B software companies, I believe the ROI on bug fixes is higher than the ROI on new features. It’s conventional wisdom that keeping a customer is cheaper than acquiring a new one - this is how. It’s just that executing on that plan is less sexy.

No investment in new features or high-touch customer success is going to fix a rotten foundation. It snowballs and spirals and you lose control of it.

Tactical steps

Audit your support tickets for failure demand. How many have you thinking: “this should just work”.
Track escalations separately. These are your most expensive failure demands. What patterns cause them?
Measure trust, not just satisfaction. NPS doesn’t capture “I like the team but don’t trust the product.” Find a way to ask: “How often does our product meet your expectations?”
Kill bugs before features.² Make it a rule: no new feature work until bug backlog is under a specific threshold. Choose your threshold.
Make reliability visible. Ship uptime dashboards, error rate graphs, anything that shows you take this seriously. Start building that trust.

Bottom line

Failure demand is a tax on poor quality. You can pay it, or you can fix the underlying failures. Those are your only options.

Fixing things builds organic growth, good word of mouth, good vibes. It gives you control over your unit economics. It’s about customer trust and long term value over gimmicks. That that is a good idea is not new, it’s just hard to do.

Smart companies recognize the tax for what it is, and invest in reliability instead.