The scenario reads like a stress test for every assumption modern tech companies hold sacred. A startup loses its founding PM, the person behind every major product decision, the keeper of market insight, the navigator through AI-driven disruption. Simultaneously, engineers discover Claude Code and suddenly have bandwidth they never had before. The founder’s logic: if engineers can move 3-5x faster with AI agents, maybe they can absorb the PM’s responsibilities too.
Four months later, they hired a new PM. But the experiment wasn’t a failure, it was a revelation about where product management actually creates value, and where AI tools genuinely change the game.
The Feedback Loop That Got Better Without a PM
The first thing the team tackled was user feedback collection. Their PM had monitored Intercom chats and reached out to users individually, a practice that provided rich context but created a bottleneck. Everything flowed through one person.
One engineer built an in-app feedback system that did something clever: it collected feedback at the exact moment things went wrong, then ran it through an LLM twice weekly to surface key issues to a shared Slack channel. The automation didn’t just replace the PM’s monitoring, it improved on it.
The critical difference: when feedback lived in one person’s head, nobody else felt responsible for it. When the system distributed it across the entire engineering team, engineers started commenting on what was broken, debating what mattered, and taking ownership of problems they could see.
This pattern aligns with broader shifts in how teams leverage AI. The key insight from our analysis of AI’s practical integration in technical teams is that the November 2025 inflection point wasn’t about agentic coding replacing humans, it was about tools that collapse the distance between user behavior and developer action.
Session Watching Got Smarter, Not Just Faster
The second improvement came from rethinking user session analysis. Their PM used to watch sessions to understand user struggles, a time-intensive practice that relied on one person’s ability to spot patterns across hundreds of hours of footage.
One engineer realized the bottleneck wasn’t watching sessions, it was finding the broken ones. He built logic to flag specific moments of failure. If a user dropped off mid-session on feature X, the engineer who owned feature X got the session link automatically.
This matters because it changed the feedback loop from osmotic to direct. Engineers could watch their own work break with a real user on the other side, and fix it the same day.
But here’s the subtle catch that emerged: session watching isn’t only about catching breakage. A commenter with product leadership experience noted that their teams generate more UX improvement ideas from one hour of watching a user work than from weeks of internal debate, not because they’re finding bugs, but because they’re observing users doing things the team never expected.
The founder admitted this was the part his team did least well. Flagging failures is deterministic. Discovering unmet needs requires someone asking “what are they trying to accomplish that we didn’t build for?” That’s harder to automate, and harder to distribute across a team that’s busy shipping.
The Prioritization Wall
Here’s where the experiment collapsed.
With feedback flowing directly to engineers and session flags triggering immediate fixes, the team had more context than ever before. Every engineer had opinions about what to fix. The marketer had market insights. Problems were visible, solutions were proposed, and everyone was moving fast.
But nobody was deciding.
The founder’s own words capture the failure precisely: “Four people with good judgment create four good lists, not one ordered list.”
This is the hidden cost of distributed product ownership. When responsibility is diffuse, prioritization becomes political. Not in the malicious sense, but in the sense that there’s no accountable arbiter whose job is to absorb context and make judgment calls that will disappoint someone.
The founder ended up owning prioritization himself, and it was much harder than expected. He underestimated how much time a good PM spends absorbing context, not just for the next week, but for the next quarter. The role isn’t about translating between engineering and users anymore, that part genuinely got easier with AI-augmented feedback loops. The irreplaceable function is deciding what matters and defending that decision against competing interests.
One commenter offered the most memorable framing: “We got rid of our pitcher. We found out that we could have the first baseman walk up to the mound. The second baseman spit near the mound, and the third base coach was able to adjust his hat. The only thing that didn’t work was throwing the ball to home plate.”
What Actually Changed in the PM Role
After four months, they hired a new PM, but the job description changed. The founder now looks for someone who does less translating between engineering and users, because the team can handle some of that themselves. What they need is someone who decides what’s important and challenges the team’s assumptions.
This maps to a broader tension in the industry. The traditional PM role is being squeezed from both directions. Engineering teams, armed with AI tools, are absorbing more of the discovery and feedback work. Meanwhile, the strategic context, understanding market shifts, navigating competitive pressures, and making hard tradeoffs, remains stubbornly human.
The uncomfortable question is whether this experiment was successful or not. Feedback collection improved. Bug resolution accelerated. Engineers gained user empathy. But the central coordinating function, the thing that connected all that distributed intelligence into a coherent product strategy, still required a single accountable human.
The AI Slop Problem
The experiment also surfaced a darker side of AI-augmented product work. A separate discussion among product leaders revealed concerning patterns: high performers over-relying on Claude for PRDs, producing 30-page documents that were long on verbosity and short on accuracy.
One product manager described the phenomenon bluntly: long-format docs were getting praised while concise thinking was being shunned as “not articulate.” This is the AI-generated-content trap in its purest form, volume masquerading as depth.
The response from experienced leaders was brutal and correct: refuse to review AI slop. If a 5-page document would suffice and someone submits 30 pages, send it back without reading. This connects directly to the importance of engineering discipline in the AI era. AI doesn’t reduce the need for judgment, it amplifies the consequences of its absence.
The founder echoed this when discussing their feedback pipeline: the LLM “softens” raw user comments too much. They read almost every comment in raw form to truly understand it, because automated summaries flatten the messy, contradictory, emotional reality of user feedback.
What This Means for Engineering-Led Product Teams
The four-month experiment offers a nuanced answer to whether engineering teams can replace PMs. It’s neither the dystopian “PMs are obsolete” narrative nor the defensive “PMs are irreplaceable” backlash. It’s an organizational design question with real tradeoffs.
What worked:
- AI-augmented feedback collection that meets users where they struggle
- Direct session ownership that connects engineers to user outcomes
- Faster bug resolution through automated failure detection
- Broader team engagement with user problems
What failed:
- Prioritization across competing but valid interests
- Long-horizon product thinking (the quarterly vs. weekly distinction)
- Challenging assumptions rather than executing on feedback
- Coordinating multiple co-equal problem-solvers without duplication
The founder’s unresolved question is the most interesting part: the team got used to owning parts of the PM role themselves, and he’s not sure they should undo that. The line between engineering ownership and PM authority is now blurry, and that blurriness might be the healthiest outcome.
Teams like this face another risk worth naming: the burnout risks from over-reliance on AI and accelerated workflows. When engineers can ship faster, there’s pressure to absorb more responsibilities. The PM role doesn’t disappear, it gets redistributed, and someone still has to absorb the context, make the calls, and own the outcomes.
The most honest answer to whether engineering teams can replace PMs is: partially, and only in specific functions. AI tools genuinely eliminate the information-brokering part of product management. But the judgment part, deciding what matters when everything matters, defending tradeoffs to stakeholders, and maintaining a coherent vision across quarters, remains a distinct discipline. The best outcome of this experiment isn’t the elimination of PMs. It’s a redefinition of what they should actually be doing.
The startups that figure out this new division of labor, AI-augmented engineering teams handling discovery and feedback, PMs focused on prioritization and strategy, will have a structural advantage. The ones that treat this as an either/or proposition will discover, as this team did, that you can remove the pitcher. But someone still has to throw the ball.