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

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 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?

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

I’m trying to understand how small teams handle user feedback about the product. Not selling anything. Four questions; answer any of them:

1. If you could change one thing about that, what would it be?
2. Walk me through the last time it happened. Where did the note go, and what happened after?
3. What have you tried, and where did it fall short?
4. If nothing changes for a year, what does that cost you?

One sentence is plenty. Thanks!

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.

Curious how other PMs handle this.

On my team, Product sets business priorities, but Engineering has increasingly become the deciding voice on what gets picked up, sequencing, sprint scope, and ultimately delivery dates.

I completely understand that Engineering owns estimates, feasibility and technical constraints. My issue is when “we don’t have capacity” or “this will take X months” ends the conversation rather than starting one about scope, tradeoffs, dependencies, or an MVP.

I find myself pushing back and asking those questions more than others on the Product side, and sometimes feel like I’m fighting the battle alone.

How does this work on your teams? Where’s the line between appropriately challenging Engineering and Product overstepping?

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:)

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?

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?

Pardon my generalization- I understand that PM and PO have multiple meanings and job functions at different organizations. In this context I’m referring to an embedded Product Owner in an agile team, where they join all team ceremonies and directly communicate with the engineering teams.

I work as a business analyst in the above team organization. I run sprint refinements and am for the most part the owner of user stories and requirements writing, but the PO ultimately makes all the decisions and calls on what the requirements should be. The team has run into several situations where the work is committed to, developed during the sprint, and when the PO tests everything, the feedback given is completely different from the requirements that were committed to. This leads to inefficiency, rework, and frustration on my end because of the amount of time spent in refinement sessions and development which goes out the window because the PO didnt communicate the requirements upfront.

Is this normal in a PO role? I feel that I overstepped by filling in requirements, but I’m not sure what I can do to prevent this from happening if the PO stays hands off until development is complete.

Hi, everyone,

I'm new to the role of product manager (around 3 months). Working in AI hardware, I’m currently using Google AI Studio to build a prototype and map out the product flow.

The thing I didn’t expect is that prototyping keeps exposing problems in my PRD—missing states, unclear logic, and assumptions I hadn’t fully considered. Every time I model the flow, I go back and revise the PRD, then update the prototype, and repeat.

I understand the processes are definitely valuable, but I’m not sure whether this is healthy product discovery or a sign that the requirements weren’t thought through enough upfront. The PRD also starts to feel like a constantly moving target.

I wanna ask for more experienced PMs：

Is this a normal phenomenon? Any suggestions for a beginners in the industry? And any tools you could recommend?

Thanks in advance!

I work at a large company whose core business is sales and distribution. Small product teams have existed across the company for several years, but there’s no dedicated product organization, standard operating model, or consistent discipline around product management.

The company swings between two extremes: either no one does product and everything runs like a waterfall project, or everyone wants to be the PM.

Many people on the business side have Product Manager titles but no real product-management experience. They demand ownership of the role without adopting any product practices.

Business SMEs who use the products also position themselves as PMs. Some have started using Copilot to create “product documents” and send them directly to engineering.

Meanwhile, some engineering managers are product-minded, which is generally valuable, but they also try to own the PM role.

The few experienced PMs sit within IT and report through the same leadership structure as engineering. We effectively operate as “secret PMs”: doing the actual product work while ensuring the business team remains the face of the product and gets credit for the few sound decisions and practices we manage to put in place.

There are a couple of director-level leaders with strong product backgrounds who deliberately hire experienced PMs. But the broader senior leadership—on both the business and IT sides—doesn’t really understand product. The few senior leaders with experience running mature product organizations have left fairly quickly.
I was originally hired by an experienced product leader, but a reorganization moved my team under someone else. Now I feel like I’m constantly defending my team’s value while trying to introduce real product management without threatening everyone else who believes they already own it.
It’s exhausting. And it’s not necessarily unique to this company. I experienced some similar challenges even at companies with solid product practices and maturity previously - a big difference here is no leadership at all to support me or my team.
Overall- I question if it’s worth it anymore. Maybe there is something better to do for a career - but I can’t figure out what.

Engineering has along with the team effort of PM implemented a great feature.

But the PM gets to present before the VPs. The engineering team gets referenced like this "the team implemented this feature"

When it's the team effort why does the PM gets to be the center of attraction.

Hey,

I want to get up to speed on these industries so that I can go further at my current role (PM in medical education).
If you have any newsletters, books, or anything useful that could help me get a better understanding of how these systems work, that would be greatly appreciated.

I work at a large bank and we’ve recently moved towards a new product structure that looks something like this:

PM → Product Lead (PL) → Product Stream Lead (PSL) → Tribe Lead

At the squad level, we typically have:

Product Manager (PM)
Product Lead (PL)
Squad Tech Lead (STL)
Engineers

