Product Management in AI-Driven Development

AI doesn’t fail at engineering. It fails at product management in AI-driven development. Give it a short brief and it will fill the gaps. Confidently. Without flagging a single assumption it made along the way. The outcome will surprise you.

A senior PM with 20 years of experience carries knowledge AI simply does not have. Social and institutional knowledge: how your team actually operates, what they deliver well, where they consistently cut corners, and what the last three product cycles taught them about each other. Customer knowledge: what users say they want versus what they actually use. Organizational history: decisions made before anyone wrote anything down. And pattern recognition: this project looks just like that one from four years ago, the one that failed for a reason nobody put in the post-mortem.

AI has none of that. It does not know what it does not know. So it fills the gaps, moves forward confidently, and delivers something that looks complete. But it is not what you meant.

As Development Accelerates, PM Has to Move Earlier

We recently worked on a project where the coding took four days. A year ago, the same scope would have taken months. Worth clarifying: I mean the coding specifically, not the full product creation. Even knowing what to expect from AI-assisted development, the speed was astonishing.

Think about what that same project looked like two years ago: six months is twenty-six weeks of engagement, thirteen sprint reviews, and over a hundred daily stand-ups. Meetings where the engineering team challenged me as the product manager, and I challenged them back. Whatever we missed in week four, we caught and corrected by week six. Even a reactive PM could deliver decent results because the timeline absorbed the mistakes.

When development runs in four days, that room is gone. If you are still working out what to build while coding starts, AI will not wait. It delivers code based on your original assumptions, or makes assumptions on the fly. You may build in human-in-the-loop checkpoints, but even if you extend the four-day coding phase into an eight-day exercise with a full week of review, you will not get anywhere near the feedback density of a hundred-plus stand-ups. And realistically, clients and other stakeholders will not give you that level of commitment anyway. If you let the coding run for four days and come back to them at the end, that is no longer clarification; it is rework, and rework is costly.

Good PM has always been proactive. The difference now is that reactive PM used to be survivable; it no longer is.

AI Has Replaced Parts of Development, Not the Parts That Matter Most

Let me be precise about what AI-driven development actually means. AI has genuinely automated certain steps of the software development process, particularly code generation and the bulk of repetitive implementation work. The change is real and significant. But the bottleneck has moved, not disappeared.

AI demonstrated that it can automate parts of development, and organizations drew the obvious conclusion: if AI can partially replace coding, PM must be next. That logic does not hold. Code can be generated from a brief. The brief cannot be generated from anything other than human judgment, context, and organizational knowledge.

There is a rare kind of person who combines strong product vision with deep engineering expertise: someone who understands security architecture, scalability trade-offs, and backend design, and who can also translate customer intent into a clear brief. Some of these people are building products right now, and they are doing it fast. But for the vast majority of AI-driven projects, that person is not in the room. The coding is fast; the judgment required upstream of it is not.

What we see consistently is what I would call the skip-forward problem. The issue is rarely that teams feed wrong requirements into development. More often, not enough requirements do. We take shortcuts, skip steps, and assume that AI carries the same institutional knowledge we have in our heads. It does not. It proceeds on the assumption anyway, and the gap surfaces only after the build, not before.

And let’s be frank: even if you could use AI to iterate your way to clear requirements, the process would be expensive and inefficient, not because AI is limited, but because people are not naturally good at describing what they want. They think they are. Ask them five detailed questions and you find out quickly that they have not considered most of it. Product management in AI-driven development exists precisely to navigate that gap, and no change in development tooling removes it.

It is a pattern we see across AI-driven projects: teams treat the PM step as optional, the build accelerates, and the outcome surprises everyone except the people who made that choice. The products built fastest with AI are often the most confused ones. A PM who takes a brief, hands it to AI, and reviews the output is not doing product management. Call it what it is: a vibe-checking PM. The job title does not change the job.

AI Does Not Pause When Requirements Are Thin

A figure that has circulated in software engineering for decades traces 60% of rework costs back to incorrect or incomplete requirements. Whatever the exact number, our experience says the direction is right. Most of what you are paying an AI dev shop for is fixing mistakes that never had to happen. And that figure comes from the pre-AI era; AI has since made it possible to build the wrong thing overnight, and the gap is even wider. Skip two hours of requirements work, find out the outcome is not what you wanted, and the cascade begins: re-gather requirements, revise the specification, check with the architect whether anything needs to change structurally, re-run the processing, pay the token cost, run a re-review. You have spent those two hours several times over before you are back to where you started.

What makes this harder with AI is that there is no natural checkpoint. In traditional development, the engineering team pushing back in a stand-up was an informal requirements review. Even reactive product managers would catch something in a sprint demo; a question would come up, a gap would surface. With coding agents, those moments do not exist in the same way. The brief goes in, the code comes out, and by the time you are reading the result, assumptions you never made explicitly are already baked into the architecture.

The feeling of overinvesting in product management at the start of a project is not a warning sign. It is a confirmation that you are doing it right, and AI has made that harder to trust. When coding that used to take months now happens overnight, spending a week on requirements and specification feels like you are making no progress. It feels like the bottleneck, like something you should wrap up faster. That feeling is a side effect of uneven efficiency: AI accelerated coding dramatically while the human work upstream has also sped up, but nowhere near as fast. If you do not feel that you are spending too much time on requirements, you are probably not spending enough. Vague requirements are not a technology problem; they are a professionalism problem.

What a Senior PM Brings That AI Cannot

A senior PM’s role is translation: taking customer intent, with all its ambiguity, unstated assumptions, and organizational context, and converting it into something a development team or coding agent can actually execute. In an outsourced development context, the vision belongs to the client. The PM’s job is to receive it, interpret it, and make it executable. That is a distinct skill, not engineering, and it is the part AI cannot substitute.

