Monday, 9:12 a.m. Five requests landed in the inbox at almost the same instant.
Every one of them is a "can you do this." Pick them up in the order they arrived and the whole day knots up.
Start with A. It looks like "one number," but whether it's a typo you fix in five minutes or a data problem you have to trace back half a day, you can't tell until you open it. Grab A first because it looks light, let the whole morning get sucked in, and C's 4 p.m. send just slips by while E quietly bleeds money the entire time. The task that caught your eye first pushes out the task that costs the most.
This is where the AI PM comes in: its job is to propose and adjust the priority of incoming work. So when a request arrives, it doesn't reach for it right away. It pushes back first. "I don't think this is the one to grab right now. I'd suggest we check the scope of the checkout error first, then open the report." It puts forward what comes first and why, and waits for a human to decide.
An emergency room doesn't treat people in arrival order. It sizes up everyone who walks in and moves the ones who are in danger if untouched to the front. This sorting is called triage. The person quietly slipping out of consciousness goes before the one with a broken arm who's shouting. Requests are the same. You sort by the size of the risk, not the volume of the noise.
But the size of the risk isn't visible until you open it. So you set the order twice. First the order to inspect; only after inspecting does the order to handle emerge.
E is still "a report." You open it first to find out whether checkout is actually blocked, and whether this is a one-off error for a single person or an outage hitting everyone. If it turns out to be a full outage, it's number one the instant you confirm it. If it's a momentary glitch for one person, it drops down the list.
A: you open it to see which number is wrong and on which screen. A second-decimal rounding and a total-revenue figure carry different weight, and a report for one customer and a shared dashboard that many customers view together reach different distances. The same "one number," once opened, can land dead last or number one.
C: you open it to see whether it really just needs a review or whether there's still work to do. If there's nothing to fix, you park it against the send time; if there is, you pull it forward.
Only after opening does the queue form. And there are four yardsticks for forming it.
You have to pull "urgent" and "important" apart first. Urgent is the time axis — the deadline is close. Important is the impact axis — doing it or not doing it changes the outcome a lot. The two often look like the same thing, but they're different axes, and the four criteria are those two axes broken down into practice.
First, is irreversible harm imminent? Something you lose permanently if you don't act now. E's checkout error sits here. Every minute you delay, that much business just evaporates. Data about to be wiped, a wrong email about to go out — same box.
Second, is this task blocking other tasks? A task that has to finish before the ones behind it can move is a "blocking task." Even if its own importance is middling, you handle it first. Otherwise everything queued behind it stalls as a block.
Third, is there a fixed deadline that won't move? C's 4 p.m. is one. The send time runs regardless of your circumstances. For this kind of task you count backward from the deadline. If the review takes 30 minutes, you need it in hand by 3:30. Set an alarm there and you're free to do other things until then. Urgent doesn't mean you have to grab it this very second.
Fourth, how many people — or how much money — does it touch? One person's inconvenience and everyone's outage carry different weight. If A above were a shared dashboard, it climbs in this box.
When the criteria fall one at a time, it's easy. The problem is when two of them collide over the same stretch of time.
Say you've gone in to inspect E as number one. Pinning down the scope takes time too. While you dig through logs and try to reproduce it, the morning melts away and C's 4 p.m. draws closer. Irreversible harm (E) and an immovable deadline (C) are fighting over a single morning.
The way to not let C slip while you're holding E is to separate "cure" from "stopping the bleed." Fully fixing E's root cause could run into the afternoon. But a measure that temporarily stops the harm — closing checkout on the affected path for a moment, or posting a notice — is far shorter. That said, this measure doesn't automatically mean "the money has stopped leaking." Even with checkout closed, as long as customers still can't pay, the risk of lost revenue remains. So after stopping the bleed you have to confirm the customer impact actually dropped — whether error transactions stopped, whether customers who saw the notice moved to another path. If that confirmation shows the harm really shrank, E's weight comes down from "number one this instant" to "root fix sometime today." In that gap you can keep C's alarm time.
So what happens to B? Run things this way and only this way, and a task like B — not urgent but important — gets pushed to "whenever there's spare time" forever, because spare time rarely comes. So you need one rule. For work that's not urgent but important, carve out a fixed slot in the day in advance and keep interrupting work from eating it. Put part of the afternoon you bought with the bleed-stop into that slot, and the long-term task edges forward a little every day.
Setting the order once isn't the end. The most common wobble comes when a customer changes their mind midway. Let's follow C to the end.
1 p.m., the customer calls. "Something's come up — can we push the send to tomorrow morning? And instead of leading this issue with the product, I'd like the lead story centered on a customer case."
Both of the rookie reactions are dangerous. Saying "sure" and shoving the schedule back on the spot, or just logging it and continuing the review out of momentum.
Draw the line first. Reordering within an already-agreed scope — pulling things forward and pushing things back — the AI PM does automatically. Decisions that change the delivery date, the scope, or what gets sacrificed, on the other hand, go to a human for approval. Lay that boundary straight onto this case.
The two things the customer sent — the delay and the change of direction — are changes the customer already requested. You take them and apply them. What needs separate approval comes after. A task you thought was "just a final review" has grown into a rewrite of the lead story. Where to pull the rewrite time from, and what you give up today because of it — that's an internal decision, and that's where approval attaches.
So the picture the AI PM brings to a human looks like this. "Send moves to tomorrow morning, direction changes to the customer-case angle. Of what we'd polished for the product version, we keep this part and rewrite that part. With the afternoon freed by dropping the rewrite, I'm thinking of pulling in the roadmap draft we'd postponed. Go with this?" And it records why the direction changed, who requested it, and when. That's the ground to walk back to when someone looks at tomorrow's output and asks, "why isn't this about the product?"
Ordering work is hard not because people don't know the criteria. It's because the ground is full of forces that shake the criteria.
One, the loud voice pushes out the quiet signal. Almost everyone who makes a request feels their own task is urgent. That's not a lie — people are built to feel the task in front of them as the big one. So take "it's urgent" at face value and the whole inbox becomes number one, and only the tasks someone chases you about directly, like A, catch your eye. E's "a report that it errors sometimes" is quiet. Yet the weight runs the other way.
I've been caught by it. Once I moved a report fix to the very top because "the customer is looking at the screen." Meanwhile a report that had come in quietly sat there, and I opened it much later — and inside was the word "checkout." The chasing voice had drowned out that word and I'd skimmed right past it. What I changed that day wasn't my attitude; it was the "open first" list. Reports involving checkout, data, or outbound sends get opened first, no matter who's shouting.
Two, new work keeps displacing the work in hand. A distinction is needed here. Independent tasks split across several hands and done at the same time are not a problem. The problem is one hand constantly switching between this task and that. Every time you fold one context and stand up a new one, time leaks — this is called "switching cost." The verification step gets sacrificed especially. "Get it running and move on" skips the box where you confirm what you got running is actually correct. A report that's 90% done can't be delivered, and a checkout bug that's 90% fixed is still leaking money. So a task one hand has taken generally finishes before moving to the next. The one exception: work with irreversible harm on the line stops everything and cuts in.
Human PMs hit these traps too. What makes an AI PM better isn't being smarter. It's that it records the grounds for the ordering in the same format every time. "Reason E was moved to number one: irreversible revenue loss in progress." A human's judgment happens inside the head, invisible from outside, and "why did you do that first?" gets you "it looked urgent." Grounds written down let you walk back a wrong case later and fix the criteria themselves. Being able to fix them is the whole point.
Everything so far — opening first, holding to the criteria, the approval boundary — gathers into a single screen in ONTLE. Here's how the morning's five land there.
ONTLE's AI PM attaches one line to each request — "currently rank N, because of this" — and lays them out as a list. Three things sit in that one line: the reason for the rank, the part still unconfirmed, and the point a human has to decide.
E's line reads like this: "Number-one candidate — checkout error. But still at the report stage, so it needs confirming as a full outage before it's locked in." A's line: "On hold — if it's a shared dashboard it goes up, if it's for one customer it goes down. Have to open it to decide." C: "Parked until 3:30 — other work possible before then." The point of this screen is that A, the one acting urgent, sits on "hold" rather than at the top.
Below the list sit a "proceed in this order" button and "change the order," side by side. The human skims the reasons and presses the button, or drags a line to flip it. Reviewing and flipping a board the AI has already weighed is faster than weighing all five from scratch. Only decisions that involve a sacrifice — what to drop today when the newsletter direction changes — get one more confirmation; reordering within an agreed scope doesn't. What the screen does is not take over the judgment, but mark clearly where a human's decision is needed.
The single most effective thing the requesting side can do is attach one line of deadline and impact to the request.
"Fix the number in the report" and "Fix the number in the report — it's a shared dashboard, so all customers see it, and it just needs to be done sometime today" are entirely different requests. The latter hands you the material to weigh with. The former makes you go back and ask "right now, or sometime today?" — and that round trip leaks time.
It doesn't have to be written perfectly. Just "by when" and "who's affected" lift the quality of the judgment a lot. The AI PM folds the rest into its criteria and sorts.
Yes — that's how it should be. What counts as "irreversible harm" differs by team. A revenue-centered team puts checkout and transaction outages at the top; a trust-centered team puts wrong information going out to customers there. Spell these definitions out as team rules and it sorts by those rules; leave the rules blank and it runs on the general criteria but escalates anything ambiguous to a human.
Rules set in advance do. The key is not to push irreversible actions and decisions that need a human's sign-off all the way through to execution overnight. Urgent work is handled only up to the point of containing the symptom, and decisions that change direction get stacked in a queue for a human to confirm in the morning. The night's role isn't to take over judgment, but to tidy the board so the morning's decisions come fast.
It doesn't assign a rank by guessing. What can be known by opening, it opens and confirms (which screen, how many people affected); what stays unclear even after opening — say, "sometime today" versus "right now" — it fills in with a short follow-up question. Whatever ambiguity remains, it leaves on hold and escalates to a human. One round trip of asking is cheaper than spending half a day on a misread rank.