Previous month:
November 2023

December 2023

Services That Scale


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.

Building A Culture of Collaboration

I remember way back when we sold MySQL to Sun Microsystems. In our early meetings with Sun executives when we would describe how Sales and Marketing worked together on product launches or how Product and Engineering were fully in sync with the roadmap, they would smile wistfully and then complain about how siloed their organization was. Inevitably they would say “that’s how it is in a big company.” 

It struck me as odd. It was a “sorry / not sorry” acknowledgment of the dysfunction they dealt with routinely. They accepted it, shrugged and soldiered on in their cloistered world. 

We were part of the Software business unit, run by Rich Green who had led the acquisition. And while there was good cooperation between Rich and Anil Gadre Sun’s CMO, I got the impression of larger silos representing the different product divisions within Sun. There was the Solaris group, the cloud group, servers, storage, processors and a random assortment of open source technologies. 

When my colleague Jeff Wiss and I decided to run some workshops to improve the product positioning across the company, Anil Gadre gave us his full endorsement. These workshops involved pulling together people from product, marketing and engineering in order to come up with a positioning that reflected the needs of the market and the unique attributes of the product. We worked with various products teams, though it was notable that none of the VPs chose to participate. People cared more about managing up in the organization than actively improving things within their scope. 

What Makes Big Companies Dysfunctional?

The longer I worked at Sun the more I realized it had probably always been this way. The company didn’t just wake up one day with a whole bunch of loosely connected  departments who didn’t collaborate. It had been this way for years. 

Still I wondered, where did it start? Why did people let it happen?

I don’t think the situation at Sun was any worse than most large companies. And perhaps that is part of the problem. People who work in big companies often operate as caretakers and are more prone to maintaining the status quo than changing things. 

Although MySQL wasn’t a large company, it wasn’t a 20 person startup either. We were approaching 500 employees, generating $100m in ARR when we sold to Sun. While we were not totally free of internal drama, there was a remarkably high degree of collaboration between Sales, Marketing, Product, Engineering and Professional Services. Why is it we had a strong culture of collaboration where Sun did not?

Or more generally, how do you make sure a culture remains collaborative as you grow? Here are some ideas that will help.

  • Co-locate your management team. More time together face-to-face helps build trust, common experience which are essential in collaboration. While there are many good reasons to have distributed teams, it comes at a price. Even though MySQL was a fully distributed company, much of the management team was located in the Bay Area and that made things a lot easier when the company had to manage through difficult situations.

  • Bring the management team together regularly. If you can’t work together side by side, this is a good alternative. It can be for in-person planning sessions, quarterly reviews, a board meeting or a conference. Any reason at all can be used to get the team together for a week. The goal is to build up enough shared experience so that working together becomes habitual. The travel is a hassle, but working together is worth it.

  • Hire people with collaboration skills. Ask for examples of how they have worked “across the aisle” with other teams. If a leader can’t collaborate with people in other departments, that’s going to have a negative impact on the organization and should not be tolerated. 

  • Don’t allow second-guessing or bad-mouthing. There are many times difficult decisions will be made and they won’t always come out right. Even with the best intentions, there will be mistakes, screw-ups, errors of judgment. You will occasionally miss deadlines, fall short of targets, ship buggy features, lose deals, etc. It’s all normal in startup world, or any business. When these things happen, you must be able to learn from the mistakes without undercutting people. As tempting as it might be to say “it’s not what I would have done,” —just don’t. You must not allow blame or divisiveness to take root in the company. And if you hear an employee, or worse a manager, speaking in such a fashion, you must take them aside and correct them. Give them a second chance. (But maybe not a third or fourth.)

  • Cross-pollinate departmental planning and review meetings. When a department holds an offsite meeting or quarterly review process, this is a great opportunity to ensure there is participation by adjacent departments. For example, Sales kickoff or Quarterly Business Reviews should include participation from Marketing and Product. When the Engineering team gets together to plan the roadmap, you would expect to have the Product team there, but you should also invite people from the Customer Success or Support teams. Having adjacent teams participate helps ensure there are more diverse perspectives, customers are represented and increases buy-in. 

  • Develop goals together. When it comes to developing the quarterly or annual goals, these work best when departments work together. Ideally leaders work directly with their adjacent teammates (e.g. Sales/Marketing, Product/Engineering) to figure out what is important for the business. While this may entail some degree of compromise, it’s essential that teams buy-in to the goals together.

  • Everyone is valued. You must also be sure that the company values every department equally. There can be no favorites. As soon as there’s a whiff of favoritism, it leads to resentment. If there’s a perception that “Sales can get away with anything” or “that’s the CEO’s pet project” you are feeding into people’s darker emotions. The best way to counter this is to make sure that management is completely fair, that rules are applied equally and that everyone’s voice is welcome in discussions. 

  • Value customers most of all. There are few things more important than building a customer-focused culture. Customer focus is the unifying truth that pulls a great company together.  When things are uncertain, when complex decisions need to be made, there is no better unifying force than doing right by your customers. It is surprising to me to see leaders who don’t actively engage with customers or treat them with disdain. Trust me, it’s never a good look. If the leaders in the company don’t care about customers, don’t expect anyone else to either.

Collaboration Super Powers

I have found over many years, that some roles and teams are better at collaborating than others. Engineering and Sales might be the two departments at the furthest ends of the spectrum when it comes to working together. These are highly specialized departments with distinct cultures, expertise and jargon which sometimes makes it difficult for others to empathize. 

In such cases, I have found that Sales Engineers and Product Managers have a super power when it comes to bridging these worlds. SEs and PMs are also extremely customer focused, which provides an important underlying context. 

I encourage you to think about ways to foster a collaborative culture. And where you can, look for people who are naturally collaborative in the organization to set a high standard for everyone.

What have you seen help drive stronger collaboration in your company? Post your thoughts as a comment below.