Premature Governance Is Its Own Failure Mode

TV
Thiago Victorino
6 min read
Premature Governance Is Its Own Failure Mode
Listen to this article

In the same week of May 2026, two senior practitioners from very different domains published essays that, read side by side, are making one argument. Amy Mitchell, writing about product management, said the instincts that make a senior PM excellent at stabilizing a product break the moment that PM is handed an AI initiative. Tey Bannerman, writing about design leadership, listed the three ways AI implementations fail and concluded that the design organizations getting it right share a habit the failing ones do not: they refuse to formalize before they have learned.

Neither essay quotes the other. Neither essay frames itself as a governance argument. Both are governance arguments in disguise.

The pattern they describe, when stacked, is the meta-failure that no AI maturity model has yet named clearly: premature governance is itself a failure mode. The frameworks meant to make AI safe at scale, applied to AI initiatives that have not yet learned what they are, kill the learning velocity that would make those frameworks useful in the first place.

This is a sequencing argument. And it is the argument leadership teams need to settle this quarter.

The PM Version: Stabilization Instincts vs Transformation Instincts

Mitchell’s distinction is the cleanest framing of the problem I have seen this year. The senior product manager who has spent a decade getting good at the job has internalized a specific operating model. Identify the metric. Optimize several steps ahead. Reduce variance. Hit the roadmap. Manage stakeholders. Stabilize.

That model is correct. It is correct for products whose problem space, user base, and underlying technology are stable enough that optimizing several moves ahead is a sensible thing to do. The cost of being wrong about the next quarter is bounded.

AI initiatives, in their first 12 to 18 months inside an organization, do not satisfy that condition. The capability frontier is moving. The user behavior is forming, not formed. The cost structure is unstable because the underlying model price changes by an order of magnitude between releases. The integration surface is being discovered, not specified.

Mitchell puts it precisely: “Learning enough to start is a different goal from getting to a stable environment.” The PM who tries to plan four quarters of an AI initiative on the same cadence used for the rest of the portfolio is not being conservative. That PM is destroying the option value of learning faster than the plan would allow.

Stabilization is a stage. Transformation is a different stage. Confusing them is the failure.

The Design Version: Three Implementation Failures

Bannerman’s interview with Designboom catalogues the three patterns he sees when AI implementations break inside design organizations.

The first is deploying technology before defining the problem. Teams ship “an AI feature” because the leadership demanded one. There is no specified user pain, no specified outcome, no specified before-and-after measurement. The feature lands, gets some adoption, and the team cannot say whether it created value or absorbed engineering capacity.

The second is measuring only efficiency. Cost per task, time per task, throughput. None of which capture whether the people using the AI trust it, whether they integrate it into their actual decision flow, or whether the work product improved. Bannerman’s point: efficiency metrics congeal early because they are easy to measure, and the organization optimizes for them long after it is clear they are not the right metrics.

The third is excluding domain experts from decisions about how AI is deployed in their domain. The platform team picks the tool, configures the policy, defines the workflow. The designers, lawyers, financial analysts, and operators who actually do the work are handed the result. The result fails because the people closest to the work were not the ones who decided what “the work” is.

All three failures share a structural feature. They are governance acts performed at the wrong stage. Deploying without a problem definition is shipping infrastructure before learning. Measuring efficiency only is locking in a metric before the right metric is known. Excluding domain experts is centralizing the decision before the decentralized knowledge has been gathered.

Each one is the same instinct that makes a senior leader excellent at running stable operations: pick the tool, set the metric, decide centrally. Each one, applied a stage too early, is destructive.

The Meta-Pattern: Sequencing

Put Mitchell and Bannerman next to each other and the meta-claim is unavoidable. The professional instincts that make senior people senior, the same instincts the rest of the organization counts on, become a hazard when the work has not yet stabilized enough to deserve them.

This is not a critique of governance. We have written extensively about why governance is becoming the moat and why organizations that ship governed AI faster will eat the ones that ship ungoverned AI faster. Those arguments stand. What this week’s essays sharpen is that governance applied at the wrong sequencing point is not weak governance. It is a different failure mode entirely.

The framework that emerges has two stages, and they have to be honored in order:

Stage one is the bounded learning environment. Small scope. Real users. Domain experts in the room. No fixed metric yet, because what to measure is itself one of the things being learned. No locked-in tool, because the criteria for tool choice are also being learned. Cost of being wrong is contained by scope. Cycle time is the only protected variable.

Stage two is scale-stage rigor. Now the metric is known. Now the workflow has converged enough to write down. Now the role of the domain expert can be encoded in the tool itself, because the team understands what the expert was contributing in stage one. Stabilization PM instincts, efficiency metrics, central platform decisions: all appropriate, all necessary, all correct.

The error is running stage two playbooks on stage one work. It looks responsible. It feels like governance. It is the most expensive way to fail at AI, because it fails invisibly. The team hits its plan. The metric improves. The audit trail is clean. The initiative produces no real learning, no real adoption, no real change in how the work gets done. Two years later the question “what did we get from this?” has no answer that survives scrutiny.

What Bannerman Is Really Saying About Leadership

There is one line in the Designboom interview that deserves to be pulled out and pinned to a wall. Asked what differentiates leaders who navigate this stage well, Bannerman names “systems thinking, moral reasoning, and relational intelligence” as the highest-differentiating skills as AI absorbs the production layer.

That is not the answer most leadership development programs are oriented around. Most of them are still selecting for execution discipline, metric command, and stakeholder management. Those skills do not stop mattering. They stop being the differentiator.

The leader who can hold a stage one initiative in stage one for as long as it needs to be there, against pressure from finance, from the rest of the portfolio, from their own discomfort with ambiguity, is the leader who gets a real result at stage two. The leader who applies stabilization rigor to a transformation problem because that is what their instincts call for is the one whose AI program produces a clean dashboard and no value.

Do This Now

The action this essay asks of leadership teams is small and specific. Pick the three biggest AI initiatives currently running in your organization. For each one, answer two questions, in order.

First, what stage is this initiative in? Is the problem definition stable, the metric agreed, the user behavior formed, the workflow specified? If yes, it is a stage two initiative and stabilization rigor is correct. If no, it is a stage one initiative and what you need to protect is learning velocity.

Second, are the people running it operating with the instincts the stage requires? A stabilization PM running a stage one initiative will produce a clean plan and no learning. A transformation PM running a stage two initiative will produce constant rework. The mismatch is the failure. Name it, fix the assignment, and let the right instincts run the right stage.

The organizations that get this sequencing right will not be the ones with the most ambitious AI plans. They will be the ones whose ambition was matched to the stage their work was actually in.


This analysis synthesizes Why AI Initiatives Break Normal Product Manager Instincts (Amy Mitchell, May 2026) and Tey Bannerman: AI Strategy for Design Leaders (Designboom, May 2026).

Victorino Group helps PM, design, and operations leaders sequence governance to match AI maturity, not the other way around. Let’s talk.

All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →

If this resonates, let's talk

We help companies implement AI without losing control.

Schedule a Conversation