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.