The product manager, before and after

Executive summary

• The old job was an allocator. When engineering time was the scarce resource, the PM decided what got built and coordinated the people who built it. The PRD was a rational way to reduce risk, and the PM’s authority came from being the only one who could see the whole picture.
• Three supports were removed. Showing an idea no longer needs an engineer, synthesis takes an hour instead of a week, and experiments cost an afternoon. The coordination half of the job is dissolving because the friction that required it is gone.
• The decision half got harder. There are more options and less time for each. Products became non-deterministic, and new risks arrived: cost, safety, data handling and the confidently wrong answer.
• The job now. Own the bet, not the ticket. Define “good” for probabilistic systems, show rather than describe, edit rather than author, carry the new risks, and be accountable for the outcome.
• What didn’t change. Saying no, sitting with customers, writing clearly, organizational politics and domain knowledge all survived. Some of them matter more now.

The first definition still describes a real job, but it’s now the junior one. The senior seats go to people who can point to a bet, the evidence behind it, what they built to test it and what the number said afterward.

I’ve carried the title “product manager” or some variant since 2013. For most of that time, if you’d asked me what the job was, I’d have given you the textbook answer without pausing. Intersection of business, technology, and user experience. Valuable, usable, feasible, viable. CEO of the product, except without any of the authority.

Somewhere in 2024 that answer stopped being true, and the job underneath it began changing faster than the textbooks did.

This is the long version of what changed. Not the LinkedIn version — “AI is transforming product management, here are five tips” — but the mechanics: what the old job was built on, which supports were removed, what’s left standing, and why the same title now describes two different jobs at two levels of seniority.

I’m writing it partly to be useful and partly to work it out on paper. I know the first job from the inside, and this is my map of the second one.

Part one: what the job was, and why

The textbook

The standard definition of product management settled in the 2000s and held for about fifteen years. The PM sits at the intersection of business, technology, and user experience, and decides what to build and why.

BusinessTechnologyUser experiencePM

Marty Cagan gave it the risks (three in the 2008 Inspired, four by 2017), and they were good: a product must be valuable (people will pay or use), usable (they can figure it out), feasible (we can build it), and viable (it works for the whole business: sales, legal, brand). Discovery meant retiring all four before committing engineering time. Ben Horowitz gave it the aspiration — “CEO of the product” — which was always more flattering than accurate, since a CEO can fire people and a PM can barely get a design review scheduled.

Every PM course for fifteen years was a variation on those two sources. Every interview loop tested them. Every job description reshuffled the same nouns: roadmap, backlog, stakeholders, discovery, metrics.

The economics underneath

But definitions aren’t what makes a job. What makes a job is scarcity — what resource is limited, and who is trusted to allocate it.

Before AI, the scarce resource was engineering time. Building software was expensive and slow, and it needed people who were hard to hire. A team of six engineers cost seven figures a year. Every week they spent building the wrong thing was a week you couldn’t get back.

So the organization needed someone to make sure that resource wasn’t wasted: someone who would find out what customers needed, argue it against what the business required, check it against what was technically possible, and write it down clearly enough that six expensive people could build it without guessing.

That’s the product manager. Not “visionary.” Allocator of a scarce resource, and preventer of waste.

Everything else about the role follows from that one fact.

Why the PRD existed

If engineering time is expensive and mistakes are costly, you specify before you build. That’s not bureaucracy — it’s rational. The PRD was a tool for reducing risk. Writing it took three days; building the wrong thing took three months.

The document’s structure encoded that logic. Background, so engineers understood why. Requirements, so scope was fixed before the estimate. Acceptance criteria, so “done” was unambiguous. Edge cases, so the expensive people didn’t discover them at the end. Non-goals, so the scope didn’t creep.

The PRD was a prediction, written in prose, about a thing that didn’t exist, by someone who couldn’t build it, for people who could. It worked about as well as that sounds: imperfectly, but better than nothing.

Why the PM had authority

The PM’s authority was never formal. It came from information position. Three groups held different kinds of knowledge and rarely spoke each other’s language:

• Engineers knew what was possible and what it would cost.
• Designers knew what users could understand.
• Executives knew what the business needed and controlled the budget.

The PM was the only person in the room who held enough of all three to make a coherent decision — and the only person whose full-time job was to write that decision down in a form everyone could act on.

