Product Managers are More Valuable and Less Protected Than Ever

Recap from Anand and JZ's Reforge Event: Product Management Fundamentals in the AI Era

Something has changed about what it means to be a product manager, and most people haven't fully processed it yet. The change isn't subtle. It touches accountability, roadmapping, prototyping, and the fundamental question of who gets to captain a project. But it doesn't mean product managers are less important. It means the ones who adapt are about to be more important than ever, while the ones who don't will quietly find that their responsibilities have migrated to someone else.

That's the argument Anand — Reforge host, Stanford Engineering professor, and former product executive at Dropbox, Zynga, and Gusto — and JZ — CPO at Laurel and Reforge host — made in a session previewing their new AI Product Management Foundations course. The first half was Anand's: how the product development process is changing. The second was JZ's: what that means for how PMs actually build.

The assumption everything was built on

To understand what's shifting, you need to understand what the old world was built on: engineering scarcity.

Historically, engineers were the most expensive resource in any R&D organization. They were also the only ones who could actually make software. So the entire product development process was designed around keeping engineers productive — which in practice meant PMs staying ahead of engineering with a steady stream of well-defined specs, and nobody touched a roadmap item until product had fully vetted it.

"If the average feature used to cost $500,000 to $1 million in salary time to build," Anand explained, "you had spend a lot of time making sure the definition is really good and the prioritization is really good before you hand it off."

That assumption is now gone. For an average SaaS feature, a web redesign, or a sign-in flow, frontier models can do most of what engineering used to do. "Engineering scarcity was the assumption the entire product development process was built on top of. And now it's dropped."

When a foundational assumption changes, you can't just swap out one part of the system. You have to rethink all of it. 

Two changes that ripple through everything

Anand identified two specific changes playing out across the companies he advises.

The first is about accountability. In the old world, product managers were the default captains of every project — the mini-CEOs accountable for success or failure. That's changing. At many AI-native companies, captains now come from design, engineering, sometimes sales or marketing. The captain role goes to whoever is best positioned for the hardest part of the project. If the project has engineering risk, an engineer might captain it. If the risk is on the product side — customer understanding, problem definition — that's where a PM might step in.

"Captaincy just used to come to you by default," Anand said. "You are the product manager, so you would be the person running the project. Now it goes to whoever is best positioned for the hard part, and sometimes that's not you." For PMs, this means some of the visibility and responsibility that came for free — especially at junior and mid-career levels — is now going elsewhere. The work doesn't disappear, but who does it can look different now.

He also flagged a failure mode he's seen at AI-native companies that go too far in the other direction: with engineers working on forty things at once – delegating everything to agents – nobody knows the state of any individual project. "Nobody knows what's blocked on what, nobody knows what the next step is, and they're just too busy reacting to whatever the agents did that day." Large, cross-functional projects require someone to hold their full state in their head. That capability doesn't come from adding more agents. It's a human skill, and it's the one that separates teams that can do big things from teams that can only do small ones in parallel.

The second change is about centralization — or rather, its collapse. Nearly all tech companies historically coordinated roadmaps centrally: strategy set by executives, roadmap curated by product, engineering assigned to items product had approved. That model made sense when the cost of building was high. When cost drops, it starts to fall apart.

Anand illustrated this with Lovable, the AI-powered app-building platform now doing nearly $500 million in revenue with about 150 employees. The last time Elena Verna — a longtime Reforge collaborator — checked, 97% of every Lovable employee had committed code to production. Not 97% of engineers. Not 97% of PMs. Every person in the company: sales, support, legal, HR, finance. Customer success people build agents to handle tickets. Finance handles internal bookkeeping. Salespeople have committed small features directly to the product.

When Verna first joined and wrote a spec to propose something she wanted to build, her colleagues didn't understand what she'd handed them. "They were like: why don't you just make it and send us the code review, and we'll approve it and ship it to the product." There was no centralized roadmap. No one coordinating projects. The company's strategy and customer context was shared with everyone, and people built what they thought was most important. Verna told another story: when someone asked what projects the team was working on, nobody could answer. They found out what had shipped by looking at the Slack channel with the PR notifications.

Anand is not advocating this for most companies. "I think most companies are definitely not ready for this." Healthcare, regulated banking, enterprise customers requiring roadmap commitments — none of them belong at the Lovable end of the spectrum. But the point is that a dial exists, and most companies should move further along it than they currently are. The practical implication for PMs isn't to give up the roadmap — it's to shift from controlling what gets built to making sure everyone else has the context they need to decide well. "That's a different job, but it's arguably more impactful if you can do it well."

The spec is the new bottleneck

The through-line connecting both changes is this: when engineering is abundant, understanding becomes the constraint. The bottleneck on most projects is now a well-written spec — a crisp distillation of the problem, the customer, and the constraints. "The spec is now more important than ever to the business," Anand said.

This is where PMs remain irreplaceable. Nobody else in the organization has historically owned problem definition at the depth that a good PM does. But that ownership is increasingly contested. Engineers can now fire up Claude Design or Figma and produce high-fidelity mocks they couldn't have made two years ago. PMs and go-to-market people can fire up Claude Code and submit a PR directly for simple things. "Things that used to be off-limits for a particular role are now commonly expected inside it."

