Ready to build your own Founder-Led Growth engine? Book a Strategy Call
Frontlines.io | Where B2B Founders Talk GTM.
Strategic Communications Advisory For Visionary Founders
CSMs hear more product signal than anyone in the company. The problem is structural: in most orgs, that signal travels across reporting lines, gets filtered, and rarely lands with authority. Andrew's move was to eliminate the translation layer entirely — not improve the feedback loop, but remove it. "How much authority do you really have in what you're building?...If the answer is like, I don't really know that I have that much authority in it which was where I've kind of always found myself. Maybe, maybe you can do things differently."
When Andrew explained the structural shift to his enterprise accounts, the reaction was unanimous and, by his own admission, stronger than he anticipated. The reason is straightforward: buyers already trusted their CSMs. Learning those same people now own product decisions collapsed the gap between relationship and roadmap. "What they tell us is that they now believe that the people that they trust that know them the best, that know their users but know how they're actually using it, are the ones who are making decisions about the tool."
Andrew came into product without a technical background and made a deliberate choice: trust engineers completely on feasibility, and own priorities completely himself. This isn't a workaround — it's a cleaner division of accountability than most product orgs actually practice. "My approach is sort of, in some ways, like, use that ignorance, because I have to trust them. I have to give them accountability."
In fast-moving markets, priority discipline is the hardest thing to maintain and the most important. Andrew is explicit about where he draws the line. "You have to be willing to stack rank things...I'll never tell people that. There are three top priorities, and all these three things are most important. I hear that a lot. It frustrates me."
Every company claims to be customer-centric. Andrew's argument is that the claim is meaningless unless decision-makers are in direct, ongoing contact with customers. The CS-plus-product structure isn't a cultural initiative — it's an accountability mechanism. "If you really want your customers to trust you, if you really want your customers to think that they have a say in what you're building" — the org has to reflect that. And on shiny new AI capabilities: "just because you can build it and you think it's sexy, doesn't mean that they care about it."
Rohirrim: Why the Chief Customer Officer Took Over Product — and What Every Enterprise SaaS Team Can Learn From It
Andrew Shoaff has been in customer success since, as he puts it, “the earth was filled with low, shallow water.” He started in the late 1990s, when enterprise software was on-prem and customer success was effectively cost of goods sold — a servicing function that, as he says bluntly, “nobody cares about anymore.” He watched the SaaS transition turn that function into revenue leadership. After twenty-five years in CS, he thought he understood what the function could become.
Then, six months ago, he took on product management too — and discovered something he hadn’t anticipated. The customers loved it.
The Structural Problem Most CS Leaders Won’t Admit
In a recent episode of The CX Front Lines, Andrew laid out a problem that most CS leaders either don’t see or won’t say out loud: the feedback loop between customer success and product is broken at the organizational level, not the process level.
“CSMs hear a lot of things…the question is how well does the feedback that CSMs have themselves, the feedback that they hear from customers, how well does that make it into decisions about what to build…It’s easy to say, sure, we have that. It’s actually kind of hard to do that.”
The reason is structural. In most companies, product reports to the CTO while CS reports to the CRO or Chief Customer Officer. Different reporting lines mean different incentives, different planning cycles, and different definitions of what matters. Voice-of-customer programs exist to bridge that gap. They work inconsistently at best.
Andrew’s diagnosis: “You got product is under CTO, the CTO and then the CRO or the chief customer officer. Those are ultimately, you’re following different people.”
His solution wasn’t a better feedback mechanism. It was a different org chart.
Merging Product Into CS: What Actually Changed
At Rohirrim, a native generative AI startup serving enterprise accounts, Andrew built what he calls a singular customer experience organization — product management and customer success under one roof, shared accountability throughout.
The immediate effect was that product managers were expected to talk to customers daily. Not monthly in a research sprint, not quarterly in a business review. Daily. That single expectation changed the role’s definition. “Giving product managers the expectation that daily they’re talking to customers…has changed the way we look at product management from like a technical functional pursuit to a strategic pursuit first. And then how do we have the technical bits follow the strategy.”
The second effect was less obvious. Pulling product into CS pulled engineering closer to the customer team. “What bringing product into CS has done is help bring the engineers and the customer success team much closer. We’re a startup company, we’re not a huge company. So there’s every reason why we should have been talking to those guys…so often. And we just weren’t doing.”
His regret was direct: “Had we done that a year ago, figured out a way of doing that a year ago, honestly, our company would be in a pretty different place than we are right now.”
The Enterprise Buyer Reaction Nobody Expected
Andrew anticipated the structural change would improve internal alignment. He did not anticipate how enterprise buyers would respond when he told them about it.
“I did not anticipate the extent to which to a account every single one of our customers would love it when I explained to them hey we’re doing some role shifts…they love it because they believe that the people they know and the people they trust to know them are now the ones making product decisions.”
The logic from the buyer’s perspective is straightforward. Enterprise relationships are built on trust with specific people — CSMs who understand the account, know the users, and have seen how the product actually gets used. When those people become the decision-makers on the roadmap, the gap between what customers say they need and what gets built narrows in a way that program-level commitments rarely achieve.
“What they tell us is that they now believe that the people that they trust that know them the best, that know their users but know how they’re actually using it, are the ones who are making decisions about the tool.”
The Discipline the Structure Demands
The model only works if the person running it can make hard prioritization calls. Andrew is explicit about the failure mode he refuses to replicate. “You have to be willing to stack rank things…I’ll never tell people that. There are three top priorities, and all these three things are most important. I hear that a lot. It frustrates me.”
In a generative AI market where new model capabilities emerge faster than most teams can absorb, the temptation to chase what’s newly possible is constant. Andrew’s filter is always the customer. “Just because you can build it and you think it’s sexy, doesn’t mean that they care about it.”
His own lack of technical depth reinforced rather than undermined his effectiveness. Because he cannot evaluate technical feasibility himself, he doesn’t try. He gives engineers full authority on what’s possible and focuses on what’s worth doing. “My approach is sort of, in some ways, like, use that ignorance, because I have to trust them. I have to give them accountability.”
The Principle Behind the Org Change
Most customer-centric transformation efforts fail because they treat the problem as cultural. Andrew’s argument is that culture follows structure — and that if the people closest to customers don’t have actual authority over what gets built, voice-of-customer programs won’t close the gap.
The question he asks CS leaders is simple: “How much say do you have? How much authority do you really have in what you’re building?”
If the answer is uncertain, the problem isn’t process. It’s the org chart.