Why Nobody Knows What Your Product Team Shipped Last Month

Here's how Joshua Berkowitz, head of product at Bench, described what it used to feel like before his team fixed the loop between product and the rest of the company: "It felt like a black box to the rest of the company. Nobody knew what was happening. Requests would come in and nobody would see what happened to them." [1]

That's not a complaint about a bad quarter. That's a normal Tuesday at most companies. Product ships something: a fix, a feature, a whole redesigned flow. The information makes it exactly as far as the engineering channel that built it. Sales finds out from a customer. Support finds out from a ticket. The exec team finds out three weeks later, in a meeting, when someone asks "wait, did we already do that?"

Nobody decided this should happen. It's just what happens when a team treats shipping and communicating as the same act, when they aren't.

This isn't a vibe

I used to think this was a "some companies are just disorganized" problem. It isn't. It's the median experience.

In a 2025 survey of 3,574 employees across six countries, only 23% said they felt "well-informed" about changes at their own company. Thirty-nine percent said they felt "not really" or "not at all" informed. [2] A separate global study of roughly 4,000 employees and HR professionals found that only 20% say their company's communicators actually help them feel informed and connected. [3]

And this isn't just an internal product communication problem in the abstract — it shows up in revenue-facing work. Allego surveyed 330 B2B sales and marketing leaders and found reps can't answer roughly 40% of the product questions their own customers ask them. [4] That's not a training problem. That's a pipe that doesn't work.

Why it keeps happening

Three things, none of them anyone's fault in isolation.

The tools we use to announce things are built to forget. Slack's free tier now caps searchable history at a rolling 90 days. [5] Anything posted before that window effectively stops existing for anyone searching for it. Post a launch announcement in March, and by June, Slack itself has quietly filed it under "gone."

Publishing isn't the same as communicating. LaunchNotes, a company built specifically around this problem, draws the line well: most release-notes tooling is built around the act of publishing (a doc, a tag, a growing Notion page), not around making sure the right person sees it, understands why it matters to them, and knows what to do next. [6] Those are two different jobs, and most teams only do the first one.

One announcement, one time, isn't enough. Product coach Jori Bell puts it plainly, from her work with PMs on exactly this: "I feel like I have to repeat myself over and over again." Different people default to different channels (Slack, email, a meeting they half-listened to), and most information needs several exposures before it actually registers. [7] A single post, however well-written, is closer to a lottery ticket than a communication strategy.

What it actually costs

Support keeps re-triaging bugs that are already fixed, because nobody told them the fix shipped. [6] That's the boring cost — annoying, recoverable, invisible unless you're counting support hours.

The expensive one is sales. Somewhere on Blind, a PM vented about exactly this dynamic, quoting the Slack DM that set them off: "Hey it's Mark from Sales. Hey, sorry to be a bother, but just wanted to give you a heads-up that I already promised our largest client that the next product release would give them the ability to do a full data migration with one click." [8] That's a rep operating on guesswork instead of the real state of the roadmap, because nobody gave them a reliable way to know it. Multiply that by every rep, every deal, every quarter.

But the cost that actually stings is the one nobody puts on a slide. Aniket Parihar, a former PM at Zalando, described being told, despite shipping, "you're doing good work, but I don't fully see your impact" — and put his finger on why: "building doesn't equal recognition. And more importantly, as a PM, you're not rewarded for what you build or ship. You're rewarded for the business impact that others see you driving." [9] He traces a specific feature's low adoption to three things his team never did: "We hadn't communicated the why... We hadn't marketed it... We hadn't documented it." Shipping and being seen to have shipped are different achievements, and only one of them is optional.

The tools you already have don't fix this

The instinct is always to make a channel for it. A #ship channel, an internal changelog page, a "what's new" doc someone maintains between everything else they're doing.

None of it holds up, because each of these inherits the same failure it's supposed to fix. A Slack channel inherits Slack's own retrieval problem (see above). A Notion page becomes a graveyard the moment nobody's actively maintaining it, which is most of the time. A newsletter one PM writes every so often relies entirely on that one person's bandwidth, forever, with no system behind it if they get busy or leave. Jori Bell's advice to the PMs she coaches (communicate more than once, in more than one channel) is good advice. It's also, structurally, a workaround: it depends on someone's discipline holding up indefinitely, which is exactly the "nobody has time to broadcast this" problem in the first place.

And it's not like the dedicated tools solve this either. I checked eight of them: changelog platforms, feedback tools, announcement widgets. Canny gets closest on paper, with a page arguing almost word-for-word what this post is arguing: keep an internal changelog, keep customer-facing teams in the loop. [1] But it's still a customer-feedback tool with an internal mode grafted on. And not one of the eight gives any credit to the person who shipped the thing being announced.

Naming the problem

Here's the strangest thing I found while researching this: this exact failure is described constantly across product-management writing, in different words and from different angles, by people who've clearly lived it. But nobody's actually given it a name. Nobody's written the definitive piece that says "this is a distinct thing, it has a name, here's what causes it." Everyone's describing the symptom. Nobody's diagnosing the disease.

I think that's the actual problem underneath the problem. As long as this stays a vague, ambient feeling that "communication could be better," it competes for attention with things that have quarterly OKRs attached to them, and it loses. It only gets fixed once someone treats it as its own discipline: something that needs a system, not just good intentions from whoever shipped last.

That's the exact gap donzy exists to close: not another channel to post in and hope someone reads it, but a place where shipping a change, the company knowing about it, and the person who built it getting credited for it are the same event.

---

Sources

1. Joshua Berkowitz, Head of Product at Bench — canny.io
2. Staffbase × YouGov, 2025 International Employee Communication Impact Study — staffbase.com
3. Achievers Workforce Institute, 2026 Engagement and Retention Report — achievers.com
4. Allego, Who Owns Sales Enablement? (Oct 2021) — prnewswire.com
5. Forbes, on Slack's 90-day free-tier history cutoff — forbes.com
6. LaunchNotes, "Why Customers Ignore Product Release Notes" — launchnotes.com
7. Jori Bell, "Why Your Product Management Comms..." — joribell.com
8. Anonymous PM, Blind — teamblind.com
9. Aniket Parihar, via LogRocket — blog.logrocket.com