A few weeks ago I stood in front of a room of product leaders at the PLA AI Product Summit and opened with a question: when AI makes the wrong call, who’s on the line?
Nobody had a clean answer.
Features ship in hours now. Entire integrations get built in a single sprint. Qualitative feedback that used to take weeks to pull together lands on a PM’s desk before Monday morning. The pace is real. So is the confusion about what it means.
From data scarcity to data flood
A year and a half ago, I was telling product teams to build feedback hubs. Centralize everything. One source of truth. Good advice then. Wrong problem now.
Nobody suffers from a shortage of signals today. Every tool in your stack generates data. Customers are talking. Deals are being recorded. Tickets keep coming. The hard part is no longer collection. It’s knowing what matters and what is noise.
LLMs make this harder in ways people underestimate. The context window is a real constraint. Throw a million pieces of feedback at a model and it will weight what appears at the beginning and end of the dataset. The rest gets lower correlation. You get outputs that feel authoritative. Whether they are right is a separate question.
These systems also carry embedded assumptions about what matters and what is relevant. They are not neutral. Use a different model, tune a different prompt, and you may get different priorities. That is worth taking seriously. It is also why generic AI tools were never built for this job.
Automation that locks in the past
Here is the trap I see product teams walking into.
A team automates their feature request triage process. Saves time, fewer manual reviews. The problem is that the triage logic reflects how that company thought about product decisions on the day the system was built. Markets shift. Customer needs change. What mattered in Q1 may be the wrong thing to optimize for by Q3.
Automated systems do not update their own assumptions. They calculate against the ones they were given. When the calculation is built on a snapshot of what you believed at a specific point in time, you are not moving faster toward the right place. You are moving faster toward wherever you were already pointed, and it gets harder to notice the gap.
Prioritization, roadmap calls, resource allocation. These require judgment. When a machine is making them and a human is signing off without examining the reasoning, that is not governance. It is a paper trail.
BCG recently named the related risk: AI brain fry. People leaving companies because they are overloaded with consequential decisions they have to make at speed, with decreasing visibility into why those decisions are being made. It is a real attrition problem and now it has a label.
What velocity actually means
Product velocity is how fast you move in the right direction. Shipping more is not the same thing.
The head of design at Anthropic said something worth repeating in a talk a few weeks ago: we built a magic wand. A human still needs to decide what to build, when, and why. That has not changed.
We are somewhere around level two or three on the autonomous driving scale. The car handles a lot. You still need a person in the seat who understands the road and can take the wheel. Level five is not close. For core product decisions, I am not sure we want it.
The product development lifecycle will look different in twelve months. Probably different again in three years. What stays constant is that someone needs to understand the business well enough to make the call.
Accountability needs a name attached to it
Four things have to be true in a product org that wants to move fast without losing grip on what it is doing.
Measurement. Agree on what impact means for your company, quantitatively. OKRs give you a starting point. You need something that tells you whether your product decisions are moving toward the right outcomes. If your first version is wrong, measure it anyway and iterate on the measurement.
Named ownership. Every decision in the product development lifecycle needs a first name and a surname attached to it. A person, not a workflow. When something goes wrong, someone needs to explain why that call was made and what the evidence was at the time.
Documented reasoning. AI-assisted decisions need to be traceable. Why did you prioritize this over that? What signals drove the recommendation? If the answer is “it came from the model output,” that is not enough. The reasoning needs to exist somewhere a person can examine it. The Bagel AI platform was built around this: every prioritization decision is tied to the customer signals and revenue data that drove it.
Judgment. When shipping is cheap, judgment is the scarce resource. Knowing your domain, knowing your customer, knowing what drives your business better than a model can infer from a dataset. That is the job.
Why this is good news
There has never been a better time to be a product manager. The tedious work, the two-week discovery cycles, synthesizing hundreds of customer calls manually, that is being compressed into minutes. You have more time and more signal than any PM generation before you.
The question is what you do with it. Do you become the person who can interpret that signal, who understands the business well enough to know what it means, who owns the decisions that follow? Or do you become the person who lets the output stand in for the thinking?
When you hire PMs, stop asking whether they can build an agent. Anyone can build an agent. Ask whether they will sit with customers. Whether they will do whatever it takes to understand what actually moves the needle. Ask whether they can own a decision that turns out to be wrong and explain clearly why they made it.
That is the job. And it is a better job than it has ever been.
