TL;DR: Most product reviews are good at spotting stuck decisions and terrible at moving them. The fix is a Decision SLA: every open decision gets a written deadline and a default that fires automatically if the deadline passes. It turns your review from something that watches problems into something that ends them. Below are the exact rules I now run, why decision latency is more expensive than a wrong call, and a five-step way to install them this week. The contrarian part is what you automate: hand AI the default, keep the decision.
A decision sat on my board for seven days.
This wasn’t a difficult choice deciding whether to build or buy a single piece of packaging technology, a decision you could typically analyze in an afternoon. I encountered it every morning and reviewed it daily, weekly, and during my Monday leadership meeting seven mornings in a row: the same issue, with no progress.
The hardware was scheduled to ship in four days. If I didn’t decide on a course of action, a thousand units would arrive as inventory rather than forming a functioning product. And I continued to watch it sit.
This was the painful part. My review system functioned well, identifying the unresolved decision on the first day and continuing to flag it daily. However, it lacked the ability to actually push for a resolution. I had created an effective tool for detecting issues, but nothing for resolving them.
That’s the trap I want to talk you out of. Because if you run any kind of recurring review- a standup, a sprint check-in, a roadmap sync- you have probably built the same thing without noticing.
Your review is a sensor. You need an actuator.
In a control system, a sensor measures what’s happening, and an actuator changes it. A thermostat reads the temperature, then switches on the heat. One without the other is useless. A thermometer that never turns on the furnace just tells you, in high resolution, exactly how cold it is.
Most product rituals are all sensor. Your standup reads status. Your roadmap review reads progress. Your dashboard reads metrics. They are good at telling you a decision is stuck, a metric is sliding, a dependency is slipping. Then everyone nods, writes it down, and carries it to next week’s meeting, where it gets read again.
The stuck item is not a data problem. You already have the data. You have too much of it. You’re overlooking the process that converts a reading into an action.
And the cost is not abstract. In my case, the market had already told me the clock mattered. Connected packaging crossed into the mainstream this year, with industry adoption reaching 81.2% (Appetite Creative’s 2026 connected-packaging survey, reported by Packaging Insights). When four out of five products in your category ship the same feature, being early stops being a differentiator and being late turns into a real cost. My seven-day stall was quietly burning the one advantage the decision was supposed to protect.
Decision latency costs more than a wrong decision.
Here’s the reframe that finally moved me.
We treat decisions as if the danger is getting them wrong. So we wait. We gather more input. We tell ourselves that a slow correct answer beats a fast mistake.
For a small, reversible decision, that’s backward. The expense of waiting accumulates each day silently, whereas the cost of a wrong but reversible decision is a one-time charge you can usually get back. A build-versus-buy call on a forty-millimeter tag is not a one-way door. If I pick wrong, I change it next month. If I don’t pick at all, I lose the window, the momentum, and the next three decisions that were queued behind it.
Jeff Bezos made this idea famous with his two-way-door framing: most decisions are reversible, and reversible decisions should be made fast by the people closest to them. The part teams skip is the enforcement. Naming a decision “reversible” doesn’t make it get made. You still need something that fires.
The Decision SLA: a deadline and a default
An SLA, a service-level agreement, is a promise about response time. Support tickets get one. Your own decisions almost never do. So they wait indefinitely, because nothing bad happens on any specific day for not deciding. The pain is real, but it has no due date, so it never wins the morning.
A Decision SLA fixes that with two written pieces.
A deadline. The date the decision must be made. Not “soon,” not “this sprint.” A specific day, chosen from the real constraint driving it. If hardware ships Thursday, the decision is due Wednesday. Work backward from the real-world event that won’t wait for you.
A default. The more important half, and the one everyone forgets. The default is the specific action that happens automatically if the deadline passes with no decision. Not “escalate.” Not “revisit.” An actual move. “If I haven’t chosen the in-house build by Wednesday, we buy the off-the-shelf option and move on.” Written down, in advance, while you’re calm.
The default is what turns your review from a sensor into an actuator. A deadline alone is still just a reading; deadlines slip all the time, and everyone knows it. A deadline with a pre-committed default is a switch. When the date arrives, either you’ve decided, or the decision makes itself in the direction you already agreed was acceptable. Indecision stops being free.
The quiet payoff is that a good default also makes the decision easier to make on time. The moment you’re forced to write down what happens if you do nothing, you find out whether doing nothing is actually tolerable. Half the time the default is fine, and you relax. The other half, writing it down makes you realize the default is not fine, which is exactly the information you were stalling to avoid, so now you decide today.
Where AI actually helps: let it enforce, not decide
Notice which part of this you could automate.
Not the decision. The judgment about whether to build in-house or buy off-the-shelf is yours, and no model has the context to own it. What a machine can own is the enforcement. It watches the deadline, and when the date passes with nothing decided, it fires the default and tells everyone it fired.
That’s the contrarian part. Every pitch right now wants AI to make the call for you. The call is the one piece you should keep. The default is the piece worth handing off, because a default is just a rule with a date attached, and rules with dates are exactly what software runs without getting tired or polite about it.
I run my own decisions this way. Open calls sit in a system with a written default and a due date, and if I go quiet past that date, the default is what happens; it gets put into the record for everyone to see, no meeting required. The AI decides nothing, but in the same token it refuses to let my indecision stay free. That is a smaller job than “AI makes your decisions,” and a much more useful one.
The PM lesson
Here it is plainly: a review process that surfaces problems without forcing decisions is only half a system, and the missing half is the expensive one.
Noticing is cheap. Every tool you own is built to help you notice. Dashboards, retros, standups, alerts. We have never had better sensors. What almost no team installs on purpose is the actuator, the pre-agreed rule that converts a noticed problem into a committed action on a specific date.
If your standup raises the same blocker three weeks in a row, the standup is not failing. It’s doing its job. What’s missing is a rule: a blocker that gets named twice gets an owner and a default on the second mention. Add that actuator, and the meeting that used to carry problems from week to week starts closing them.
What this looks like in practice
Here’s the exact format I now use. Steal it.
For any open decision, write one line with four parts:
- The decision, stated as a question. “Build the NFC tap experience in-house, or buy an off-the-shelf builder?” A vague decision can’t have a clean default, so sharpen it until it’s a real question with real options.
- The forcing constraint. The real-world event that sets the clock. “Tags ship 7/23.” If you can’t name a real constraint, that’s your signal the decision might not be urgent, and you can say so out loud instead of carrying it silently.
- The deadline. One date, derived from the constraint, with a buffer. Tags ship Thursday, decide Wednesday.
- The default. The specific action that fires if the deadline passes. “Default: buy the off-the-shelf builder.” Make it a real, acceptable move, not a placeholder like “escalate.”
A filled-in line looks like this:
Decision: In-house NFC build vs. off-the-shelf builder? · Constraint: tags ship 7/23 · Deadline: Wed 7/22 · Default: buy off-the-shelf, revisit in-house after launch.
Then two rules make it real:
Rule one: the default gets equal billing with the deadline. Most people write the deadline and skip the default, which leaves you exactly where you started when the date slips. If you only do one thing from this post, write the default.
Rule two: when the deadline hits, the default fires without a meeting. No re-litigating. No “let’s give it a few more days.” The whole point is that you already made the call when you set the default. If you find yourself wanting to override the default when the day comes, good, that means you have a real opinion now, so make the opposite call and move. Either way, the item leaves the board.
I put three aging decisions on this format the morning after my seven-day stall. Two hit their defaults and resolved themselves by the deadline. The third I actually decided a day early, because writing the default made me realize I didn’t like it.
What to do this week
You can install this in about twenty minutes. Do it today.
- Open your review, standup notes, or task board and find every item that has appeared two or more times without moving. Those are your stuck decisions. There are probably fewer than five. They feel heavier than they are.
- For the worst one, write the four-part line: decision as a question, forcing constraint, deadline, default. If you can’t find a real constraint, mark it “not urgent” and stop pretending it’s weighing on you.
- Write the default first if you’re struggling. Ask “if I do nothing, what’s the least-bad thing that should just happen?” That answer is often the decision.
- Put the deadline where the decision lives, not in a separate tracker. It should stare at you in the same review that surfaced it.
- Tell one other person the default out loud. Saying “if I haven’t decided by Wednesday, we buy it” to a cofounder or teammate is the cheapest commitment device there is, and it makes the default fire on its own.
Do that for one decision this week. Not all of them. One. The point is to feel what it’s like when a stuck item leaves your board on a date instead of riding along for another month.
FAQ
What exactly is a Decision SLA? A written rule for a single open decision that pairs a hard deadline with a pre-committed default action. If the deadline passes without a decision, the default happens automatically. It borrows the idea of a service-level agreement, a promised response time, and points it at your own decision-making instead of a support queue.
How is this different from just setting a deadline? A deadline tells you when a decision is late. It doesn’t do anything when the date arrives. The default is the part that acts. Deadlines alone slip constantly because missing them has no consequence. A default gives the missed deadline a consequence you chose in advance.
Doesn’t a default just encourage lazy or rushed decisions? The opposite. Writing the default forces you to look honestly at what happens if you don’t decide. If the default is acceptable, the decision was never as high-stakes as your stalling implied. If the default is unacceptable, you’ve surfaced the real reason to decide now. Either way, you get clarity you were avoiding.
Which decisions should get an SLA, and which shouldn’t? Use it for reversible decisions with a real clock: build-versus-buy calls, vendor picks, scope cuts, anything you could change later without much cost. Do not default your way through one-way doors like a pricing model you can’t walk back, a key hire, or a data-privacy commitment. Those deserve the slow path.
What if I pick the wrong default? Then you change it, because you only put reversible decisions on this system in the first place. A wrong reversible default costs you one correction. A decision that never gets made costs you the window plus everything queued behind it. The math favors deciding.
Who owns the default when it’s a team decision? Name one owner per decision, the same way you’d name one owner for a ticket. The owner writes the default and is the person the default fires for. Shared ownership is how decisions get stuck in the first place.
Implementation: how do teams fit this into existing workflows and tools? Don’t add a tool. Add two fields to the artifact you already argue over. Whatever holds your open decisions- a ticket, a roadmap row, a doc, a standup line- gets a “deadline” field and a “default” field. The rule lives in the same place the decision already lives, so nobody has to check a second system. If your tool fires automations on a due date, point one at the deadline so the default surfaces on its own.
Team dynamics: what if people disagree on the default or the deadline? Good. That disagreement is the decision, surfaced early instead of on the deadline. Write down both proposed defaults, name the owner, and agree which one fires if nobody breaks the tie by the date. Disagreement about the default is a signal the call actually matters, so it earns a real conversation now rather than a silent stall for three weeks.
AI integration: what tools actually automate the default firing? Anything that can act on a due date. That means your task tool’s automation rules (Asana, Linear, and ClickUp all fire actions on a date), a calendar event with a pre-written “default fires today” note, or a small scheduled script or agent that reads the decision doc and posts the default when the date passes. The bar is deliberately low: you don’t need an AI that reasons, you need one that reliably does the boring thing on time. Start with the automation already inside the tool you use, and only build a custom agent when the default action is more than a notification.
Edge cases: how should teams handle high-stakes or irreversible decisions? Keep them off this system. The Decision SLA is built for reversible calls with a real clock. A one-way door, like a pricing model you can’t walk back, a senior hire, or a data-privacy commitment, should never have an auto-firing default, because a wrong default there is not refundable. For those, the deadline still helps, but the “default” is “escalate to a real decision meeting,” not an automatic move.
Measurement: how do you track whether this is working? Count two things. First, decision age: how many days your average open decision sits before it resolves. That number should fall. Second, default-fire rate: how often the deadline passes and the default fires instead of you deciding. A little is healthy, because the system is doing its job. A lot means your deadlines are too tight or you’re using the default to dodge calls you should be making. Watch both for a month, then adjust the deadlines, not the rule.
The morning I finally moved that packaging decision, nothing about the problem had changed. Same options, same tradeoffs, same four days on the clock. The only new thing was a rule that wouldn’t let it sit.
That’s the whole shift. You don’t need better judgment or more information than you already have. You need to stop letting “not yet” be free.
Give your next stuck decision a deadline and a default. Make the call yourself, then let a rule you can automate make sure the date never slides. That’s the AI job worth having: not deciding for you, just refusing to let indecision stay free. Watch how fast your board clears once it finally has a price.
Leave a Reply