After being with us since the start of the company, our amazing PM left to start her own thing. We were devastated. She was behind every big product decision. She also drove a lot of our biggest market insights and helped us navigate how fast AI was changing. We were in the middle of building our second product and it was brutal. 

That happened at the same time that all of our 20-odd engineers went all-in on Claude Code and suddenly had more bandwidth and were moving much faster. So I thought: maybe we can distribute parts of the PM job across engineering until we find someone good. We split it among 3 engineers and one marketer.

The first thing we wanted was better user feedback. Our PM used to monitor Intercom and reach out to users 1:1. One of the engineers built an in-app feedback system. It collects feedback right where things go wrong, runs it through an LLM twice a week, and posts the key issues to a Slack channel the whole team sees.

Because there was no one person reading it anymore, many more people started to pay attention to it. Engineers began commenting on what was broken and what wasn't. This felt like an upgrade.

The second was user sessions. Our PM used to watch them to understand where users were struggling. One engineer realized the hard part wasn't watching sessions. It was finding the broken ones. So he built logic to flag the specific moments where something went wrong. If a user drops off mid-session on feature X, the engineer who owns X gets the session link.

Engineers could see their own thing break with a real user on the other side and fix it the same day. That seemed to work better too.

But the third thing didn't work: prioritization.

Now everyone had a better understanding of user problems and ideas about what to fix. What we didn't have was anyone whose job it was to take all of that context and decide what mattered most. Four people with good judgment create four good lists, not one ordered list.

Everyone can identify bugs and new features. But someone still has to decide.

I ended up owning it myself. That was much harder than I expected. I underestimated how much time a good PM spends just absorbing context and working out what matters. Not just for the next week, but for the next quarter. 

The one thing that did get easier was convincing engineering to make changes. Because the whole team was now closer to how users actually behaved, I didn't have to justify much. Engineers had seen the problems firsthand.

After 4 months, we hired a PM again and I now look for different things in a PM. Less translating between engineering and users, because the team can now do some of it themselves. More deciding what's important and challenging our assumptions.

What I haven't figured out is where the line sits now. The team got used to owning parts of this themselves, and I'm not sure we should undo that.

This report is saying PMs are dead by 2030. Are we cooked?

How are they oblivious to the feedback? People are practically begging them to keep the old search.

I recently inherited a product team that I manage now and my team is across the spectrum in their skillset and capability.

Recently, I’ve noticed some of the “high performers” on my team are overly relying on Claude for their jobs. For example, I read a PRD and although long (30 pages) and well thought in some areas, it was missing key details about the product and had inaccurate assumptions on certain features.

I’m also noticing a strange phenomenon among my larger org where these long-format docs are getting praised while concise thinking is being shunned as not articulate or well thought out.

How are other managers dealing with this? I’ve built AI products and am very comfortable with Claude myself so am mostly interested in technical PMs comfortable using these tools but navigating a similar shift in culture

How are other PMs thinking about AI features that help someone during the job instead of telling them what went wrong afterward. I’ve been looking at this through contact centers. The usual workflow is pretty reactive. Calls happen. A small sample gets reviewed. Managers spot problems. Agents get coached days later. AI changes that a bit. If an agent misses a required step or can’t find the right policy then the system can catch it during the call and surface the right info. That could prevent a bad outcome instead of explaining it later.

But the UX seems tricky. Show too much and the agent is fighting the software while talking to a customer. Show too little and you’ve built another dashboard nobody checks. Get something wrong at the wrong moment and trust drops fast. I was reading about how products like Cresta handle this by using conversation data for live agent guidance as well as QA and coaching afterward. That approach makes sense to me because the feedback loop isn’t limited to a report someone reads days later.

There’s also the employee side. PMs might see “real-time guidance.” Agents might see “software watching everything I say.” What seems more useful to me is connecting live agent help with the same conversation data used for QA and coaching afterward. That way the product isn’t just pointing out mistakes later. It can help prevent them while the customer is still on the call. PMs who’ve worked on real-time assist products: how did you decide when the AI should step in?

For those that have both in their organization, how are the two defined? Is there a hierarchy in their relationship? How is the work divided?

Right now I work at a company where I am the only PM with no POs, so I do it all in terms of strategy, roadmap, and execution. I’m interviewing with a company that has the PO own strategy and roadmap and PM owns execution. This is the reverse of what I would have expected.

Hi wondering how people are thinking about this.
-Are people concerned that their AI products could be commoditized relative to base models (e.g., Claude)?
-Are customers / users asking why not just use base models instead of buying their product?

Hello,

We're thinking about how we could estimate beta releases in our company. We're a B2B product and sometimes we deliver beta version that can require different capacity according to feedback given. Our roadmap is estimated using number of days required to produce an output. However, in this case the number of days can double if the feedback requires a lot of work and company policy is that once in roadmap, it can't move from it.

What are the tools you would use in this situation to allocate time for these beta releases?

Thank you in advance:)

Has anyone worked in an organisation where leadership have become so sold on the idea of being able to move to a “product operating model” that they throw out all normal programme and project management functions, including for the delivery of work that is physical in nature like building new sites, delivering reforms across multiple in person and digital services or other large scale initiatives that touch many product teams?

If yes, did it work? If no, what were your learnings? if this sounds like a bad idea, what would your reasons be?