How to Excel as a PM in an AI-First World

AI is pulling product managers toward code, prototypes, data queries, evals, and implementation details.

That drift is useful up to a point.

When I use AI-coded or AI-assisted prototypes at AIStackWorks, the important part is not the build itself. It is the conversation it makes possible. A customer, client, or teammate can point at a rough interaction and say, “Yes, that is the workflow,” or, “That is not what I meant.”

Having something concrete to talk around used to take ages, and what you had were pencil sketches or whiteboard diagrams at best. An AI-generated prototype can now turn a fuzzy idea into a good enough talking point before the plan hardens.

That's the key part though. It is a discussion tool. A prop. Never meant for production, too thin for customer validation, and too early to justify disappearing into a coding agent for weeks and coming back with something beautiful nobody asked for.

Successful PMs are using AI as another tool in their arsenal.

Building is not the PM’s new center of gravity

The debate is easy to follow. Ron Yang caught the useful tension in a recent post about PMs becoming engineers, arguing that AI should help PMs get closer to customers, not substitute for knowing them.

AI lets a PM turn a thought into a clickable flow, ask sharper data questions, inspect a codebase, and think through the implications more thoroughly to write a better first-pass spec.

With AI, product managers can become more technical. They should understand the system they're shaping and speak concretely with engineering teams, not through vague tickets that make no sense to whoever picks them up.

A PM who can prototype has a better instrument to validate their thought process with. With AI enabling greater pace of delivery for product and delivery teams, customer judgment has become even more important.

Builder fluency is real leverage

The lazy version of this argument is comforting and wrong: “PMs can ignore code. Stay in the customer lane. Let engineers build.”

Reality is moving the other way.

The Skip interview on Meta product management describes a world where the old long PRD gives way to shorter artifacts: a paragraph, a prototype, and an eval. The product artifact is becoming more executable, more testable, and more tied to judgment.

Lenny describes how top PMs are using AI: AI-forward PMs are using real-code prototypes, conversational data queries, coding agents, evals, and sometimes PRs.

PMs can now ask the codebase a question instead of going to an engineer for the answer, interrogate a data pattern without asking someone to craft the SQL query, use AI to rough out a prototype without needing to wait for UX time. That's the leverage. The shared working surface has changed.

AI now touches every part of the PM job: discovery, data, design, prototyping, and the handoff to engineering. It stopped being a meeting-notes tool a while ago.

AI changed the work. Customers still decide value

Customers still decide value. Markets still move while the team is polishing. Competitors still reset expectations without asking permission.

A beautiful demo still doesn't prove demand.

David Pereira warns that AI amplifies the product system you already have, including feature factories, bloated roadmaps, and performance theater. If a team rewards artifact volume, AI produces more artifacts. If a team rewards delivery, AI makes delivery faster. If a team avoids customers, AI hands them better excuses to keep avoiding customers.

The bottleneck is shifting from producing something to choosing the right thing.

Before AI, bad ideas had friction. They had to fight for design time, engineering time, and roadmapping attention. Now the first artifact can appear so quickly that the team confuses existence with evidence.

Compare AI-enabled PMs with AI-enabled engineers

A lot of the PM-coding conversation makes the wrong comparison: an AI-enabled PM against an old-world engineer.

Engineers use AI too. They move faster through scaffolding, tests, refactors, debugging, documentation, and implementation options. And they still own technical judgment. The architecture, security, reliability, maintainability, data modeling, deployment, observability, cost, and production accountability.

A useful community thread about moving an AI-built internal tool from prototype to dependable work tool makes the production gap painfully concrete. The demo was only the beginning. Real data, hosting, logins, security, maintenance, accountability, and developer involvement still mattered (Reddit).

That's the boundary. AI prototyping can compress learning. It does not remove the need for production ownership.

Taste is disciplined signal selection

The word taste gets abused because it sounds like personal preference.

Product taste is disciplined signal selection: identifying which customer complaint is a symptom and which is the root, hearing different requests and finding the same theme across them, and understanding when a competitor launch changes what buyers expect. It also means knowing when a sales objection is noise and when a rough prototype has answered enough to stop.

Taste says, “The evidence points here, and this is what would change my mind.”

AI helps when you point it at reality. It can summarize transcripts, cluster objections, scan competitors, compare support themes, draft assumption maps, and turn a product question into a prototype people can react to.

At AIStackWorks, faster AI-assisted building made the pre-build decision feel more important, not less. When execution speeds up, planning, ownership, and alignment become the guardrails that keep the wrong idea from becoming executable too quickly.

AI-assisted planning can turn a rough thought into a collaborative, reviewable plan before any build starts. That's powerful precisely because the entire team still needs to challenge the plan, pressure-test the assumptions, and decide whether it deserves engineering attention.

The right workflow moves PMs closer to reality

The constructive version of AI-assisted product discovery starts with a customer conversation.

Use AI to produce the transcript and a first synthesis. Pull patterns across calls, support tickets, sales objections, churn notes, usage data, and market changes. Name the assumption being tested. Build the smallest prototype that makes it visible. Put that prototype in front of customers and the team, then decide what would make you stop, change, or continue. Hand it to engineering only if the evidence says the bet deserves production work.

The point is technical fluency joined to customer backing.

Productboard packages AI around feedback categorization, customer-need summaries, and insight surfacing. Dovetail’s AI docs center on analyzing customer data, generating insights, and answering questions about research and feedback.

The highest-leverage AI workflow for PMs runs from customer signal to synthesis to assumption to prototype to decision.

Product goals have not changed

AI changes the tools around product management.

Product leaders should still prioritize actual insight: what customers are trying to accomplish, which business metrics need to move, which constraints matter, and which bets deserve scarce engineering attention.

The management question is not, “Can our PMs build now?” Better questions sound like this:

1. Which customer signal started this idea?
2. Which core business metric could this improve?
3. What assumption is the prototype meant to test?
4. What evidence would make us stop? change? keep going?
5. Who owns production if the evidence is strong enough?

That last question keeps AI prototyping from turning into shadow production software with unclear accountability.

Give PMs permission to prototype, query data, and inspect code. If they use Claude Code, v0, Lovable, or the prototyping mode inside the team's design tool, the tool should serve the product question. It should not become the proof.

Reward actual insights. Reward clearer customer evidence. Reward a sharper view of how the team can move the metric that matters.

A strong product culture in the AI era asks PMs to become better product thinkers with sharper tools, rather than worse engineers. They should bring engineering a better question, better context, better evidence, and a cleaner handoff.

That's how to excel as a PM in an AI-first world: disciplined AI use, technical fluency in service of learning, taste grounded in evidence, and fewer pretty features nobody needed.

AI should help PMs get closer to customers, markets, and business reality faster.

The best PMs won't hide from reality behind better demos. They'll use AI to make the right bet obvious sooner.