"I'll pass that along." The account executive says it. If they're not already over it, the customer nods their head. It sounds like follow-through, but everyone knows nothing will happen.
This sounds like apathy, but this disengagement is the logical response to feedback loops that don't work. For GTM teams, time is literally money. If your product feedback process doesn't result in actual customer outcomes that they can point to, they're not spending time on it. That's rational.
Before things were broken — or when everyone had a little more hope — maybe the account rep would ping the Product Manager. There was a connection between the person closest to the customer and the person building the product. Maybe it was a quick Slack message, a video call, or even bringing the PM into the next customer meeting. Sometimes it was no, but with explanation. Whatever happened next, it was something the rep could bring back to their customer. But when product went quiet, it stopped feeling worth it.
∗ ∗ ∗
The customer support engineer leaves the call, lets out a long sigh, and turns to her team lead.
"The account exec asked for an updated list of the customer's issues. I mean, I will generate it for them, but I know nothing has changed. There's no way they're going to close that expansion deal."
"It's not on us. Just send them the list. Besides, we've got a queue to manage."
Is this abdication of responsibility or pragmatism? If product issues aren't prioritized, addressed, and communicated, issues pile up — and customer support is left to drown. They're using the time they have to move forward where they can. That's rational.
When issues were still getting addressed — maybe when the company was smaller, or when there was better alignment — that piece of intelligence about an expansion deal might have made a direct line from customer support to product while there was still time to fix something. Without that relationship, the message still gets there. It arrives after the deal was lost, filtering down from what might have been an explosive CEO staff meeting.
∗ ∗ ∗
The engineering manager asks the team: "How did the sprint review go?"
"The PM signed off on everything. Said we're ready to release."
"That's good, right?"
"One would think. But all of that was a waste of time. I built what she asked for, but it's just another thing they'll show off in a keynote, no one will use, and we'll be stuck supporting until the end of time. Shoot me."
What looks like cynicism is really something more familiar: a practitioner who has stopped expecting his work to matter to anyone outside the sprint. The engineering manager has been around long enough to know the pattern. He builds. The PM ships. Someone presents. The feature lands in the product graveyard. He is not wrong to be skeptical. The system has taught him to be.
There was a time when he and the PM were aligned enough that he could ask "will this actually get used?" and get an honest answer, when his team's efforts felt connected to a customer outcome that someone could name. That connection didn't require a transformation. It required a relationship.
∗ ∗ ∗
Every function in the building has a version of this story.
The marketing team that builds the launch campaign from a product brief they received forty-eight hours before ship date, with no visibility into what drove the prioritization or what the CS team has been hearing for six months. The implementation consultant who discovers a customer's edge case at go-live because discovery was done without her. The sales engineer who builds a demo for a capability that the PM already deprioritized — because no one told him. The legal team that reviews contracts for features that haven't been scoped yet, and the security team that hears about the new integration from a customer advisory call.
These are not failures of communication in the ordinary sense. They are the predictable outputs of a model that treats cross-functional teams as the recipients of product decisions rather than contributors to them.
Here is the thing that changes everything: becoming a bystander is not a failure of character. It is a rational response to a system that has stopped making it worth your while to be anything else. The GTM rep who stopped submitting feedback, the support engineer who stopped escalating, the engineering manager who stopped asking questions — none of them woke up one day and decided to disengage. They were trained out of engagement, one unanswered Slack message and one unaddressed issue and one keynote feature at a time.
Which means the problem is not motivation. The problem is architecture.
And if the problem is architecture, then the person with the most agency to change it is the one whose job it is to understand the whole system. That is the product manager.
This book starts from a specific and uncomfortable premise: if the broader team isn't engaged with us, it is our problem to solve. Not because we caused it — the bystander problem predates any individual's tenure and outlasts any individual's departure. But because we are the function most positioned to see the full system and most able to change the conditions within it.
I know this because I've lived on both sides of it. I've been the PM whose roadmap process trained the people around me into bystanders before I understood what I was doing. And I've been the PM who found a different way — one that made the work bigger and the outcomes better and, not incidentally, a lot more interesting.
Whole Product Partnership is the practice of doing that. It changed how I show up as a product leader. I think it will change how you show up, too.