That’s an unusual kind of power: authority not over people but over coherence. You were trusted because you were the only one who could see the whole thing at once.

What the job actually looked like, day to day

Strip away the aspirational language and the pre-AI PM’s week looked like this:

I’d estimate that half to two-thirds of that was coordination — moving information between people who couldn’t or wouldn’t move it themselves.

• At least
• Up to

Coordination 50–67%

The essay’s estimate: somewhere between half and two-thirds of the week.

The numbers

Part of the week	Share
Coordination	50–67%
Everything else	33–50%

In one sentence: the person who decides what gets built, and coordinates the people who build it.

Hold on to the “and.” The whole argument that follows is about what happened to each half.

Part two: what happened, 2022 to 2026

The timeline, honestly

ChatGPT launched in November 2022, and it’s tempting to draw a straight line from there. The line isn’t straight.

1. 2022–2023

   A crash that wasn’t about AI

   The post-COVID tech bubble burst at almost exactly the same moment. Layoffs peaked in 2023 with more than a quarter of a million people affected, and PM openings hit their low. Most of it was overhiring correcting itself.

   But the timing meant AI took the credit, or the blame.

2. 2024

   The composition changed

   Hiring recovered, but not uniformly. The growth went mostly to senior roles, and more listings began to ask for hands-on AI experience.

   The year “traditional PM” started to cost something as a label.

3. 2025

   Usage went universal, power moved up

   In the teams I worked with, first drafts of specs, research synthesis and status updates started coming from a model. And — the part people skip — product teams got less empowered. According to a survey of nearly 400 product people, senior leadership was setting product strategy more often than a year earlier, and output measures like “roadmap items completed” were creeping back in.

   More capability per person, less authority per team.

4. 2026

   Recovery with a smaller footprint

   By March 2026, PM openings were at their highest in over three years — more than 7,300, 75% above the early-2023 low — and the growth was concentrated in senior roles. How many engineers one PM can cover is an open question again; the old ratios no longer settle it.

   The openings are real. They just sit further up.

So: not a straight line. A crash, a quiet rewrite of the job description, and a recovery into a different shape.

The three supports that were removed

The old job rested on three conditions. Each has been removed or is being removed. This is the mechanical core of the argument.

Support one: showing an idea required an engineer

This was the deepest one. If you had an idea, you could describe it in words, mock it up statically, or convince someone expensive to spend a week building it. Description was cheap and lossy; building was expensive and accurate. So you described.

Every reader of a spec has to rebuild the product in their own head from your prose. Every head builds a slightly different one. You discover the differences in review, two weeks later, and half of what looks like team dysfunction is just this.

Now an idea becomes a clickable, working thing in an afternoon. Not production code — a real prototype with screens, state, and enough logic that a customer can use it and say “no, not like that.” The first time I built one, it settled in an afternoon questions a spec would have argued about for weeks.

When showing is cheap, describing loses its reason to exist. Not entirely — see Part four — but as the default, it’s finished.

Support two: synthesis was a week

Research had a timing problem nobody in research liked to discuss, because the honest fix sounded like “do it worse.” Recruiting took a week. Interviews took a week. Synthesis — reading transcripts, tagging, clustering, arguing about whether “frustrated with export” and “annoyed by CSV” are the same theme — took another week if you were rigorous.

The interviews were never the slow part. Eight conversations is two days of talking. The slow part was turning eight hours of audio into four hundred observations into a defensible set of themes.

That’s now an hour, done well, with traceability back to the quotes. So research can happen inside a decision instead of arriving after it. Interview Monday, findings Tuesday, prototype revised Wednesday. That loop was impossible before, and it changes what research is for.

Support three: engineering was too scarce to experiment with

If an experiment costs three engineer-weeks, you don’t run it — you argue about it in a meeting instead, because the meeting is cheaper. That’s why so much pre-AI product work was argumentation. The RICE score wasn’t analysis; it was a socially acceptable way to have an argument with numbers attached.

When an experiment costs an afternoon, the meeting becomes the expensive part. That turns a lot of process upside down. Discovery stops being a phase that comes before building and becomes something you do by building.

• Before
• Now

Showing an ideaa weekan afternoon

Research synthesisa weekan hour

Running an experiment3 engineer-weeksan afternoon

