Signal vs. Noise: What Customers Actually Care About
I was recently helping a Chief Product Officer review their release notes for the month. We went through the list of changes together, and about halfway through, they paused.
“Half of these items are like adding a database index,” they said. “I know that was a valuable change… but that’s noise when communicating benefits to customers.”
They were right. And this is a problem I see at almost every company: the inability to distinguish between work that matters internally and work that matters to customers.
Not All Work Is Customer-Facing
Here’s a sample of what engineering shipped last month at a typical SaaS company:
- Added new onboarding wizard
- Upgraded to PostgreSQL 15
- Fixed race condition in payment processing
- Added database index on user lookups
- Implemented new dashboard analytics
- Refactored authentication module
- Fixed typo in error message
- Migrated to new hosting provider
- Added retry logic for failed API calls
- Updated dependencies to patch security vulnerability
Some of these are major customer-facing improvements. Some are important but invisible. Some are somewhere between. And the challenge is that to the people who did the work, all the changes feel significant.
The Filter Problem
When teams don’t filter, two bad things happen:
Option A: They share everything. The monthly update becomes a wall of technical changes that customers can’t parse. The important stuff gets buried. Customers skim, learn nothing, and stop reading updates altogether.
Option B: They share nothing. Faced with the difficulty of filtering, the team delays or skips the update entirely. Customers don’t know what shipped. The company gets no credit for its work.
Neither outcome serves the customer or the business.
What Makes Something Customer-Facing?
Here’s a simple framework for filtering:
Customer-visible: Will customers notice this change in their day-to-day use of the product?
- New onboarding wizard: Yes
- Database index: No
Customer-impactful: Does this change affect something customers care about (speed, reliability, cost, capability)?
- Fixed payment processing race condition: Yes
- Refactored authentication module: Probably not directly
Customer-communicable: Can you explain the benefit in terms the customer understands?
- “Faster page loads” is communicable
- “Reduced technical debt in auth layer” is not
If a change passes at least one of these tests, it’s a candidate for customer communication. If it passes none, it’s probably noise.
The 80/20 Reality
A CEO at a fintech company told me: “Roughly 80% is good to know internally, 20% relevant externally. There’s no good system today for separating internal vs. external.”
This ratio holds at most organizations. Engineering ships a lot of work, and most of that work stays invisible to customers by design. That’s not a problem — that’s how good products get built. Infrastructure improvements, technical debt reduction, and internal tooling all matter.
The problem is when organizations can’t distinguish between the two categories, leading to either over-communication (noise) or under-communication (silence).
Why This Is Hard
Filtering requires context that doesn’t live in any single place:
Technical context: What did this change actually do? (Lives in the code)
Business context: Why did we build this? (Lives in the PM’s head)
Customer context: Who cares about this? (Lives in support/success knowledge)
Communication context: How should we talk about this? (Lives in marketing)
No single person or system has all four. Engineers know what changed but not necessarily why it matters to customers. Marketing knows how to communicate but not what actually shipped. Support knows customer pain points but not the technical details of fixes.
This is why filtering often fails: it requires synthesis across organizational boundaries that rarely happens organically.
Signs You’re Getting It Wrong
Too much noise:
- Customers stop reading your updates
- Updates read like technical changelogs
- “Bug fixes and improvements” appears regularly without specifics
- Internal stakeholders forward updates asking “what does this mean?”
Too much silence:
- Customers don’t know about features that exist
- Support gets surprised by changes
- Churn mentions “we didn’t know you had that”
- Sales team has stale battle cards
The worst case:
- You’re doing both: sharing too much detail about things that don’t matter while missing the things that do
Practical Filtering Approaches
Review as a team. Don’t let one person filter alone. A quick 15-minute review with engineering, product, and marketing catches misses and reduces noise.
Use explicit categories. “Customer-facing” vs. “internal” as a required label on every change. Forces the question early.
Separate internal and external channels. Internal teams might care about the database index. Customers don’t. Have different destinations for different audiences.
Ask the support test. Would support need to know about this to help customers? If yes, it’s probably customer-facing.
Apply the “so what” test. For every item, ask: “What does this mean for the customer?” If you can’t answer directly, it’s probably noise.
The Key Updates Paradigm
When showing a demo to a Head of Product recently, I showed her our “key updates” filter, an automatic classification of which changes represent customer value. Her response: “That’s a game changer.”
The insight is simple: you need a system that separates signal and noise before a human ever has to review it. If the starting point is “here are 100 changes, you figure out which ones matter,” you’ve already lost. The cognitive load is too high.
The better approach is “here are the 12 changes we think customers will care about, plus the full list if you want to dig.” Reduce the filtering burden to validation, not discovery.
Building the Filter Muscle
Filtering is a skill. Teams that do it well have built the muscle over time:
They document patterns. “We never communicate dependency updates unless there’s a security angle.”
They create templates. “New features get a spotlight. Bug fixes get a line item. Infrastructure gets internal-only.”
They review retroactively. “Last month we shared X and got no engagement. This month we’ll try different filtering.”
They listen to feedback. “Sales said they need more on pricing changes. Let’s adjust our filter.”
Like any skill, filtering improves with practice. The first few attempts will be rough. That’s normal.
The Goal: Appropriate Communication
The goal is appropriate communication, not less communication.
Customers should know about things that affect them. Internal teams should know about things that affect their work. Everyone should be able to find more detail if they want it.
This means many channels, many formats, many levels of detail. It means thinking about audience before writing. It means accepting that one update won’t serve everyone.
The companies that get this right ship just as much as everyone else. They just communicate it more effectively.
If filtering signal from noise is taking too long, let’s chat about how Changebot automatically identifies what customers care about.
