Pieter Boon

Pieter Boon's writing returns again and again to one core diagnosis: customer success teams collect signal constantly, but almost none of it gets acted on in time. His account of a typical lost customer lays this out with almost clinical precision: usage drops in month 2, the CSM notices something is off by month 6, the customer raises a concern in month 9, and by month 11 it's already a renewal conversation instead of a save. "The information was there the whole time," he writes. "The problem wasn't the customer. It was that nobody had a system that surfaced the signal early enough to do something about it" . This is the thread running through nearly everything he says: the failure in customer success is rarely a knowledge problem, it's a timing and permission problem.

That permission piece shows up most explicitly in his thinking about psychological safety inside CS teams. He argues that leaders need to invert how they treat risk reporting: "A flagged risk is a win. It means someone caught the signal early enough to act on it," while "an unflagged risk is the actual failure" . The CSM, in his framing, is usually the first person in the org to sense trouble, an exec gone quiet, a champion who's left, usage that's slipping, and if raising that isn't safe, the system has already broken before the renewal ever comes up . This connects to his repeated frustration with how CS performance gets measured. He tells the story of his best CSM having the worst NRR on the team, purely because she was handed the hardest, worst-fit accounts, and warns that leaders who "manage your CS team on retention numbers alone" end up rewarding "the easy book" and punishing "the people doing the real work" . He extends this into a broader critique of proxy metrics, quoting a fellow CS leader's line that "all our metrics are proxies... none of them actually tell me if the customer is succeeding" , and pointing out that the same login spike can mean deep adoption or one confused admin clicking around in confusion .

Boon is also sharply skeptical of how the industry talks about being "proactive." He says nearly every CS leader claims to want a proactive team but "almost none of them know what that actually means" , and that under the surface, CSMs are still buried in invoices, support tickets, and implementation work nobody else wanted, while nobody has actually defined what "successful" looks like for a given account . His answer isn't a slogan but a structural split, separating reactive account work from a genuinely proactive motion, and he frames this in terms of playing both defense and offense: unify customer data so every CSM works from the same picture, build signals to catch risk early ("defend your base"), and then set milestones and chase them deliberately rather than just reacting ("play offence") . This defense/offense framing recurs as his shorthand for what proactive CS actually requires operationally.

On the question of AI, his position is pragmatic rather than defensive. Rather than reassuring customers that "you still need us," he describes actively testing his own product's territory with Claude to find "where it's genuinely impressive... where it falls apart... where the product actually earns its keep," and then converting those findings into talking points for renewal conversations . His line is blunt: "'trust me, you still need us' doesn't survive a budget review," but proof of specific gaps does . He treats a leader's discomfort with letting their team run that experiment as itself diagnostic: "if the idea... makes you nervous... that's the real signal. Run it anyway" .

His view of data and "voice of the customer" work follows the same logic of using what's already there instead of chasing more inputs. He describes a customer who pulled 90 product complaints out of 600-700 accounts, already sitting in the CRM across tickets and notes, and used it to move a feature up the roadmap without commissioning any new research . For him this marks the real shift from CS as "account manager relaying feedback" to CS as "internal influencer bringing evidence," and his advice to teams is concrete: mine tickets, calls, and notes for repeating patterns, then build a data-backed narrative rather than waiting to be handed an insight . This same instinct, that founder-close feedback loops are seductive but limited, shows up in his account of building his own tool: starting as both CSM and product owner gave him instant feedback, but he learned "you don't have the luxury of being both CSM and product owner" once you're inside a larger org, so feedback "has to be forced into the loop; continuously, deliberately" .

Finally, Boon is candid about the management side of CS, particularly the common failure of promoting a strong CSM into a leadership role with no support. Drawing on his own experience as a "first-time manager" who "made every mistake in the book," he insists that being a good manager is a fundamentally different skill from being a good CSM: "One is about your own execution. The other is about creating the conditions for other people to execute well" . His practical fixes are modest and specific rather than grand: get a mentor who's managed before, invest in leadership training even informally, and treat the two skill sets as genuinely separate rather than assuming one implies the other . Combined with his broader framing that not every SaaS company needs a dedicated CS function, that the need depends on product complexity and pricing tier, with simpler, lower-ticket products better served by tech-touch ¹², and his experience-based caution against adopting a customer success platform before the data infrastructure is ready ¹¹, the overall picture is of someone who keeps steering conversations away from tools and slogans and back toward structure, timing, and what's actually being measured.