12 Apr 2026 11 min read AI

Beyond the Backlog: Why the Next Great PM Will Be a Builder of Clarity

The product management playbook is changing fast. Not in theory. In practice.

A lot of the work we used to do to indicate PM value is getting cheaper. I can write a decent memo, generate a decent diagram, summarize out some human quotes, and write a first draft of a PRD in about an hour. But let’s be real. None of those things were ever the part of the job that was actually hard.

So what is the harder part of the job? When the facts aren’t easy to make decisions on, and there are many stakeholders that all have different views on how to move forward, it can be very hard to figure out what matters most. And, by the time you and your team figure it out, it may be too late - you’ve spent a quarter building the wrong thing.

My take is that the role of the Product Manager is shifting from producing artifacts to making judgements. Not louder or more vocal opinions, but better judgement. Calm, disciplined business-minded judgement under considerable uncertainty.

As the landscape of what it means to be a great Product Manager continues to shift, I’m seeing a new breed of PM emerge. I’m calling them the “builder” PM. They won’t be writing production code (although the lines are blurring and with a growing number of PMs dabbling in feature design, maybe someday they will). But what they will be doing is building clarity, conviction, and momentum in the organization where others are left standing in the fog.

This development is promising; it also comes with some challenges. These new strategies demand real organizational changes.

AI handles all the drudge work. That's plain to see. So, what's the deal? Seriously, what unique value do experienced product managers actually provide these days?

Quite a lot, actually.

Subscribe (button at top right) to get these blogs in your inbox, and enjoy additional features!

The Ground Is Shifting Beneath the Role

AI is shrinking the value of PM paperwork and raising the value of PM judgment.

Traditional Product Management follows a familiar cadence. Requirements are gathered, a spec is written, the backlog is groomed, and features are shipped one by one until the next sprint or release.

This role traditionally has a familiar rhythm. There is a clear cycle to follow. But that makes one tend to confuse motion with progress.

Artificial Intelligence is quickly changing the economics of product work by automating routine, time-intensive processes such as strategy writing, user journey mapping, and synthesizing user feedback. AI is useful today, and even magical at times, but it is powerless to prevent a leadership team from quietly shifting expectations during the second half of a quarter.

That gap matters.

Product artifacts are arriving into the market faster and at a lower cost. As a result, they no longer hold the same amount of value. Instead of documentation, the most valuable asset is judgment. The ability to frame good problems, to discern between the signal and the noise, to make better bets for your team.

I’m not trying to romanticize what PM work has become, but there is a shift in what is rewarded and in what is hard / time consuming. Yes, a lot of what PM’s used to do still needs to happen, it is just that the center of gravity for what is rewarded and what is hard / time consuming has shifted from rewarding the PM who can keep the machine running to rewarding the PM who can aim the machine in the first place.

That is a different job.

What a Builder PM Actually Builds

The builder PM does not build code first, but builds shared understanding that makes good decisions possible.

Don't misunderstand me. A builder PM? I'm certainly not envisioning someone stealthily pushing code onto the main branch late at night.

I mean someone who can build order from ambiguity.

My experience of traditional Product Management is that it is similar to an air traffic controller - guiding planes around each other so that they all land safely on time. Builder Product Management is very different. It feels more like being an engineer designing a bridge for people to drive across. Just as the engineer may not need to drive across the bridge themselves, the Builder PM may not “deliver” the project. But they still design it within constraints, ensure that it can be built safely within those constraints and that the team know how to cross it safely before they drive across.

From what I have seen, this version of the role shows up in five ways.

For one, they solve a different problem at a different scale. It’s bad when, sometimes, after 6 weeks of hard work, you realize you are chasing something completely the opposite of where you are going. Having a builder PM means you will know what customer pain point you should be solving for, what business outcome you are trying to achieve, and why now.

