In the software industry, professional services have a bad rap: services don’t scale. Yet for many enterprise software companies, professional services can be a huge enabler of revenues and a significant differentiator.
Many startups begin with a focus on product-led growth. Companies are started by engineers, often target other engineers and, at least for a while, getting people to download your software or try your SaaS offering on their own is a good way to see if there’s interest. In the early days, you may not have anyone else in the company to provide a lot of assistance, so this is a reasonable strategy.
However, many startups hit a speed bump as they grow. They get some initial traction with product-led growth but then larger companies start trying it out and things slow down. In lean times, Engineering budgets get cut, just like everyone else’s and things stall.
Selling to Enterprise customers is easier said than done. When the deals happen, they’re larger, which is great. And name brand accounts bring credibility to your company. So, naturally, you hire an Enterprise sales team to build relationships with buyers and navigate the choppy waters of determining who has budget, authority, etc.
Getting meetings is no problem, but somehow, projects seem to slip. Deals move from Q3 to Q4 and beyond. The customer loves what you’re doing, they have the exact problems you’ve described, they’re excited but somehow… it just keeps slipping.
I remember one large deal that kept slipping at Gatsby. We eventually realized that because they didn’t have React programming skills on staff, they were overwhelmed with some of Gatsby’s capabilities. Eventually, we proposed a “Concierge” offering whereby we would help them optimize their Gatsby builds for a five figure price. We were clear that we would not be doing coding, but rather identifying areas where their architecture could be improved. Best of all, we structured the deal as subscription service that renewed annually. The initial Concierge deal lead to a larger cloud subscription deal some months later. And because they always had new Gatsby projects underway, they ended up renewing the Concierge services for several years.
Are They Ready To Buy From A Startup?
One thing you will want to test is whether the prospect really has the appetite to buy from a small company. The only proof is if they’ve done it before. Otherwise, you can find yourself in the situation of implementing “must have” customer requirements like SOC-2 compliance, Role-Based Access Control or integration with legacy systems all on spec, hoping that this work will be sufficient to close the deal.
Now if all these features are on your roadmap already, it’s not the worst situation in the world. It’s all part of growing up to serve larger customers.
Unfortunately, after you’ve implemented the first set of requirements, there’s often another bunch of “must have” features or security requirements that has surfaced from some another group within the company. Even if you closed an initial deal, if the customer doesn’t put your software into production then there’s nothing you can build on.
However, even in the best of situations there is often a mismatch between the skills of the team that is building the product and what the customer is able to figure out and implement on their own. In many cases deals stall because customers don’t know how to proceed. The buyer may lack dedicated resources or skills to use all the fancy new technology you’ve invented.
There is some irony in the fact that a large Enterprise customer is several orders of magnitude larger than the startup they are buying from, but that’s just how these things go. Often because of how large companies are structured, it’s easier for them to get technical expertise from outside than from within. And this provides a significant opportunity for savvy startups who can help customers with their implementation.
The first thing to remember about Enterprise customers is they are accustomed to paying for premium support. When they have a problem, they don’t want to be out there searching on the forums or stuck in a customer support queue. They want eyes on it immediately. Especially if it’s a production issue impacting their users.
More importantly for early stage startups, you can greatly improve your odds of finding product market fit by working closely with early Enterprise customers.
Offering professional services can eliminate one of the potential deal killers in selling to large companies: who will do the work?
Customers, who are already busy with existing projects, will be much more open to buying if you are there to provide hands-on assistance during implementation and available to trouble-shoot anything that might go wrong. Best of all, there’s no reason you can’t charge for this.
For startups entering the Enterprise software market, this is almost always a good approach. It gives you more control on getting to the finish line and it can drastically shorten the time frame from finding out issues and getting them fixed in your product. It also helps build customer focus in your organization. People who have had to roll out software and fix bugs in a live system have much more empathy about getting things right the first time. Additionally, many engineers want to know how their work performs “in the real world.”
It’s not a bad idea to assign your core engineers to the first half a dozen or more Enterprise implementations. I know you’re wondering: Won’t this take time away from new feature development? Yes, but it means when you get back to it, new features are far more likely to land well with future customers. There is no better way to understand how your product actually works than being on the front-line with the customers, sharing the responsibility to go live.
One of the best things about helping Gatsby customers improve their performance was we saw all kinds of interesting ways that they misused and abused our technology. That helped us improve our documentation and engineer better defaults and best practices into the product.
After you’ve done a few implementations, you’ll have smoothed off some of the rough product edges that might have otherwise taken you months to discover. The result is going to be a better experience for future customers.
Ideally you can take what you’ve learned and turn it into a repeatable implementation methodology for future customers. Document all the phases, determine who does what, what kind of systems you need access to, and write down all the details. Future customers and System Engineers will thank you.
Even though human services don’t scale as easily as servers, it’s fairly linear for startups on a path from $1m to $100m in ARR as long as you have the discipline to learn from the experience and improve your product and your services as you go. While there can be margin concerns at large scale, generally speaking if services revenues are 20% or less of total revenue no one is going to worry about it. And sometimes, that 20% professional services is exactly what it takes to close an Enterprise deal.
That said, here are a few additional things to keep in mind:
You will need to identify specific steps in your services that are highly repeatable. It’s not going to be completely cookie-cutter, but understanding common patterns makes it much easier. For example, you will need to develop a clear set of questions and guidelines for scoping integration points and performance requirements.
Figure out your rough time and costs for implementation work. Then double it. And for early deals, double it again. You will likely want to propose any implementation work at a fixed price with a “not to exceed” number of ours. Keep an eye on the actual implementation times so that you can improve the accuracy of estimates over time. You will occasionally screw up, so make sure enough buffer that you don’t lose your shirt. Remember, you’re delivering real value to your customers, so charge for it.
Make sure you create a statement-of-work that defines the milestones, dates and deliverables. Also be clear about what work you will not be doing. (e.g. are you writing integration code or is the customer?)
Watch for scope creep. In early projects you’re likely to miss some things. But over time, you want to make sure that implementation projects are 80-90% predictable. Look for ways to continue to make implementations faster and easier.
Ideally after the first six or ten implementations, as you’ve started creating a repeatable methodology, you should be able to use a mix of junior and senior engineers.
You’ll want to get customer-blocking features prioritized on your internal product roadmap. And also ensure that there’s steady communications from the implementation team back to product and engineering so that you’re making things easier and faster over time. This may require building internal tools for your services team.
Engineers who do implementation work have to like working with others. Not everyone is cut out for front line work.
Remember, you’re not just selling a product, you’re making sure the customer gets the solution they need. Good service is a powerful way to differentiate from larger vendors, by showing you’re able to move fast, make decisions and address their concerns.
In contrast, sometimes large companies have terrible service, because they view it as a cost center which they are constantly trying to minimize. You can do much better by actually caring about customers and their outcomes.
Over time as you develop a prescriptive methodology for designing and implementing customer solutions you can use that to build an even bigger services ecosystem led by independent agencies and consultants. You’ll have a much easier time guiding your partners if you’ve led those kinds of projects internally.
Special kudos to Ben Robertson who led the Customer Success team at Gatsby. He not only created the Concierge program that led to more than 50% of our Enterprise deals, but he also helped establish the culture of customer focus.