How How Big Things Get Done changed how I work

Bent Flyvbjerg and Dan Gardner's How Big Things Get Done has become one of the most influential books in how I think about product work, planning, and delivery.

The book's central lesson is simple, but uncomfortable: most projects do not fail because people are stupid, lazy, or careless. They fail because teams underestimate complexity, overestimate certainty, start building too early, and treat their own project as more unique than it really is.

That idea has shaped how I approach design and product work.

What changed in my practice

I have become much more skeptical of plans that sound confident but are not grounded in evidence.

Before committing to a direction, I now look harder for the reference class: What similar problems have we seen before? How long did they really take? Where did they get stuck? What assumptions quietly carried the whole plan?

That was already part of good design judgment, but the book gave it sharper language. Better outcomes do not come from confidence alone. They come from better grounding:

• understanding comparable examples instead of assuming this case is special
• exposing dependencies early while they are still cheap to change
• reducing avoidable complexity before execution hardens
• treating planning as real work, not administrative delay

The book also reinforced the value of front-end loading. Good product work is not about making everything slower. It is about doing the right thinking early enough that delivery can move faster later.

For me, that means spending more time clarifying the problem, mapping dependencies, testing assumptions, and making trade-offs explicit before a team invests heavily in execution.

Why it maps to product design

This is one reason I think the book matters for product designers working in complex environments: internal tools, operational systems, revenue-management workflows, and AI-supported decision systems.

In these contexts, the risk is rarely just a bad interface. The bigger risk is building the wrong workflow, automating the wrong judgment, or scaling a decision model that no one fully understands.

Design is often brought in after a delivery shape already exists. By then, teams may already be carrying the cost of bad assumptions: a weak product model, unresolved edge cases, technical constraints discovered too late, or an interaction structure that was never made coherent at the system level.

The strongest design contribution often happens earlier.

It happens when design helps teams see structure sooner: where complexity lives, which flows are tightly coupled, what can be simplified, and which decisions need evidence before the roadmap becomes too expensive to question.

That is not separate from delivery. It is part of delivery quality.

The question I now ask earlier

How Big Things Get Done gave me a better language for this kind of work. It pushed me to think less in terms of "Can we build this?" and more in terms of "What has to be true for this to work?"

That question changes the shape of design work. It makes base rates, constraints, sequencing, modularity, and assumption testing feel central rather than adjacent.

It also separates ambition from wishful thinking. A team can have a strong direction and still need a more honest model of the conditions required to make that direction work.

Where design has leverage

What I would add from a product perspective is that planning quality is not only about schedule or budget accuracy. It is also about model quality.

A product can ship on time and still be structurally weak. It can meet a milestone while leaving users inside a system that is harder to learn, harder to trust, or harder for teams to evolve. So when I read Flyvbjerg, I do not just think about project controls. I think about whether the underlying product logic is becoming more coherent before scale makes change expensive.

That is where design has leverage.

The strongest design contribution is often the work that happens before screens feel final: defining the problem clearly, making system behavior explicit, testing the riskiest assumptions, and helping teams see which decisions should not be deferred.

What I carry forward

The book has made me a more grounded designer. More patient in diagnosis. More suspicious of vague optimism. More focused on turning uncertainty into a structure that teams can actually act on.

The phrase most associated with the book is "think slow, act fast," and it is useful because it names a discipline many teams resist. Good execution is rarely the opposite of careful planning. More often, careful planning is what makes real speed possible later.

For product design, that usually means doing enough hard sense-making up front that execution can become faster without becoming messier.

In short, it taught me that good product work is not just about imagining a better future. It is about increasing the odds that the future can actually be built.