They do not wait for ambiguity to be reduced. Good PMs do not demand complete clarity before making a decision. Instead, they utilize prototypes, customer evidence, usage data and AI-assisted synthesis to make the next decision less risky. Not perfectly clear, less risky. That is the game number two.

Third, the builder PM connects the product work to business outcomes. While story points are not a business model or a polished roadmap, the builder PM can articulate how different product bets contribute to strategic objectives such as revenue, retention, margin, adoption, or time-to-value in simple language. Without this, the work may still be interesting and valuable to customers, but difficult to justify as strategic.

Next, builder PMs enforce the 4 key characteristics of effective product teams, which are:

The team has a clear hypothesis on what to build and why.
The team has the structure to surface and discuss ambiguity.
The team has the right mix of skills and the right amount of depth.
The team has enough cross-functional fluency (not fake expertise) to understand enough about engineering, design, data, and commercial to have a great conversation about trade-offs.

And lastly, they own the learning loop: Strong Product Managers treat new feature development roadmap items as bets. When creating a roadmap item, they define success before launching and then go back and honestly inspect what actually happened. If a Product Manager identifies that one of their bets was weak, they should quickly cut-lose on underperforming features to reallocate resources to higher potential ones - this requires judgement and guts.

The Market Is Sending a Pretty Clear Signal

PMs are being held to business outcomes while still drowning in administrative drag, and that tension will force the role to evolve.

This is not just a fashionable LinkedIn opinion.

The numbers are pointing in the same direction. Airtable’s report on product management trends lays out the tension clearly:

92% of product leaders say they own revenue outcomes
More than 66% of their week is still consumed by manual, administrative work
Only 31% feel confident they are building the right product for their market
Just 1 in 3 product teams believe their workflows are efficient and repeatable

This is rough. PMs will be responsible for significant business outcomes but likely will have a large portion of their time taken up by other operational work.

AI is cool. AI is really cool. But only really cool if you use it properly and responsibly. One of the most important jobs for AI is to take away repetitive, administrative and operational work so that your PM can focus on making well-informed, potentially game-changing decisions.

Also, generating “great” prompts to an AI is not a key success factor for adopting AI. Instead, success will rely heavily on skills that were crucial for products long before AI existed, like framing the right problem, trying new things, and stitching together workflows. And, yes, many of those same skills will remain crucial.

And don’t forget that hiring data moves too. The Institute of Product Leadership found that there was 40-50% growth in product hiring in the last year, with approximately 87% year-over-year growth in senior product roles. What’s as interesting as the sheer volume of hiring is the evolving set of criteria that organizations are using to screen candidates. There’s less weight put on legacy experience at legacy companies and more weight put on practical experience building products and making product bets.

So the moral of the story is: Not a fancy job description. Anyone can just crib that. But the real stuff, the absolute grit, that razor-sharp judgment you need when you're tackling an actual knot of an issue, with a whole crowd of people watching? That, my friend, you can't fake.

The Risks Nobody Should Ignore

A builder PM is a stronger role design, but it becomes a bad joke if companies pile on accountability without support or authority.

This trend is real. It is also easy to misuse.

The first risk of a builder PM org function is that the builder PM becomes a budget workaround. ie, the company stops doing user research, stops providing GTM support, stops helping customers with analytics. The builder PM gets credit for “rising to the occasion” but really that is not role evolution that is understaffing with better branding.

A 2nd risk I see is accountability theater. Many organizations like to tell their PMs to “own the outcome”. Fine. But do they really control pricing, sales incentives, marketing investment, customer success motions? If not, then this needs to be a very nuanced conversation. Don’t just hand someone the scoreboard and pretend they control the game.

The third risk to the PM profession is what I call the superhuman generalist trap. I have seen companies describe what they see as the job of a modern PM as being an AI expert, a strategic thinker, a monetization guru, engineering leader, growth hacker, operations manager, and GTM expert. That’s not a job description - that’s a superhero’s origin story.

