Imagine a simple scenario: users say the export report flow is bad.
A PM does not immediately ask engineering to change the code. They first talk to a few users, inspect the data, and separate the problem into parts. Is export too slow? Are the fields missing? Is the format wrong? Or should users not be manually exporting from this page in the first place? They also need to ask which users are getting stuck, where the product created the wrong expectation, what step the next version should remove, and what should change in the data once the fix is live.
This process feels natural. It felt natural because, in the old world, getting a feature wrong was expensive.
If one change consumed two weeks of engineering time, a PM had to think as much as possible before work started. If the team discovered after launch that the problem had been framed incorrectly, everyone paid for the rework. If real user feedback arrived a month later, the PM had little choice but to do more interviews, read more data, and simulate more options before release. PRDs, roadmaps, and design reviews did not become central because they were inherently more important. They became central because execution was slow, expensive, and hard to reverse, so PMs had to stack judgment up front.
This is where AI starts changing the PM role.
AI has pushed down the cost of writing code, building prototypes, running experiments, and shipping early features. Execution is no longer the slowest and most resource-intensive part of the product loop. It is becoming an ability that teams can call on constantly. Once that happens, the center of gravity for PM work shifts as well. The old question was whether the team could make the right call before implementation. The new question is whether the loop from idea to implementation to release to feedback to correction can run fast enough.
Cat Wu on Lenny’s Podcast offers a good sample from a frontier team. Cat leads Claude Code and Co-work at Anthropic. In the interview, she says product planning used to happen on a six-to-twelve-month window. Now many features move from idea to delivery in one month, sometimes one week, sometimes one day.
That is not just a mild speedup. For PMs, the cadence of the product loop has changed. Their value used to concentrate on getting pre-launch judgment right. Now it is moving toward designing the learning loop itself.
The full Chinese translation of the interview is here: Lenny’s Podcast × Anthropic Cat Wu: Claude Code, the Evolution of the PM Role, and Building AI-Native Products. This article does not try to retell the interview. It uses Cat’s material to think through the deeper shift in the PM role under AI.
The daily life of a traditional PM contains a lot of work that does not look like direct product output: writing PRDs, running user interviews, reading data, mapping user journeys, sitting in design reviews, ranking priorities, preparing launch notes. In practice this often feels bureaucratic. But under the cost structure of traditional software development, every piece of it made sense. A feature moved from idea to launch through user research, requirements, design, technical planning, implementation, testing, rollout, and release. Every stage consumed people. Every round of rework consumed scarce engineering capacity.
PRDs existed to clarify the problem definition, target users, core experience, and success criteria before engineering began. Roadmaps existed to decide which user problems deserved scarce resources first. Design review existed to align product, design, and engineering around one target experience. Underneath all three sat the same logic: execution was expensive, so product judgment had to become more certain before work started.
That logic also shaped the PM skill model. A strong PM was expected to make good calls under incomplete information: pulling needs out of interviews, inferring problems from data, translating engineering estimates into cost, and sorting priorities out of feedback from sales and support. Most of the time, PMs stood outside the engineering system and moved product decisions through documents, prototypes, reviews, and user evidence.
I made a related argument in Disposable Software and Compressed Reality: many professional skills were compression strategies built for a world where information was expensive to access. For PMs, the engineering system often looked like a running environment they could not directly see. Building visualizations, prototypes, intermediate tools, and inspection surfaces cost too much, so PMs had to learn how to decide without seeing enough.
Traditional PM work was not inefficient. It was a rational adaptation to an old price structure. As long as engineering remained expensive, rework painful, and feedback slow, front-loading product judgment created real value.
The real turn begins when that price structure changes.
Go back to the export-report example. In the old rhythm, once a PM noticed a problem they had to do interviews, write requirements, sketch options, and then wait for implementation and release. Much of the time was simply waiting. It was not that PMs did not want faster answers. The engineering queue was there, and many product judgments could only be validated after something shipped.
Under the new rhythm, a PM or engineer can use AI to build a prototype in half a day and put it in front of a small set of users the same day. Once that becomes normal, the entire mode of judgment changes. Questions that once had to be guessed inside meetings can now be answered through small experiments. Decisions that once belonged in a six-month roadmap can first appear as research previews that test how real users respond.
Cat says this very plainly in the interview: the Claude Code team wants anyone to be able to push an idea into the world within a week, and sometimes within a day. She also talks about concept corner, a deliberate experimental space inside the product where ideas from engineers or PMs can reach users in the same week.
That changes the meaning of release as well. Release used to look like the endpoint of a long build cycle, almost a ritual of delivery. Now release can become an observation tool. Putting something in front of real users delivers value, but it also becomes the fastest way to collect the next signal.
This is where the pressure on PMs shifts. When engineering moved slowly, PMs had time to think, write, and align. If engineering can now move in a day, and product judgment still runs on the rhythm of a six-month roadmap, the PM becomes the slowest part of the loop.
That is why Cat’s light process, research preview, and evergreen launch room matter. They are not style choices for the sake of lighter process. They all create the same benefit: they shorten the path from idea to user feedback.
Research preview is one of the clearest examples. Many Claude Code features ship with that label to tell users that the feature is an early idea, the team wants feedback, and long-term support is not guaranteed. The label itself is cheap. What it really lowers is the commitment cost of launch, which lets the team put things in front of users in a week or two.
More importantly, it changes the default contract between the product and the user. In a traditional GA setting, users assume they are getting a finished product and the team carries a heavier stability obligation. Research preview shifts part of that expectation into shared experimentation. Users know they are participating in an active product judgment process, and the team can therefore move features into real environments earlier.
At bottom, it is one shift: PM work moves from maximizing the correctness of one-shot judgment to increasing the learning speed of the whole loop.
If a team can only make one small change per day, the PM’s central job is deciding whether that change is worth making. If the team can make ten, the problem changes. The question is no longer only whether a change is worth doing. The question becomes which changes should enter the loop, what signals each change should be judged by, and who decides the next step once those signals arrive.
As execution becomes cheaper, the questions PMs need to answer change as well.
The old question was: is this user problem worth spending engineering
time on?
The new question is: is this product hypothesis already cheap enough to
test directly, and if so, how small and how fast should the test be, and
what signals matter?
The old question was: did the PRD describe the need clearly
enough?
The new question is: can the team still make decisions aligned with the
product direction without the PM stepping into every single choice?
The old question was: have we thought the solution through before
launch?
The new question is: after launch, can we see what is wrong quickly
enough and make the next round better?
This also explains why Cat spends so much time in the interview on team principles and metrics readouts. The Claude Code team reads metrics rigorously every week so that everyone carries the business goals, trend lines, and drivers in their head. They also write down who the core users are, why those users matter, and what the team is willing to give up. That way an engineer looking at user feedback can tell whether it belongs to the core user set. A designer making interface tradeoffs can tell which experiences can be sacrificed. PMM and docs can tell how a feature should be explained once it is about to launch.
On the surface these things still look like documents. In practice they function as loop infrastructure. In the old process, goal definition mainly supported alignment before execution. In the new process, it also has to support high-frequency autonomous judgment. If many people on the team can already build something end to end, the PM cannot stand on every path and approve one choice after another. The PM has to lay out the user model, the success state, the failure modes, and the feedback channels early enough that the team can move inside a much shorter loop on its own.
This also explains why the PM role does not disappear. Once engineers can build product directly, the PM whose only function is message-passing does begin to shrink. But once the product loop accelerates, the number of judgment points does not fall. It rises. The team has more ideas it can execute, more user feedback it can process, and more experiments it can put online. Once execution is no longer scarce, the real scarcity becomes deciding what deserves to enter the loop and how to tell whether the loop has actually learned anything.
When Cat is asked what abilities PMs will need in the future, she gives one line that ties much of this together: once code becomes cheap to generate, what becomes scarce is deciding what should be written.
People often summarize that as product taste. But taste can become empty very quickly. In day-to-day work, what it really names is a form of cost judgment.
Suppose a user says a button is in the wrong place. Under the old process, a PM would often wait, gather more feedback, and push it into the next release. Even moving one button still required design work, engineering work, testing, and a release path. Under the new price structure, if the change is genuinely small, an engineer or PM can produce a version the same day and put it in front of internal users or a small external cohort. At that point, holding three meetings about whether the button should move no longer matches the cost. On the other hand, if a seemingly simple feature affects permissions, billing, enterprise security, and data migration, then it still deserves serious planning.
This is why Cat says engineering background helps. She is not saying every PM must become an engineer. She is saying that engineering understanding gives PMs a real feel for practical difficulty. If something is easy, spend an hour and do it. If it touches long-lived infrastructure, spend more time and more care before moving the team.
So the first layer of PM technical ability in the AI era is cost intuition. You need to distinguish what is already cheap enough that you should just test it, what only looks simple but would slow the whole system down, and what still cannot be built today but is worth watching at the edge of feasibility.
This connects to an argument I made in Beyond DRY. AI has turned part of code from a long-lived asset into a temporary material that can be generated on demand. In the past, teams instinctively avoided disposable tools, repeated implementation, and purpose-built software for small problems. Now disposable prototypes, temporary scripts, and short-cycle experiments make more sense. A PM who still prices all engineering investment as if it were long-lived asset creation will miss the learning value of these temporary outputs.
Cat uses Claude Code’s to-do list as an example. Early Claude Code often said it would change twenty call sites and then stopped after five. The team added a to-do list so the model would make a list and complete it item by item, more like a human. Later models learned that behavior more naturally. The to-do list became less important for the model’s task completion itself, but it remained useful for users trying to understand what Claude was doing.
That example shows something important about AI products. A feature can carry two identities at the same time. One identity compensates for model limitations. The other helps users understand and trust the model. As models improve, the first identity may fade while the second remains. PMs therefore have to keep re-evaluating what role the same feature is now playing. In traditional software, features often enter a long maintenance phase after launch. In AI-native products, a single model improvement can force a feature to be re-priced.
This is also tied to Cat’s AGI pill comment. She argues that one of the hardest PM abilities inside AI companies is defining what the product should look like a month from now. Models change. User behavior changes with them. Designing for an imagined super-model is easy in one sense, because many intermediate products disappear in that world. The hard part is working with the model that exists now, without over-believing the future and without letting current limits lock the team in place.
That means product judgment happens right at the moving boundary. You need to know where the current model is reliable, where harnesses still need to compensate, where product design can steer users onto a golden path, and which deficits are likely to disappear in the next model generation. Otherwise you end up building overly heavy products around weaknesses that are about to vanish.
Taken together, Cat’s interview and this changing cost structure point to three fairly durable changes in the PM career path under AI.
First, classic requirements management loses weight while goal definition gains it. Writing PRDs still matters, especially in ambiguous features and infrastructure-heavy projects. Cat herself says they still write PRDs sometimes. But PRDs are no longer the core vessel of PM value. What matters more is whether you can define the target user, the success state, the failure modes, and what can be traded away so the team keeps moving in one direction while acting at high frequency.
Second, engineering understanding shifts from a bonus to a baseline judgment ability. PMs do not need to become full-time engineers, but they do need to read the new price structure created by AI. Should this feature go through meetings, or should the team ship a research preview today? Is this issue solvable at the prompt layer, or does it require harnesses, evals, and product interaction changes together? Is this capability about to be absorbed by the model, or does it need long-term productization? These decisions directly shape speed and resource allocation.
Third, PMs become more like designers of loops. That loop includes how user feedback enters the team, how the team turns feedback into experiments, how experiments reach production quickly, how users interpret expectations, how the team decides whether something worked, and how AI uses those signals to improve the next output. Documents, data, launch mechanisms, evals, and organizational coordination all sit inside that loop. Together they define much of the new PM surface area in the AI era.
This is also why Cat can say roles are blending while Anthropic still has thirty to forty PMs. The title has not disappeared. The work under the title has changed. In the past, PMs often acted as translators between user problems, product solutions, and engineering implementation. In frontier AI teams, they look more like maintainers of a high-speed learning system.
The effect of AI on PMs cannot be understood well through the crude question of replacement. That frame assumes PM work is a fixed list of tasks and then asks, one by one, whether AI can do them. The deeper change is that AI has altered the relative price of tasks, and with it the cadence of the whole product loop.
When engineering costs are high, the PM’s value lies in getting the
pre-launch judgment right.
When engineering costs are low, the PM’s value lies in increasing
learning speed.
When AI can execute, the PM’s value lies in setting direction, supplying
context, designing feedback, and judging output quality.
When model capability keeps moving, the PM’s value lies in re-evaluating
what should be solved in product, what should be constrained, and what
should simply be handed over to the model.
Cat Wu’s interview is compelling because Claude Code sits far enough toward the frontier to make the signal visible. For ordinary PMs, the underlying message is simple: the old price sheet they learned to work with is losing validity.
Over the next two years, the PM profession is likely to split. One group will continue to do requirements coordination, roadmap maintenance, and cross-functional alignment. Those functions will remain in large companies and traditional industries for a long time. But AI-native teams will increasingly need another kind of PM: one who understands model capability, understands engineering cost, can define ambiguous goals, and can help both people and AI learn inside shorter loops.
That kind of PM helps a team see reality faster, and then update itself faster in response.