How Big Things Get Done: Lessons for Product Managers

Optimism

I first read about ‘optimism bias‘ in Thinking, Fast and Slow (highly recommended*) by Daniel Kahneman. Reading about it felt like looking in a mirror. I would say my baseline wellbeing sits around 8 or 9 out of 10. I’m always smiling, I recover from setbacks quickly, and I’m relentlessly upbeat. This is sometimes too much for the long suffering people around me. I’m incredibly lucky. But this undoubtedly makes my life easier and is a great fit for product work – it feels natural, always solving the next problem, live and learn from the many mistakes, keeping the team’s energy up, and seeing the bright side.

But optimism has a flip side. I give optimistic timelines. I naturally assume the best and trust very easily. My default is “it’ll be fine”, which is a lovely human trait but can be unrealistic for delivery. Bent Flyvbjerg’s How Big Things Get Done hits this tension head-on and helps me see where my optimism helps me, and where it quietly undermines my work.

The book is data-driven, packed with clear insights, and framed around memorable stories from the Sydney Opera House to a cursed home renovation. The lessons scale from mega-projects to everyday renovations, detailing what makes a successful project deliver on-time and on budget – or more commonly what makes them fail.

Start with “Why?”

One of the most useful ideas is the insistence on a clear “why”. Drawing on architect Frank Gehry (RIP), Flyvbjerg describes the need to “fill in the box on the right”: define the underlying problem, who has it, then outline the steps that will actually solve it. That discipline separates vanity projects from serious ones.

PMs hear “start with why” constantly, it’s a meme, but this framing is sharper. It’s not about vision statements or customer empathy (though those matter). It’s about being ruthlessly honest: what problem are we solving, and will this solution actually solve it? If you can’t fill in that box clearly, you’re not ready to build.

Gehry’s framework led not only to the construction of some of the most spectacular buildings in the world, but ones that hit their financial, timeline, and conceptual targets. Jorn Utzon’s Sydney Opera House only hit one of that trifecta and the shame and pressures of this led him to never see his completed building.

[Guggenheim Bilbao – sucsessfuly designed to rejuvenate an entire city with a spectacular art museum. Now famous the world over. On-time and in budget after much preparation.]

[Sydney Opera House – famous the world over but a disaster in terms of cost and timelines, Utzon suffered intense reputational cost for much outside of his control. ]

Carrot Peelers and Embedded Technology

The book keeps coming back to the Latin root experiri, which underpins both “experience” and “experiment”.

Flyvbjerg uses the humble carrot peeler as an example, it’s the product of intense iterative experiments from experienced masters. Good tech feels slick, easy, obvious. In reality it is complex, version 386, the work of dozens of committed highly-skilled experts embodying this experience in a product. It is “technology as embedded experience“.

You need both in modern Product work. Use what has already been delivered, off the shelf, by experienced people. Custom and bespoke sound glamorous, but in project terms they are often a red flag. Iterative processes and repeated patterns are safer. This does not mean we can’t experiment or create beautiful products, it just helps ground us in reality and allows teams to scale by innovating where it matters.

Flyvbjerg notes how often we ignore these basics, we reinvent instead of using what already exists, we pick custom and bespoke when off-the-shelf would do and we fall in love with uniqueness and forget reliability. We chase the shiny new thing (hello AI everything) when the best solution already exists.

Reference Class Forecasting

This section should be in Product 101 classes. It is where most big projects go wrong, and where simple methods help. Instead of pretending you can predict cost and time from first principles, you pick a similar project as your baseline. You anchor your forecast in how long and how expensive it actually was in the real world, unknown unknowns included. You are likely to be around average.

For PMs, this means that we stop estimating features in isolation. Look at the last five similar features you shipped. How long did they actually take? What went wrong? That’s your reference class. It’s more accurate than gut feel or optimistic planning, because it’s grounded in reality rather than hope.

This one stung a bit. I’ve historically been quick to act and plan on the fly. At sizing time, too optimistic, too few questions, and not enough deep thinking. For sure, not enough post-mortems of previous projects and no reference class database.

Think Slow, Act Fast

