June 15, 2018
Ep. #1, Monitoring vs. Observability
In episode one of O11ycast, Merian Ventures' Rachel Chalmers and Honeycomb.io's Charity Majors dive into a few ways observability can driv...
Achieving quick Time To Value is a foundational element of great customer onboarding, but for technical products that require certain expertise and resource intensive implementation periods, it can take weeks or even months to get your customers to a great “ah-ha” moment.
In a recent group session, Dremio’s VP Customer Success Ohad Almog discussed some of the most common challenges early-stage teams encounter when onboarding customers, the benefits and tradeoffs of using CSMs vs Professional Services, and where professional services land in your org.
My name is Ohad Almog, I’m the VP of Customer Success at Dremio, the data lake engine. It’s a startup that is growing very fast and my responsibilities include all post-sales for Dremio. That includes the support organization, customer success management, as well as a professional services team. Dremio is a very technical product that requires a good amount of implementation. With that, I will share some of the things that we’re doing at Dremio and things that I’ve done in previous companies that are also technical.
One clarification though that is worth mentioning, I talk about customer onboarding here. You might have heard the phrase “customer onboarding” in a different connotation. Sometimes a customer onboarding is meant to describe the initial user acquisition from websites to the start of using the product. When I say “customer onboarding,” I mean an actual paying customer. Once you have a paying customer, you have a signed PO (Purchase Order), now let’s get that customer onboarded and implemented and get them into production, essentially.
The implementation for the onboarding is your opening act, right? It’s the first impression that you give the customer, and potentially they had some PoC (Proof of Concepts), but oftentimes they become a customer because they are new folks involved in the engagement, and surely everything changes once they become the customer. The onboarding implementation sets the tone and has a long lasting effect. If you do it right, it will go a long way and it has lots of benefits. If you do it poorly, it will be hard to fix that first impression.
A well executed implementation will give you better customer experience, better communication, less friction with the customer. It will also reduce support needs. Not everyone thinks about it, but if you do it right and the product is well implemented, it is less likely that they’ll come back with issues. If you do a poor implementation, many of the issues I guarantee will be related to that misconfiguration that took place at the beginning. So, do it right. You’ll see that it will also help support.
A well executed implementation also leads to faster time to value. “Time to value” is the amount of time it takes a new customer to realize value from your product. Value is something that you should sit down with your customer– either during a kick off or in the initial stages and maybe even the sales cycle, to understand what’s their definition of getting value out of your product? It will be different for every customer. Understand “what’s a good ROI (Return on Investment) in their mind?” and make sure that you aim for that.
Why is a short time to value important? Every day that goes by is another day that something can go wrong. It’s another day that the customer has not seen ROI. That means that especially in the SaaS world, you’ve got more or less 12 months. Your champion can leave, and again you’re stuck now with no one that promotes your product internally. If you’re not implemented and the customer is not in production seeing value, that means that now you’re in a mode where you need to resell your product and make sure they don’t churn.
If you get them up and running fast, they will consume your licenses potentially and come back for more. They can also become references. If you onboard them fast, you can see those benefits as early as a month or two. I had in-quarter extensions in my career where the customer was onboarded in about a week, and before the end of the same quarter they came back to consume more licenses.
Kick off the engagement quickly. You’ve got a PO, you move the Salesforce opportunity to close. Have some automatic trigger, have someone have a process in place so that someone can get the ball rolling. Don’t let it sit there for weeks until you get the kickoff meeting and engagement. Maybe not more than one or two weeks after they become a customer, there’s also usually a momentum that you can benefit from. The customer is excited to finally get the bill signed.
Understand the scope, identify potential roadblocks earlier. That means that if there’s any gap between what they expect and what your product can do, the earlier you identify that the better. It gives you some time to fix it, maybe it gives you some time to go back to stakeholders and discuss something. But if you find that there’s a problem gap three months into it, you just wasted three months.
Agree on priorities and timelines with key stakeholders on the customer side. We agree what priorities this will have internally on their end as well as what is the expected timeline, and this is important because oftentimes things will get prioritized by certain people on the customer side. If we’re able to agree on those priorities and timelines with the key stakeholders at the very beginning, you can come back to that and say, “we’re not getting enough time and focus from your team. Can we get back on track, so that we can accelerate getting you on into production?”
It’s good to have owners on as many things as possible. With many tasks during the onboarding, you don’t want to get stuck waiting for customers to open a firewall that causes the entire project to be delayed, and you don’t want to continue to chase down that person until they open that file.
Don’t be shy, do hold the customer accountable. Yes, you are the vendor and they say the customer is always right, which is true. But the person who signed the check, the buyer, also expects you to get things done even if it means to push their team and make them accountable and make sure that things get delivered.
Design an efficient and structured onboarding plan. What we do with Dremio, and in my previous company as well, is we designed onboarding packages. This may not fit all of your specific use cases but it’s working really well for us. It’s always good to have multiple options for how much time you’re going to give, or your professional services or implementation teams are going to spend. But it’s not just about more options, it’s also about how you design those onboarding packages.
Keep in mind that you’re not selling a product, you’re not selling features, you’re selling value.
The customer is paying you X amount of dollars and they don’t care about the features, they care about the value that they expect to get out of your product. Just because the product is installed and working doesn’t mean that the customer is happy and seeing the investment.
When you design your implementation, look at what business outcome the customer is looking to get out of your product and try to design your onboarding packages based on that. Have a beginning and an end. The end result is not just a working product, it’s also a solution that is delivered that is able to provide that business impact.
Build an MVP implementation that represents most customer needs, and break it down into tasks. Of course each customer is different, but focus on the things that are similar. That’s how you want to start building your implementation project. Break it down to really two individual tasks, and then each task could have an owner.
Most tasks will be probably assigned to your implementation team, but some of the tasks will be assigned to the customer. If something gets stuck, you know who to address and who to approach. If you’re dealing with enterprise customers you know that oftentimes there is a disconnect between different stakeholders. Even though the buyer said, “Go and implement this,” the technical team in the field have a lot of other things on their plate and it may or may not get the proper attention.
The customer is buying a solution that provides value, and with it the customer is expecting you to be the expert and lead the way. The customer might have a couple of people who know about this space, but no one knows the space as much as you do. Because potentially you’ve done this already dozens or hundreds of times with other customers. You bring a lot to the table, and that’s part of the expectations the customer has.
Oftentimes you’ll sell them hours or you get the implementation team engaged and the customer says, “I want you to do this and I want you to do this,” you have to hold your ground and say, “Listen. I appreciate what you’re trying to do here, but let me tell you that this does not follow best practices. We’ve done this a lot of times with enterprise customers, and from our experience this is not the right way to do it.”
Don’t be shy and don’t let the customer lead the way, especially if you think they’re not doing the right thing. The results will be a poorly implemented product and that will backfire sooner or later. If three months into it you’re letting the customer lead the way in implementation and you don’t think what they’re doing is the right thing, the result will be that the product is not working. They’re going to blame you, or they’re going to think that your product doesn’t work well or is not enterprise ready.
Usually in early stage startups, engineering is heavily involved or maybe exclusively doing the implementation with customers. The pro is direct feedback to what’s working and what’s not. The person who wrote the code is the person working with the customer, if something’s not working they go back to the keyboard and fix it. Great.
The con is it’s expensive and it’s not just because you’re paying that developer a good amount of dollars, it’s also because if that developer is doing implementation they’re not writing code. That’s why it’s a double lose. Also, customer facing skills is not one of their strengths, which is what you need to unblock and navigate the account.
There’s some knowledge that is being accumulated during implementation. If your engineers are the ones doing it, then you’re missing out on the people that will end up doing it in the future, i.e. someone eventually will be dedicated to doing implementation and you’re just going to have a hard time transferring that knowledge.
The pro of CSM-led implementation is good customer facing skills, or at least better than most engineers. It’s cost-efficient because support’s usually– Especially if you talk about highly technical products, are not as expensive as professional services or engineers. If you don’t have a super complicated product that requires very specific skills, then you might get by.
The con is they’re not focusing on their actual job, whether it’s solving tickets or adoption and other things customer success managers should do. Limited knowledge, again, if it’s a simple product maybe it’s OK, but if it’s a complicated product it’s not going to work for long. Lastly here, it goes back to limited knowledge building and accumulation.
If you can afford it, I think Professional Services is usually the best option. Even if you have one dedicated person, then you can set the foundations. First of all, you bring someone who is knowledgeable and provide the best practices. The customer expects guidance from an expert, and that’s what a professional services architect or consultant can provide. They’re a dedicated resource because all they do is focus on getting the customer up and running as fast as possible.
They can start building a knowledge base, cheat sheets and a lot of information that will help making the onboarding process better. The con against professional services is that it’s expensive. It’s another headcount, unless– With an asterisk, unless margins are positive to at least breakeven.
Bring in experts in the space if you have a technical product. The product is never a standalone solution. It’s always something that lives in the whole ecosystem, integrates with other tools, and it’s part of the process. Being able to provide that knowledge and expertise on the entire ecosystem of the customer, it will go a long way.
Most professional services teams talk about billable hours, so you want to use a good project management tool or tool to record the hours they spend with customers. If it’s done correctly and people really put in the time they spend, it will give you a rare visibility into how your professional services spend their time. That will help tremendously as you try to optimize, understanding where they spend time and where things can get better.
Try to avoid having the services or implementation teams do dev work. They love the idea of working through the weekend and coming up with some hack. It may be good initially, and sometimes you can’t avoid it, but long term it’s going to– You’re going to regret it. It’s not supported by the product, it doesn’t have a release cadence, the person who wrote it will leave at some point, the company, and then no one really knows what happened there or what they did.
Your first thought should be, “Let’s make the customer successful.” Cost is secondary. At some point you do have to start thinking about margins because your investors are going to have a hard time with you spending millions of dollars on consulting or professional services. If you’re able to get them to at least breakeven then you can also scale a team much easier and it’s less of a burden on your company.
Build an internal knowledgebase of everything that the PS team runs into, anything that is not already documented, some hack that they did or some best practices, anything. Keep in mind the attitude of “whatever we’re fixing now, let’s make sure that we never have to fix it again, or whatever we can withstand to research something that we need to accomplish, let’s make sure no one else has to do it ever again.”
I’m a big believer that you don’t have to scale your professional services team. Ideally, the product will do most of the work. You’re always going to need some professional services to some degree, because you’re always going to have the big enterprises of the world that will have super complicated projects. You’re always going to need it, but you don’t want to become a professional services shop.
You want to keep your services revenue at 5-10%, if it’s more than that it’s going to become hard to scale. You really want to make sure that the product does as much as it can and not have human beings do it, especially during the implementation with it. If you really want to make sure that you minimize the need for services, make it super easy for the customer to get on board independently. Products can do a lot of the heavy lifting, but good implementation can do the rest.
I tell my team, “You need to document everything and essentially eliminate your job.”
If you’ve outsourced your professional services, dump all the information that is in their head into a knowledgebase so the customers can consume it offline independently, versus having to put a person in front of them.” If you’re dealing with smaller deals that are $5-10K, it doesn’t make sense to get professional services to work with the customer.
Make the product self-service and supportable as possible, not just self-service, but also supportable. If they’re running into an issue, provide guidelines around how they can solve the problem themselves. If they are trying to achieve something, not just implement your product, but again get to a certain result of it, provide that article.
We use things like Jira and other things, but you definitely want to make sure that you eliminate as many friction points as possible and make sure that the process is smooth and there is good handoff, good knowledge transfer. You get good continuity with the customer, you have good working relationship with engineering. There’s a lot of processes that can be put in place to make sure that the team doesn’t spend unnecessary time doing things that they shouldn’t.
The goal is to make your customers successful, not to make money out of services. What we usually do is we understand how much money the services team is costing us and calculate backwards and see, in order to break even how many people we need based on the needs of customers in one hand, and cost of professional services. That allows us to do head count planning.
Last but not least, at some point many companies and many vendors outsource PS. That can work well for certain companies or most companies at a certain stage. There are several things that you need to keep in mind, though, and several things they need to be in place before that can happen. One of them is strong enablement, you don’t want to outsource something to a third party without making sure that they’re fully enabled. They represent your brand, if they screw up, they make you look bad.