Fight for Simplicity: The Third-Order Cost of Complexity
Entropy always wins unless you fight it — price every feature at its dimensional cost, not its build cost.
- Difficulty
- Moderate
- Time to result
- ~ongoing to results
- Steps
- 5
- Confidence
- 95%
Shah frames the second law of thermodynamics as the founder's real adversary: in a closed system, disorder increases over time unless you intervene. Companies die in three stages — trying not to die, trying not to stagnate, and finally crumbling under their own complexity. His counter is a set of hard, systematic constraints: a one-in-one-out feature rule, and a discipline of pricing every new feature or product at its third-order cost (the dimensional complexity it adds to every future decision), not just its build or maintenance cost.
Origin
Dharmesh Shah's articulation; the one-in-one-out product rule was implemented by co-founder Brian Halligan and was inspired by Apple. The second law of thermodynamics is physics; the 'mechanisms over intentions' framing is credited to Amazon.
Core principles
- 01Within a closed system, entropy increases over time. Absent intervention, everything goes to crap.
- 02Complexity kills companies — maybe not as quickly as other things, but far more reliably.
- 03Simplicity is worth fighting for, and it requires fighting for — even well-intentioned people introduce complexity, because that is the natural way of the world.
- 04First-order cost = build. Second-order = maintenance. Third-order = the dimensional complexity added to every future decision. The third is the most important and the most ignored.
- 05A reasonably well-designed system will beat any amount of cultural exhortation. Values on a wall deteriorate; mechanisms do not.
- 06Coarse constraints beat no constraints — an imperfect rule at least forces the conversation.
How to run it
- 1
Name the enemy
Recognise which stage you are in: fighting not to die (early), fighting not to stagnate (growth), or fighting complexity (scale). Stagnation is death; complexity is a slower but more reliable death.
- 2
Impose a one-in-one-out feature rule
Every time you add a knob or dial called a feature, you must take one out somewhere else. Keep the net complexity of the product roughly constant.
Pro tip Not every checkbox, radio button, and menu item is equivalent — the measure is coarse. Use it anyway; it is better than having no constraint at all.
- 3
Price features at third-order cost
Before committing, ask what dimensional complexity this adds. Going from one product to two is not incremental: now every hire, every marketing campaign, every chart in the business must be sliced by product one and product two, forever.
Watch out Teams routinely stop at 'it takes six months and Y engineers'. That is first-order thinking and it systematically underprices the decision.
- 4
Build mechanisms, not slogans
Put systematic guardrails and constraints into how the company operates. You can and should reinforce simplicity in all-hands meetings and culture docs — but a system beats exhortation, because words deteriorate over time and are hard to scale.
Pro tip Look for constraints that come free from your market. HubSpot's SMB + freemium positioning capped how much complexity the product could ever carry, because there is no army of implementers to absorb it.
- 5
Apply the same rule to your own calendar
Every time you say yes to something, you are by definition saying no to something else. When you commit calories to a new thing, force yourself to name what comes out of your schedule to make room.
Pro tip Shah's default answer to a new shiny object is no. He forces himself to find reasons to say yes rather than reasons to say no.
In the wild
Shah's worked example: companies budget for product number two as a build cost plus a maintenance team. What actually happens is dimensional complexity — you just hired an engineer, do they work on product one or two? You are launching a campaign, how many minutes go to each? Every chart you have ever looked at now has to be sliced by product.
→ The real cost of a second product is a permanent tax on every future decision, not a one-off engineering spend.
Because HubSpot built for SMB with a freemium tier, there was a hard ceiling on complexity: no army of consultants would spend 18 months implementing it, and the free product had to deliver value on its own. The constraint was not deliberate at the time, but it did the work of enforcing simplicity.
→ Market constraints did what culture alone could not, keeping the product simple enough to be self-serve at scale.
Common mistakes
Measuring a feature by cost of implementation
First-order thinking — 'six months, Y engineers, Z designers' — ignores both the maintenance burden and the dimensional complexity that will tax every future decision.
Relying on culture instead of mechanisms
You can put 'we believe in simplicity' on a page and repeat it at all-hands, but those things deteriorate over time and do not scale. A well-designed system outperforms any amount of reinforcement.
Waiting until you are complex to start fighting complexity
It is never too early to plant the seeds of simplicity. By the time you feel the weight, the entropy is already compounded into every process and every chart.
Is it for you?
Best for
Founders and product leaders at growth-stage companies deciding whether to add a second product line, a new pricing tier, or another feature surface.
Not ideal for
Pre-PMF teams whose actual problem is that they have not yet found anything customers want — premature constraint discipline can starve exploration.
From the transcript
“the amount of disorder and Randomness in a system is going to increase over time”
“what I call fight for Simplicity it's literally those three words right”
“the product grew in those early years that every time you added what we thought of is a knobber dial called a feature you had…”
“the third order thinking which is I think is the most nuance and it turns out to be the most important is the other costs…”
“it's like now every decision you make has to be made to the lens of now we have two products”
From the episode
Zigging vs. zagging: How HubSpot built a $30B company
Dharmesh Shah (co-founder/CTO)