Article details
Recap from Jiaona's Reforge Event: Product Leaders, Your Job is Fundamentally Changing
There's a quiet anxiety running through the product management community right now. Not the kind that gets written about on LinkedIn — the optimistic posts about shipping ten features in a week. The other kind: burnout, uncertainty, the creeping sense that no matter how many tools you try or how many hours you put in, you can't quite keep up. And underneath all of it, a harder question: does any of this even matter?
Jiaona Zhang (JZ) — product leader at Laurel, instructor at Reforge, Yale, and Stanford — opened her session by naming all of it. The excitement when a new model drops. The exhaustion of staying current. The confusion about whether to leave a comfortable, well-paying role for something less certain but more AI-native. She didn't dismiss any of these feelings. She engaged with them directly, because the feelings are pointing at something real: the gap between companies that have built AI-native from the ground up and companies that are still trying to retrofit AI into existing processes is large, and it is growing.
The core argument she made — and the one most likely to make people uncomfortable — is this: using AI at a non-AI-native company does not make you AI-native. And the distinction matters more than most people realize.
The myth of the current PM
The intuition most people are operating on goes something like this: if I use the new tools, try the new models, build automations where I can, I'm staying current. I'm doing the work. I don't need to blow up my career to learn what AI-native means.
JZ thinks this is genuinely dangerous, not because the tools don't help, but because the fundamental structure of an AI-native company is different in ways that tool adoption can't replicate. Companies built from scratch on AI don't have the tech debt that constrains what's possible. They don't have processes that calcified around the assumption that software is expensive to ship. They've built what she calls a software factory — an environment where the rate of learning, the rate of building, and the rate of iteration are simply different in kind, not just degree.
Being in that environment teaches you something you can't learn from trying tools on the side. Meg Whitman, an advisor to Laurel who has seen the transitions from mainframes to PCs to the internet to mobile to cloud, told JZ that AI dwarfs all of those combined. If that's even partially true, then trying to experience AI transformation through the lens of an older company's change management process is a fundamentally limited way to learn it.
The data on what's happening at the top of the pay scale reinforces this. From a community of 140 senior product executives, only about 10 are actively in transition — an unusually low number. The reason isn't that everyone is happy where they are. It's that the exec builders who've truly worked inside AI-native companies are so differentiated that they're essentially unreplaceable at the compensation level they're at. Meanwhile, mid-career roles at companies that aren't building in new ways are starting to compress. The bifurcation is real and it's accelerating.
What the executive builder actually does
The shift in what senior product leaders are expected to do is substantial. At Webflow, JZ's team had roughly 20 PMs and 20 designers supporting about 150 to 200 engineers. The ratios are now changing significantly, and more importantly, the nature of the work is changing.
The new ethos she described is what she calls the executive builder. A few things are true about this person that weren't true about the previous version of the product executive.
They are builders by definition — not process managers, not people managers in the traditional sense. They are shipping things themselves, not waiting for handoffs between design and engineering. At Laurel, PMs build frontend features. They've now moved into backend work too, as the codebase has been cleaned up enough to support it.
They manage projects and agents, not just people. When you want to expand someone's scope today, you don't necessarily add three PMs under them. You make sure they're using AI in ways that multiply their leverage. The headcount expansion that used to mean three months of hiring now might mean three weeks of building better tooling.
They are systems thinkers, not task executors. The tedious, high-volume work — the laundry and dishes, as JZ called it — gets delegated to automation. What remains for the human is the work that requires judgment: reading a room, sensing morale, understanding what customers feel and haven't said, making calls about what deserves to ship.
The capacity expectations have increased dramatically. This is why the burnout is real even for people who are thriving. If you're making significantly more than you used to, it's because significantly more is expected of you — not just in hours, but in the leverage you're creating through the tools and agents at your disposal.
How to build judgment when everything is shippable
One thing that's become a cliché in the industry is the advice to "develop better product judgment." JZ finds this frustrating for the obvious reason: it doesn't tell you how. At a summit Lenny hosted recently, a speaker made the observation that everyone can ship now — and that this mostly means that teams are shipping more bad ideas. Execution is cheap. Judgment is what separates good product work from a pile of features.
Her framework for building judgment in practice has three parts.
The first is data. Qualitative and quantitative. If you're building something new, your data is primarily conversations — customers, their workflows, their facial expressions when something doesn't work. If you're iterating on something live, your data is instrumentation. If you don't have it, fix the telemetry before doing anything else.
The second is having a clear answer to the alpha question: why would you win? In a world where everyone can ship, everyone can also ship against you. The question isn't whether you can build the feature. It's whether your company has distribution advantage, trust advantage, data advantage, or brand advantage that means your version of the feature compounds while a competitor's doesn't. Technology advantage alone is no longer sufficient; it's table stakes. Intellectual honesty about this question separates the things worth building from the things that just fill a roadmap.
The third is fast learning loops. The benchmark she gave: can you prototype in one hour and get directional feedback? Can you learn something in 24 hours? Can you run an eval in a week and know how you're doing? If your cycles are longer than that, you're not operating at the pace the environment demands.
One important corrective to the easy availability of shipping: don't just ship more. Eighty percent of your prototypes should die. The point of being able to prototype quickly isn't to produce more features — it's to diverge more before you converge. You explore more options, kill most of them, and arrive at what you actually build with substantially more conviction. Users have change fatigue too. A product that's a Frankenstein of features without design coherence creates confusion even if every individual feature technically works.
The work chart
The org chart at most companies is a list of people and their reporting relationships. JZ argues that the more useful thing to map is what she calls the work chart: humans, agents, workflow automations, shared skills, and things running autonomously — together.
At Laurel, the team tracks not just how people are spending their time, but how much of the work on any given feature is done by agentic development versus human development. That data becomes the basis for decisions about what to automate, what to keep human, and where the leverage actually lives. A product manager who controls a significant scope of work supported by an army of automated tooling is genuinely more powerful than a product manager who manages three people the old way.
The key individual practice she recommended: audit your own time. Map the buckets of your work — across the full product lifecycle, from problem validation to solution design to shipping to measuring — and for each bucket, ask two questions. Is this something that requires uniquely human judgment? And if not, do I have an automation for it?
The buckets that require human judgment have a consistent character. They're user-facing. They require reading people — customers, stakeholders, the CEO, the team. They require foresight — not just synthesizing existing information, but imagining what might happen that isn't predictable from the data. They require asking the right questions, which is increasingly the core skill in an AI-assisted world: knowing what to ask, what to push on, when to go recursive and demand better.
The laundry and dishes — status updates, templated communications, recurring reports, administrative coordination — all of this should be on a path to automation, either by you or by your team. The goal isn't to eliminate work. It's to get more of your time into the part that's actually yours.
Getting there from where you are
The hardest question JZ fielded was from people who can't easily make a move to an AI-native company — whether because of life circumstances, financial constraints, or simply because they're the person responsible for bringing their current team along.
For people who need to stay: the two things that actually move the needle are bringing in people who have done tours of duty at AI-native companies (if you have the budget to hire) and finding a community outside your company where the learning compounds. The point she kept returning to is that you can't learn this in isolation. The problem space is changing fast enough that sharing homework — being willing to say here's what I tried and what broke, not just what worked — is the only viable approach.
For engineers worried about what their role means in a world where PMs are shipping features: she's seen this tension at Laurel and her recommendation is to reframe the role, not eliminate it. Engineers shouldn't be reviewing garbage PRs. They should be architects — designing the systems, setting the guardrails, leading the structural decisions at the start of a project and doing meaningful reviews at specific checkpoints. The engineering role isn't smaller; it's moved upstream.
For anyone trying to become the executive builder from wherever they're standing: the concrete test is whether you've shipped something end-to-end. Not contributed to a feature, not reviewed a PR, but taken something from idea to production yourself. If you haven't done that yet, that's where to start. Customer success managers at Laurel ship features. If the only thing standing between you and that capability is your IT department's tool restrictions, that is information about whether your environment can teach you what you need to learn.
The closing argument
The session ended not with reassurance but with a genuine challenge. The world where AI does the tedious work and humans do the creative work sounds appealing — and it's actually achievable. But it requires making the choice to pursue it, which means being honest about whether your current environment is helping you build the capabilities this moment demands.
The art and the poetry is real. Understanding customers at a level of nuance AI can't replicate. Asking the questions that produce insight rather than synthesis. Making the calls about what deserves to exist. These have always been the core of good product work. The difference now is that the surrounding conditions — who you work with, what your company's tech stack allows, whether your organization is building in genuinely new ways — determine how quickly you develop those capabilities and how much leverage you have to act on them.
Watch the full recording here
Find out more about Jiaona's upcoming cohort of AI Product Leadership