PM MasterclassThe future of product management

If Everyone Can Build, What Is the PM's Job?

The Future of Product Management in the AI Era

A practitioner's look at what's changing, what isn't, and what to do about it, told through a real product I built along the way.

Kunal ParekhPrincipal Product Manager, Microsoft

Information Mover
AI-Augmented PM
Builder
Evaluator
Outcome Owner

The questions in the room

Let's Name the Worries First

If you've felt any of these in the last year, you're in good company. Almost every PM I talk to has.

Is product management becoming less important?

Do I need to learn to code now?

Will AI end up doing the work I do?

What should I actually learn next?

The interesting question isn't whether AI replaces PMs. It's which PM capabilities create the most value when building gets cheap.

Ask the roomShow of hands: which one has crossed your mind this month?

~3 min · Claims: Interpretation

Let's be honest about what's in the room.

Some of you are wondering whether product management is becoming less important. If a designer or an engineer can prototype a feature in an afternoon, who needs the person writing the PRD?

Some of you are wondering whether you now have to learn to code.

Some of you are quietly wondering whether AI will end up doing your job, or at least the parts of it you're paid for.

And almost everyone is wondering: what should I learn next?

[ASK THE ROOM: a show of hands for each one. Take a quick read of the room. Don't solve anything yet.]

Here's where I've landed, and it's the doorway for today. I don't think the interesting question is whether AI replaces Product Managers. I think the interesting question is which PM capabilities create the most value once building gets cheap.

Hold on to that. Everything we do today is an attempt to answer it.

Transition: Before we go there, a quick word on who's asking you these questions, and why I care about them.

Your facilitator

Kunal Parekh

Principal Product Manager, Microsoft

I've spent 15+ years in product, shipping big data platforms at Microsoft and at Shell. Lately I also build my own products with AI, mostly to find out where the hype ends and the real work begins.

15+

Years in product

VLDB 2024

Co-author, big data systems research

1 live product

Built hands-on with AI, idea to production

Earlier sessions

How to Create an Impressive PM Portfolio through Vibe CodingBuilding a portfolio with AI, without a dev team From Problem to ProductionA live product-building case study

kunalparekh-portfolio.netlify.app·linkedin.com/in/kp27·bigdata-hub.lovable.app

~2 min

Quick context on me, and then I'll get out of the way.

I'm a Principal PM at Microsoft. A lot of my career has been spent shipping big data platforms, at Shell and at Microsoft. That's the unglamorous plumbing a lot of AI now runs on. I co-authored a VLDB paper in 2024, so I'm comfortable in the technical weeds. But I think like a product person first.

Today is the third conversation in a thread I've been pulling on. In the first session, I showed how I built my PM portfolio by vibe coding, with no dev team and no budget. In "From Problem to Production", we went deep on one product, and how it went from an idea to something live.

Today I want to zoom out. Not "how do I build with AI?", but "what does that do to our job?"

One disclaimer. I'm not here as an AI evangelist. I'm a PM who got curious enough to build, and I'll show you the messy parts along with the nice screenshots.

Transition: Here's how we'll spend our time together.

The next 90 minutes

Five Acts, One Question

We'll go from the big shift, to a real product, to your career. You'll leave with a plan you can start on Monday.

The Wake-Up Call

AI isn't just changing what PMs do.

Information mover

The New Build Loop

It's changing how products get built.

AI-augmented PM

III

Show, Don't Tell

What that looks like when I actually build something.

Builder

The Career Question

So the PM capability model is changing.

Evaluator

What Now?

How to start behaving like that PM today.

Outcome owner

Underneath all five acts, one question: are you using AI, or are you redesigning how you build?

Information mover → AI-augmented PM → Builder → Evaluator → Outcome owner is a way to picture growing capability. Not a ladder, and not job titles.

~2 min

Five acts, one question.

Act One is the wake-up call: AI isn't just changing what PMs do. Act Two: it's changing how products get built, the build loop itself. Act Three is the heart of it. I'll show you what that looks like when I actually build something, including the parts that didn't work. Act Four: so the PM capability model is changing. And Act Five: how to start behaving like that PM today.

You'll notice a small label under each act: information mover, AI-augmented PM, builder, evaluator, outcome owner. That's the thread I'll keep coming back to. It isn't a career ladder, and they aren't job titles. Think of them as capability you can add.

And underneath all five acts sits one question I'd like you to keep asking yourself: am I using AI, or am I redesigning how I build?

There's one exercise, in Act Five, and it takes about eight minutes. So keep a real, annoying, recurring problem from your own work in the back of your mind.

[Set expectations for questions: take them anytime, or hold them for the end.]

Transition: Let's start with what we can actually measure.

Act I · The wake-up call

The Cost of Turning an Idea Into a Prototype Is Collapsing

Notice the wording: the cost of a first version, not the cost of a great product. That difference will matter all day.

55.8%

faster on a scoped coding task with an AI pair programmer, in a controlled experiment

Peng et al., 2023Verified

280×

drop in the price of GPT-3.5-level AI between Nov 2022 and Oct 2024

Stanford AI Index 2025Verified

~25%

of YC's Winter 2025 startups said ~95% of their code was AI-generated

Y Combinator, 2025Verified

2025

"Vibe coding" went from a Karpathy post in February to Collins Word of the Year by November

Collins, 2025Verified

Sources: Peng et al. 2023 · Stanford AI Index 2025 · TechCrunch on YC W25, 2025 · Collins Word of the Year 2025

~4 min · Claims: Verified

Let's start with what we can actually measure.

In 2023, a controlled experiment gave developers an AI pair programmer and one well-scoped task: build a small web server. The AI group finished 55.8% faster. That's verified, but notice it's one narrow task.

The price of intelligence is collapsing too. Stanford's AI Index found that running a GPT-3.5-level model got more than 280 times cheaper in under two years.

In early 2025, Y Combinator said about a quarter of its winter batch had codebases that were roughly 95% AI-generated. These are technical founders who could write the code. They chose not to. It's a self-selected startup cohort, not the whole industry, but it's a strong signal.

And "vibe coding" went from a post by Andrej Karpathy in February 2025 to Collins' Word of the Year by November.

So here's the first half of the thesis. AI is collapsing the distance between thinking and building. The cost of a first version (a prototype, a demo, a working draft) is falling off a cliff.

[Pause.] But I chose those words carefully. First version. Not finished product.

Transition: Because if I only showed you this slide, I'd be doing the hype's job for it. Here's the other side.

Act I · Challenging the thesis

…But Building Faster Isn't the Same as Building Right

Here's the part the hype skips. Real-world results are messy, and the bottleneck is increasingly trust, not typing speed.

19%

slower: experienced open-source developers using AI on their own repos, who believed they were ~20% faster

METR trial, Jul 2025Verified

~30%

of tech professionals have little or no trust in AI-generated output, even though ~90% use AI

DORA, 2025Verified

66%

of developers say their biggest frustration is AI answers that are "almost right, but not quite"

Stack Overflow, 2025Verified

Amplifier

AI magnifies a team's existing strengths, and its dysfunctions

DORA, 2025Verified

Speed is real. So is "almost right." The gap between the two is where PMs earn their keep.

Sources: METR RCT, Jul 2025 · METR update, Feb 2026 · DORA 2025 · Stack Overflow Developer Survey 2025

~4 min · Claims: Verified, Emerging

In July 2025, METR ran a proper randomized trial. Sixteen experienced open-source developers worked on real issues in repositories they knew deeply. With AI, they were 19% slower. And here's the part I love: afterwards, they believed they'd been about 20% faster.

[Pause.] Our sense of speed is not a measurement.

To be fair, METR published an update in February 2026. Developers are probably faster now. But measuring it had become genuinely hard, because 30 to 50% of developers didn't want to do some tasks without AI at all. If METR finds this hard to measure, your team will too. Hold that thought. It comes back when we talk about evaluation.

DORA surveyed around five thousand tech professionals. About 90% use AI, but about 30% have little or no trust in what it produces. In Stack Overflow's survey, two-thirds of developers said their biggest frustration is output that's almost right, but not quite.

And DORA's headline conclusion: AI is an amplifier. Good teams get better. Messy teams get messier, faster.

So here's the refined thesis for today: building got cheap. Being right didn't.

Transition: So building got cheap, and being right didn't. But there's a bigger story underneath both of these slides.

Act I · The bigger shift

From Productivity Tool to Operating Model

Most AI talk is about speed. The bigger question: what happens when AI stops being a tool inside the product process and becomes part of the process itself?

Wave one

AI as a productivity layer

Drafts, summaries, code suggestions. The same process, done faster.

Changes: individual speed

Wave two

AI as a product-development capability

Prototypes, evals and AI features. The build loop itself changes.

Changes: the build loop

Wave three

AI as an operating-model change

Roles, team shapes and career paths get redesigned around AI.

Changes: the organization itself

"Our goal eventually is to empower any builder who has a strong idea to be able to develop it and take it to market, regardless of their product role in the stack."
Tomer Cohen, then LinkedIn's CPO, Jan 2025 · In his words

One company's bet, not yet a pattern: LinkedIn's APM program became Associate Product Builder from Jan 2026. Google and Meta still run APM and RPM.

Sources: Tomer Cohen, LinkedIn Pulse, Jan 2025 · Tomer Cohen on Lenny's Podcast, Dec 2025 · LinkedIn APB program (Business Insider)

~4 min · Claims: Quoted, Emerging, Interpretation

So far we've talked about speed. Building got cheap; being right didn't. But I think there's a bigger story underneath, and it comes in three waves.

Wave one: AI as a productivity layer. Drafts, summaries, code suggestions. The same process, just faster. That's where most teams are, and it's genuinely useful.

Wave two: AI as a product-development capability. Now the build loop itself changes: prototypes before specs, evals as part of the requirement, AI features inside the product. That's Act Two.

Wave three is the one I want you to notice: AI as an operating-model change. Roles, team shapes and career paths get redesigned around it.

LinkedIn is the clearest public example. In January 2025, Tomer Cohen, then LinkedIn's Chief Product Officer, wrote about "full-stack builders": people who can take an idea all the way to market, whatever their role. [Read the quote on the slide.]

And they acted on it. From January 2026, LinkedIn's Associate Product Manager program became an Associate Product Builder program, which teaches coding, design and product management together. On Lenny's Podcast, Cohen described three pillars: the platform, internal agents, and culture. And he said culture matters most: incentives, performance reviews, celebrating early adopters.

Two honest caveats. This is one company's bet, and there's no outcome data yet. Google and Meta still run their APM and RPM programs. And Cohen has since moved on from LinkedIn, which is why I say "then CPO".

[ASK THE ROOM, optional: "Which wave is your company in today?"]

Transition: So if the operating model is shifting, which PM capabilities is it reweighting?

Act I · What's being reweighted

AI Is Changing Which PM Capabilities Matter Most

This isn't "hard skills versus soft skills". AI compresses more of the making, so the boundary moves toward deciding what's worth building.

AI increasingly compresses

Execution
Generation
Analysis
First drafts

PM differentiation shifts toward

Direction
Judgment
Taste
Context
Evaluation
Adoption
Accountability

The PM advantage is not knowing how to produce the most output. It's knowing which output matters.

Ask the roomIf AI can produce more of the work, who decides what good looks like?

Gaining value: the work around the output. Andrew Ng argues that when engineering gets faster, deciding what to build becomes the bottleneck.

Sources: Andrew Ng, The Batch

~4 min · Claims: Interpretation

Here's how I'd describe what's actually shifting. And I'm deliberately not framing it as hard skills versus soft skills. That framing misses it.

The top row is what AI increasingly compresses: execution, generation, analysis, first drafts. The making. It doesn't disappear. It just gets cheaper and faster every quarter.

The bottom row is where PM differentiation shifts: direction, judgment, taste, context, evaluation, adoption and accountability. None of those are tasks. They're decisions, made under uncertainty, with people who disagree with each other.

A small example from the product you'll see in Act Three. It flags some signals as "act now". If it gets one wrong, the system doesn't lose any sleep. I do. That's the difference between producing an output and owning an outcome.

Andrew Ng puts it well: when engineering gets dramatically faster, deciding what to build becomes the bottleneck. So a PM who's close to users and decides well becomes more valuable, not less.

I want to steelman the other side, because it's real. Some companies are hiring fewer PMs per engineer, and at least one AI startup CEO has said early-stage teams don't need PMs at all. If your value was mostly moving documents around, that's a real risk. We'll come back to it in Act Four.

[ASK THE ROOM: "If AI can produce more of the work, who decides what good looks like?" Take one or two answers.]

So: the PM advantage is not knowing how to produce the most output. It's knowing which output matters.

Transition: If that's the shift in what we do, the next question is how products actually get built now. That's Act Two.

Act II · Show, don't just ask

The Prototype Becomes a Research Instrument

Users often can't tell you what they want until they see it. So the prototype becomes another research tool. It doesn't replace research; it gives research something to react to.

Traditional

Research
Requirements
Design
Prototype
Build
Launch

Emerging

Research
Hypothesis
Prototype
Observe
Learn
Refine

Where it's working

New bets, internal tools, early discovery, small teams: anywhere a wrong prototype is cheap.

Where it struggles

Regulated domains, deep platform work, anything irreversible, and orgs where prototypes quietly become production.

Prototype before the PRD, so scientists and engineers react to something tangible, not a description.
Marily Nika, AI product lead at Google · Paraphrased

Sources: Marily Nika on Lenny's Newsletter · Marily Nika with Aakash Gupta

~4 min · Claims: Emerging, Paraphrased

Here's the model most of us grew up with. Research, requirements, design, prototype, build, launch. It's a relay race. The PM runs an early leg and hands over a document.

Here's what's emerging. Research, then a hypothesis, then a prototype, often built by the PM, in days rather than months. Then you watch people use it, learn, and refine. And it loops.

The key idea: users often can't tell you what they want until they see it. So the prototype becomes another research instrument. It doesn't replace talking to users. It gives those conversations something real to react to.

Marily Nika, an AI product lead at Google, describes working this way. She builds a quick prototype before writing the PRD, so the research scientists and engineers she works with react to something tangible rather than a description. That's my paraphrase of how she's described it on Lenny's Newsletter and on Aakash Gupta's podcast.

My own version: in the product you'll see in Act Three, the spec was written thirteen days after the first prototype. The prototype taught me what to specify.

And I want to be careful here. This is emerging, not universal. It works for new bets, internal tools and small teams. It struggles in regulated domains, deep platform work, and anything irreversible. And watch for the classic failure mode, where a weekend prototype quietly becomes production because nobody said no.

[ASK THE ROOM: "Which of these two rows looks more like your team today?"]

Transition: But a prototype only tells you something if you know what "good" looks like. Which brings us to evals.

Act II · Evals are product work

A Requirement Without an Eval Is Incomplete

In AI products, "what good looks like" can't live in your head. If you can't test it, you haven't finished specifying it.

The requirement

"The system should produce a useful competitive-intelligence summary."

"Useful" can't be tested
It will pass the demo
It can quietly get worse when the model changes

The evals that make it real

Finds the changes that genuinely matter
Separates fact from interpretation
Cites evidence for every claim
Avoids duplicates
Makes no unsupported claims
Spells out what to do about it
Stays consistent from run to run

Writing evals is becoming a core skill for product managers.
Kevin Weil, then OpenAI's CPO · Paraphrased

The AI-native flow: intent → spec → eval criteria → prototype → evaluation → iteration → production monitoring.

Sources: Kevin Weil on Lenny's Podcast, Apr 2025 · Hamel Husain, "Your AI Product Needs Evals"

~4 min · Claims: Interpretation, Paraphrased, Prediction

Here's a requirement I could easily have written for my own product: "The system should produce a useful competitive-intelligence summary."

It sounds fine. It'll pass the demo. And it's untestable. What does "useful" mean? And when the model underneath changes, it can quietly get worse without anyone noticing.

Now look at the right. These are the evals that make the requirement real. Does it find the changes that genuinely matter? Does it separate fact from interpretation? Does every claim cite evidence? No duplicates. No unsupported claims. Does it spell out what to do about it? And does it stay consistent from run to run?

Each of those can be checked on real examples, every time something changes. That's all an eval is: almost like a quiz for the model. That's Kevin Weil's analogy, paraphrased. He was OpenAI's Chief Product Officer at the time.

Lenny Rachitsky recounts Weil saying, on a 2024 panel that also included Mike Krieger, then Anthropic's CPO, that writing evals is going to become a core skill for product managers. I'm paraphrasing that too. It's a prediction, not a measurement, but it matches what I've seen.

Hamel Husain, who has helped a lot of teams build AI products, put it bluntly in 2024: "unsuccessful products almost always share a common root cause: a failure to create robust evaluation systems."

So the AI-native flow, at the bottom of the slide, has a new step in the middle. Intent, spec, eval criteria, and only then the prototype. You define good before you build.

[ASK THE ROOM, optional: "Think of one AI feature your team shipped. Could you write down its evals today?"]

Transition: And evals matter even more in AI products, because the ground under them keeps moving.

Act II · A moving substrate

Building on a Moving Substrate

What happens when the technology under your product changes faster than your planning cycle?

Traditional planning asks

What capabilities do we have?

What can we build with today's stack?
What will it cost to build and run?
When can we ship it?

AI-native planning also asks

What's improving fast, and what should we build around or abstract away?

Design around capabilities, not one model
Treat eval sets as lasting assets
Run regression tests on every model change
Re-check quality, cost and latency as models move

The model you're using today is "the worst AI model you will ever use for the rest of your life."
Kevin Weil, then OpenAI's CPO, Apr 2025 · In his words

METR: the length of tasks AI can complete doubled about every 7 months for six years, faster lately. A trend, not a guarantee. Model retirement notice: 6+ months (OpenAI, GA models), 60+ days (Anthropic).

Sources: METR task-length study, Mar 2025 · METR Time Horizon 1.1, Jan 2026 · OpenAI deprecation policy · Anthropic model deprecations · Kevin Weil on Lenny's Podcast, Apr 2025

~3 min · Claims: Verified, Quoted, Interpretation

Here's something genuinely new about AI products. The technology under your product changes faster than your planning cycle.

Traditional planning asks: what capabilities do we have? What can we build with today's stack, what will it cost, and when can we ship?

AI-native planning also asks: what's improving fast, and what should we build around, or abstract away?

Kevin Weil, then OpenAI's CPO, put it memorably on Lenny's Podcast in April 2025: the AI model you're using today is the worst AI model you will ever use for the rest of your life.

There's data behind the feeling. METR measures the length of tasks AI agents can complete, and in March 2025 they found it had doubled roughly every seven months for six years. Their January 2026 update suggests it's been faster since 2023. That's a historical trend with wide error bars, not a guarantee.

And the substrate doesn't just improve. It also gets retired. OpenAI commits to at least six months' notice before retiring generally available models. Anthropic commits to at least 60 days. The model your feature depends on today has an expiry date.

What that means in practice: design around capabilities, not one specific model. Treat your eval sets as lasting assets, because they outlive any model. Run them as regression tests every time the model changes. And re-check quality, cost and latency as things move.

This is also why the evals slide matters so much. Evals are what let you swap the engine without crashing the car.

Transition: So the technology moves under us. What about the strategy work on top of it?

Act II · Strategy work

AI Removes the Blank Page. Not the Editor.

For strategy work, AI gives PMs more raw material, not less responsibility.

What AI hands you

Competitive research and market scans
Trends and patterns across sources
Draft strategies and options to react to
Counterarguments and blind spots to check

What you still do

Decide which problem matters most
Choose what to ignore
Make the trade-offs, and say no
Tell the story people will rally behind
Own the call when it's wrong

AI is useful in the preparation phase of strategy: competitive research, spotting trends, even drafting mock strategies to react to.
Chandra Janakiraman, VRChat's CPO, Jan 2025 · Paraphrased

In my product, the system surfaces the signals. I decide what matters, why it matters, what to do, and what to ignore.

Sources: Chandra Janakiraman on Lenny's Podcast, Jan 2025

~3 min · Claims: Paraphrased, Interpretation

One more shift in how products get built, and it's the one PMs feel first: strategy work.

AI is genuinely good at the preparation. Competitive research. Market scans. Spotting patterns across a pile of sources. Even drafting a few strategies for you to react to. And asking it to argue against your plan is underrated.

Chandra Janakiraman, VRChat's Chief Product Officer and formerly Headspace's, talked about exactly this on Lenny's Podcast in January 2025. AI helps in the preparation phase of strategy, with competitive analysis and trend spotting, and even by generating mock strategies as input. That's my paraphrase.

But notice the word "input". The right-hand column doesn't get any smaller. Deciding which problem matters most. Choosing what to ignore. Making the trade-offs. Telling the story people will rally behind. Owning the call.

Here's how I'd put it, and the blank-page line is mine, not his. AI removes the blank page. It doesn't remove the editor. Your job shifts from writer to editor, storyteller and decision-maker.

In my product, the system surfaces the signals. I decide what matters, why, what to do about it, and what to ignore.

Transition: Enough framing. Let me show you what all of this looked like when I tried it myself.

Act III · Show, don't tell

My Case Study: Big Data Intelligence Hub

I work in a noisy, fast-moving market. Keeping up was quietly eating my week, so I tried to build my way out of it.

The problem

What changed across dozens of vendors, blogs and releases, and does any of it matter to me?

The trap

Collect more information. More feeds, more tabs, more noise.

The real job

Help a product leader see what changed, why it matters, and what to do next.

Big Data Intelligence Hub showing Today's Big Data Brief — Live product · bigdata-hub.lovable.app (sample view)

Observed500+ commits, Apr–Aug 2026Observed28 written plansOwner-reported134 visitors in 3 monthsNot claimedAccuracy, revenue, time saved

~3 min · Claims: Observed, Owner-reported

This is the Big Data Intelligence Hub. I built it, it's live, and I'm going to use it as evidence rather than as a demo.

The problem was mine. As a PM in big data, I need to know what changed across a lot of vendors, open-source projects, blogs and releases. Most of it is noise. Some of it matters a lot. And the important stuff is easy to miss.

The obvious solution is the trap: collect more. More feeds. More tabs. That just moves the noise closer to you.

The insight that shaped everything: the job isn't "collect more information". It's "help a product leader understand what changed, why it matters, and what action may be required".

Let me also be clear about what I'm claiming. The strip at the bottom shows how I'll label evidence for the rest of this act. "Observed" means you can check it in the repo: 500+ commits between April and August 2026, and 28 written plans. "Owner-reported" means analytics I'm sharing honestly: 134 unique visitors in three months. That's small, and I'm not dressing it up. And I'm not claiming accuracy, revenue or time saved. I haven't measured those properly yet.

[Optional: switch to the live site for 60 seconds.]

Transition: How it got here is more interesting than where it is.

Act III · How it found its shape

The Product Found Its Shape by Building

I didn't design version six on day one. Each version answered a question the previous one raised.

What it became

v0Big data news
v1Intelligence hub
v2Live ecosystem
v3Competitive intel
v4Executive intel
v5Action Radar
v6Decision intelligence

What the commit log shows

2 AprLive pipeline and a daily brief, on day one
3 AprDaily email switched off
15 AprProduct spec written, after the prototype
21 AprFreshness rules and tiered sources
28 May"Ask the Hub" AI copilot
AugRadar, decisions and outcomes

Prototype the workflow before you productionize the architecture.

~3 min · Claims: Observed

This is the part I find most interesting, and it's all in the commit history, so it's not a story I'm reconstructing from memory.

Day one was 2 April 2026. I went from mock data to a live pipeline and a daily email brief in a single day. That's the "cost of a prototype is collapsing" slide, in real life.

Day two, I switched the daily email off. [In your own words: why you switched it off.] That was a product decision, and no model made it for me.

Here's my favorite. The product spec was written on 15 April, thirteen days after the first prototype. The prototype taught me what to specify.

Then came freshness rules and tiered sources in April, and an AI copilot, "Ask the Hub", in May. In August came the big shift: from reading about signals to acting on them, with the Action Radar, decisions and outcomes.

Now look at the top row. News, intelligence, ecosystem, competitive, executive, action, decision. Each version moved it closer to the real job: from information toward decisions.

The lesson: prototype the workflow before you productionize the architecture.

Transition: When people see this, they usually ask me: "What was the prompt?" That's the wrong question.

Act III · The honest part

One Prompt Did NOT Build This

People see the screenshot and assume it was magic. Here's what actually went into it. Notice how little of it is "prompting".

Problem selection

A pain I felt every week

User understanding

Who reads this, and when?

Information architecture

Brief, trends, radar, compare

Source selection

Tiered, trusted and fresh

Workflow decomposition

Ingest → filter → score → brief

Signal definition

What counts as "changed"?

Evidence handling

No evidence, no claim

Evaluation

Is this brief actually useful?

Iteration

500+ commits, 28 plans

Human judgment

It recommends; I decide

Reliability

Retries, run logs, fallbacks

Product design

Less reading, more deciding

The prompt was an accelerator. It was not the product strategy.

~2 min · Claims: Observed

[Optional slide: if you're short on time, skip it. The next slide makes the same point.]

Here's the honest ingredient list.

Problem selection. User understanding. Information architecture. Which sources to use, and how much to trust each one. Breaking the workflow into steps. Defining what a "signal" even is. How to handle evidence. How to evaluate. Iteration, five hundred commits' worth. Human judgment. Reliability: retries, run logs, and falling back to the last good snapshot when a source breaks. And product design.

Count how many of those twelve are "prompting". [Pause.] Arguably none. The prompts were how I expressed each of these decisions to the AI.

The AI made me dramatically faster at turning a decision into software. It didn't make the decisions.

So: the prompt was an accelerator. It was not the product strategy.

Transition: Prompts still matter, though. So let's look at what a good one actually contains.

Act III · Prompts are product thinking

Prompting Is Not the Moat. Structured Thinking Is.

Same model, very different products, depending on how well I'd thought before I typed.

Weak

"Build me a big data news dashboard."

You get a generic news page. Pretty, and useless by Tuesday.

Better

"For a data-platform PM: pull posts from these sources daily, summarize them, group them by topic, and show a clean dashboard."

Defines the user, the sources, the output and a basic workflow.

Product-grade

"Score every signal: importance, confidence and the reasons why. Never merge impact and confidence. Drop release notes. If a run fails, fall back to the last good snapshot. Non-goals: billing, SSO."

Adds rules, evidence, edge cases, failure handling and non-goals.

Ask the roomWhich one gives the AI the best chance of building something useful, and why?

The product-grade example is condensed from my real plan documents. The first two are illustrative.

~5 min · Claims: Observed, Illustrative

This is the prompt teardown. [If you're short on time, skip the discussion and just make the point.]

Here are three prompts for the same product.

Weak: "Build me a big data news dashboard." You'll get something. It'll look fine. And you'll stop opening it by Tuesday, because it doesn't know who it's for or what "important" means.

Better: it names the user, the sources, the output and a basic workflow. That's a big improvement, and most people stop here.

Product-grade: this one is condensed from my real planning documents. Explainable scoring with reasons. A rule that impact and confidence are never merged into one number. Release notes filtered out. What happens when a run fails. And non-goals: what we are deliberately not building.

[ASK THE ROOM: "Which one gives the AI the best chance of building something useful, and why?" Take two or three answers.]

Here's the point. Look at what makes the third one better. It isn't clever wording. It's product thinking: users, rules, evidence, edge cases, failure, non-goals. That's a PRD, just written for a machine.

The quality of a prompt largely reflects the quality of the product thinking behind it. Prompting isn't the moat. Structured thinking is.

Transition: But even a product-grade prompt is still just one prompt. The bigger shift was turning it into a system.

Act III · Context is infrastructure

From One Good Prompt to a Repeatable System

The real step change came when the product stopped depending on a single prompt and became a repeatable system.

Ad hoc prompting

Prompt
Output
Tweak
Re-prompt

Context-rich workflow

Prompt
Context
Workflow
Evaluation
Repeatability
Product

In my product

Tiered sources, scoring rules, evidence requirements, quality checks and failure handling, written once and reused on every run.

Across a team

A shared rules folder every AI tool points to, plus reusable instructions that people and agents both use.

Zach Davis, engineering leader at LaunchDarkly · Paraphrased

The future isn't prompt engineering at scale. It's context and workflow engineering at scale.

Sources: Zach Davis on How I AI, Jul 2025

~4 min · Claims: Observed, Paraphrased, Interpretation

Here's the shift that actually changed my product.

The top row is how most of us start. Prompt, output, tweak, re-prompt. It works, but it lives in your head and your chat history. Every run starts from zero.

The bottom row is what it became. The prompt is wrapped in context: tiered sources, scoring rules, what counts as evidence. That sits inside a workflow, with quality checks and failure handling. The workflow gets evaluated. And because it's written down once and reused on every run, it's repeatable. That's when it became a product.

This isn't only for solo builders. Zach Davis, an engineering leader at LaunchDarkly, described on the How I AI podcast how his team moved scattered docs into one shared rules folder in the codebase. Each AI tool's own config simply points back to it. They also write reusable instruction files that people and agents both use. And he noticed that improvements made for humans help the models too. That's my paraphrase.

So the lesson: context isn't something you paste into a chat. It's infrastructure. You build it, version it and maintain it.

The future isn't prompt engineering at scale. It's context and workflow engineering at scale.

Transition: And the biggest structural decision I made was about what the product is actually for.

Act III · Where the value moved

From Information to Decision Intelligence

The first version told me what happened. The useful version helps me decide what to do, and remembers what I decided.

1
InformationArticles, releases, posts
2
IntelligenceFiltered, deduplicated, scored, explained
3
DecisionAct now, watch or ignore, with an owner
4
ActionTracked from open to done
5
OutcomeDid it matter? Close the loop

Action Radar showing prioritized actions with owners and statuses — Action Radar: every signal gets a priority, an owner and a status

The system didn't make the decision. It helped me make, and remember, the decision.

~3 min · Claims: Observed

If I had to name the single biggest product decision, it's this one.

Version one was an information product: here's what happened this week. Useful, and exactly what every newsletter already does.

The value moved when I asked a different question: what is the reader supposed to do with this?

So the product moved up this chain. Information. Then intelligence: filtered, deduplicated, scored, and explained, so I can see why something scored high. Then a decision: act now, watch, or ignore, with an owner. Then an action, tracked from open to done. And finally the outcome: did it actually matter?

That's the Action Radar on the right: a priority, an owner and a status, with a "why" on every card.

The line I keep coming back to: the system didn't make the decision. It helped me make, and remember, the decision.

That's what I mean by AI-augmented judgment, as opposed to AI-replaced judgment.

Remember the blank-page slide? Same thing here. AI gave me more raw material. The hard part was deciding what it was for.

And there's a nice irony in it. I built something to do my information moving, so I could spend my time on decisions.

Transition: Which raises the obvious question: how do I know any of this is actually good?

Act III · Evaluation

What Makes an AI Product Good?

"The demo worked" is not an evaluation. I ended up checking five different layers, and each one can fail on its own.

Layer	The question	How it shows up in my product
Model	Is the output grounded?	Recommendations carry their evidence; missing evidence stays neutral
Task	Did it do the job?	Duplicates removed, release notes dropped, stale items filtered
Product	Do people actually use it?	Visitors, sign-ups, questions asked: small numbers, honestly reported
Business	Is it worth it?	Not proven yet. It isn't monetized, and I say so
Safety & trust	Does it stay in bounds?	Read-only tools, confidence shown separately, graceful fallback

Evaluation isn't one number. Each layer can pass while another quietly fails.

~3 min · Claims: Observed, Owner-reported

Remember the evals slide in Act Two? This is what it looked like in my own product, layer by layer.

How does a PM know whether an AI product is actually good? "The demo worked" is not an answer.

I ended up thinking in five layers, and each one can fail independently.

Model: is the output grounded? In my product, every recommendation carries its evidence. And where there isn't enough evidence, the score stays neutral instead of guessing. That rule is written into the code.

Task: did it do the job? Duplicates removed, release notes filtered out, stale items dropped.

Product: are people using it? The numbers are small, and I'll say them out loud: about 134 unique visitors over three months, a handful of registered users, and a few copilot questions. That's early. That's honest.

Business: is it worth it? Not proven. It isn't monetized, and I don't pretend otherwise.

Safety and trust: the tools I expose to other AI agents are read-only. Confidence is shown separately from impact, never blended into one magic number. And if the pipeline fails, it falls back to the last good snapshot instead of showing garbage.

Remember METR struggling to measure productivity? This is the PM version of that problem. Evaluation is a product skill now.

Transition: And the last layer, safety and trust, deserves its own slide.

Act III · Responsible innovation

Responsible AI: Neither Fragile Nor Stalled

Responsible AI isn't a compliance afterthought. It's a product-quality requirement, and the PM's job is to know which failures matter.

Fragile

Innovation without safeguards

Ships fast, then loses trust with one bad answer.

Stalled

Safeguards without innovation

Nothing ships, so nothing is learned.

Sustainable

Innovation with safeguards

Ships, learns, and earns trust over time.

In my product: source validation, evidence and attribution, uncertainty shown, human review.

Every technology wave brings ways to hurt people, by accident or on purpose. Be conscious of that, and don't panic.
Benedict Evans, technology analyst · Paraphrased

The PM's job: decide which failures matter, design the safeguards into the product, and keep shipping.

Sources: Benedict Evans on Lenny's Podcast, 2026

~3 min · Claims: Observed, Paraphrased, Interpretation

Responsible AI isn't a compliance afterthought. It's a product-quality requirement. I find it easiest to think about with three words.

Fragile: innovation without safeguards. It ships fast, and then one confidently wrong answer undoes months of trust.

Stalled: safeguards without innovation. Every risk review says "not yet", so nothing ships and nothing is learned. The risk doesn't go away. It just moves to whoever does ship.

Sustainable: innovation with safeguards. That's the target, and it's a product design problem, not a legal one.

In my product, it shows up as very ordinary things. Sources are validated. Every claim carries its evidence and attribution. Uncertainty is shown, not hidden. And a human reviews what matters before it becomes an action.

Benedict Evans, the technology analyst, made a point on Lenny's Podcast that I like a lot. Paraphrasing: every wave of technology brings ways to hurt people, deliberately or by accident. You have to be conscious of that, and also not panic.

So the PM's job isn't to make AI risk-free. It's to decide which failures matter, design the safeguards into the product, and keep shipping.

Transition: Let's zoom back out, to your career.

Act IV · The career question

From Information Mover to Product Builder

As AI moves more information for us, the relative value of moving it may decline. Decline, not disappear.

The information mover

Relays updates between teams
Turns meetings into documents
Tracks status and chases owners
Summarizes what others found

The product builder

Frames the problem worth solving
Turns intent into something testable
Defines what good looks like
Owns the outcome, not the handoff

Move decisions. Move outcomes. Move products forward.

Ask the roomIf AI can move information for us, what should PMs move instead?

Framing paraphrased from Nikhyl Singhal. A split market: 7,300+ open PM roles (most since 2022), but big-tech hiring is ~25% below 2019 and tilts to engineering.

Sources: Nikhyl Singhal on Lenny's Podcast · Lenny's Newsletter, PM job market, early 2026 · SignalFire State of Talent 2026

~4 min · Claims: Interpretation, Prediction, Verified

Here's the career question in its sharpest form.

Nikhyl Singhal, a former product leader at Meta, Google and Credit Karma and the founder of Skip, framed it on Lenny's Podcast in a way that stuck with me. Paraphrasing: a few years ago, a product leader's day was largely moving information around. That's exactly the part AI is getting good at. And the people who love building are going to have the time of their lives.

On the left is the information mover. Relaying updates between teams. Turning meetings into documents. Tracking status and chasing owners. Summarizing what others found. All useful. And all things AI is getting better at every quarter.

On the right is the product builder. Framing the problem worth solving. Turning intent into something testable. Defining what good looks like. Owning the outcome, not the handoff.

Notice what I'm claiming, and what I'm not. The relative value of moving information may decline. Decline, not disappear. Somebody still has to align people. It just stops being the whole job.

What does the market say? It's bifurcating. Lenny's analysis of TrueUp data in early 2026 counted more than 7,300 open PM roles at tech companies globally, the most since 2022, and trending up. But SignalFire's 2026 talent report has big-tech hiring about 25% below 2019, with engineering holding up better than product. Both are true at once. The demand is real, and it's shifting toward people who can build.

[ASK THE ROOM: "If AI can move information for us, what should PMs move instead?"]

My answer: move decisions. Move outcomes. Move products forward.

Transition: So what does growing into that look like? Not as job titles, but as capabilities.

Act IV · Capabilities, not titles

Five Capability Shifts, Not Five Job Titles

The labels running along the bottom of these slides are capabilities you can add, in any order, at any level. Most PMs will mix several.

How PM capability grows

Information moverGathers, summarizes, routes
AI-augmented PMSame job, done faster with AI
BuilderTurns intent into working prototypes
EvaluatorDefines and checks what good looks like
Outcome ownerOwns results, risk and adoption

Not a ladder

You can be a strong evaluator before you ever build. Skip steps, mix them, come back.

Titles are still forming

AI PM, product builder, product engineer: names vary by company. The appendix maps the common ones.

One distinctive AI PM skill: translating frontier technical capability into understandable, trustworthy, useful product experiences.

Ask the roomWhere are you on this line today, and which step is next?

~3 min · Claims: Interpretation, Emerging

Let me pull the thread together. All session, there's been a small label running along the bottom of the slides: information mover, AI-augmented PM, builder, evaluator, outcome owner.

These are five capability shifts, not five job titles. And it's not a ladder. You can be a superb evaluator before you ever build anything. Plenty of great PMs will never want to be builders, and that's fine.

Information mover: gathers, summarizes and routes. Still useful, but increasingly what AI does well.

AI-augmented PM: the same job, done faster and better with AI. Most of us are here today, and it's a fine place to start.

Builder: turns intent into a working prototype, with real data.

Evaluator: defines what good looks like, and checks it. That's the evals slide from Act Two.

Outcome owner: owns the results, the risks and the adoption, not just the launch.

The titles are still forming. You'll hear AI PM, product builder, product engineer, and more. The appendix maps the common ones to these shifts.

If I had to name one distinctive AI PM skill, it's this: translating frontier technical capability into product experiences that are understandable, trustworthy and useful. That framing is mine. Marily Nika's work at Google, bridging research scientists and product, is a good picture of what it looks like in practice.

[ASK THE ROOM: "Where are you on this line today, and which step is next?"]

Transition: Now let's be honest about where you and your team actually are.

Act V · Where are you, really?

Using AI vs. Redesigning Work Around It

Most teams are using AI. Far fewer have redesigned how they work around it. Here's a simple way to tell the difference.

Level	What it looks like	An example
AI as a tool	Individual productivity	Where most of us started
AI as a workflow	A repeated task, redesigned around AI	My daily big data brief
AI as a team capability	Shared context, rules and reusable workflows	LaunchDarkly's shared agent rules
AI as a product capability	AI built into a product people use	My product's scored signals and MCP tools
AI as an operating model	The org changes how products get built	LinkedIn's full-stack builder pods

Are you using AI, or are you redesigning how you build?

Ask the roomWhich level is your team at? Which level are you at?

A thinking tool, not a benchmark. Teams in one company sit at different levels, and you don't need the top level to create real value.

~3 min · Claims: Interpretation

Before the exercise, a quick, honest self-check. Most teams are using AI. Far fewer have redesigned how they work around it.

Level one: AI as a tool. Individual productivity: drafting, summarizing. That's where most of us started.

Level two: AI as a workflow. A repeated task, redesigned around AI. For me, that was the daily big data brief.

Level three: AI as a team capability. Shared context, rules and reusable workflows. Remember LaunchDarkly's shared rules folder? That's this level.

Level four: AI as a product capability. AI built into something people actually use. In my product, that's the scored signals, and the MCP tools other AI agents can call.

Level five: AI as an operating model. The organization changes how products get built. LinkedIn's full-stack builder pods are the public example.

This is a thinking tool, not a benchmark. Different teams in the same company sit at different levels. And you don't need to reach level five to create real value.

[ASK THE ROOM: "Which level is your team at? Which level are you at?" Often the honest answer is: a level ahead of my team, or a level behind it.]

The question underneath all of it: are you using AI, or are you redesigning how you build?

Transition: Let's make that concrete, with your own work.

Act V · Your turn · 8 minutes

Automate, Augment, or Leave It Human?

Pick one recurring problem from your own work, something real that annoys you every week. Fill in the canvas, then make the call.

User

Who has this problem?

Problem

What exactly goes wrong?

Frequency

Daily, weekly, quarterly?

Current workflow

How is it done today?

Pain

Time, errors or frustration?

Available data

What could AI actually see?

AI capability

Summarize, classify, draft or act?

Human decision

What must a person still own?

Success metric

How would you know it worked?

Biggest risk

What happens when it's wrong?

So: should you automate this, augment it, or leave it human?

Ask the roomSix minutes to fill it in, then two minutes to swap with a neighbor and challenge each other's call.

~10 min

Your turn. This is the one exercise today, so let's make it count.

Pick one recurring problem from your own work. Not a moonshot. Something that annoys you every week: status reports, triage, synthesizing customer feedback, preparing for a review.

Fill in the ten boxes. [Walk through them quickly.] Pay special attention to number 8, the human decision that remains necessary, and number 10, what happens when it's wrong.

Then make the call: automate, augment, or leave it human.

Automate means AI does it end to end, and a human checks occasionally. Augment means AI does the heavy lifting, and a human decides. Leave it human means the judgment, the trust or the relationship is the whole point.

[Timer: six minutes solo or in pairs, then two minutes to swap and challenge each other's call. Then take three volunteers.]

Debrief questions. Who chose "automate"? What's your success metric? Who chose "leave it human", and why? Notice how often the answer is "augment". That's usually the right call.

Transition: Now let's turn that into a plan.

Act V · What now

Ask, Learn, Do: Your 30 / 90 / 365-Day Plan

Practical, not motivational. Each step leaves you with something you can show, not just something you read.

30 days

Ask and identify

Ask for one real AI problem on your team, and tell your manager you want to grow this capability.

Show: one meaningful problem, and why it matters.

90 days

Learn and build

Learn context, evals and data by building something real, then evaluating it honestly.

Show: the prototype, 20 test cases, and what failed.

365 days

Do and own

Do the job before you have the title: own an AI-enabled product outcome.

Show: a metric that moved, and a case study you can share.

Don't wait for the AI PM role to appear. Start demonstrating the behaviors of one.

~4 min · Claims: Interpretation

Three horizons, and each one leaves you with an artifact, not just a feeling. I think of it as ask, learn, do. That's my own framing, nothing official.

30 days: ask. Don't wait for someone to hand you an AI project. Ask for one real AI problem on your team. Use the one from the exercise if it holds up. And tell your manager you want to grow this capability. At the end, you should be able to show one meaningful problem, and why it matters.

90 days: learn, by building. Not by collecting certificates. Learn context, evals, data and responsible AI by making one meaningful prototype with real data, and then evaluating it. Twenty test cases. An honest list of what failed. That list is worth more than the demo.

365 days: do. Do the job before you have the title. Own an AI-enabled product outcome, with a metric attached, and write it up as a case study you can share, sanitized if you need to.

Notice the pattern. Every step is about building, testing and learning.

And the line I'd like you to remember: don't wait for the AI PM role to appear. Start demonstrating the behaviors of one.

Transition: Let me leave you with one question.

Closing

What Will You Build That You Couldn't Build Before?

The future of product management isn't about competing with AI at producing output.

It's about getting better at choosing outcomes, framing problems, providing context, evaluating systems, and turning intent into responsible products.

So: are you using AI, or are you redesigning how you build?

Your 30-day challenge

Ask for one real AI problem on your team. Rebuild one workflow around it. Share what you learned, including what broke.

Kunal ParekhPrincipal Product Manager, Microsoft

kunalparekh-portfolio.netlify.app·linkedin.com/in/kp27·bigdata-hub.lovable.app

~2 min

Let's go back to where we started. What happens to Product Management when almost anyone can build?

Here's my answer. The future of Product Management isn't about competing with AI at producing output. You'll lose that race, and you should.

It's about becoming better at choosing outcomes, framing problems, providing context, evaluating systems, and turning intent into responsible products.

So don't ask yourself, "How do I compete with AI?"

[Pause.]

Ask: am I using AI, or am I redesigning how I build? And what can I now build, test and learn that I couldn't before?

Your 30-day challenge: ask for one real AI problem on your team. Rebuild one workflow around it; the one from the exercise is perfect. Share what you learned, including what broke. Tag me; I'd genuinely love to see it.

Thank you. [Open for questions.]

Appendix · Technical fluency

Just Enough Technical Fluency

Not a technical course. Just the concepts that change product decisions.

Concept	In plain language	Why a PM cares
LLM	A model that predicts likely text, code or answers	Powerful, but a probability engine, not a database
Context	Everything the model can "see" when it answers	Better context beats cleverer prompts
Grounding / RAG	Fetching real sources and answering from them	Your main defense against confident nonsense
Tools & MCP	Letting AI call your systems through a standard interface	Answers become actions, so permissions matter
Agents vs. workflows	The model picks the steps vs. you fix the steps	Start with workflows; earn your way to agents
Evals	Test sets that check whether AI output is good	Acceptance criteria for AI features
Hallucination	Fluent output that simply isn't true	Design for it: show sources, allow correction
Guardrails & human-in-the-loop	Limits, plus a person approving what matters	Where accountability actually lives
Cost, latency & drift	What it costs, how fast it is, how it changes	The unglamorous half of "production"

Appendix · Evidence ledger

What the Evidence Says, and How Sure We Are

Claim	Source	Status
Scoped coding task finished 55.8% faster with an AI pair programmer	Peng et al., arXiv 2302.06590 (2023)	Verified
GPT-3.5-level inference cost fell 280× (Nov 2022 to Oct 2024)	Stanford AI Index 2025	Verified
~25% of YC W25 startups: ~95% AI-generated code	Jared Friedman (YC) via TechCrunch, Mar 2025	Verified
Experienced OSS developers 19% slower with AI, but felt ~20% faster	METR randomized trial, Jul 2025	Verified
Likely faster by early 2026, but uplift is getting hard to measure	METR update, Feb 2026	Emerging
~90% use AI; ~30% have little or no trust; AI acts as an amplifier	DORA State of AI-assisted Software Development 2025	Verified
84% use or plan to use AI; 46% distrust accuracy; 66% cite "almost right"	Stack Overflow Developer Survey 2025	Verified
Length of tasks AI can finish doubled ~every 7 months for 6 years	METR, Mar 2025; Time Horizon 1.1, Jan 2026	Verified
Retirement notice: 6+ months (OpenAI GA models), 60+ days (Anthropic)	OpenAI and Anthropic deprecation pages	Verified
7,300+ open PM roles globally, the most since 2022	TrueUp data via Lenny's Newsletter, early 2026	Verified
Big-tech hiring ~25% below 2019; product lags engineering	SignalFire State of Talent Report 2026	Verified
Fewer PMs per engineer at some firms; "no PMs" at some startups	Business Insider reporting, 2025	Emerging

Sources: Peng et al. 2023 · Stanford AI Index 2025 · TechCrunch on YC W25, 2025 · METR RCT, Jul 2025 · METR update, Feb 2026 · DORA 2025 · Stack Overflow Developer Survey 2025 · METR task-length study, Mar 2025 · METR Time Horizon 1.1, Jan 2026 · OpenAI deprecation policy · Anthropic model deprecations · Lenny's Newsletter, PM job market, early 2026 · SignalFire State of Talent 2026

Appendix · Voices

Who Said What, and How This Deck Uses It

Named voices are perspectives, not proof. Here's how each one is used.

Voice	What we use	Where	Status
Tomer Cohen	"…empower any builder who has a strong idea…"	LinkedIn Pulse, Jan 2025	Quoted
Kevin Weil	Today's model is "the worst AI model you will ever use"	Lenny's Podcast, Apr 2025	Quoted
Kevin Weil	Writing evals becomes a core PM skill	Lenny's Podcast; 2024 panel with Krieger	Prediction
Marily Nika	Prototype before the PRD, so experts react to it	Lenny's Newsletter; Aakash Gupta's podcast	Paraphrased
Zach Davis	One shared rules folder that every AI tool uses	How I AI, Jul 2025	Paraphrased
Chandra Janakiraman	AI helps prepare strategy, even drafts mock ones	Lenny's Podcast, Jan 2025	Paraphrased
Benedict Evans	Every tech wave brings harms; be conscious, don't panic	Lenny's Podcast, 2026	Paraphrased
Andrew Ng	Deciding what to build becomes the bottleneck	The Batch	Paraphrased
Nikhyl Singhal	Information moving fades; builders thrive	Lenny's Podcast	Prediction
Kunal Parekh	Waves, maturity levels, Ask / Learn / Do	This deck	Interpretation

Quoted: their exact words. Paraphrased: our wording of a documented point. Prediction: a view of the future, not a measurement. Roles as of the source date.

Backup slide. If anyone asks "did they really say that?", this is the answer.

Quoted means their exact words, and those carry quotation marks on the slides. Paraphrased means my wording of a point they've documented. Prediction means a view about the future, not a measurement.

Roles are as of the source date. Kevin Weil was OpenAI's CPO when he said this, and has since moved on. Tomer Cohen was LinkedIn's CPO, and has also since moved on. Mike Krieger, then Anthropic's CPO, was on the 2024 panel, but I don't quote him.

Two things I deliberately didn't use. "Context is king" is a popular line, but I couldn't trace it to any of these voices. And Nikhyl Singhal has a memorable phrase about what happens to information movers; I use his framing, not his phrase.

Where a framework is mine, like the three waves, the maturity levels, or Ask, Learn, Do, I say so.

Appendix · Emerging titles

The Titles You'll Hear, and What They Emphasize

Titles are still forming, and they vary by company. Read them as emphasis, not a standard.

Title	What it emphasizes	Closest capability shift
AI Product Manager	Shipping AI features: model behavior, data, evals and trust	Evaluator
AI Product Builder	Going from problem to working AI prototype, fast	Builder
Product Engineer	An engineer who owns product decisions end to end	Builder
Forward-Deployed Product Engineer	Building alongside customers, inside their workflows	Builder
Agent Experience PM	Designing products that AI agents can use well	Builder
AI Evaluation PM	Defining quality, test sets and launch readiness	Evaluator
Responsible AI Product Leader	Safeguards, governance and trust across products	Outcome owner
Product-oriented MTS	A technical staff role at an AI lab, with product scope	Builder
Founder-style PM	Owning the whole problem, from idea to adoption	Outcome owner

Only the builder signal is clearly documented, via LinkedIn's Associate Product Builder program. The others are emerging labels, used differently by each company.

Sources: LinkedIn APB program (Business Insider)

Appendix · What to grow

The AI-Native PM Capability Stack

Five capabilities. You don't need to be an expert in all five, but you should know where you stand on each.

Capability	The question it answers	Learn next
Product judgment	Am I solving the right problem, with the right trade-offs?	Write down the decision you want to enable before you write a prompt
AI fluency	Do I know what AI can and can't do?	Learn context, grounding, tools and agents at a PM level
Building fluency	Can I turn intent into something testable?	Ship one working prototype with real data
Evaluation & trust	Can I tell whether it actually works?	Write 20 test cases before you demo anything
Outcome leadership	Can I turn experiments into real outcomes?	Tie one AI bet to a metric your leaders already care about

Beginner and advanced behaviors for each capability are on the next slide.

Backup slide. Here's the model I'd use to think about your own growth. Five capabilities, deliberately simple.

Product judgment: are you solving the right problem, with the right trade-offs? What to learn next: before you write a prompt, write down the decision you want to enable.

AI fluency: do you understand what AI can and can't do? Not how to train a model, but what context, grounding, tools and agents mean for your product. There's a one-page glossary in the appendix.

Building fluency: can you turn intent into something testable? Ship one working prototype with real data. Not a mockup. Something that can fail.

Evaluation and trust: can you tell whether it works? My favorite habit is to write 20 test cases before you demo anything.

Outcome leadership: can you turn experiments into outcomes? Tie one AI bet to a metric your leaders already care about.

Notice the order. Judgment is on top, because every other layer amplifies it, for better or worse. Remember DORA's word: amplifier.

Appendix · Capability matrix

What Good Looks Like, From Beginner to Advanced

Capability	Beginner	Advanced	Common misconception
Product judgment	Starts from the tool or the solution	Starts from the decision the user needs to make	"AI will tell me what to build."
AI fluency	Uses chat for drafts and summaries	Knows when to use retrieval, tools, or no AI at all	"A better prompt fixes everything."
Building fluency	Clickable mockups	Working prototypes with real data and failure handling	"A demo is a product."
Evaluation & trust	"Looks good to me"	Test sets, error analysis, uncertainty shown to users	"Quality is one accuracy number."
Outcome leadership	Ships AI features	Moves a metric that matters, and owns the risk	"Adoption equals value."

Appendix · Case study evidence

What I Can Show, and What I Don't Claim

The rules I used for the Big Data Intelligence Hub story, so you can hold me to them.

Observed

In the repo and live product

500+ commits, April to August 2026
28 written plan documents
Ingest → filter → dedupe → score → summarize → trends
Scores carry importance, confidence and reasons
4 read-only MCP tools for other AI agents
Retries, run logs, last-good-snapshot fallback

Owner-reported

From product analytics

134 unique visitors and 252 page views, 28 May to 28 Aug 2026
29 Jul to 28 Aug: 80 visitors, 7 registered, 3 active
8 copilot questions, 5 bookmarks
85% bounce rate: early, small, and honest

Not claimed

What I haven't measured

Accuracy or precision benchmarks
Time saved for users
Revenue or business impact
Adoption beyond a small early audience