How is the product manager job changing?

The biggest change is between doing the same job faster and rebuilding how the job works. Doing it faster saves time but leaves decisions the same. Rebuilding it changes what a product manager knows before a decision, what they notice between decisions, and how quickly they find out they were wrong.

How should product managers use AI?

Rather than using AI to speed up each task on its own, rebuild one part of the job around it. Good starting points are a single context file your tools read first, a weekly review of calls and tickets against open questions, building several options before deciding, and a written signal that tells you when a shipped decision is going wrong.

What is a context file for product managers?

A context file is one document your tools read before anything else. It records every decision, why it was made, and what would reopen it. It means each new task starts from what you already know instead of from zero, and it keeps your reasoning visible from one decision to the next.

Will AI replace product managers?

The better question is what the job looks like for the people who adapt. As the comic puts it, you won't lose your job to a tractor, but to a horse who learns how to drive a tractor. The product managers who rebuild how the work is done change what they can see before a decision, which is different from simply doing the old job faster.

Where should a product manager start rebuilding their workflow?

Start with the thing you explain from scratch every time, such as the background you paste into every chat or repeat in every meeting. Put it in one file your tools read first, including past decisions and what would reopen them. Once that works, add the next part: weekly review, exploring options, or a signal that tells you when you're wrong.

Rebuild the Product Manager Job, Don't Just Do It Faster

1

The full infographic, as a PDF

The exact one from the post, sized to print or keep within reach.

2

A copy in your inbox

The download link lands in your email too, so it's there when you need it. No follow-up campaign.

3

The Product System, weekly

My note on leading product in the AI era. One idea a week that compounds. Unsubscribe anytime.

There are two ways to change how you do a job. You can do the same job faster. Or you can rebuild the job itself.

In product management, that choice is being made right now, mostly without anyone noticing they're making it. Of the product managers I see using AI, 9 in 10 are doing the same job faster. The best are rebuilding the job. That's my own observation, not a survey, but the gap between the two groups is easy to spot once you know what to look for.

The comic that goes with this piece puts it in farm terms. A farmer tells his horse: "You won't lose your job to a tractor, but to a horse who learns how to drive a tractor." The tractor was never the point. The point is what the horse does with it.

One question separates the two groups

The gap between them isn't tools or prompts. Both groups have the same tools. Both can write a decent prompt.

It comes down to one question. Did you rebuild the job, or just speed it up?

Speeding it up means the work looks the same, it just takes less time. Rebuilding it means the work itself changes: what you know going into a decision, what you notice between decisions, and how you find out you were wrong.

Faster is useful. Rebuilt is a different job.

What doing the same job faster looks like

Here are four things the first group is still doing.

Starting every task in a blank chat. The answer only knows the context you remembered to paste.

Summarising each call, ticket and review separately. The notes are cleaner, but the connections between them stay hidden.

Choosing one answer, then using AI to write the PRD. The document is better. The decision inside it is just as untested.

Watching dashboards without deciding what should trigger action. The numbers move, but the plan does not.

None of that is lazy. It is the job we were all trained to do. Every one of those habits made sense before, and each one now runs a little faster. That first list saves you time. The next one changes what you can see before every decision.

It remembers

Now: every chat starts from zero, and you paste the background in again. The quality of the answer depends on what you happened to remember that morning.

Instead: keep one file your tools read first. Every decision, why it was made, and what would reopen it.

That file does something a faster chat can't. It carries your reasoning from one decision to the next, so the context you built last month is still there when the next question arrives. It also makes your decisions visible to you in a way a pile of chats never will.

The job stops starting from zero.

It notices

Now: research is a project you schedule, so your picture of the customer is a quarter old by the time you use it.

Instead: every week, read last week's calls, tickets and reviews against your open questions.

The shift is from research as an event to research as a habit that runs in the background. You're no longer asking "what did we learn in that study?" You're asking "what changed this week about the things we haven't decided yet?" The open questions do the filtering, so the signal arrives while it can still change a decision.

A picture of the customer that updates weekly is a different job from one that updates quarterly.

It explores before it decides

Now: one option, written up and defended.

Instead: build three versions before the decision, so you learn which assumption breaks first.

This is the one that changes the most. When exploring an option was expensive, picking one early and defending it was reasonable. When you can build rough versions of three options cheaply, the decision moves later and gets better evidence. You stop arguing about which idea is right and start watching which assumption fails.

Defending one option is a writing job. Comparing three is a product job.

It corrects itself

Now: you ship, and nothing is written down about what would prove you wrong.

Instead: write down the number that would prove you wrong before you ship. Then have something watch it and tell you when it moves.

This turns a dashboard from something you look at into something that looks for you. The hard part isn't the monitoring. It's deciding, before launch, what result would change your mind. Once that's written down, being wrong stops being a surprise in a quarterly review and becomes a signal you act on the week it shows up.

A plan that knows what would break it can change before it's too late.

Start with one part of the job

You do not need more AI. You need one part of the job rebuilt around it.

The four rebuilds above work together, but you don't have to do them all at once. Pick one. The easiest place to start is the thing you explain from scratch every time: the background you paste into every chat, the context you repeat in every meeting, the reasoning behind decisions that only lives in your head.

That's what the first rebuild, the one file your tools read first, is for. Build it once and every decision after it starts from what you already know, instead of what you remembered to mention.

The Context File template is in the Vault and walks you through building yours.

Download the one-page version and keep it where you plan the next rebuild.

Questions people ask

How is the product manager job changing?: The biggest change is between doing the same job faster and rebuilding how the job works. Doing it faster saves time but leaves decisions the same. Rebuilding it changes what a product manager knows before a decision, what they notice between decisions, and how quickly they find out they were wrong.
How should product managers use AI?: Rather than using AI to speed up each task on its own, rebuild one part of the job around it. Good starting points are a single context file your tools read first, a weekly review of calls and tickets against open questions, building several options before deciding, and a written signal that tells you when a shipped decision is going wrong.
What is a context file for product managers?: A context file is one document your tools read before anything else. It records every decision, why it was made, and what would reopen it. It means each new task starts from what you already know instead of from zero, and it keeps your reasoning visible from one decision to the next.
Will AI replace product managers?: The better question is what the job looks like for the people who adapt. As the comic puts it, you won't lose your job to a tractor, but to a horse who learns how to drive a tractor. The product managers who rebuild how the work is done change what they can see before a decision, which is different from simply doing the old job faster.
Where should a product manager start rebuilding their workflow?: Start with the thing you explain from scratch every time, such as the background you paste into every chat or repeat in every meeting. Put it in one file your tools read first, including past decisions and what would reopen them. Once that works, add the next part: weekly review, exploring options, or a signal that tells you when you're wrong.