This is Flyvbjerg’s core message and the one I’m taking most to heart. Spend serious time understanding what you’re doing, why you’re doing it, and how it’s gone for others. Then, once that groundwork is done, move quickly and decisively while the window is open.

Too often we think fast with high-level design, heroic assumptions and flimsy reasoning allowing us to start quickly. But in reality we end up acting slowly as we are left with unfocused teams, nasty surprises in low-level design, and in the end half-finished initiatives.

The longer a project lingers half-committed and unfinished, the more chances it has to fail. Slow at the start is investment, proper Product Discovery. Fast at the end isn’t rushing, it’s capitalising on that investment before circumstances change and while the full team is focused on one goal.

Stakeholders and Power

Flyvbjerg is blunt, you need to know who actually holds power in your project and who has special interests at stake. Projects don’t fail in a vacuum. They fail because someone’s incentives weren’t aligned, or because a key stakeholder wasn’t brought along.

A tough area for PMs who usually have little real power but strive to bring both clarity to those who do and influence these decisions based on their experience or vision. This is hard work, I have had projects be successful when flows of power were clear, and a mess when it was unclear or obscured. Experience can help, as can learning from those who walk these paths more often.

Storytelling

The book is very good on storytelling. It is now a top-listed attribute in job descriptions. Humans love a good story, they prefer it over cold data – even when the data is more true.

Heroic narratives of visionaries who land successful projects by bending reality through sheer will and genius are enticing, fun. They do exist. But they are the outliers. It’s survivorship bias.

Most big projects come in over budget and over time (~80% based on his data). Many come with a truly nasty long tail in price or time too. We do not hear heroic stories of all the failures, and we never know what the true opportunity costs were – what did we not do instead of them, and what did the people involved not do next?

For PMs it is important to tell the story but ground it in the data, don’t get too caught up in your own narrative, it’s a dangerous path.

Your biggest risk is you

This heuristic (the others are listed at the end) hit home and inspired this post. It’s important to recognise and manage your own biases and blind spots. For optimists like me that means building in checks, forcing myself to use reference classes, asking “what could go wrong?” before assuming it’ll be fine, and being honest when my confidence outstrips my evidence.

The book helped me see my optimism as a tool to manage rather than a virtue to celebrate. It’s a minor asset for resilience and momentum. It’s a minor liability for estimation and risk assessment.

What’s your Lego?

Modular construction is “magic” because it gives you scale without losing control. The book shows that the most successful project types (solar farms, wind installations, roads) are highly modular and repeatable. The disasters (nuclear plants, Olympics, bespoke mega-projects) combine complexity, novelty, and politics in ways that invite failure.

The question for PMs is what are the units, modules, or patterns you can repeat, refine, and scale? Where are you treating things as bespoke when they don’t need to be? I’ve been trying to take a more modular approach to work, putting the effort in upfront to create reusable AI templates, building a personal co-pilot, and building reference class data that can be used again.

Verdict

How Big Things Get Done is a strong mix of narrative, data, and practical advice. If you manage any kind of complex initiative, which, as a PM, you do, it’s worth your time. The lessons are scalable, the evidence is solid, and it might just save you from your own optimism!

Appendix: The 11 Heuristics

Hire a masterbuilder – choose a leader with deep domain experience and a proven track record.
Get your team right – build a strong, experienced team, ideally one the leader has worked with before.
Ask “why?” – clearly understand the ultimate goal and purpose of the project.
Build with Lego – use modular, replicable components; start small and scale up.
Think slow, act fast – invest time in thorough planning before moving quickly into execution.
Take the outside view – learn from similar projects; use real-world data and reference classes.
Watch your downside – identify and mitigate risks; focus on avoiding catastrophic failures.
Say no and walk away – stay focused, avoid distractions, and be willing to abandon projects with poor prospects.
Make friends and keep them friendly – build and maintain strong relationships with key stakeholders.
Build climate mitigation into your project – integrate sustainability and climate considerations from the start.
Know that your biggest risk is you – recognise and manage your own biases and blind spots.

* Thinking Fast and Slow was a foundational book for me, I recommended it to everyone and I still do but I must mention that it has since suffered from the replication crisis in science, particularly affecting psychology. Many of the studies in it have failed to replicate and so must be disregarded, but it remains full of insight!