1 hour1 day1 week3 weeks

The essay’s own estimates. A week is taken as 40 working hours, an afternoon as 4.

The numbers

Support	Before	After
Showing an idea	about a week of engineering	an afternoon
Research synthesis	about a week	about an hour
Running an experiment	about three engineer-weeks	an afternoon

What this did to the coordination half

Take those three away and look at what remains of the pre-AI week.

The PRD, as a tool for reducing risk, is mostly redundant — the prototype reduces the same risk more accurately. Synthesis is no longer a bottleneck. The tracker can generate the status relay. Translation between groups matters less when every group has a capable assistant that speaks all three languages. Asking the warehouse yourself replaces the “wait two days for an analyst” loop.

The coordination half of the job didn’t vanish because coordination stopped mattering. It’s dissolving because the specific frictions that made a full-time human coordinator necessary have been removed. That’s a different and more uncomfortable claim: the work isn’t being automated so much as it’s no longer needed.

What this did to the decision half

Nothing good, if you were hoping for an easier job.

The decision half didn’t just survive. It got harder, for three reasons.

More decisions, less time each. When building is cheap, the constraint moves from “what can we build” to “what should we.” Each quarter brings more viable options and less time to consider each.

The products themselves became non-deterministic. An LLM feature gives a different answer every time you ask. “It worked when I tried it” is no longer evidence of anything. Someone has to define what good means across a distribution of outputs — a product decision, not an engineering one, and a new skill.

New categories of risk arrived. What happens when the product is confidently wrong? What does it cost per call, and how does that scale? What does it do with a user’s data? What’s the failure mode that ends up in a newspaper? None of these were PM concerns in 2019, and all of them are now.

Part three: the job now

In one sentence: the person accountable for what gets built and whether it was right — with the taste to choose and the hands to show it.

That’s compressed. Unpacked, the post-AI product leader does six things.

1. Owns the bet, not the ticket

A bet is a decision made under uncertainty with real consequences. Stating one properly means saying what you believe, what evidence supports it, what it costs if you’re wrong, and what would change your mind — the part almost nobody does.

The pre-AI version of this was a prioritization score. The difference is accountability: a RICE score is something a team produced, a bet is something a person made. When building was expensive, hedging was reasonable because being wrong was catastrophic. When building is cheap, hedging is just slow.

2. Defines “good” for probabilistic systems

This is the new one, and it’s where evals come in.

With a deterministic feature, you write acceptance criteria and QA checks them: the button works or it doesn’t. With a model-powered feature, the same input yields a hundred slightly different outputs — some excellent, some subtly wrong in ways that only matter if you understand the user.

An eval replaces “I tried it and it seemed fine” with a repeatable measurement: a set of real inputs, a rubric for what good looks like, a grader, and a score you rerun whenever anything changes. An engineer can build the harness. Only the person who understands the user can say that a summary that is accurate but misses the one contradiction is a failure.

This is acceptance criteria, reborn for a world where nothing is exactly repeatable. It’s the same skill, applied to a harder problem, and it’s unambiguously the PM’s.

3. Shows rather than describes

The default output of product thinking changed medium. It used to be a document. It’s now a working thing plus a page of context.

This isn’t about being able to code. It’s about the loop: idea, prototype, customer reaction, revision — measured in days rather than sprints. The PM who can close that loop alone works at a different speed from one who has to ask for each step.

It also changes what “thinking it through” means. You used to think it through by writing. Now you think it through by building and watching someone fail to use it. The second method is harsher and more accurate.

4. Edits rather than authors

Drafts, research syntheses, competitive analyses, prototypes, status updates — a model can generate all of them. What it can’t generate is the judgment of which draft is right, what the synthesis missed, whether the analysis is asking the right question.

This shift is underrated because it’s a different skill. Authoring rewards fluency and stamina. Editing rewards taste and the ability to notice absence — the theme that isn’t there, the objection nobody raised, the user who wasn’t interviewed. Plenty of excellent authors are mediocre editors, and the job now rewards the second more than the first.

5. Carries the new risks

Trust and safety, model cost, latency, data handling, and the confident-wrong-answer problem. These are product decisions with real trade-offs — a cheaper model that’s wrong 3% more often might be right for one feature and unacceptable for another — and weighing them is nobody else’s job.

