Why I Started Training PMs on This
When I first put together a training program for product managers on AI, most of the room expected a session on prompt engineering — better ChatGPT inputs, a few templates, maybe a tools list. That's not what we built.
Over several cohorts, working closely with a core team of product managers I directly mentor and a wider group across the org, I ended up redesigning something bigger: how AI changes what a PM actually does at every stage of building a product, from the first discovery conversation to a mature product's twentieth iteration.
The resistance was real in the first sessions. Experienced PMs — people who'd shipped products for a decade — were skeptical that a chatbot had anything to teach them about strategy or judgment. That skepticism turned out to be the most useful signal in the room. It meant the training couldn't be about tools. It had to be about how thinking changes when you have a tireless, occasionally brilliant, occasionally wrong collaborator available at every step.
AI won't replace Product Managers. But Product Managers who know how to orchestrate AI will replace those who don't.
Most people use AI as a better search engine. The PMs who got the most out of this training learned to use it as a thinking partner, research analyst, designer, engineer, data scientist, customer interviewer, and strategy consultant — often within the same hour, and always with a human making the final call.
Two Journeys, Different Machinery
The framework splits Product Management into two journeys that require fundamentally different mindsets: 0→1, creating something that doesn't exist yet, and 1→N, scaling and optimizing something that already does. AI shows up differently in each, and one of the first mistakes I saw PMs make was applying 1→N habits — heavy analytics, incremental optimization — to a 0→1 problem that needed speed and disposability instead.
Part 1 — AI Across 0→1
Discovery: Better Questions, Not Faster Answers
Before AI, discovery meant weeks of reading industry reports, running interviews, and scanning competitors by hand. AI compresses the legwork into hours, but only if you ask it the right way. The unhelpful question is "what should we build?" The useful ones are narrower: what problems do customers keep working around, what frustrations show up across unrelated industries, what's expensive today that won't be in three years.
Used well, AI doesn't hand you an answer — it hands you a sharper set of questions to go validate with real people.
Customer Research: AI Prepares, You Still Show Up
AI cannot replace talking to customers, and I say this explicitly in every cohort because it's the assumption newer PMs reach for first. What it can do is make every interview better: generating hypotheses and interview guides beforehand, then summarizing transcripts, clustering recurring pain points, and surfacing contradictions afterward. The job shifts from reviewing fifty transcripts line by line to reviewing AI-generated themes and spot-checking the ones that seem important.
Market and Competitive Research
Comparing competitor pricing, positioning, app store reviews, and public discussion used to take days. AI can pull that together in minutes. The PM's job correspondingly shifts from collecting information to validating it — because AI research is fast and occasionally wrong, and shipping a strategy built on a hallucinated competitor detail is a real risk, not a theoretical one.
Product Strategy: Use AI to Destroy Weak Ideas
This is where AI becomes a genuine sparring partner rather than a research tool. I ask it to argue against my own thinking: why will this fail, who will never buy this, which assumptions are load-bearing, what's the actual moat. The best prompt in this stage is often just "challenge my thinking." Strong PMs don't use AI to confirm ideas they already like — they use it to try to kill the idea before a customer does it for them, more expensively.
Prioritization
AI is useful here for evaluating customer impact, engineering effort, dependencies, and opportunity cost side by side, faster than a PM could alone. It doesn't replace judgment on trade-offs, but it turns solitary prioritization into something closer to debating with several well-informed personas at once.
PRDs: The Smallest Benefit Is the One Everyone Reaches For First
Most PMs' first instinct is to ask AI to write the PRD. That's the least valuable use of it. Where it actually earns its keep is in stress-testing a PRD you've already drafted — surfacing missing requirements, edge cases, failure scenarios, telemetry needs, and gaps in acceptance criteria that are easy to miss when you've been staring at the same document for a week.
Designing for Failure, Not Just Success
This is the stage most AI-for-PM content skips entirely, and it's the one I spend the most time on, because it's where the products I've worked on — real-time speech translation, live communication platforms — actually live or die. An AI feature is not "done" when it works on the demo. It's done when you've defined what happens when it's wrong: what the acceptable failure modes are, when the system should refuse to act rather than guess, and how a user recovers when it does fail. Trust in an AI feature is built through clarity about its limits, not through confidence in its outputs. I've seen more AI features damage user trust through an overconfident wrong answer than through a feature that visibly wasn't ready yet.
Evaluating and Pricing AI Itself
Somewhere between design and engineering sits a decision most AI-for-PM frameworks skip: which model, at what cost, for what accuracy. This is build-vs-buy at the model level — a smaller, cheaper model may be entirely sufficient for a given task, while a frontier model is overkill and expensive at scale. Getting this wrong shows up directly in your infrastructure bill; getting it right is one of the highest-leverage decisions a PM can influence on an AI product, and it's rarely taught because it sits at the boundary of product and engineering economics rather than cleanly inside either.
Engineering Collaboration
You don't need to write code, but AI genuinely helps PMs understand APIs, architecture, scalability limits, and security trade-offs well enough to have a real conversation with engineering instead of a translated one. This alone measurably reduced the back-and-forth in the cohorts I ran — PMs came into engineering reviews asking sharper questions instead of open-ended ones.
MVP Planning
AI helps define the smallest usable version of a product, the assumptions that most need testing, and the metrics that will tell you if the bet worked. The discipline hasn't changed — build only enough to prove or kill the hypothesis — but AI removes a lot of the friction in getting there.
Part 2 — AI Across 1→N
Once a product exists, the job changes completely. Success stops being about discovery and starts being about continuous, disciplined optimization under constraints that get less forgiving as scale increases.
Feedback at Volume
AI turns thousands of support tickets, app reviews, NPS comments, and call transcripts into structured themes — bugs, feature requests, usability friction, performance complaints — far faster than any team could triage manually. The risk is treating the output as ground truth instead of a first pass; I require every cohort to spot-check clusters against raw source before acting on them.
Analytics: Ask "Why," Not Just "What"
A dashboard telling you DAU dropped is not insight. AI is useful for generating hypotheses across funnels, cohorts, retention curves, and feature adoption to explain why — but the PM still validates against real data before acting. AI proposes; the PM disposes.
Prioritization at Scale
With hundreds of requests landing every quarter, AI can score opportunities against RICE, ICE, or Kano and, more usefully, explain why one initiative should outrank another — which turns a prioritization debate into something you can actually defend to stakeholders.
Experimentation
AI accelerates the mechanics of experimentation — writing hypotheses, sizing samples, explaining statistical significance, recommending the next test — which shortens the learning loop considerably. It does not replace the discipline of deciding what's actually worth testing.
Roadmapping as a Decision Model
Rather than a static plan, AI lets you simulate scenarios: what happens if engineering capacity drops 30%, which roadmap sequence maximizes retention instead of revenue. This reframes a roadmap from a document you defend to a model you can interrogate.
Stakeholder Communication
Leadership updates, board materials, release notes, and executive summaries all get faster to draft with AI. The time this saves is only valuable if it gets reinvested in strategy work rather than absorbed into more meetings — a distinction worth being deliberate about.
Governing AI in Production
This is the other stage most frameworks miss, and it matters more the longer an AI feature has been live. Models drift. Data quality feeding a personalization or recommendation loop degrades if nobody's watching it. And in any enterprise or regulated context — which is where a large part of my own career has sat — there's a real governance question underneath all of this: what customer data is going into these tools, under what consent, and who's accountable when a model's behavior changes after an update nobody flagged. Treating this as an ongoing operational responsibility, not a one-time launch checklist, is what separates AI features that stay trusted from ones that quietly erode trust over eighteen months.
Operational Excellence
Meeting notes, action items, documentation, sprint summaries — AI automates the repetitive layer of PM work. The point isn't the time saved in the moment; it's what that time gets reinvested in.
The Biggest Shift Isn't Faster Execution — It's Better Thinking
Most conversations about AI and product management focus on speed. I think that undersells what actually changed in the rooms I trained. Yes, PMs moved faster. But the more durable shift was in the quality of their thinking — sharper challenges to their own assumptions, more alternatives considered before committing, faster fluency in unfamiliar domains, clearer communication of ideas that used to take three drafts.
The research on generative AI in knowledge work increasingly points the same way: the biggest gains aren't from replacing whole jobs, they're from accelerating and sharpening the many individual tasks inside a job — and that gain compounds fastest when the AI is paired with real domain judgment, not used in place of it.
What Changed After the Training
The clearest signal that this worked wasn't a survey score. It was watching PRDs come back from review with fewer missing edge cases, watching PMs walk into engineering syncs with sharper questions instead of open-ended ones, and watching prioritization debates get resolved with a shared framework instead of the loudest voice in the room. None of that shows up in a slide about "AI adoption." It shows up in how the work actually gets done six months later.
The future Product Manager won't compete on who writes the best PRD or builds the prettiest roadmap. They'll compete on who asks better questions, orchestrates AI more deliberately, and makes better calls under uncertainty.
Execution is getting commoditized. Judgment isn't. That's the whole bet behind this training, and it's the reason I keep running it.