AI surfaces the mess before it surfaces the outcome

Point an AI agent at one of your team’s real workflows and give it a week. It will find everything wrong with that workflow before you do. The doc that’s three sprints out of date. The step nobody actually owns. The decision that gets made by whoever happens to be in the room that day. You knew those rough edges were there, vaguely. Now they’re on a screen, itemized, with the agent stuck on each one.

One thing to catch up on, if you tuned out the AI news this summer. An AI agent is software that takes on a multi-step job and runs it across your real tools and tickets, deciding its own path through the work instead of following a fixed script. That improvised, dynamic behavior is why it trips over the mess so fast. Traditional feature work could hide a stale doc or an unclear owner for months. An agent operating across the same workflow hits every one of them in the first few interactions. The product writer Amy Mitchell, who studies how AI changes the PM job, put it plainly in her piece “Why AI Initiatives Break Normal Product Manager Instincts”: these inconsistencies surface far faster than traditional work would ever expose them.

So you do the responsible thing. You standardize the doc. You assign the owner. You formalize the decision that was floating. This is good discipline, and you can name the principle behind it: don’t set rules in the dark. Wait until you can see what’s actually going on, then govern based on what you saw. You just saw it. So you act on it.

That instinct is sound, and in an AI pilot it fires at precisely the wrong time. The mess the agent surfaced first is the thing you are least ready to govern on. Acting on it is the new way of setting rules in the dark, except now the room is lit and you’re reading the wrong dial.

To see why, separate two things that usually arrive together and that we lazily call by one name: visibility.

The first kind is seeing that the workflow is ragged. The docs are stale, the ownership is fuzzy, the hand-offs are improvised. Call it inconsistency-visibility. An AI agent hands you this instantly, on day one.

The second kind is seeing what the workflow actually produces once it runs. Faster delivery, or the same speed with more rework. More features shipped per engineer, or fewer. Call it outcome-visibility. This one you cannot get on day one, by definition, because it only exists after the workflow has run enough times to throw off a pattern. It needs repetition.

In ordinary product work these two show up at roughly the same moment. By the time a process has run enough for its raggedness to be obvious, it has usually run enough to show its results too. So we shorthand both as “visibility” and never notice we’ve bundled two different things.

The whole rule about waiting to govern was built on the second kind. Look at the cases that support it. UKG, the workforce-management software company, built a dashboard measuring whether AI adoption actually translated into engineering outcomes, velocity and rework and shipped features, so managers could coach against real numbers instead of guesses. Priceline, the travel-booking company, let measurement of workflow dysfunction trigger its governance changes rather than the other way around. Both cases, reported in the DX Newsletter this July, run the same loop: measure what the work produces, then adjust the rules to fit. That loop is what makes governance grounded instead of arbitrary. And it runs entirely on outcome-visibility.

AI pulls the two kinds apart in time. It delivers inconsistency-visibility first and loud, at the exact moment outcome-visibility does not yet exist. So you’re handed a screaming signal that feels like evidence, at the one point in the workflow’s life when the real evidence hasn’t arrived. The thing that feels like “now I can see it, so now I govern” is just noise that showed up before the evidence did.

Mitchell’s own read is that the stabilize reflex, correct almost everywhere else, is reliably mistimed in an AI initiative that’s still in its experimental phase. Standardize a workflow that has run five times and you’ve frozen it before you know which parts were dysfunction and which were the team learning. The variation you stamped out was the point.

The honest objection is that waiting is dangerous too, and it’s a real danger. A workflow with no owner doesn’t heal itself. Left alone, missing integration ownership produces customer-visible fragmentation within a couple of months, by the accounts in the same body of practitioner writing. So “just relax and let it run” is its own failure, and a PM who hears “don’t govern the mess yet” as “never govern the mess” will walk straight into it.

The rule that resolves both, at least on paper, is that governance should track the workflow’s maturity, not the inconsistencies it happens to surface. A workflow becomes governable once it has run enough times to produce consistent, measurable outcomes. Before that, its raggedness is learning and you protect it. After that, its raggedness is dysfunction and you fix it. Same ragged edge, opposite correct response, and the only thing that tells them apart is how many real runs sit behind it.

Which lands us on the question nobody has answered. How many runs is enough? What outcome, measured how, says a workflow has graduated from “experimenting” to “ready to freeze”? I went looking for that threshold across the governance writing and it isn’t there. No number of runs, no outcome bar, no test. Mitchell names the timing trap clearly but doesn’t draw the line either. So the rule is undecidable at the exact moment you need it: the premature governor standardizing too early and the disciplined one waiting correctly are looking at the same warning on the same screen, and nothing on that screen tells them apart.

That’s the spot to sit with the next time an AI pilot lights up with stale-doc and no-owner warnings in its first week. The pull to standardize is your wait-until-you-can-see discipline working exactly as trained. The question it can’t answer for you is which kind of seeing you’re doing. Are you governing on what this workflow produces, watched across enough runs to trust? Or on the first thing the agent happened to trip over, three days in, before it produced anything at all? If the only reason to act is that the mess surfaced, then surfacing is doing the work that evidence is supposed to do, and those are not the same thing.