Seriously, forget other setups. The T-shaped product manager is the real deal. What’s a T-shaped PM? They can move across tons of areas, no problem. They connect different departments easily. Then, one or two specific fields they absolutely dominate. Maybe they just get pricing mechanics inside and out. Or growth loops are completely sorted in their mind. Maybe they're even brilliant at crafting those super complex workflow systems big companies need. Or perhaps, it's understanding the weird quirks of AI products. That's where their true mastery lies. All that breadth gives them huge flexibility. Depth? It earns trust.

You need both. You do not need to pretend one person can be everything.

What Leaders Should Do Now

If you want stronger PMs, stop hiring for polished artifacts and start hiring for clear thinking in messy situations.

For product and technology leaders, the practical response is fairly clear.

Hire people who have good judgment. Give them some ambiguous problem to solve, and see how they think when information is lacking, and trade-offs are tough, and the answer isn’t obviously right or wrong. Ask how someone would test whether an idea was right or wrong, and you’ll probably learn everything you need to know to figure out whether they could efficiently launch that idea.

Make the distinction between ownership and influence clear. This may seem minor, but it’s not. Specify the levers to pull, the decisions to make, and the areas for which PMs need to collaborate with other teams that they don’t fully own. Not doing so will lead to frustration sooner than later.

Automate the admin (manual, dull, routine admin) but don’t automate the thinking and understanding that a Product Manager brings to the party. There is already far too much of the PM’s time taken up by manual tasks - two-thirds of a PM’s time is often spent on dull repetitive admin tasks that could be automated with the aid of AI and workflow tools to clear the sludge from the process. Management problems need management solutions, not IT workarounds that generate more reporting, more data, more admin.

Make sure your function is properly resourced. A strategic PM is not a replacement for great research, design, analytics, or GTM. You get more powerful as a strategic PM when surrounded by strong partners, not weaker ones.

One last thing. Reward actual learning. You do not just want to churn out tons of things. When your teams can't even tell you what bets paid off, which ones utterly failed, or how they adjusted their strategy because of it, then they aren't doing real product work. That is just a glorified shipping department, nothing more.

What PMs Should Do Now

The PMs who stand out in the next few years will be the ones who turn ambiguity into business decisions.

If I were advising PMs looking ahead, I would focus on four moves.

This is how you get to be sharper on business. Read the P&L, understand the growth model, and know what the right metrics are and why. If you don’t your competitors will, and I’m not sure you’d like how they make the connection between product work and business results.

Developing some basic technical understanding is also important for understanding the challenges and limitations within the platform. You don’t need to become proficient in all of the technical details of how the engineers build the tools, but having enough understanding to discuss issues like architecture trade-offs, data quality, platform limitations, and failure modes without sounding ceremonial is very important.

Artificial Intelligence (AI) is best used as a means to accelerate analysis, synthesize large datasets, build prototypes, generate initial hypotheses and evaluate possible options, all ultimately to inform human judgment.

We can shift the story we tell about our work as we ascend the levels. First, we stop simply listing out the features we delivered, then we progress to tell the story of the uncertainty we reduced, the trade-offs we made explicit, the factors that influenced certain decisions and, ultimately, the business result that followed. This is a more senior story. It’s the more accurate story of the work we’ve done.

Shipping matters, of course.

But shipping is not the whole story.

The Human Moat

In an AI-rich world, the lasting edge is not artifact production but judgment, influence, and the ability to make sense of complexity.

I do not see this shift as bad news for product management. I see it as overdue.

Durable value is embedded in people. It judges influence. It recognizes patterns and has taste. It asks awkward questions at the right time. It connects customer pain, technical feasibility, and business needs in a practical and sustainable way.

That is the moat.

The future of product management, who'll really own it? It's not the crowd just making pretty documents. Nope. It belongs to folks who honestly make things clearer for everyone. They help businesses decide better and take smarter risks.

That is a harder standard.

It is also a better one.