“Dreams (Feat. Judah and the Lion)” by NEEDTOBREATHE and Judah and the Lion
I’ve been thinking about onboarding paths – how folks hope there is one golden path for customers in their organization only to find that “the one path” is not working as they had hoped.
I am reminded that internal organizations at end user companies do not always know sales methodologies, and that engineers, technical product managers, and product managers alike can benefit from strategies that help teams approach how they close internal customers and provide the best support.
Sales teams often do not adopt “One-Golden-Path” because they have learned early that customers can come from several discrete places, have different personas, and thus need outreach mechanisms aligned for them.
The challenge is that each of these is an investment and the farther away you are from revenue, the harder it is to get it. Perhaps to the uninitiated readers who have never been a part of sales team, they may see some ideas here that resonate, or at least, help in their journeys to resist against the desire for “one golden onboarding path.”
Account Teams & Sales Engineers
Pick your favorite role names – account executive, solutions architect, sales engineers, engineering consultant, sales account lead, developer relations, engineering advisor – all of these people make up a go to market team.
Vendors have account teams – which is a subset of people dedicated to a specific subset of customers. Sometimes these are regional teams or sometimes these are based on market size in a specific industry and sometimes they are dedicated to strategic customers. If we are an end user company with an internal platform team but have no “go to market” strategy that involves the idea of people dedicated to interfacing with customers internally this makes cross-knowledge share a challenge.
It means we hope they will find and hit that domain for the internal portal and know a mailing list exists. It means we hope they will find us. And just like a vendor – they will not.
The other challenge is that in an end user company staffing such a team can be a central GTM team or on individual service groups in a platform organization – both of which come with their own pros and cons of disorder. The con of centralizing a GTM team is that the ask is for the engineering personas in those teams to upskill on every single service in a department in a hopes that they can onboard customers to them without any load to the service owners.
On the other hand, putting a GTM strategy into individual service owner teams explodes engineering headcount. While this may be fine for the Amazons and Googles of the world (or, perhaps not even them), it is extremely hard in organizations < 20K in employee size to have service specific subject matter experts that live outside from the ones developing the platform. I do not attempt to propose a perfect headcount solution to this problem, only to say that if there are 0 efforts to this, it is probably a gap, and it is easy to land (and perhaps even desired) at a hybrid solution.
Demos, Labs, and Launch GUIs – Oh My!
End user companies end up building a lot of tools in their platform teams in a hope to make the customer onboarding experience less terrible. But the truth is – nothing fully replaces what it feels like to have another human actually talk and listen to a customer. What’s hardest is when customers get attached to having that 1 person embedded in their team – you know what I’m talking about. The engineers that get DMed all the time outside of the support channel as customers dial for yes.
Vendors who deal with this in volume put salesforce and quotas with specific, quantified and qualified steps (more later in sales plays) to prevent the dialing for yes getting so out of control that they no longer have a business because they gave 80% of a $300K engineer’s time to a customer paying $100K/year.
While platform engineering teams end up fixing that problem by redirecting internal customers to other onboarding paths as they try to build tools that will help – everything from demo environments, to hosted labs, to customize GUI flows for configuring the customer’s environment – they find they land at abstraction being a whole other investment.
They may spin their wheels not knowing what “platform even is” as they build an internal BaaS or ticketing DAG (directed acyclic graph) instead of provisioning or platform software and infrastructure state management – feeling like any of this is wrong. The first (a ticket DAG) is easier than the second (a state management abstracted GUI that hits APIs like the AWS Console) and when customers really do not know how to find a way to their solution, platform teams are desperate to solve any problem. There’s nothing wrong with this except that at some point teams have to decide the actual scope of the investment and cap it to the problem they really are solving today.
Which leads me to – all that collateral? Each of those are separate, discrete onboarding investments. For example, some vendors have lab teams. Not each individual service building their own demos and labs, but lab teams with standards, documentation, and hosting SLAs for their lab environments for teaching their customers. Each portal also needs those things. If teams actually want labs, they cannot half-invest the cost. It cannot be a line item that gets punted every quarter until the next lunar eclipse with floaters. The alternative is not to build a labs team or ever own or run a portal and to buy something that lets teams properly design these for internal users. That also requires significant investment and, often, still, some maintenance or self-hosting.
This brings me to – don’t build things without a strategy for why you built them in the first place.
Sales Plays
I personally think a lot of the above investments become a lot clearer once a team has defined sales plays. Sales plays are the de-facto “This is why I am using this investment.” in action. Call it finger-wavvy corporate lingo or, give me 5 minutes as someone who has lived on enough sides of the platform diamond to clearly state this refraction.
A sales play combines a few factors to create a go to market strategy:
- Who is the customer we are targeting? Note that this is never: All teams in the company or even all types of personas in the company. Customers can map to customer segments just like they would at a vendor – for example, we may have, early adopters or greenfield users, we may have “existing customers” we need to upsell. Define what that is for a team. In SaaS companies this also includes “Lead qualification” which is simply – you have a lead on a new customer, but do they meet the requirements of this specific sales play? If not you need a different plan.
- What is the close you are trying to achieve and by when? For some this may be done through an OKR but it does not have to be. The idea is – what are you trying to land for that subset? Is it to get them to launch or integrate with a single specific service? A group of services that go together? Note that it should never be all services in the menu or whatever they want because that is not a strategy.
- What collateral you going to use to tie 1 and 2 together? Are you sending a specific list of customers to a demo? Are you meeting monthly with them? Are you sending them to a form to fillout? On calls what are you going to say and how are you going to say it? Your collateral likely will not be the same for every play! If it is – something is wrong.
I made this image with Claude after some fun back and forth. Someone is going to think “Why did you use Claude for text when there are better pla—-” and I will tell you, I used it because it’s great at making codified .SVG files and I spend $20/month for it so I might as well try.
“This looks like OKRs!” – Sure, Very similar! if that is what helps to generate excitement – The difference between an OKR and this is that each “play” clearly identifies a type of customer, it can be repeatedly executed through a quarter or two, and it has specific outlined steps and the collateral that will be used with it – some of which isn’t even stuff your engineers would make!
I particularly laughed at Claude suggesting platform teams use swag to give to customers as I also simultaneously remembered the customer I was supposed to buy custom cupcakes for after an internal migration and that I never asked for budget to do that.
If a process is leveling up a spreadsheet to leadership showing all the teams that haven’t migrated from legacy infrastructure… and hoping each customer convinces themselves? That’s not a sales play. That’s madness dressed up as cost savings and begging from engineering managers to influence with 0 incentives for your customers to do anything against their own goals and no shepherding of the collateral required to close the play via channels. Channels in the platform engineering world would be all hands or wider newsletters that show that their play is important as opposed to externally facing outbound communication such as social media. The difference between an OKR and this is it is a much tighter closing pattern and with anything tight you really need agreement up front for the windows that you are aiming for as well as commitment to the window from everyone.
Sales plays come with the nod that there is a go to market team, that they are chartered to…go to market…and that if they do not, they will miss on their success metrics and that we all care about them enough to fund their collateral and give them visibility.
For the people in the back yelling, “We use MEDDPICC” – this is valid. I want to point out that there are many ways to close deals and tens of different sales methodologies. All of them are spiritually related to each other and materially not that different – in a startup, teams will pick the one the CRO they work for and the VCs of the company like. But if you do like these or come from those background there likely are ideas that would work from those too!
However, in a platform engineering team the goal isn’t to close an enterprise discount backed by 50 statements of works, POCs that gave away hundreds of dollars in credits, and a mutual NDA signed 2 years ago as someone went around and championed everyone in the company. The goal is to get a small group of developers to love 5 of a team’s products enough to trust that perhaps the other 40 they built may solve some or the rest of the problems we all have tomorrow. Those people? Absolutely do not want to sign anything first – they want people who care about them, onboarding designed with their persona in mind, and sadly, platform teams to not touch their sh*t even though, sadly, they have to to survive (a story for another post).
In Summary
Teams often try the “one golden path” approach – if we build this platform, they will find it, they will come if we send enough emails about it. We must have one path! We must send everyone to the same flow!!!!
But they won’t because that platform now becomes a subset of products, discrete services, and all of this appears as noise to customers who do not, ever, want to sit down and go through the full menu of offerings many large enterprise organizations have because all they want is their problem, today, solved.
This means, under fire, your team will feel like they must respond to the today problem – these strategies, which are only 3 out of a myriad of ones sales teams use – help identify the variety of today problems in order to provide robust support through tight collateral, influence, and reward mechanics.
Header Image by Caleb Jones from Unsplash.
