Over the past few weeks, we hosted a series of small, off-the-record AI roundtables for senior product leaders. Six to eight people per session. Companies across edtech, fintech, and enterprise SaaS, ranging from growth-stage to publicly traded. Two topic areas: using AI for internal efficiency, and building AI-powered products.
We went in expecting variation. What we found instead was striking consistency. The same patterns kept surfacing across company sizes, industries, and AI maturity levels. Less “different teams figuring out different things,” more “everyone is wrestling with the same handful of unsolved problems.”
Here’s what stood out.
Output is up. Judgment is not.
The phrase one participant used was “AI slop,” and it landed with the rest of the room immediately. Leaders described 50-page documents that no one had actually read, PRDs full of jargon, and prototypes disconnected from real customer problems. AI is becoming a surrogate for thinking, not a tool to sharpen it.
“We’ve been calling it the increase in AI slop. Folks that are producing 50-page documents that don’t do anything, that get fed into another AI, and we end up just thinking in an AI circle.”
“I went on vacation for a week and came back and had to spend an entire day reading ridiculous memos. 30-page stupid memos written about how they were going to ‘AI’ their organizations.”
What made this theme so consistent was how leaders were responding to it: individually, by hand, with no scalable system behind them. One leader built a custom communications persona and shared it with her PMs. Another built a Claude project loaded with her review criteria so PMs would get feedback before bringing work to her. A third had a team practice of taking Claude through a problem once with all the nitpicking, then generating a reusable Claude Skill from the conversation.
Every leader was solving this on their own. Nobody had a repeatable, organizational answer.
Nobody can prove AI is working
This was the most universal and the most uncomfortable theme. Across every session, leaders said versions of the same thing: they can show their boards that AI is being used. They cannot show that it’s working.
“We don’t measure it. We talk about it quite a bit.”
“Every single time we do something, the board is like, okay, so you did 12 more story points instead of 10. How much money did that save me? And the answer: that’s not fully clear.”
One leader was unusually candid about the cost: “I would have tied business outcomes much more tightly to the integration of the AI in our products. We didn’t do that. I would have held the line much harder and said, we’re not doing this AI feature until we have a way to show this has made the product and the business better.”
The pattern is consistent. AI features are getting built and launched without early indicator frameworks wired in from day one. Teams are figuring out measurement after the fact, which means most of them are flying blind on whether the investment is paying off.
Charging for AI is harder than building it
Closely tied to the measurement problem, and almost as universal: leaders are wrestling with how to monetize AI in a way customers will actually accept. Several described pushback that caught them off guard. The argument from customers, roughly: you can’t charge me extra for capability inside a product I’m already paying for, just because the underlying tech changed.
That left leaders facing a real strategic split. On one side, AI-powered improvements to existing offerings, where customers see the AI as an expected upgrade rather than a new line item. On the other, net-new offerings that solve problems the product couldn’t address before AI made them tractable. The first is hard to price. The second is hard to find.
This isn’t a side issue. It directly compounds the measurement problem above. If you can’t price the improvement, and you can’t yet point to a new product line generating new revenue, the AI work shows up as cost without obvious upside. Several leaders described actively reframing their AI roadmaps around that second category, looking for problems they genuinely couldn’t solve before, precisely because the path to ROI is more defensible there.
For product leaders, this is one of the most strategic calls on the table right now, and it’s getting less air time than it deserves.
The prototype has replaced the document
This shift is real and it has happened fast. Leaders described requiring prototypes before any leadership review, mandating at least three different approaches per problem, and testing with real customers before bringing anything internal for discussion. The PRD no longer earns a seat at the table. The clickable prototype does.
“We now only engage with clickable, usable prototypes, even from the very beginning. And have also had our team test out three different paths before we engage as a team, to broaden the aperture of ways of thinking.”
But the speed gains are getting eroded by a familiar pattern: teams building impressive-looking prototypes without grounding in real data or customer problems, and pulling engineering in too late to catch issues that create downstream rework.
“Engineering got mad about the data problem. ‘Have you guys even thought about where this data is going to come from?’”
One leader had implemented a rule we thought was sharp: anything vibe-coded or AI-generated must be maintained by the person who built it. That single constraint became a natural filter for what was worth building in the first place. “If you can’t own it, don’t send a PRD.”
Product leaders are quietly asking what their job is now
This one was personal. Not just ICs feeling shaky. Senior product leaders openly asking, in a room of peers, what their role becomes in an AI-native world.
“What’s my role in this new setup? I’ve been a product leader now for years and this is something I kept on improving. And I’m also thinking, what can I do in this new setup?”
“I see a lot of imposter syndrome out there. Product owners or product managers that are now developers, struggling with: ‘I don’t know if it’s good, but it works.’”
“Engineering started saying, ‘Well, I don’t know the role of PM here.’”
The leaders who seemed most settled had landed on a consistent answer: judgment, curation, customer proximity, prioritization discipline. The parts of the job that don’t automate. But few of them had successfully translated that conviction into language their teams could rally around.
One CPO had gone further. She’d restructured her team entirely, replacing the PM-plus-designer-handing-off-to-engineering model with what she calls “product builders,” people who generate the actual experience in Claude, check in code, and work alongside a single senior engineer. She described shipping a full MVP in 90 days that would previously have taken two to three quarters. If it scales, it rewrites the PM and designer job descriptions entirely.
The speed question doesn’t have a consensus answer
The most genuinely contested moment across all three sessions was whether the new speed is a gift or a risk. Leaders were split, and the split wasn’t predictable by industry or seniority.
The risk camp described actively slowing teams down because they were building the wrong things quickly: “The core job of a product manager becomes even more important: what to build. I built it in three hours and said: this is not a product. This is a technology.”
The gift camp pushed back hard. If you can build fast and learn fast, the cost of a wrong turn drops dramatically, and the speed itself becomes a quality input.
“Speed and judgment aren’t opposites. You can overlay critical thinking on top of a system that’s suddenly moving a lot faster.”
“Nicole Forsgren’s research: she traced that the faster teams were able to iterate, quality went up. All the other metrics went up in correlation with the speed data.”
This is not a settled question. It is an active debate among thoughtful, experienced product leaders, and how each leader answers it is shaping how they’re operationalizing AI in their org.
What this snapshot tells us about the state of AI in product
A few things stood out when we stepped back from the conversations.
The first is that the technology adoption story is essentially over. Every leader in every session was using AI in some form. The question has moved entirely from “should we” to “how, and with what discipline.”
The second is that the gap between using AI and getting value from AI is widening, not closing. Speed has been delivered. Outcomes have not. And the leaders we talked to know it, even if they’re not yet saying it out loud to their boards.
The third is that the fundamentals of product management matter more in this environment, not less. Customer proximity, problem clarity, outcome orientation, prioritization discipline. The leaders who seemed most grounded were the ones who’d held onto these tightly even as the tools changed. The leaders who seemed most anxious were the ones whose teams were treating AI as a substitute for the thinking those fundamentals require.
We came away from these sessions more convinced than ever that this is a leadership moment for product. The teams that win the AI shift won’t be the ones with the best tools. They’ll be the ones whose leaders have the clearest answers to the questions everyone is wrestling with privately.
Want help putting this into practice?
At Product Rebels, we work with product leaders and teams navigating exactly this shift: using AI to accelerate delivery without losing product discipline or customer trust.
Is your team experiencing challenges in implementing AI into your product operating model or struggling in establishing the practices that enable the best outcomes from AI product building?
Schedule 30 minutes with us to learn a little bit about you and explore how we can help.
About Product Rebels
Product Rebels helps product leaders bring their teams from good to great. We work with established product organizations that already know the basics of product management but want to operate at a higher level. Our focus is not Product Management 101. It’s helping teams build strong customer foundations and outcome-oriented ways of working that consistently translate into better results; for customers and for the business.
We partner with leaders and teams to change how product work actually happens day to day: how customer insight is gathered and shared, how problems are framed, how tradeoffs are made, and how learning compounds over time. AI is infused throughout these practices as an accelerator, helping teams synthesize learning faster, explore more options, and move with greater confidence without sacrificing judgment or customer connection.
The result is product teams that don’t just ship more, they build the right things, make better decisions under pressure, and deliver meaningful, sustained impact.