The first challenge is that people think they have a clear idea. One individual may have a vague notion they believe is well-defined. A group is more complicated still: they share what they believe is a common vision, but each person carries their own version of it. Ask detailed questions and the gaps and contradictions surface quickly. There is rarely just one valid way to solve a UX problem; there are several, and the choice between them carries real consequences for architecture, user experience, and scale. AI will take the first interpretation that fits and run with it. A senior PM brings the experience to recognize when the first idea is not the best one and the confidence to say so.

The second challenge is what I would call the personal preferences trap. Junior PMs and non-specialists tend to design for themselves, not for the person they are building for. A client will drift toward what they personally find intuitive, what they like visually, what they would use. A senior PM holds the actual user in view and pushes back when the client’s personal preferences start replacing product decisions. Clients do not need someone to build what they would personally pick. They need someone willing to tell them their favorite idea is wrong.

I keep coming back to what Steve Jobs said at WWDC in 1997: “You’ve got to start with the customer experience and work backwards to the technology.” The same principle applies today: do not build AI products. Build great products that use AI where it helps. A senior PM holds that distinction throughout the engagement, and most clients need someone to hold it for them.

There is also a practical reason to keep a senior PM in the process. It is much easier for a client to react to a concrete proposal than to generate content from scratch. A blank brief is paralyzing. But it is not only about giving clients something to confirm or push back against. A good PM also asks questions that lead to insights neither party had before the conversation, and offers options: not every option imaginable, but the ones that are relevant, thought through, and can actually be implemented. That combination of structured questioning and curated options is what moves a vague intent toward a clear brief.

Tough Decisions Belong Before the First Line of Code

Translating customer intent into a specification is not transcription. It requires architectural understanding, engineering input, and a willingness to surface trade-offs the client may not want to have. Some requirements turn out to be significantly more complex or costly than they appear. Others deliver less value than the effort they require. In traditional development, a senior engineer would push back mid-build when they hit something that did not add up. In AI-driven development, that moment does not exist in the same way. The PM has to create it before coding starts.

Consider what typically comes after the code exists. Integrating with external systems through APIs looks simple in a demo: use static data, skip the live connection. Authentication feels like a checkbox until you hit production and discover the client uses a specific identity provider, with role-based access requirements nobody discussed. Data volumes that run fine on a small test set time out at scale in ways that require architectural decisions, not code fixes. Notification systems that send one email in a demo face deliverability, consent, and compliance requirements in production. These are not edge cases; they are standard production requirements, and every one of them carries architectural implications you have to settle before the first line of code.

This is also where the real value of planning reveals itself. AI can produce a starting point quickly: a draft specification, a rough structure, an initial set of options. What transforms that starting point into something that actually reflects what the customer needs is the PM’s tacit knowledge: the organizational context, the experience of similar projects, the instinct for what is likely to cause problems downstream. A plan that AI generates in minutes still needs that layer of judgment applied to it.

What often surprises people is that the planning process itself generates requirements. A thorough session uncovers things neither the client nor the PM knew they needed to decide, and each round of questions surfaces something the previous round missed. Senior PM work is largely invisible in the outcome: people see the finished product, not the decision made in week one that prevented a restructure in week three, or the requirement someone challenged before it became a two-day rework. That invisibility is partly why organizations underestimate what good PM takes, and partly why they assume they can skip or replace it.

At A-CX, a significant part of our engagement time on AI-driven projects is spent before the build starts. Clients sometimes find that surprising. It should not be.

Scope Creep in the AI Era

Scope creep has always been a problem in software development. Senior PMs learned over time to balance between pushing back on client requests and finding ways to get things delivered through engineering. Not all PMs develop that skill, and many engineering teams carry frustration from the ones who did not: the PM who kept appearing with “can you just quickly look at this” while the team was mid-build. Inadequate expectation management on both sides of that relationship was a constant source of tension.

With AI-driven development, adding something new is fast and cheap if it happens before the build starts. After a build it still costs less than it used to, but it is not free. What has changed more fundamentally is that cost is no longer the main signal that tells people to think twice before asking. The financial consequence that historically slowed the conversation down is largely gone. The scope creep does not disappear with it; it just loses its most visible deterrent.

Every addition outside the original intent pulls the product further from its intended user. A focused product serves one persona well. One that accumulated stakeholder preferences along the way serves everyone partially and nobody completely. A product designed for everyone is loved by no one.

Saying no has always been part of the PM’s job. What changes now is the reason it matters. Before, cost and timeline created a natural inhibitor; asking for one more feature had consequences everyone could see. Now those consequences are less visible, and the PM’s judgment becomes the primary guard. In most cases, if the PM does not hold that line, nobody will. If nobody on your team can say no to a client, the client ends up doing your job for you. Badly. The risk is a product that lost its focus somewhere between the brief and the release.

The senior PM role is concentrating, not shrinking. Its work has shifted earlier, become more consultative, more architectural. The questions that matter most come before the build starts, not during it. That requires experience, judgment, and a willingness to challenge assumptions in a room where everyone else is ready to start building.

What shrinks is the role that does not require those things. Execution-level PM work that a well-structured brief and a capable coding agent can replace will continue to compress; the strategic layer will not. If anything, the distance between a PM who genuinely understands the space and one who does not will become more visible, faster.

At A-CX, we have been working through this with clients on Agentic AI projects and have developed a structured approach to product management in AI-driven development. If your PM can’t tell you no, you don’t have a product manager. You have an expensive typist. If you want to talk about the difference, reach out.