Structured decision making is a method for breaking a hard decision into parts and handling each part on purpose: the problem, the objectives, the alternatives, the consequences, and the trade-offs. As of October 2026, after 15 years of building products, I think it is the most useful decision method that product teams have never heard of. It comes from environmental and natural-resource management, where decisions are public, contested, and hard to undo. Product teams know those conditions well. This page translates the method for engineering and product work, with a filled-in build-vs-buy worksheet you can copy. One note on names: child-welfare agencies use an unrelated risk-assessment model with the same name, and this page does not cover it.
What is structured decision making?
Structured decision making is a method for splitting a hard decision into five parts and handling each on purpose: the problem, the objectives, the alternatives, the consequences, and the trade-offs. It separates what you want from what you could do and from what each choice would cost you, so a team argues about one thing at a time.
Most team arguments about a decision are really three arguments tangled together. One person is arguing about the goal. Another is arguing about the options. A third is arguing about a guess at what will happen. Nobody can win, because nobody is on the same step.
The method pulls the tangle apart. That's all it does, and it's more than it sounds.
Where does structured decision making come from?
It was developed for environmental and natural-resource management, where decisions are public, contested, and often hard to reverse. Hammond, Keeney and Raiffa gave the sequence its PrOACT name in Smart Choices. Gregory and colleagues wrote the practitioner guide for environmental managers. Product teams face the same conditions, so the method transfers well.
I'm naming the sources in prose because I can't link them from where this was written. The books are Smart Choices by Hammond, Keeney and Raiffa, and Structured Decision Making by Gregory and colleagues, published by Wiley-Blackwell. Read them for the full method. This page is my translation, not a summary of either.
Here's why I think it transfers. A wildlife agency deciding how to manage a habitat has many stakeholders, real uncertainty, and a choice it can't easily take back. A product team deciding on a platform has the same shape at a smaller scale. That's an inference from the shape of the problem, not something I've tested across teams.
What are the steps of the PrOACT method?
PrOACT stands for problem, objectives, alternatives, consequences, and trade-offs. You define the real problem, write down what you want, list the options, estimate what each option does against each objective, and then decide which trade-offs you will accept. Each step produces a written answer before the next begins.
Here is each step in product terms.
Problem. State the decision in one sentence, and check that it's the right one. "Which vendor should we pick?" is often a smaller problem than the one you have. The bigger one may be "Should we own this capability at all?"
Objectives. Write down what you want, as outcomes, not as features. Keep each one short enough that you could tell, a year later, whether you got it. A vague objective like "be scalable" belongs here only if you can say what scalable means for you.
Alternatives. List the real options, including the dull ones. "Do nothing this quarter" is almost always an alternative, and teams skip it because it feels like losing. Add one hybrid if you can. The best option is often a blend of two.
Consequences. For each alternative, estimate what happens against each objective. Mark your confidence honestly. A guess is fine, as long as the page says it's a guess.
Trade-offs. Only now do you decide. Some alternatives will be clearly worse on every objective, so drop them. For the rest, say out loud what you are giving up to get what you want.
What does a filled-in PrOACT worksheet look like?
A filled-in worksheet shows each step as a short written answer, with the consequences laid out in one table. The example below is a build-vs-buy decision. It is a composite I made up to show the shape. The numbers are invented for illustration, not from a real project.
DECISION: Build or buy our notification service
Owner: Engineering lead
Date: <date>
Revisit if: monthly volume passes the vendor's mid tier
1. PROBLEM
We need reliable notifications in the app. The real question
is whether we should own the delivery layer at all.
2. OBJECTIVES
A. Ship within one quarter.
B. Keep user data under our control.
C. Keep ongoing maintenance under 4 engineer-hours a month.
D. Keep the option to switch providers later.
3. ALTERNATIVES
1. Build it in-house.
2. Buy a hosted service and call it directly.
3. Buy a hosted service behind our own thin interface.
4. Do nothing this quarter.
Here are the consequences. Every cell is an estimate, and the confidence column says how much I'd trust it.
| Alternative | A. Weeks to ship | B. Data control | C. Maintenance hours/month | D. Can switch later | Confidence |
|---|---|---|---|---|---|
| 1. Build | 10 | Full | 12 | Not needed | Low on time |
| 2. Buy, direct | 3 | Partial | 2 | Hard | Medium |
| 3. Buy, wrapped | 5 | Partial | 3 | Easy | Medium |
| 4. Do nothing | Never | Full | 0 | Not applicable | High |
5. TRADE-OFFS
Alternative 4 fails objective A outright. Drop it.
Alternative 1 misses A and C by a wide margin and wins only
on B. Drop it unless B outranks everything, and it doesn't.
Between 2 and 3: the wrapper costs two extra weeks and one
extra maintenance hour a month, and buys objective D.
We accept that cost. Switching providers later is the
expensive mistake, and the wrapper is cheap insurance.
DECISION: Alternative 3. Owner decides on <date>.
Look at what the table did. It didn't pick the answer. It made the disagreement specific. If someone still wants to build, they now have to argue that data control outweighs two objectives, and they have to do it in the open.
How do you handle trade-offs without pretending to be certain?
Name the trade-off in plain words, mark which numbers are guesses, and decide anyway. The method doesn't remove uncertainty. It shows you where the uncertainty sits, so you can see whether it could change the answer before you pay to reduce it.
This is the part I think teams get wrong. They treat a table of estimates as a calculation. It isn't one. It's an argument written down so people can disagree with a specific cell instead of a general feeling.
Try one test. Take the cell you trust least and ask whether changing it would flip the decision. If it wouldn't, stop worrying about it. If it would, that cell is where you spend your next day.
Why do I translate this for product teams?
I do it because the product world mostly reinvents this method badly. We write a decision doc with a recommendation on top and a pros-and-cons list underneath. That format hides the objectives, because they're implied by whichever pros got listed. It also hides the alternatives we never wrote down.
In my experience, the worst decisions I've seen were not wrong answers to good questions. They were good answers to the wrong problem statement, reached by people who never agreed on the objectives. Step one and step two catch that. The rest of the method is bookkeeping.
If your decision is under real time pressure, the sequence compresses. I wrote about that in decision-making under pressure. Structured decision making is the slow version, for when you have days and the call is costly to undo.
When is structured decision making the wrong tool?
It is the wrong tool for small, reversible decisions, where the worksheet costs more than a wrong answer would. It is also wrong when the real obstacle is a person who will not decide. A method cannot supply ownership. Use it when the stakes are real, the options are close, and people disagree.
Two failure modes are worth watching for. The first is theatre: a team fills in the worksheet after the choice is made, to dress it up. You can spot it because the objectives read like a description of the winning option.
The second is paralysis. A worksheet with fourteen objectives and nine alternatives is a way of not deciding. Keep it to a handful of each. If you can't get there, the problem statement in step one is probably too big.
One more thing. Put an owner's name at the top. A worksheet without one is a document. With one, it's a decision.