Capital, Complexity, and the Cost of Ignoring Demand
1. Funding Mirage and the Subsidy Trap
For a successful startup, there's a moment where capital becomes a sedative. When a company raises significant funds before its business model is demand-driven, it enters a state of reality detachment. This capital acts like a government subsidy.
In national economics, a subsidy allows an inefficient entity to survive without being "chosen" by the market. The entity stays alive not because customers want what it sells, but because someone else is paying the bill. In business, "Bad Money", as Clayton Christensen defines it in The Innovator's Solution, Ch. 9, does the same thing. It allows a company to hire talent and increase valuation while ignoring that product development has stalled. Instead of building what customers demand, the company begins building what it wants, funded by investors who have money but no actual demand for the product.
Christensen drew a sharp distinction between good and bad money. While a company nurtures emergent ideas during nascent years, money must be patient for growth but impatient for profits. When winning strategies become clear and deliberate ideas need execution, money should be impatient for growth but patient for profit. The problem is the type of money companies receive. VC funding before product-market fit encourages reality detachment. Managers start using it to increase company valuation or hire talent. They're busy, feeling good, but they're not investing in what they should. Getting paid for your job and getting subsidized by the government are very different things, even if the amount is the same. If money comes from demand, that's good. If it comes from a subsidy, the government took that money from people in taxes and it has nothing to do with demand. As soon as the money runs out, a business that customers never truly validated dies. It was artificially alive.
2. How the Inefficiency Parasite Multiplies Cost
Complexity has a price companies rarely calculate on a balance sheet: I call it the Sync Tax. Companies pay this tax when they maintain an interdependent product architecture while trying to scale. As the product grows, the gradual increment in complexity creates a wasteful system where every new feature or modification results in higher coordination friction: code, data, and human alignment beyond meetings.
I saw this firsthand. I joined a company where the product had found its market. The original system was a monolith, and the company had started building a new service alongside it. Data had to stay in sync between both systems. Not a huge deal at first. But as the domain became more relevant, a third system entered the picture. Now there were three systems we had to keep in sync. Every "temporary" solution, every rushed feature, added another layer of coordination overhead. A new feature that should have taken a week required two months of a four-person team, not because the feature was hard, but because keeping three systems aligned consumed most of the effort. That's the Sync Tax in practice. It drains value the way a parasite drains its host.
Mises showed that capital invested against consumer demand is malinvestment, capital squandered (Human Action, Ch. XX §9). The same logic applies inside a company. Every dollar spent maintaining complexity that customers never asked for is internal malinvestment. In a clean system, $1 of effort generates multiple units of value as it flows through the organization. That's an efficiency multiplier: capital compounds when complexity stays low. When complexity grows unchecked, the multiplier reverses. Each dollar circulates less, feeds more overhead, and returns less value to the customer who was supposed to justify it in the first place.
The business pays for the feature plus the cost of feeding the parasite of its own inefficiency. The natural reaction is to automate the mess, but automating an inefficient system just makes it more inefficient. Automation makes sense for repetitive tasks that don't require human judgment. You wouldn't pay an elevator operator to press buttons for you, and that job disappeared because a button and an electronic system does it better. But automation doesn't fix structural problems. The fix is removing the inefficiencies first, then letting automation amplify what works.
3. The Factor of Time in Strategy
Deliberate Strategy (top-down) gets a bad reputation. Emergent Strategy (bottom-up) gets treated as inherently better. The distinction originates with Mintzberg & Waters (1985), and Christensen applied it to innovation strategy in The Innovator's Solution, Ch. 8. In reality, strategy shifts over time, and timing is everything.
The CEO must constantly steer between experimentation and discipline. There are periods where strategy must be pragmatic (Emergent), experimenting, researching, and listening to the "front line" (engineers and middle managers) who are the first to detect shifts in customer demand. There are other periods where strategy must be dogmatic (Deliberate), consolidating those discoveries into a winning strategy the organization must execute with discipline.
The factor of time is the one leaders consistently overlook. What works today might not work six months from now, and what failed last year might be exactly right for the current moment. The world keeps evolving, and strategy must evolve with it. Emergent strategy brings solid knowledge that can become dogma for a while. But learning never stops because the market doesn't stop changing. The person in charge is responsible for deciding when to dedicate more resources to experimentation and when to keep delivering what's already proven.
The "Sync Tax" is what happens when a company stays dogmatic for too long. Because the system is too complex to change easily, the company ignores the warnings from the front line and insists on top-down features that no customer wants, simply because they have the "bad money" to pay for them. By the time the company realizes the strategy is wrong, it's also too far from the customer to know what right looks like at the moment.
4. Playing the Political Game of Refactoring
Escaping this trap demands both technical and political skill. Because the business side knows little about technology, they view the tech department as an expensive "black box" and respond with micromanagement and reports. The business side wants higher margins. The tech side wants better metrics and convince the business that those metrics mean the company is doing well. Neither side speaks the same language, and the cost of that disconnect lands on the customer.
This lack of trust creates a bureaucratic loop that makes refactoring nearly impossible. In the triple sync story, I had to propose stopping all new feature work to remove the syncs that were strangling the product. Nobody liked the idea. The business saw an expensive department asking to slow down, and the tech department hadn't been transparent about the mess it was maintaining. We were heading straight for failure if we continued on that path, but getting budget approval to stop building and start fixing required fighting through layers of bureaucracy that existed precisely because trust had eroded.
To break free, you must play the "political game": stopping the production of new, unwanted features to remove the unjustified complexity that is smothering the business. You can't scale an inefficient system; you must first remove the inefficiencies to allow the money to accelerate growth rather than accelerate loss. The business side needs to understand this in their language, which is dollars and timelines, not technical jargon. If the tech department can't translate the cost of complexity into numbers the business feels, nothing changes.
5. The Decoupling Point
After product-market fit, all product companies pass through a moment I call the Decoupling Point, a term I learned in Prof. Christensen's Disruptive Strategy course at Harvard Business School. Christensen used it to mark the point in the value chain where it makes sense to shift from interdependent architecture to modular architecture. I extend it here to mean something broader: the moment when architecture, strategy, and demand all signal the same transition at once.
The strategy must shift from learning what customers want to preparing the product to handle much larger demand. This is the first time in the lifetime of the company that the strategy needs to change. Until this moment, the company was in learning mode, making quick changes, trying to understand the customer, until they did it and that's what product-market fit is about. But now, they need to prepare to handle a much bigger demand.
The current product isn't scalable. It's an original product with lots of modifications and patches, far from ideal. That same product can't scale essentially because to get there, the company had accumulated a lot of complexity, which means higher cost and slow changes.
This is time for deliberate strategy. Now the C-suite learned what to do and can take that knowledge and apply it properly. But here's the confusion. The job now is to stop adding features and scaling the same product, and instead make the product work at low cost, make it stable, and make it able to change fast. The product that got the company to product-market fit isn't the product that carries it forward. You have to remake it for the next phase, not by adding more, but by removing what's in the way.
References
-
Christensen, C. M. & Raynor, M. E. (2003). The Innovator's Solution: Creating and Sustaining Successful Growth. Harvard Business School Press.
Mintzberg, H. & Waters, J. A. (1985). "Of Strategies, Deliberate and Emergent." Strategic Management Journal, 6(3), 257-272.
Mises, L. von (1949). Human Action: A Treatise on Economics. Ch. XX §9: The Market Economy Affected by the Recurrence of the Trade Cycle
Christensen, C. M. Disruptive Strategy. Harvard Business School Online course. The term "Decoupling Point" as used in this article was learned in this course, where it marks the point in the value chain where it makes sense to shift from interdependent architecture to modular architecture. The extension to strategy and demand timing is the author's own.
