Most teams don't have a decision problem. They have a framing problem. The decision they're trying to make isn't the decision they actually need to make, and until someone names that, the conversation goes in circles. This is a practical guide to mapping a decision before you try to make it.
Start with the question behind the question ¶
The first thing we do in any decision architecture engagement is ask: 'What would have to be true for this decision to be easy?' Usually the answer reveals a hidden assumption or a prior decision that hasn't been made yet. If the answer is 'we'd need to know whether the market is big enough,' the real decision is about how much uncertainty you're willing to act under, not about the market itself.
Write down who actually decides ¶
Most decision-making processes have an implicit RACI that nobody has written down. Someone recommends, someone approves, someone gets informed after the fact. When this is unclear, decisions stall because people are waiting for permission they don't know they need. Write down, for this specific decision: who recommends, who decides, who needs to agree, who gets informed. If you can't answer that in five minutes, that's your first problem.
Map the constraints before the options ¶
Options are easy to generate. Constraints are harder to name, and they're more important. Before listing what you could do, list what you can't do and why. Budget, timeline, team capacity, existing commitments, things that are politically impossible even if they're logically sound. A decision made without a clear constraint map will get revised the moment it hits one of those constraints.
Separate the reversible from the irreversible ¶
Jeff Bezos's two-door framework is overused but it's right. Some decisions are easy to reverse; some aren't. The level of rigor you apply should match the reversibility. A hiring decision for a senior role deserves more process than a decision about which project management tool to try next. Teams often apply the same level of deliberation to both, which means they're either too slow on the easy stuff or too fast on the hard stuff.
When to stop mapping and decide ¶
Decision mapping is a tool, not a destination. The point is to get to a decision faster and with more confidence, not to map indefinitely. A useful heuristic: if the next piece of information you're waiting for would genuinely change the decision, wait for it. If it wouldn't, you already have enough. Most teams are waiting for certainty they'll never get. The map helps you see that.
If your team is stuck on a decision right now, the Strategic Clarity Session is designed for exactly this. Ninety minutes, one problem, one framework. You can find the details on the full list of engagements.