6. Is accountable

The last one, by definition, can’t be delegated. Cheap production means more bets, which means more wrong bets. Someone has to have made each call, said so, and be there when the number comes back.

This is also why the role won’t disappear, whatever the more excitable predictions say. An organization needs a person who owns the outcome, because accountability is a social fact, not a technical one. You can’t point at a tool during the postmortem.

The shift, one line at a time

Read down the left: the job I did well for ten years. Down the right: the job as it is now.

Part four: what didn’t change

A post that only says “everything is different” was written by someone selling something. Five things survived intact, and some of them matter more now.

Saying no. The backlog was always infinite; now generating plausible things to build is free, which makes the backlog infinite faster. Cheap production means more tempting bad ideas. The no is more of the job than it was, not less.

Sitting with a customer while they fail to use your product. No tool substitutes for watching someone’s face while they can’t find the button. Synthesis got faster; the value of having been in the room didn’t move.

Writing clearly. The artifact changed — a one-page brief instead of a twelve-page PRD — but the skill didn’t. A bad brief is worse than a bad PRD because it’s shorter; there’s nowhere for confusion to hide.

Organizational politics. Getting a decision through a company is still human work, and AI made decisions arrive faster than most organizations can absorb them. If anything, the gap between “we decided” and “the company acted” has widened.

Domain knowledge. Knowing how insurance underwriting works, or what a nurse’s shift looks like, is not in the training data in any usable form. It comes from years in the domain, and it’s what lets you spot the plausible-but-wrong answer.

So the honest version of the argument isn’t “the old job was worthless.” It’s that the old job was half judgment and half friction, and the friction half is going, leaving something more concentrated and more exposed.

Part five: the uncomfortable corollary

The first definition still describes a real job at a lot of companies. It will for years — enterprise software, regulated industries, and large organizations with long approval chains all move slowly, and there’s real work there.

But it’s now the junior version.

That’s the sentence this whole piece is built around. If your working day is writing specs, relaying status, running the roadmap meeting, and waiting on analysts, you’re doing work that a smaller team with better tools does faster — and, more and more, everyone in the room can feel it. The role still exists. It’s just no longer the senior one, whatever the title says.

The senior version is the second definition. There are fewer of those seats, and they don’t go to people who add “AI” to a skills section. They go to people who can point at a bet they made, the evidence they had at the time, the thing they built to test it, and what the number said afterward.

Which raises the obvious question for anyone who, like me, spent a decade becoming excellent at the first job.

What you actually do about it

Not a course. Not a certification. Three things, in order:

The uncomfortable weeks are real. For the first month you feel like you’re pretending to be an engineer. That passes around the time the first tool you built becomes something you actually use.

---

What I’m doing with this

I’ve done this job since 2013, long enough to watch the ground move under it. So instead of a think-piece about what everyone else should do, I’m rebuilding my own job in public: finding the parts that broke, building a tool for each one, and including the failures.

That series is here, and the toolset it takes is here.

If the argument in this piece is wrong somewhere, I’d rather hear it than not.

— Chris

Sources

Where the evidence comes from. Each row opens the document itself; the tag says which part of the argument it supports, and ↩︎ goes back to the sentence that uses it.

1. The Four Big RisksMarty Cagan, SVPGThe textbookArticle2017↗︎Value, usability, feasibility and viability risks
2. Good Product Manager/Bad Product ManagerBen Horowitz & David Weiden (a16z; orig. Netscape memo)The textbookArticle1997↗︎'CEO of the product' aspiration
3. Introducing ChatGPTOpenAITimelineArticleNov 2022↗︎ChatGPT launch date
4. A comprehensive archive of 2023 tech layoffsTechCrunch (citing Layoffs.fyi)TimelineNewsMay 2024262,735 tech layoffs in 2023↗︎2023 layoffs over 250,000
5. State of the product job market in early 2026Lenny Rachitsky, Lenny's Newsletter (TrueUp data)TimelineNewsletterMar 20267,300+ open PM roles, +75% vs early-2023 low; ~9,000 companies tracked↗︎PM openings: 2023 low, 3-year high
6. The 2025 State of Product Management ReportProductPlanTimelineReportJan 2025~400 respondents; +5% leadership-set strategy↗︎Teams less empowered, output measures return