AI Doesn’t Replace Product Management. It Reveals Whether You Ever Learned It.

Every few years our profession discovers a new tool that promises to change everything. Agile was going to fix “build the product right.” Then Design Thinking or Jobs to Be Done would ensure we “built the right product.”

Then there was no-code. And now there’s AI.

The pattern is always the same. We become fascinated with the tool and quietly forget to ask whether the people using it understand the fundamentals of the job.

Just to be clear, the job is to understand friction for the people who buy and use our products.

That's the real issue.

Product Managers Still Need The Fundamentals

After training product managers for more than thirty years, I've come to believe the biggest problem facing our profession isn't AI. It isn't Agile, or org structure, or roadmaps. It's that most product managers were never actually trained in product management.

In my experience, most product managers have been trained in Scrum or agile methods. Which is great, but it’s not product management.

Many product managers came from engineering, project management, support, or consulting. They were good at one job, and then someone handed them the title "Product Manager," and they learned by watching whoever happened to be sitting nearby. Sometimes they had an excellent mentor. More often they inherited someone else's habits. And maybe they watched some YouTube videos or attended a LinkedIn Learning class.

Some learned to write user stories. Some learned to groom a backlog. Some became experts in Jira; others became experts in PowerPoint. They got very good at the mechanics of the job without ever learning its purpose.

They didn’t learn product management.

And that matters more now than ever before.

AI is an extraordinary assistant, but it has no idea whether you're doing product management well or badly. It helps you do more of whatever you ask it to do. If your thinking is clear, AI makes you dramatically more productive. If your thinking is confused, AI produces confused work much faster — and with better formatting.

You still have to know what "good" looks like. That's the part nobody taught.

With today’s tools, you can build the wrong product faster than ever.

Requirements and specifications are not the same thing

I was surprised recently to learn how many organizations are still writing PRDs. There's nothing wrong with a Product Requirements Document, but most of the documents I see aren't requirements documents at all.

They're a little bit requirements and a little bit specification. A little design. A little project plan. A few screenshots, some implementation ideas, maybe a paragraph about the market. By the end, nobody can tell where the customer problem ends and the technical implementation begins.

Years ago, I was taught a distinction that has stayed with me. Requirements describe “what” and “who and “why.” Specifications describe “how” and “when.”

One explains the business problem. The other explains the implementation.

That isn't academic hair-splitting. It changes how teams think. When we jump straight to implementation, we stop talking about customers. We get absorbed in screens, workflows, permissions, and technical elegance. Before long, we're optimizing a solution nobody has confirmed is worth building.

And here's the practical consequence: you don't want a junior programmer writing the spec without understanding the requirement. That's true whether the junior programmer is a person or a model.

Vibe coding makes the problem visible

Many product managers have embraced vibe coding, and I understand why. Describe an application in plain English and minutes later you have something running. It's exciting. It's fun. Frankly, it's a little addictive.

Then something predictable happens. Instead of asking whether we understand the customer, we start decorating the prototype. Move that button. Change this workflow. Try a different color. Maybe the dashboard should look like this instead.

And AI is party to this. Mine asks me. “Do you want to add a dashboard?” “How about a heatmap?” “Should we add an executive summary?”

Sure, all those sound good, but wait—what is the requirement again?

Hours become days. Days become weeks. The entire conversation is about the solution, and the customer has quietly left the room.

That's not an AI problem. That's a product management problem. AI just made it faster to reach.

What good developers actually ask for

One of the most useful lessons of my career came from my first development team. I assumed they would want detailed specifications. Instead, they kept asking business questions.

Who is the customer? What problem do they have today? Why are we building this now? What have we learned from customers recently? Is there a marketing campaign planned around this release?

At first I thought they were slowing me down. Eventually I realized they were teaching me something. They weren't asking for more documentation. They were asking for context.

Good developers can usually figure out the implementation. What they can't invent is an understanding of the market. They need product managers to bring the customer into the room. That's our job.

The more context we provide, the less detail your team needs.

And context isn't something you explain once. Organizations change constantly. New developers join. Designers leave. A new engineering manager arrives. Teams get reorganized, contractors rotate through, and every change takes a little shared understanding with it.

So we keep rebuilding it. Who are our personas? What problems are they trying to solve? What have we learned in the last month? Which assumptions have changed? Why does this initiative matter to the business? Where is your README.md file?

Explaining context isn't overhead. It's one of the central responsibilities of the job.

We stopped teaching this

Somewhere along the way, training disappeared from onboarding. New product managers get a Jira login, a calendar full of meetings, and now an AI subscription. Then we wonder why strategy never reaches daily decisions.

Real training looks different. New product managers should learn how to conduct customer conversations, and how to tell the difference between one customer's request and a market pattern. They should understand personas, segments, business models, positioning, prioritization, and outcomes. They should learn to communicate customer context, so engineering, design, marketing, and sales are all focused on the same problem.

Most of all, they need an operating model — a clear picture of where product management fits in the business. The job isn't collecting feature requests or maintaining a backlog. It’s not administrivia. The job is understanding the market, helping the company make sound investment decisions, and making sure everyone building the product understands the customer they're serving.

AI reinforced this rather than replacing it

I've been building software with today's AI tools. I expected to spend most of my time talking about code. Instead, I spent it talking about users and their scenarios.

The tools kept asking questions. Who uses this feature? Walk me through their workflow. What are they trying to accomplish? Who has permission to do this? What happens when two users need different outcomes?

The better I explained the customer, the better the software got.

I found myself inventing personas — Susan, Saeed, Barb — not because the tool required names, but because giving each user an identity helped me think clearly about what that person was trying to do. And the loop is fast. Working software comes back with "do you mean like this?" and I see immediately where I've been vague. “No. This user shouldn't be able to edit that. The facilitator needs different permissions than the team leader.”

Each round sharpened my understanding of the problem before it improved the solution.

That's the part I keep coming back to. AI didn't replace product management. It forces us to practice it.

The companies that win over the next decade won't be the ones with the best AI tools; those are available to everyone. They'll be the ones that teach product managers how to think like product managers before they teach them how to prompt.

AI can write a document. It can generate a prototype. It can write working code. It still depends on someone who understands the market well enough to describe the problem worth solving.

That's what product management has always been about.