Becoming an AI-Era PM 01 | Which PM Tasks AI Took Over, and Which Ones Got More Valuable
Start with a shift in hiring.
In 2026, a lot of AI product manager job descriptions dropped “can write PRDs, can draw wireframes, can build data dashboards” from the hard requirements and replaced them with three work samples: a product you actually built that someone can open and click; a retro with real numbers in it; a set of evals you wrote yourself. One recruiter ran the math — a resume gets about 90 seconds on average, but a decent case study gets read for eight minutes.
Put those two things together and you can see a shift: the tasks AI can take over are falling out of the hiring requirements; what’s left as the bar is the part only a person can do. This piece lays out those two columns, as the overview for the whole series.
The column that got taken over
The grunt work of writing requirement docs went first. Tools like ChatPRD generate a fully structured PRD in a few minutes — what you edit is the judgment, not the formatting.
Drawing wireframes and standing up clickable prototypes is depreciating fast too. Lovable, v0, and Claude Code turn “one sentence” into a page you can click in the browser, a fresh version every few minutes. This step used to need scheduling, used to mean waiting on design and front-end; now it’s cheap enough to try five directions in a day.
There’s one more thing people don’t often say out loud: the scarcity of “being technical” is itself dropping. Part of a product manager’s bargaining power used to come from being able to talk to engineering and estimate how hard a given feature would be to build. Now you describe the idea clearly and AI eats the implementation difficulty for you. This is exactly what doaipm keeps talking about — speak it and AI builds it: say it clearly, and AI builds it for you. If anything, people who aren’t technical lose one layer of self-imposed limits, the “isn’t this going to be way too hard to build” reflex.
Chasing schedules and the more mechanical parts of cross-team alignment are getting nibbled away by tools and agents in the same way.
The column that got more valuable
Judging “should we build it” is, for the first time, more expensive than “can we build it.” METR ran a randomized controlled trial: 16 senior developers did real work on projects they’d maintained for years using AI, and were actually 19% slower — yet they still finished believing they’d gone 20% faster. If even the people doing the work with their own hands can’t judge their own output accurately, then judging “what to build, and whether it’s worth building” only gets scarcer.
Stating requirements clearly turns from a soft skill into a hard one. AI won’t infer from omission: if you don’t write “we’re not doing login this round,” it’ll most likely add login for you. Whoever can spell out the boundaries, the states, and the not-doing list produces work that’s an order of magnitude better than everyone else’s.
Defining “what good means” is starting to require a dedicated craft. Lenny and OpenAI’s CPO are saying the same thing: evals are becoming the first new hard skill for product managers in twenty years. The last hard skill the whole industry had to learn on the fly was SQL and Excel. Being able to use evals to translate “seems fine to me” into a measurable standard is the new dividing line.
Making the call among the pile of options AI hands you has become a daily thing. Marty Cagan puts it this way: AI can surface patterns, draft hypotheses, and generate options, but it doesn’t judge which pattern means something, which hypothesis is worth testing, which option fits the business. That one decision is left to a person.
The column that hasn’t changed much
What users actually want, and whether the business can stand up — AI can’t replace these two, and we haven’t seen it try. One of a16z’s pieces of advice for product managers: the pure process manager gets phased out; the person with a “builder mindset” is the one with leverage. A builder mindset means being willing to make the idea yourself and take it out to validate — which has nothing to do with whether you can write code.
Look at the two columns side by side and one thing jumps out: the left column (taken over) is exactly the hard skills product manager job postings wrote most often over the past decade; the right column (got more valuable) is what almost nobody tested in an interview before.
The next nineteen pieces in this series take the right column apart one at a time — from how to think it through, to how to build it, to how to know it’s good.
Discussion