The PM as Automation: Why Product Managers Build Systems That Break

Brian Sierakowski - Founder

A Product Operations lead at a large developer tools company recently described a pattern I’ve seen at every organization I’ve worked with: “PMs kind of create their own systems. They tend to think, I need to solve this problem with generic tools — like spreadsheets. And then they are the automation.”

Read that last part again. They are the automation.

The PM builds a spreadsheet to track releases. The PM builds a process to gather updates from engineering. The PM builds a workflow to notify stakeholders. And then the PM becomes the single point of failure for it all.

The Spreadsheet Trap

Here’s how it typically starts:

  1. A PM needs to know what’s shipping this sprint
  2. There’s no good system for this, so they create a spreadsheet
  3. The spreadsheet works great — for that PM, for that sprint
  4. Other people start asking for access
  5. The PM becomes responsible for keeping it updated
  6. The PM leaves or gets busy, and the spreadsheet rots

I’ve seen this pattern play out dozens of times. A Director of Product at a workplace software company told me their PMs “hate creating product documentation and frequently forget.” The bespoke systems they build are no different — maintained only as long as someone has bandwidth.

PMs aren’t bad at building systems — building systems simply isn’t their job. Every hour spent maintaining a release tracking spreadsheet is an hour not spent talking to customers or shipping product.

Why Every PM Does This Differently

Walk into any mid-sized company and ask three PMs how they track releases. You’ll get three different answers:

  • PM 1 uses a Notion database
  • PM 2 uses a Google Sheet with custom scripts
  • PM 3 just reads Slack and remembers

None of these systems talk to each other. None of them survive that PM moving to another team. And none of them scale beyond a single person’s cognitive load.

A VP of Product Marketing at an observability company described the downstream effect: “We have a releases Slack channel, a love channel, a changelog page — and we still have to hunt across all these sources for meaningful updates.” The information exists, fragmented across every PM’s personal system.

This fragmentation happens because there’s no standard way to answer a simple question: what shipped?

The Meeting Tax

When personal systems fail, organizations compensate with meetings.

A Director of Product described her company’s release process as “absurdly cumbersome” — three or four sync meetings per week just to track what’s shipping. The meetings exist because no system reliably captures the information.

This is the hidden cost of the PM-as-automation model. When the PM is the system, the only way to extract information is to talk to the PM. Scale that across ten PMs and twenty stakeholders, and you’ve built a company that runs on status meetings.

One Head of Developer Relations at a startup put it simply: his goal was to “reduce reliance on lengthy cross-team meetings to learn what shipped.” He wears many hats, and every hour in a meeting is an hour not spent on docs, content, or community.

The Unmaintained System Problem

Bespoke PM systems have a half-life measured in months.

Consider what happens when:

  • The PM who built the system leaves the company
  • The PM gets promoted and no longer has time to maintain it
  • The scope grows beyond what one person can track
  • Someone asks a question the system wasn’t designed to answer

In each case, the system becomes technical debt. It’s too useful to delete, but too outdated to trust. Teams start working around it, building their own parallel systems, and the fragmentation compounds.

At an enterprise data management company, the documentation burden is significant enough that it’s actively blocking their path to continuous delivery. They know CI/CD would help them ship faster, but they can’t figure out how to keep up with the release notes. Their PM systems weren’t built for that velocity.

The Standardization Paradox

Here’s the uncomfortable truth: you can’t standardize PM systems by asking PMs to use the same tools.

Every PM has different needs, different team structures, different communication preferences. The spreadsheet that works for a platform team doesn’t work for a growth team. The Notion database that works for a startup doesn’t scale to an enterprise.

And yet, without standardization, you can’t get reliable, organization-wide answers to basic questions:

  • What shipped last month?
  • What’s coming in the next release?
  • Which features address the feedback customers gave us?

A Product Operations lead described the challenge: “How do you standardize outputs so different PMs don’t get wildly different summaries from the same data?” You can’t solve this by buying another tool and asking PMs to use it. They’ll customize it into another bespoke system within weeks.

The Alternative: Systems That Don’t Need PMs

The answer isn’t better spreadsheets or more disciplined PMs. It’s removing PMs from the automation loop entirely.

What if the system that tracks releases doesn’t require anyone to update it? What if it captures what ships automatically, directly from the source — the code?

This shifts the PM’s role away from data entry and toward quality control. Instead of building and maintaining tracking systems, they review and refine outputs. Instead of answering “what shipped?” they answer “why does it matter?”

Teams that make this shift share a few patterns:

  1. They instrument the development process. The act of shipping something automatically captures context about what it does.

  2. They separate capture from curation. Raw data about what changed gets captured automatically. Humans with context refine the narrative.

  3. They make outputs consistent by default. Different PMs get similar summaries because the system — not the individual — defines the format.

  4. They accept imperfection. An 80% accurate automated summary is better than a 100% accurate manual summary that never gets written.

Shifting the PM’s Role

The PM-as-automation model assumes PMs should build communication systems. But building systems is hard, and maintaining them is harder. PMs are better at understanding customers and making decisions than they are at data engineering.

The alternative model treats PMs as editors, not authors. The system drafts; the PM refines. The system captures; the PM curates. The system distributes; the PM decides what’s important.

The goal here is applying PM judgment to the right problems. PMs waste their insight about customer value when they’re copying text from Jira tickets into a spreadsheet.

Breaking the Cycle

If you recognize your organization in this post, here’s the pattern to break:

  1. Audit your bespoke systems. How many spreadsheets, Notion databases, and custom workflows exist? Who maintains them?

  2. Count the meetings. How many recurring meetings exist primarily to share status updates that systems should provide?

  3. Find the single points of failure. Which PMs would cause chaos if they went on vacation for two weeks?

  4. Identify what’s actually needed. Strip away the custom systems and ask: what questions do stakeholders actually need answered?

The PM who builds the perfect release tracking system is solving the wrong problem. The right problem is making release tracking automatic.

Your PMs are too valuable to be spreadsheets. Stop asking them to be.

If your PMs spend more time tracking releases than improving products, let’s chat about how Changebot automates the capture so they can focus on what matters.