Paul Mander currently leads all of go-to-market for B2B at Optery. He previously built the pre- and post sales solutions team at mParticle from zero to supporting hundreds of enterprise customers. Along the way of selling and supporting a product as complex as a Customer Data Platform (CDP), he tackled some of the more common topics go-to-market leaders encounter as they build and scale their customer facing teams.
Should your sales engineers also implement the software?
In the early stages, we went down the path of hiring a solutions person (in this case, myself!) to be the sales engineer during the sales process and then stayed on with customer post sale to manage the implementation process.
We would have loved to persist in this model and build a solutions team that spanned pre- and post sale, and in fact that is the best way to do it from a customer experience perspective if can work for your product and customer.
However, we knew that this wouldn’t be the right move for mParticle. CDPs can be technically complex pieces of software, with deep and lengthy sales cycles and cross functional implementations. Thus, we had to pretty quickly separate out our sales engineering from our post sales implementation solutions work.
Ask yourself these questions as the business grows to determine the best path forward for your company:
- Do I have a long and complex sales cycle that requires a lot of deep sales engineering support? Are things relatively straightforward?
- What are my sales engineers doing during the sales process—Are they focused on the table stakes sales engineering functions of being product consultants who focus on value realization, or are they also technical architects or going deep on specific topics that go beyond product functionality?
- How easy is it to implement your product? Is there a lot of internal or customer work that needs to be done or managed by your team?
Products that are straightforward to understand and implement, tend to have sales engineers who don’t have to go as deep. These products are conducive to a model where the sales engineers implement the product. There are two primary advantages to this model. The first is that customers receive a better experience from the continuity of working with the same person they’ve been talking to. The other advantage is, when done right, having the same person do both sales engineering and implementation work can lead to a leaner, most cost efficient organization.
Conversely, if your product has a lot of technical complexity and/or requires a lot of work on either your or your customer’s side to implement, you will eventually need to carve out your pre-sales from your post sales solutions function. The level of depth required on both sides will require dedicated experts, otherwise, your solutions team will underperform and burn out due to high volumes of context switching between pre- and post sales motions. The customer experience would also suffer, as pressure to meet growth targets will cause team members to generally prioritize pre-sales work. Splitting out the sales engineering work from the implementation work avoids the pressure that complex products and technologies create.
Enabling a commercially focused customer success team
If you look across SaaS companies, there is a tremendous amount of variance around what the CS function owns and how it operates. As the lens of efficiency is further applied in SaaS, Customer Success is coming under greater scrutiny. There is no longer an appetite for CS functions that lack a commercial focus and don’t own metrics such as Net Dollar Retention (NDR).
It’s worth reflecting on how we got here. How exactly did we end up with CS functions without commercial focus and, ergo CSMs that lack commercial skills? The answer is usually inertia. While mParticle has a killer, commercially focused CS team, inertia affected the team as well early on.
It’s common for SaaS companies to put more attention on growth (the sales team) and product (product and engineering teams) than on how the day-to-day with their customer operates. It’s that inertia that can lead to CS becoming the catch all for things that slip through the cracks. Sometimes it’s compensating for the lack of a workflow that requires automation that doesn’t (yet) exist, other times, it’s manual effort to support a use case that was sold but isn’t fully baked into the product just yet. Even without those issues, you often hear of CS teams spending substantial amounts of time on customer support.
It was our support that challenged us in the early days. As mentioned, we had a technically complex product. Alongside this, we engaged with technical stakeholders—mobile developers and data engineers, throughout the customer lifecycle. Thus, a lot of the incoming inquiries from our customers were technical and support related. For example, “How do I implement X using this API?”
These inquiries initially landed with our CS team. Every good CSM wants to do right by the customer and ensure they are attaining value. However, having CSMs handle these sorts of queries is a poor experience for both the customer and the CS team. It removes the customers from direct interaction with the correct experts, and distracts CSMs from being commercially focused as they manage communication flows between internal teams and the customer.
We were able to get past this inertia by getting our CS, Solutions, and Product teams together to go deep into what our customers do with our platform and how they do it. We went into what they were looking to accomplish, how they can accomplish those things, and what sort of support was needed. The result was a RACI that described how all customer queries were handled and by whom. The RACI allowed us to route the right customer issue went to the right team member between CS, Solutions, and Support. It also helped guide both the hiring and product roadmaps, by giving us a deep understanding of how the team spent its time and where we saw the most friction in our product experience. The key thing we did was be intentional, we intended to minimize the amount of time CS was spending on support, as we saw how having CS spend time on support issues would hold the business back.
What type of services should be included in a software subscription as opposed to something I charge customers for?
This question comes up often from early stage companies. Generally, in the very early stages, you want to avoid charging customers for services. Your focus should be on understanding what drives customer adoption and how you can minimize customers’ time to value. Eventually, you will want to charge customers for services, if possible. “Setup Fees” or charging customers for services related to implementing the software are a good place to start if your implementation process is relatively complex and requires effort that drives value for your customers. Charging for services beyond setup fees is possible, but the services provided must truly drive value for the customer.
This is certainly how we began at mParticle. We knew it was time to transition to charging for implementation services when the following pieces were in place:
- A repeatable sales motion
- A strong understanding of what a good implementation looks like
- Polished, value-driven implementation process artifacts
However, we didn’t stop there. Given that our product sat at the center of marketers’ infrastructure, our solutions team members were world class experts in how data traversed the mar-tech ecosystem. This created demand and allowed us to charge for technical account management services, where we helped our customers understand and implement the right type and technical format of data to drive marketing use cases in various tools. More important than the actual service revenue, was the additional stickiness the expert services provided for the platform.
