The Vendor Side — What this section is about and who it is for
CS should function as a solution practice, identify where your technology creates exponential value, build repeatable patterns, remove adoption blockers through hands-on work.
If you lead customer success or professional services at a developer tools or platform technology company, something on this list will sound familiar.
Your early adopters are thriving. Your early majority cohort is churning at a rate that does not make sense given the product quality and value. Your CS team is working harder than ever while having diminishing impact and producing less. Someone has asked you to own the renewal number and you have a quiet suspicion that this is corrupting the work your team should actually be doing. Your PS function is operating as a free consultancy that closes deals and destroys margin.
These are not performance problems. They are design problems. And they are connected.
The thesis
Customer success at platform and developer tools companies should function as a solution practice — recognizing the maturity of the customer’s organization and teams, identifying where your technology creates exponential value, building repeatable patterns to reach that value faster, and removing adoption blockers through hands-on work.
Not a relationship motion. Not a hidden sales arm. Not a QBR calendar dressed up as strategic engagement and health score theater.
The CS motion that works for early adopters — exploratory, high-bandwidth, no script — is precisely the wrong motion for the early majority, who need scaffolding, templates, proven patterns, and a clear path to return on investment before they commit fully. Running one model for both destroys value for both cohorts and no amount of CSM training fixes a structural mismatch.
What the Vendor Side covers
The Wardley CS model. Simon Wardley’s evolution axis tells you what stage your technology has reached and helps you identify the maturity of the customer you are working with. That stage and maturity determine the engagement model the customer actually needs — and why the model that succeeded with early adopters is structurally wrong for the enterprise majority now at your door.
The chasm handoff. The transition from early adopter CS to early majority CS is where most developer tools companies lose momentum. It is a CS design problem, not a sales problem. The Vendor Side covers what the redesigned motion looks like and how to execute the transition without losing either cohort.
Separating CS from commercial responsibility. Commercial incentives corrupt CS judgment, because the incentives are misaligned or inappropriate. The case for moving renewal and expansion responsibility to the finance or the sales organizations is structural, not ideological. This section makes that case and covers the org design that supports it. This isn’t a run away from accountability, rather focus on the levers for real impact on the growth of your company’s business.
AI-native CS scaling. The best CS knowledge in your organization should not live in your best CSMs’ heads. It should be encoded into system prompts, coding standards, agent contexts, and reference architectures that disseminate without proportional headcount growth.
PS productization. The models that break the free-consultancy cycle and the internal case for making the change without losing deal velocity.
Who this is written for
Sofia leads CS at a developer tools vendor. Her early adopter segment is thriving. The early majority is arriving and churning. She is being asked to own renewal numbers that are corrupting her team’s judgment. Her best people are doing account management instead of solution work. She needs a CS model differentiated by adoption stage and freed from commercial responsibility.
Daniel is VP of Professional Services at a platform vendor. PS is operating as a deal sweetener. Customers expect unlimited advisory. The team is exhausted and the revenue does not reflect the value delivered. The constant discussion on what is the appropriate cost of Services is wearing him out. He knows the model is broken and needs the structural arguments to have the internal discussion persuasively.
If either of those sounds like your situation, this section is written for you.
The frameworks
The Vendor Side uses three lenses consistently:
Wardley Mapping to position technology on its evolution from genesis to commodity and match the CS engagement model to the stage.
Diffusion of innovation (Moore’s chasm) to differentiate the early adopter CS motion from the early majority CS motion — and design the handoff between them deliberately.
Team Topologies applied to post-sale org design — specifically the three interaction modes (collaboration, X-as-a-service, facilitating) mapped to customer adoption stages.
Cadence
One issue every two weeks. Each one addresses one specific structural problem in enough depth to be genuinely useful. Every issue is labelled [Vendor Side] in the subject line.
If you find the Builder Side (enterprise technology leadership) consistently irrelevant, you can turn off those notifications in your Substack settings. The Vendor Side will continue uninterrupted.
Reply to any issue if something resonates — or if you disagree. That conversation is where the thinking develops.
— Val
Val Yonchev · Platform Curve · valyonchev.com Associate Principal, Conflux · Team Topologies Valued Practitioner Director & Head of Enterprise Solutions and Customer Success EMEA, Apollo GraphQL
Connect or follow Val on LinkedIn