The thing I’m struggling to understand is why there are now so many layers around product leadership.

For people working in big tech or large product organisations:
How many layers are there typically between a PM and the head of product?
Does every squad normally have both a PM and a Product Lead?

How do you prevent PMs from becoming glorified delivery managers in a structure like this?
Is it normal to just have 1 PM reporting into a PL?
Has anyone experienced a similar restructure? Did it actually improve product outcomes?
I

I’m a product lead at a SaaS business. My manager has given me feedback that I need to be more in the weeds with design. He doesnt like some of the screens we shipped and has critiqued that I hadnt picked up on it. It was fair feedback.

This is coming at the back of a mandate our new CPO has handed down to PMs that we need to critique every pixel, colour choice and wording choice.

I am quite opinionated but keep my lane at the UX level and trust my designers to do what they do best.

The designer is also extremely difficult to work with and takes a ton of energy to convince him to change anything.

However I want to improve my product craft and i’m keen to hear from others.

I work in a very highly regulated industry where domain expertise is king. About 6-12 months ago the general feeling with AI was that it's here to stay, but it isn't quite taking any jobs because developers need to constantly supervise and do a decent amount of manual corrections and supervision. Sort of like a new power tool that makes things way faster, but doesn't change the game totally.

Today, I honestly am not sure where this is going. I'm hearing too many jokes from developers saying "you could've just given AI your specs to get the same result, don't need me" or "AI one-shotted it, don't know where I'm needed". The newest models with a very good infrastructure makes it possible for AI to fix almost any bug or create any feature based on specs you give it. The scary part is, it's starting to get things right almost all the time. This wasn't the case just 6 months ago. Not only does it get the requirements right, there's very little code changes anymore.

I'm trying to get requirements to devs at a speed never seen before. Some devs are finishing work in a day that used to take weeks or even months.

• Testers are getting so busy they have no time for anything else but try to validate all the new stuff coming out.
• Product management is so busy trying to get quality requirements so that devs have work on their list.
• Designers are too slow and we can't wait for designs for every case.

We've had many refinement meetings which make us question refinement as a whole, because AI has already built the stuff for refinement so it becomes more of a demo than a refinement.

I actually raised an idea to the team:

• What if anyone can create requirements and specify what needs to be built? why does it have to be product people only writing requirements and improving the product? What if a dev, tester sees an improvement area, they ask PO or PM for a green light, but they can improve the product just as well?
  • Some immediately answered they can only know there is a problem to be solved, but they don't want to write what the solution should be. Especially testers or more junior devs.
  • The more senior developers, who have vast domain knowledge, are thriving with the idea. They continue to build, test and provide value for the users at high speed. The more juniors have no domain expertise yet, which really makes me think about where the roles are going.

Have you seen the change as well if you work in domain-specific products as well? Any predictions about how product teams will look like in the near future? Any good ideas?

Hi all, I've got the privilege of starting a new club at my business school for product management. We are in the process of shortlisting names to accurately represent it. Any suggestions or idea would be highly appreciated for the same. Please do try to include your reasoning or how it does relate to product management or why do you think it's appropriate.

Thanks in advance!!

There are a lot of people here working on projects of some sort - side projects, startups, podcasts, blogs, etc. If you've got something you'd like to show off or get feedback, this is the place to do it. Standards still need to remain high, so there are a few guidelines:

• Don't just drop a link in here. Give some context
• This should be some sort of creative product that would be of interest to a community that is focused on product management
• There should be some sort of free version of whatever it is for people to check out
• This is a tricky one, but I don't want it to be filled with a bunch of spam. If you have a blog or podcast, and also happen to do some coaching for a fee, you're probably okay. If all you want to do is drop a link to your coaching services, that's not alright

is that actually true?

I've been going through the 2026 product surveys (Product Focus, State of Product) and some of the numbers stopped me

- 34% have no clear primary metric they're accountable for

- of those who do, 35% are on revenue/P&L and about 4% on feature adoption

- 49% say they can't find time for data analysis and metrics tracking

- 4% think their company's metrics reflect the value of their work

- 40% do little or no experimentation, and set the roadmap on leadership

preference instead

I'm not a pm by any means, I work at a startup but does this mean the job is essentially being accountable for revenue numbers you don't control, without enough time to investigate, using metrics you don't believe in on a roadmap that isn't wholly yours?

so I guess I'm just kind of curious how accurate are those numbers?

and for those of you who work at SaaS companies how do you define success? does data play a significant role?

Just started in a new org. I want to ask AI how a feature on the website works based on the code. How can I do that? Does anyone have a guide or has done this as a PM and have any advice? Does it produce useful results or do you need to know the code/repos to give the right prompt for useful results? I have access to Cursor and Github.