In January I wrote about the velocity wall: engineering gets fast, the processes around it don’t, and the gains pile up at the boundary. Since then I’ve come to think the wall starts further upstream than I described, in how the work gets chosen. In most organizations, what’s available to choose from is a ranked list of requests.

The habit is close to universal, so I’ll describe it generally. Departments bring their ideas to product planning. Product collects them, weighs them, picks the best, and the ranked result gets called strategy. Sometimes the chosen items get grouped into themes afterward, and the themes get dignified names. Nobody in this picture is being unreasonable; every request is someone’s honest attempt to help. And for decades the habit was defensible, because building was expensive. When you can only build five things a year, choosing which five feels like the whole job of strategy. Ranking was the only strategic act assumed necessary.

We still work this way more than I’d like.

AI breaks the habit quietly. When building gets cheap, the scarcity that excused the habit disappears. You can work through the whole bucket now, ship most of it, and still not solve anything anyone would name as solved. The defect is in the unit itself: a request has no termination condition. Shipping one doesn’t end anything; it makes room in the bucket.

Requests also invite commitment before evidence. A requested feature gets bundled, priced, and announced before anyone has checked that it solves the problem it was meant to. The whole company rallies around a bet nobody has scored yet. I said this to our leadership team recently: we fall in love with solutions too early. The love should be earned, by evidence that the problem is actually solved. Output-based work never asks that question; it has no introspection muscle to even know what it’s missing. A way of working that cannot detect its own failure will repeat it at whatever speed you give it.

This is what feeds the wall from January. The organization’s capacity to rally, package, train, and sell is its scarcest resource, and request-driven planning spends that capacity on the unproven.

A request is a conclusion with the premises removed. Someone lived a problem, reasoned their way to “this feature would help,” and handed over only the last step. The fix isn’t to reject requests; they’re evidence, often the best evidence available. The fix is to recover the premises. None of this is new advice; product leaders have preached problem-focus for a decade. What’s new is that the excuse for skipping it just expired. I’ve been coaching PMs to hold a few questions against every incoming request: what makes this important now, what it costs to leave unsolved, who feels the pain most, what evidence says it’s the right problem. And the one that changes the work: what would be different if this worked well? That answer is a problem with a definition of done.

From there the work inverts. You don’t schedule the request; you work the problem, through bets. Sometimes a bet is the requested feature. Sometimes it’s something different. Usually it’s a mix, revised as results come in. Bets that miss get killed rather than extended. And ranking doesn’t disappear; problems still compete for the next bet. The difference is the unit: problems ranked by what they cost to leave unsolved, not features ranked by who asked. You keep placing bets until the problem is solved, and solved is not a feeling: it’s when what you said would be different is different. Solved ends the work. Shipped never does. And solved, not shipped or announced, is the moment worth rallying the rest of the company around.

The strongest objection is the request that seems exempt from all of this: “we need it for compliance.” In health care that phrase usually ends the conversation. It should start a more specific one:

• What specifically must be true for us to be compliant?
• Which regulation, policy, contract term, or audit finding requires it?
• What must the system be able to demonstrate?
• What risk are we mitigating, and what is the deadline on the triggering event?
• What scenarios must be supported?
• What evidence will prove we satisfied it?

Every one of those has a concrete answer, and the last one quietly does the most work: it defines done as evidence existing, not as a feature shipping. A shipped feature and a satisfied obligation are different claims. And if the request that carries the force of law decomposes into a problem with a definition of done, no request is exempt.

The harder case than compliance is the request with money already attached: the sales promise, the renewal term, the roadmap a board has seen. Those are real, and no amount of problem-framing makes them disappear. But they are bets someone already placed on the company’s behalf, usually without the questions. Working from problems doesn’t excuse you from honoring them; it keeps the next quarter’s list from being built out of them by default.

I won’t pretend we operate this way today. The questions live with a handful of PMs who wanted them, not in the operating model, and moving an organization from ranked requests to worked problems is slower than any technical change we’ve made: the habit sits with everyone who has ever been promised their request, not just the team doing the ranking. This is a direction, not our current state.

But I’ve become convinced it’s one of the only sane ways to work at the speed of AI. Working from problems was always the better way; speed just raised the price of skipping it. Output was scarce for so long that we learned to treat producing it as the point. It never was; it only looked like the point while it was the constraint. What’s scarce now is knowing which problem you’re working on, and the discipline to stop when it’s solved.