Decision Under Constraint
In one sentence: when every stakeholder is right, the decision is not about who is right, it is about which constraint is genuinely immovable.
The problem
A product owner in an enterprise environment regularly faces a decision where engineering wants to rebuild a component, risk wants a control added, security wants a dependency removed, and the business wants the thing that was promised in the quarter.
Every one of these positions is defensible. Scoring frameworks do not help much, because the inputs are not commensurable and because the person doing the scoring chooses the weights. What usually happens instead is that the loudest or most senior voice wins, and the decision gets rationalised afterwards.
The model
Sort every competing demand into one of three categories. The categories are about the nature of the constraint, not its importance.
Immovable. If this is not satisfied, the thing cannot legally, contractually or technically proceed. A regulatory requirement. A control function's decision. A hard dependency. These are not prioritised against anything. They are the shape of the box.
Costly. This can be deferred, but deferral has a price that will be paid, with interest, at a knowable point. Technical debt with a named consequence. A control gap with a compensating measure and an expiry. These are the real decisions.
Preferred. Someone wants this, it would be better, and nothing specific breaks if it waits. Most roadmap items live here, including many that arrive labelled urgent.
The discipline is in the sorting, and it is harder than it looks, because almost every stakeholder presents their item as immovable. Two questions separate them:
What specifically happens if this does not happen, and when?
Who would have to agree that it is acceptable?
An immovable constraint has a specific answer to both. A preferred item has a vague answer to the first and no answer to the second.
How to use it
Sort in a room with the stakeholders present, not afterwards in a spreadsheet. The sorting conversation is the product of the exercise.
Satisfy every immovable item, then spend remaining capacity on the costly items with the nearest and largest consequence, then on preferred items in whatever order creates the most optionality.
Then write down what you deferred, what it will cost, and when. This is the part that makes the model durable: a deferral with a named price and a date is a decision, and a deferral without one is an omission that will be discovered later and attributed to you.
When to use it
Quarterly planning where the demand exceeds capacity by an uncomfortable margin. Any decision where two senior stakeholders are in direct conflict. And the moment you notice you are about to prioritise by seniority.
Limitations
The sorting is contestable, and a determined stakeholder can argue almost anything into "immovable". The model does not remove politics; it makes the political move visible, which is a smaller claim than it sounds but is usually enough.
It does not size anything. Two costly items can have consequences that differ by two orders of magnitude and the model treats them alike until you add estimates.
It works badly where the consequence genuinely cannot be estimated, which is common in novel technology. There, the honest move is to buy information cheaply rather than to prioritise confidently.
And it assumes you have the standing to run the conversation. If you do not, the model will not give it to you.
An example
A quarter with four competing demands: a control requirement from a review, an engineering request to replace a component that keeps failing, a security ask to remove a dependency, and a business commitment made to a stakeholder group.
Sorted: the control requirement is immovable, because a named function will not approve promotion without it. The failing component is costly, with a consequence that is already being paid in incident time. The dependency removal is costly but with a longer fuse and a compensating control in place. The business commitment, on inspection, turns out to be preferred: nothing breaks if it moves a quarter, and the person who wanted it says so once asked the two questions.
The plan writes itself, and more importantly the stakeholder whose item moved has seen why, which is the difference between a decision people accept and one they relitigate.
Related
Why this matters in a hiring conversation
Most candidates describe prioritisation as a framework they applied. This describes prioritisation as a conversation they were able to run, which is the actual job.