The net result: if you're a PM who's good at the foundational work — problem definition, customer understanding, spec writing — you are more valuable than you've ever been. A small team with great specs and AI coding tools can now ship three to five times what it used to. But you don't get that leverage for free. The free part — the default captaincy, the implicit accountability — is gone.

What prototyping looks like now

JZ picked up where Anand left off, walking through what this change actually means for how PMs build things day to day. The short version: prototyping has moved from something PMs hand off to something PMs do.

"In the past, prototyping was really expensive because engineering was really expensive, and engineers were the only ones who could really build something that felt high-fidelity enough for you to get signal," JZ said. "And so we used to do all this work to build conviction before we passed it over to engineering to write a single line of code. Now we're using software prototyping at all different levels of fidelity to build that conviction."

She walked through Laurel's experience building a billing management product — a significant new surface area that in the traditional model would have required months of spec-writing and waterfall execution before anything shipped to customers. Instead, they followed a process that's become the standard at Laurel for anything new.

It starts with being crisp on strategy. Not just a one-pager, but a comprehensive document that captures every key decision and its rationale — because in an agentic development environment, the strategy document is what agents, engineers, and other contributors will reference when they hit ambiguous moments. "If you're using agentic workflows to develop, you need to essentially emulate what it was like previously when you sat down in a room with a bunch of engineers and you appointed one person to be the owner of the technical architecture." All the conversations that would have happened organically between a PM and an engineering lead now have to happen upfront, written down, before anyone writes code.

From there, the PM builds a working prototype – not a Figma mock, but actual working software. At Laurel, Nick Basley (who has a sports management background, not engineering) built the vision prototype for the billing product end-to-end with no design support and no engineering. Laurel's design system was uploaded into Claude Design, and he built directly from it. It took days.

That prototype goes in front of real customers — CFOs, billing partners — before a line of production code is written. The goal is to watch reactions, refine the spec, and hear the question that tells you you've hit something real: "When is this going to be in beta so I can use it?"

Once the prototype is validated, it splits into two parallel branches. One is the "vision prototype" — the thing you keep building forward to continue testing the full picture with users. The other is the MVP scope — a deliberate reduction of the prototype to what engineering will actually build first. "You want to make sure that you're not just making your prototype the absolute source of truth for code, because your prototype will go further."

A new division of labor inside the process at Laurel

JZ was specific about who does what at each stage at Laurel, because it's counterintuitive in several places.

Engineering review — historically done by engineers — is done by PMs at Laurel. The system has enough automated guardrails and agent-assisted code review that by the time an engineer sees the PR, most of the obvious problems have already been caught. Engineers comment on the final PR, agents incorporate the comments, and then — here's the most counterintuitive part — the PM merges. Not the engineer. The PM merging is a forcing function to follow the process end-to-end and know where the gotchas in the codebase actually are.

There's also a cultural shift embedded in this structure. Every PM and designer who builds this way at Laurel is on call. When something breaks at 2am, they get paged. It sounds like a minor operational detail. It isn't. "It's a huge relief to the engineering team to say to the other product builders: if you're going to build a thing and you have full ownership, when this thing breaks at 2am in the morning, you will get paged. And that is a really important piece to get this working, and it changes the responsibility of the PM to really feel like they are the owner and the captain throughout this process."

Engineering investment, meanwhile, is going somewhere different: infrastructure, reliability, automated testing, and codebase cleanup to make it actually good for agentic development. It’s all of the more foundational work that makes everything else possible.

Strategy is more important than ever, not less

A theme running through the live questions was this: does strategy even matter anymore if you can just ship everything quickly? Both Anand and JZ pushed back hard.

"If you can make things twice as fast and you're running in the wrong direction, it doesn't matter," Anand said. "We haven't made you any faster as a company if you ship twice as many things that are pointless."

The premium on getting strategy and customer understanding right has gone up, not down, because the consequences of running in the wrong direction at speed are worse than they used to be.

"It is so easy to be seduced by speed. We're shipping tons of stuff and tons of features. I'm like, yeah, but none of it mattered."

The PM's role in strategy hasn't changed in substance. What's changed is distribution: where strategy used to route through the product function, it now has to be taught to everyone. The PM who can take a strategy, make it legible to a cross-functional team, and trust that people will apply it well when building independently — that person is more valuable than the PM who controlled the roadmap by holding a bottleneck.

JZ added one more frame for thinking about this: teams that win aren't the ones that build the most. They're the ones that learn the fastest. "When you learn the fastest, you're compounding your advantage." Every prototype, every customer conversation, and every alpha deployment is a question: what is the thing we're trying to learn? At Laurel, a big question is whether agents can truly replace the low-leverage work that billing partners don't want to do anyway. Everything they build is oriented toward answering that question faster. Features that don't help answer it get cut.

The one thing to take away

The product manager who thrives in this moment is one who can hold two things simultaneously. The first: that building has never been cheaper or faster, and the old process that treated engineering as a scarce resource is obsolete. The second: that understanding — the problem, the customer, the strategy — is harder than ever to get right, and it's now the only real constraint.

The PMs who treat the new tools as a way to ship more things are going to get lost. The ones who treat them as a way to learn faster, validate assumptions sooner, and distribute good product thinking to more of the organization — those are the ones who will find that this moment has made them even more valuable.

Watch the full recording here
Find out more about Anand and JZ’s course here: https://www.reforge.com/courses/product-foundations