Managing Risk

Every plan rests on beliefs nobody has checked. That people want this. That the data exists. That legal will approve it. That the team can build it in a quarter. Most are fine. One or two, if wrong, sink the whole thing.

The cost of being wrong climbs steeply with time. An assumption caught in a workshop costs an afternoon. Caught in a prototype test, a week. Caught after launch, it costs the launch and the roadmap stacked on top.

So the job is not to remove uncertainty — you cannot — but to sort it. Some of it is fixed: the budget, the platform you are stuck with, the regulation. You design around that. The rest could go either way, and one or two of those beliefs are holding up the plan. Buy those answers while they are still cheap.

Assumption Mapping

Get the team in a room and write out what has to be true for the idea to work — one claim per note, each phrased so someone could read it and say no. Cover all four kinds: people want this (desirable), we can build it (feasible), it makes money (viable), and people can work out how to use it (usable). Teams that only list the first kind spend months testing the wrong things.

Then place each note against two axes: how badly it hurts if that belief is wrong, and how much real evidence you have. High stakes plus thin evidence is your list. Everything on it needs an experiment before anyone writes production code.

Teams reliably test the assumption that is easiest to test. Test the one that would kill you.

Risk Identification

Run a pre-mortem. Tell the team it is a year from now and the project has failed badly, then ask everyone to write down why — privately, before anybody speaks. Calling it an autopsy rather than a forecast gives people permission to say what they have only hinted at in standup.

Cast wide. Engineers know which system will buckle under the load. Support knows which customers will revolt. Legal knows about the consent requirement you have never heard of. Ask one function and you get one function's worth of risks.

Then give each serious risk a row of its own: an owner, a date, and the thing that will close it — a spike, a throwaway prototype, a call with the vendor. A risk register with no names beside the rows is a list of things everyone has agreed to be surprised by later.

No questions on this lesson yet. Highlight a passage to ask about it, or use Ask a question.