The strongest product managers don't plan for success — they plan for the moment their plan breaks, argues a new essay from the Darden School of Business' Darden Report. The piece makes the case that designing for failure is a core discipline of product management, not a defensive afterthought.

The argument lands at a moment when product teams face pressure from two directions: compressed shipping cycles that reward fast iteration, and high-profile outages and trust failures that punish teams which never rehearsed what happens when things go wrong.

What does "designing for failure" actually mean?

The Darden Report frames it as a mindset shift. Instead of asking only "will this feature work?", product managers should ask what happens when it doesn't — when a dependency disappears, when a user misreads the interface, when adoption stalls, or when an assumption in the business case turns out to be wrong.

This is familiar territory in adjacent disciplines, and the piece sits in a broader tradition:

• Engineering: reliability practice treats failure as inevitable and builds graceful degradation around it.
• Strategy: pre-mortem exercises ask a team to imagine a project has already failed, then work backward to the causes.
• Product discovery: testing the riskiest assumption first, rather than the easiest one to validate.

For practicing PMs, the operational translation is concrete: identify the assumptions your roadmap silently depends on, decide in advance what evidence would falsify them, and design the product — not just the process — to fail safely and observably when reality diverges from the plan.

Where does the approach work, and where does it fail?

Failure-first design has real tradeoffs, and the Darden framing should not be read as a blank check for pessimism.

It works best when the cost of failure is high and detectable: payments flows, data migrations, trust and safety surfaces, anything where a bug destroys user confidence faster than a fix can rebuild it. Rehearsing failure modes before launch is cheap; incident response is not.

It fails or gets misapplied in three common ways:

• Paralysis by pre-mortem: teams catalogue so many failure scenarios that they ship nothing, trading the risk of failure for the certainty of irrelevance.
• Failure theater: documenting risks in a template without assigning an owner, a detection signal, or a mitigation — the artifact exists, the protection doesn't.
• Blaming individuals: if a pre-mortem culture curdles into blame culture, people stop surfacing risks early, which defeats the entire purpose.

The distinction that matters is between planning for failure and expecting it of people. The first is engineering discipline. The second corrodes teams.

How can PMs apply this on Monday?

The practical entry point is small. Take your current top roadmap bet and list its three riskiest assumptions — the ones that, if wrong, invalidate the whole item. For each one, write down the earliest observable signal that it's wrong, and what the team does when that signal fires. That's a failure design, and it fits on one page.

The second move is building failure affordances into the product itself: reversible actions instead of irreversible ones, clear feedback when something breaks rather than silent degradation, and defaults that limit blast radius when a user (or the system) errs.

As AI-assisted features move from novelty to load-bearing in mainstream products, the discipline is becoming non-optional — probabilistic systems fail in ways deterministic software never did, and the PMs who already design for failure will be the ones whose products survive it.