Designing How Organizations Decide What to Work On

Most organizations treat prioritization as a capacity problem. There is too much to do, not enough time, and not enough people — so the question becomes: how do we fit more in? They build roadmaps, score backlogs, run quarterly planning cycles, and still end up with teams that feel scattered, leaders who feel reactive, and work that never quite maps to what actually matters.

The diagnosis is usually wrong. Prioritization is not a capacity problem. It is a decision design problem. The question is not how to fit more work into available time. The question is: what criteria govern which work gets done, and who has the authority to apply them?

The substitution problem

When organizations lack explicit decision criteria, they substitute three things: people, process, and urgency.

People substitution means routing every ambiguous prioritization call to the same individual — usually a founder, a VP, or whoever is perceived as having the clearest strategic view. This creates a single point of friction, burns leadership bandwidth, and trains teams to stop thinking independently. It also concentrates context in a way that does not scale.

Process substitution means installing a scoring framework — RICE, ICE, weighted matrices — and treating the output as authoritative. Scoring frameworks are useful, but they are not decision logic. A RICE score answers: "given these inputs, how does this item rank?" It does not answer: "what are we actually optimizing for, and does this project serve that goal?" When the inputs are inconsistent or the underlying strategy is unclear, more scoring produces more work with no better decisions.

Urgency substitution is the most expensive. It means using recency, loudness, or client pressure as the primary signal. The loudest request wins. The newest problem displaces the most important one. Teams are responsive in a way that feels virtuous but compounds over time into a bias toward activity over outcome.

What explicit criteria actually look like

Explicit decision criteria are not a ranked list of values. They are a set of conditions that make a specific prioritization call legible to multiple people without requiring the same person to make every call.

They answer questions like: When does a customer request become a priority? At what revenue threshold? When it appears from how many accounts? When it blocks what type of contract? They specify thresholds, not just directions. They make the decision reproducible.

They also define what does not qualify. This is often more useful than defining what does. When teams know what conditions disqualify a piece of work from being prioritized — regardless of who is asking or how urgently — they can decline without escalating, explain without hedging, and move forward without waiting.

Criteria need to be calibrated to the actual strategic question. A company optimizing for expansion revenue has different criteria than one optimizing for retention. A company at 50 customers has different thresholds than one at 500. The criteria are not generic principles. They are specific to what the organization is trying to accomplish in this period.

The ownership question

Criteria without ownership are aspirational documents. The question of who can apply criteria — and who can override them — is as important as the criteria themselves.

Organizations often design prioritization systems that require consensus at every decision point. This solves the problem of inconsistency by replacing it with a slower problem: coordination cost. Every decision touches every stakeholder. Meetings multiply. The system grinds.

Effective prioritization design assigns authority at the level where the relevant context lives. Tactical work is decided by teams with tactical context. Strategic exceptions are escalated only when the decision genuinely requires strategic input — not when it is merely ambiguous.

This requires being explicit about what constitutes a genuine strategic exception versus a routine judgment call that has been escalated out of habit or discomfort. Most escalations are the latter. Reducing them requires giving teams the criteria and the confidence to decide without referring upward.

Why this is a design problem

Organizations approach prioritization as though the right outcome will emerge if they improve the inputs: better data, better scoring, better frameworks. The assumption is that the decision is the easy part — if the information is clear, the right answer will be obvious.

This underestimates how much of prioritization is contested. Different functions have legitimately different incentives. Sales wants the feature that closes the deal. Engineering wants the architectural investment that prevents the next fire. Customer success wants the fix that reduces churn. Finance wants the initiative with the clearest ROI. None of these are wrong. They are different criteria producing different answers.

Prioritization design does not resolve the contest by finding the objectively correct answer. It resolves it by making the actual decision criteria explicit, assigning authority to apply them, and building a process that is legible to everyone — so that when the answer is "not this," people understand why, and when the answer is "yes, now," they know what made it so.

What changes when the design is right

The first thing that changes is speed. When criteria are explicit and authority is assigned, routine prioritization stops requiring meetings. Teams make calls, document the reasoning, and move. The exception is the thing that actually needs a meeting — not everything.

The second thing that changes is legibility. When work is prioritized, people know why. When work is deferred, people know why. This sounds minor. In practice, it is the difference between teams that feel led and teams that feel managed. Transparency in the criteria — even when the decision is frustrating — builds more trust than perpetual consultative consensus.

The third thing that changes is the relationship to urgency. When criteria are clear, urgency becomes a factor rather than a default. An urgent request goes through the same evaluation as a non-urgent one. If it meets the criteria, it moves. If it does not, it does not — regardless of the volume or source of the pressure. Organizations that reach this state are not less responsive. They are more intentional.