AI did not break your product org. It just made the break impossible to hide.
AI did not break your product org. It just made the break impossible to hide.
In one of my previous roles not too long ago we had more information flowing through our product organization than ever before.
Meeting recordings in Google Drive. Discovery findings in another product. Status updates in Jira. Notes in Notion. AI-generated summaries appearing in every tool we touched. We had invested in the stack. We had invested in the processes.
And still nobody had the full picture about what we were working on. Including me.
I used to explain this as a culture problem. People do not update things. People do not read the summaries. People treat tools as a dumping ground and not a shared source of truth. And that is all true. But it is not the real reason.
The real reason is that we had never made explicit decisions about what information mattered, who was responsible for it, and how it connected to actual choices. We had built the structure around those decisions without ever making the decisions themselves. And when you add AI capture to that situation, you do not get clarity. You get beautifully organized chaos. The noise, arriving faster.
I have been thinking about this a lot since reading a field report from a product leader who ran a full product lifecycle with AI in 30 days. Competitive analysis, assumption mapping, experiment design, architecture, QA. One person. One month. (credits to Thomas Dias - The new Job of a Product Leader - Posted on LinkedIn)
The report was honest in a way most AI content is not. Around half of the total build was revision work. The AI skipped process gates because nobody had documented them explicitly. It violated design constraints because the visual standards existed in someone’s head, not in a written spec. It optimized for completion over correctness because the success criteria were not specific enough to push back against.
And still, the product shipped. 30 days. One person.
We talk a lot about the speed we think we gain, but we barely talk about what breaks and why.
Every failure point in the described experiment mapped to the same cause. The system was not documented well enough for AI to follow it without constant human correction.
The insight: AI does not make a bad operating model better. It makes it faster. And faster bad is worse than slow bad, because you get more of it before anyone notices.
The product orgs getting real value from AI right now are not the ones with the most sophisticated toolstack. They are the ones where someone already made explicit decisions about how work flows. What ready to build actually means. What counts as evidence. Who can decide what without asking upward.
Those decisions are not technical. They are leadership decisions. And most product leaders have been putting them off for years, because when humans absorb the cost of an implicit system, the absence of a real system is invisible.
AI has removed that cover.
Here is what I mean practically.
When you give AI a task in analysis or planning, it can operate with a lot of independence. Competitive research, assumption mapping, scope breakdown, risk identification. These tasks are systematic and thorough in ways humans rarely have time to be. The AI does not get tired in the third hour of a mapping session. It does not skip a risk category because the meeting ran over. If your briefing is good, the output is often better than what the team would have produced in twice the time.
But when you move into building, the autonomy needs limits. And those limits only work if they are written down. AI will follow the spec that exists, not the one you intended. If your definition of done is in someone’s head, the AI will not find it there. If your process gates are enforced by a specific person’s judgment, AI will walk past them. Teams that get this right have already done the hard work of making their system explicit. The AI did not force them to do that. It just exposed that they had.
Design is the place where human judgment still needs to stay in control, almost fully. AI cannot hold visual coherence in mind across sessions. It cannot tell when a component undermines the credibility of a page. It does not recognize when technically correct becomes visually wrong. The teams that discovered this the hard way did so because nobody had said it out loud before.
There is a second thing AI cannot do. It cannot catch its own mistakes across disciplines.
It does not know that the architecture decision made in sprint two will create a QA failure in sprint five. It does not notice that the onboarding copy contradicts the pricing page. It does not flag that a feature shipped this week conflicts with a customer commitment from a sales call three months ago that nobody wrote down.
Catching those things requires something that is not general intelligence. It is domain overlap. The ability to hold enough context across enough areas that you notice when something is wrong before it causes damage.
This used to be absorbed by the teams themselves. Senior engineers who had been around long enough to know where the bodies were. PMs who had read enough customer calls to recognize a pattern. Experienced leaders who had seen this type of failure before in a different context.
AI makes that coverage question sharper. If you have team members who are deep in one area but have no real working knowledge of what surrounds it, they will not catch what AI gets wrong. They will review the output from inside their lane and miss the collision coming from outside it.
The people who thrive in AI-enabled product orgs are not the deepest specialists. They are the people with enough working knowledge across discovery, delivery, design, and commercial reality to supervise AI well. That is a hiring decision. It is also a development decision. Helping a PM build commercial judgment, or helping an engineer understand product thinking, is not a nice-to-have. It is how you get real value from the AI you have already bought.
So here is the question I would sit with.
If you handed your full product cycle to an AI tomorrow, with your current documentation and your current process rules and your current definition of what good looks like, what would happen?
Not what would it produce. What would break, and why?
If the honest answer is that it would skip the gates nobody has written down, miss the standards nobody has specified, and optimize for something that looks like done but is not actually done, that is not an AI problem.
That is an operating model problem. And it was already there before AI arrived. You just did not have to look at it directly.
The good news is that this is fixable. Not by buying more tools.
By making the system you already have explicit enough to trust. Writing down the decisions that currently live in someone’s head. Documenting the process rules that govern how ideas become features. Being honest about what autonomy each type of work can actually have without someone checking the output.
This is the work that has always needed doing. A lot of product leaders have been sitting in a room with this work for years, knowing it needs to happen, never finding the week to start.
AI has just made the cost of waiting visible.
And the cost is no longer theoretical.
This is the work I do with CPOs and VPs of Product.
If this article made you think of a specific gap in your own org, I built something that helps you close it.
The Leadership Taxes Playbook is the system I use with Senior Product Leaders I work with. It covers the Four Leadership Taxes, the operating model that sits underneath them, and a 90-day sprint to start fixing it without rebuilding everything at once. Including a full chapter on what AI actually changes in each pillar, and what it does not.
49 CHF. No subscription. Yours to keep.
If you want to work through a specific situation with someone who tells you the truth, a Power Hour is the right next step. (Paid offering)
"Garbage in, garbage out" predates AI by decades, but it's never been more consequential. AI will follow the spec that exists, not the one you intended. And the system has no idea the spec is incomplete. It can't question what it doesn't know to ask about. It will do exactly what it's told, including the wrong thing, with complete confidence.
This connects to something your piece touches: we've quietly lost the discipline of Systems Engineering and Systems Thinking over the last two decades. When everything had to be properly documented, organisational memory survived people leaving. Knowledge lived in the system, not just in someone's head. The proliferation of tools produced the opposite — the assumption that because something exists somewhere in a repository, it's preserved. In reality it's been scattered across twelve platforms and effectively lost. The assumption that the tools are good enough replaced the discipline that made them useful.
The AI-will-take-jobs narrative misses this entirely. What AI cannot take is experience, accumulated judgment, and the wisdom to recognise when something is wrong before it fails. That's not sentiment — it's where the actual value from human engagement sits. The person who has seen this class of failure before, across enough contexts to pattern-match early, is irreplaceable precisely because that knowledge was never written down anywhere a system could locate it.
Your point about domain overlap is exactly this. The specialist reviewing output from inside their lane missed the collision coming from outside it because they'd never had reason to look. That instinct is earned, not documented. No AI-ready operating model recovers it once it's gone.