Insurance is a product category built entirely on risk management, which made Surround Insurance one of the more instructive engagements I have had. The product team was smart and moved fast. They were also consistently surprised by problems they should have seen coming - not because they were careless but because the risk identification process was informal and reactive. Problems surfaced when they became expensive, not before.
The product risk management discipline we built was not about slowing things down. It was about making risk explicit before committing to a direction. The distinction matters: risk management that adds process overhead to every decision is a tax on velocity. Risk management that surfaces the right questions before the right decisions actually makes teams faster, because they stop discovering problems after they have already built around them.
The most dangerous risks are the ones the team does not know they are taking.
The Risks That Kill Products Are Rarely Technical
In fifteen years of marketplace and B2C product work, the product failures I have seen up close were almost never caused by technical failures. The code worked. The infrastructure held. The product failed because the team was wrong about something they believed was true - about user behavior, about market timing, about a competitor's response, about regulatory tolerance.
Technical risk is relatively manageable because engineers are trained to think about it explicitly. Assumption risk is harder because it requires naming things the team believes are true but has not tested.
The failure mode I see most often: a team that is rigorous about technical risk management and almost entirely informal about product assumption risk. They have incident runbooks and on-call rotations. They do not have a practice for surfacing the product assumptions that, if wrong, would make the feature irrelevant.
Making Risk Visible Before It Is a Problem
The practice that has worked best across engagements is a pre-mortem at the start of a major initiative rather than a post-mortem at the end. The framing: it is twelve months from now and this initiative failed. What happened? The goal is not to generate a comprehensive risk list - that produces a long list of things that are technically possible but mostly not relevant. The goal is to surface the two or three things the team is most worried about but has not said out loud.
At TripAdvisor, the Instant Booking initiative required hotels to give up control of their inventory in real time - a significant behavior change that we underestimated. A proper pre-mortem early in the project would have surfaced supply adoption risk as the primary risk much sooner. We got there eventually through the market response, but the cost of discovering it through failure was higher than the cost of surfacing it through deliberate process. (see also: marketplace growth strategies)
The pre-mortem is not a risk register. It is a conversation. The output is not a document - it is shared awareness of what the team is betting on and who is responsible for watching each bet.
Marketplace and Supply-Side Risk
Two-sided marketplace products carry a category of risk that single-sided products do not: supply behavior risk. The marketplace depends on suppliers behaving in ways that support the demand experience, and suppliers have their own incentives, constraints, and veto power that the product team does not control. (see also: shaping the supply and demand product organization)
At EverQuote, expanding into new insurance verticals meant depending on carrier participation - carriers who were not obligated to integrate, who had their own compliance requirements, and who could pull back if the economics shifted. Each vertical expansion carried supply-side risk that was independent of whether we built the right product.
The discipline this requires: treat supply-side assumptions with the same rigor as demand-side assumptions. What behavior are you depending on from suppliers? What would cause that behavior to change? What is the early indicator that it is changing? These questions are easy to skip because supply relationships often feel like sales problems rather than product problems. They are product problems.
Risk Tolerance Is a Product Decision
Different product bets warrant different risk tolerance, and the mistake is applying the same risk management overhead to decisions of different consequence. A feature experiment on a mature product tolerates higher failure risk than a platform migration that touches every user. Treating them the same either slows down decisions that should move fast or accelerates decisions that deserve more scrutiny.
The framework I use: categorize decisions by reversibility and blast radius. Easy to reverse, limited blast radius - move fast, minimal process overhead. Hard to reverse or large blast radius - slow down, make assumptions explicit, get the right people in the room.
Reversibility is the more important of the two variables. An irreversible decision with a small blast radius is still high risk because you cannot course-correct. A reversible decision with a large blast radius is lower risk because you can recover.
Most teams apply uniform process to everything, which means they are simultaneously too slow on low-consequence decisions and too fast on high-consequence ones.
Third-Party and Regulatory Risk
The risk category that product teams most consistently underweight is dependency on parties outside the organization - platforms, regulators, partners, data providers. These risks are hard to manage because they are not under the team's control, which creates a tendency to either ignore them or treat them as someone else's problem.
At Spark Networks, managing a $50M media budget across multiple brands meant depending on platform policy decisions at Google, Meta, and programmatic networks that could change with little notice. The right response was not to pretend that risk did not exist but to build enough channel diversification that no single policy change was catastrophic.
Regulatory risk in particular tends to be underweighted until it is immediate. The product teams that handle it best treat regulatory exposure as a product attribute to be monitored, not a legal problem to be handed off.
When to Surface Risk to Leadership
Product managers often sit on risk information longer than they should because surfacing a risk feels like admitting uncertainty. The right time to surface a significant risk to leadership is before the decision is locked in - not after you have already built three months of work around a flawed assumption. (see also: product launch checklist)
The format that works: one sentence naming the risk, one sentence on the evidence you have that it is real, one sentence on what you need to resolve it, and your recommendation on whether to proceed given current information. That is not admitting failure. That is doing the job.
The organizations where risk surfacing is healthy are the ones where raising a risk reliably produces either resources to address it or an explicit decision to proceed despite it - not punishment for raising the issue. If raising a risk produces blame rather than action, people stop raising risks. That is when the surprises get expensive.
