Why You're the Last to Know What Engineering Just Shipped

It is 2:00 PM on a Tuesday. The #releases channel in Slack just pinged with an automated message. A new version of the platform is live. As a product manager, this should be a moment of quiet satisfaction. Instead, it is the start of a frantic, disjointed scramble.

You open Jira to cross-reference the ticket numbers. You skim pull request descriptions that read like "refactored auth service to handle edge cases." You try to remember the nuance of a conversation you had with the lead engineer three weeks ago about whether this change would break existing SAML integrations. Then, a customer support ticket escalates: a user cannot log in. You didn't even know that was a possibility.

The problem is not that engineering is hiding things. The problem is that information lives in engineering systems, while you live in roadmap tools and customer conversations, and there is no clean handoff between the two. Engineering ships. You find out later. Customers ask questions you cannot answer. Support escalates bugs you did not know were possible. The release notes you thought were final turn out to be incomplete or wrong.

Anyway. We have built an entire discipline around agile development and continuous delivery, and we still seem to be having trouble figuring out how to tell each other what we just built.

The Format Problem

The disconnect is structural. Engineering documentation is written for engineers. Commit messages, pull request descriptions, and technical specs are accurate, but they are not in a format you can use to communicate with customers or leadership. They focus on the mechanics of the change, not the impact.

Product managers need narrative. You need to know what changed, why it matters, who it affects, and what the customer should do differently. An engineering artifact might state that a database index was added. You need to translate that into a message about faster report loading times for enterprise users. This translation process is manual, time-consuming, and prone to error. Research on information asymmetry in software product management confirms that the shift to agile accelerated delivery while simultaneously weakening documentation practices, leaving PMs with incomplete, outdated, or inconsistent information about the system they are supposed to be managing.

The tools we use make it worse. Engineers live in Jira and GitHub. Stakeholders and product managers live in Slack. The coordination breaks down across these boundaries. A customer issue comes up in Slack, you create a Jira ticket, an engineer asks a question in Jira, you go back to Slack for clarification, and eventually, the ticket gets implemented. But it is slightly off because some nuance from the Slack discussion did not make it to Jira. The context loss is real, and it is not a failure of effort. It is a failure of architecture.

As Melvin Conway observed in 1968, organizations design systems that mirror their own communication structure. The corollary for product management is uncomfortable: if your engineering team and your product team are not in the same communication loop, the information artifacts they produce will not be in the same format either. You will always be translating.

The Costs Nobody Measures

I don't know if this is actually true, but it often feels like we are optimizing for the wrong kind of speed. We celebrate deployment frequency as the holy grail of modern software delivery, without asking if anyone knows what we just deployed. On one hand, shipping fast is good. On the other hand, shipping fast without a narrative just means we are breaking things faster and confusing our users at scale.

This misalignment has real costs. Product managers spend hours acting as human routers, chasing down information instead of focusing on strategy. Research shows that knowledge workers spend nearly a quarter of their working week just looking for information or recreating things that already exist. Airtable's own research on product teams found that PMs spend 66% of their week on manual work, including chasing down information and compiling documentation, instead of driving strategy. When that information is the very product you are supposed to be managing, the drain compounds.

Engineering teams end up building technically sound solutions that fail to solve the actual user problem because the business context was lost in translation. Without a clear grasp of the strategic agenda, developers risk building features that are technically elegant but market failures. And ultimately, the customer pays the price when release notes are inaccurate or missing. They encounter friction, they open support tickets, and they lose trust.

Research on software release notes found that most releases list only 6 to 26 percent of all addressed issues in a given version. That is not a rounding error. That is a systematic gap between what shipped and what anyone outside engineering knows about.

The Human Workaround

Product managers who are good at this often have engineering backgrounds or have built strong individual relationships with engineers. They can read a pull request description and understand its customer implications. They know which engineers to ping and how to ask the right questions.

That shouldn't be a requirement. The process should work even when the PM is new, the engineering team is large, or key people are unavailable. Relying on individual relationships to bridge a structural gap is not a process. It is a workaround that breaks the moment someone leaves the team.

The answer is to treat deployments and release notes like any other entity in the system. Mews, the hospitality technology company, documented this approach in 2019: when they moved to continuous delivery, they automated the connection between deployments and customer-facing release notes, so that when a pull request merged and deployed, the associated release note published automatically. The technical writers prepared the narrative in advance; the system handled the timing. No one had to remember to loop anyone in.

This is the architecture the problem requires. Not better communication habits. Not a new Slack channel. A system where the information flow is automatic.

What the Artifact Looks Like

GitHub now supports automatically generated release notes that pull from merged pull requests and their labels, giving teams a structured baseline to work from. Tools like Graphite can automate label assignment based on file changes, so that every PR is categorized before anyone has to write a summary. Recent research on LLM-powered release note generation shows that systems trained on commit history, pull request descriptions, and code changes can produce structured, audience-appropriate summaries that outperform manual drafts on completeness and organization.

The point is not that automation writes the release notes for you. The point is that automation gives you something to review, rather than a blank page to fill. The PM's expertise goes into validating accuracy and tuning for customer impact, not reconstructing what happened from Slack threads and engineer memory.

Engineering teams that use systems like Doc Holiday produce release notes, API documentation, and changelogs directly from their workflows, pulling structured data from pull requests, commit history, and ticket metadata. That gives product managers a structured artifact at the start of the review process, not at the end of a long game of telephone. When the process is set up correctly, you stay aligned because the information flow is automatic, not dependent on someone remembering to loop you in.