One of the truisms of software business strategy is that services is bad business; heck, we’ve also said it. The reason, put bluntly, is that it’s a business with low margins and is not as scalable. So in the early days of bringing to market a complex enterprise software product, the repeated feedback I got from nearly all my advisors was to make sure customers were paying for software licenses, not services. (Although I remember when receiving this advice in the early days of Nicira that I wished I even had the problem of money coming in the “wrong” way in the first place — wow, look at all this cash; if ONLY my margins were better and I could scale faster!)

Now, it’s certainly good advice as a company matures: limiting non-recurring revenue from services means better margins/ unit economics, a more scalable business, and so on. And even in an earlier stage company (that’s pre-product-market fit or in a pre-chasm market), the advice is still a sound warning — because unless someone is actually buyingthe product, you don’t actually know if you have the right minimum viable product (MVP) to sell in the first place. In this context, services can be startup speak for “I’m doing custom engineering per customer because I don’t yet have a product more than one customer wants”.

Yet the reasons for this advice are far more nuanced than appears on the surface, and I’d argue that for a company that’s in a pre-chasm market — particularly one with a complex product that touches sensitive infrastructure — leaning in to services can also be a good thing for the business. Because services are a well-established path to helping a deployment be successful and helping your startup become a strategic advisor to the target customer. Being in that support flow and having that position are both crucial aspects of getting an early go-to-market engine going.

Here’s more on why enterprise startups should not dismiss services so quickly, particularly in pre-chasm markets…

• Services are an account control leverage point. Often when doing enterprise sales, the initial sale is for just a few seats (individual licensees within an organization), and the hope is to “land and expand” that over time. Having a strong solutions architect work with the customer to help integrate and run the product positions you as a strategic advisor, especially if you’re the one helping define the value of the product to the company in the first place. More importantly, it provides you direct visibility into their context and culture that helps control and frame the conversation when it’s time to expand or upsell. Most enterprise startups are competing against large incumbents who almost certainly have a sizeable service arm, and that are likely directing the customer away from your product (Cisco’s services business alone is $12B annually!). So it’s fair to assume that organization will have someone close to the buyer with the ability to de-position your startup once you start to pose a threat. In such situations, having your own employees deeply engaged in the account is a good leverage point for re-asserting control.

• Services help ensure a new product works. For a fledgling startup still figuring out product-market fit — let alone how their product works “in the wild” — a problematic early deployment would be a terrible setback in terms of customer credibility (not to mention internal morale for your startup). But besides obvious bugs or downtimes, issues are most often caused by user error or misconfigurations. Having someone inside via services, with their finger on the pulse of the deployment, can immediately help troubleshoot and detect the problem — a good solutions architect can often identify and rectify a bug before there is any impact. That person or account support team can also be a local knowledgeable resource for the company’s engineering organization to work with to figure out the issue and fix the situation before it escalates any further, giving advocates from the inside more reason to believe in the product and continue championing it.

• Service dollars are a great way to get channel partners involved. In enterprise sales, a lot of distribution and purchasing is done via a third-party ecosystem of channel partners. However, it’s hard for a pre-chasm startup to bootstrap this partner ecosystem; without an existing market draw, it’s hard to incent those channel partners to put in the work (pitching, educating, hiring the right sales force). Yet without the channel it’s hard to get leverage in sales and services as you scale. So a successful approach I’ve seen is for a startup to build a material services business, and over time, as more customers bite on the core software product business, to then offload the services business to the channel. Service revenue is often far more attractive to channel partners than software license revenue anyway. And if there are real dollars at play, those channel partners will be far more incented to dedicate the necessary resources, prioritize your product in their offerings, and look past conflicts with more entrenched competitors. In this way services are a vector to engaging the channel without keeping it as a burden; the services business should not be an albatross around your neck later — the key is to use it to draw and entice your partner ecosystem, but then offload it at the right time.

• Service dollars reveal the true price the market is willing to pay for license. I’ve seen this play out multiple times in early sales: Annual contract value (ACV) per account — which measures the value of the contract over a 12-month period — is very high, indicating customers are willing to pay you more on average for your product over time. But each account — especially if you’re giving away tons of services or they’re buying into short contracts (or contracts with the option to discontinue without penalty) — is effectively getting unlimited, free attention, from integration to operations. What’s often really going on is that the startup is offering free services in exchange for a smaller discount on license. There is no free lunch: In reality, those free services are hitting the startup’s balance sheet, thus impacting overall margins. And when the startup eventually does ask for the “fully loaded” price of the license, they lose leverage and may see a decrease in ACV. Since young startups can use all the pricing leverage they can get, offering services can actually be a good practice to help set license pricing high in the early days. However, it’s also important to be realistic about what’s going on with respect to future roadmap and pricing planning.

Now comes the hard part… How do you know when you have the just-right amount or timing of services, or that it’s an albatross around your company’s neck dragging down your unit economics and preventing you from scaling the business as you grow? When are you doing too much — or that it is too late to do services?

Here’s the thing: Customers often WANT to pay for services. Enterprise buyers know what it means to adopt technology from a startup and are realistic about product maturity; they understand that there will be integration time as well as educational and operational hurdles. If you’ve made the case that your product is core to their strategy, and they are engaging with you, then it’s likely they’re deeply motivated to make absorbing your product into their enterprise successful. One of the very few actions the customer can take to de-risk the effort is to throw money at services. I’ve been in multiple situations where companies effectively demanded services precisely because they were keen on investing in the new product’s success.

So services are a good way for startups to engage with targets. The reality is that with most complex software products, you’re going to have to do the work anyway, and you might as well also collect services revenue to raise your top line and provide the business (and channel partners) more incentive to lean into the product. But this is where the truisms about services on the surface are also, well, true — relying on services can be risky and even be a fatal distraction. How can you tell the difference between a good services scenario and a bad one?

There are some pitfalls to be aware of, that can help avoid going down a fatal path:

• Services dollars are not necessarily a signal for product-market fit. As I’ve mentioned before, companies are highly motivated to pay a lot (at least to a startup) for services simply to learn about a technology area or as an expected later stage in the sales process. But service dollars do not necessarily translate to product dollars down the line. Even if services can be a useful leverage point to expand or upsell the customer account over time, there is no direct correlation between services and product dollars. So beware.

• Watch out for the line between solutions integration and engineering. I would be very careful before extending services to include engineering work, because the most limited (and arguably most valuable) resource a software company has in its early days is the R&D organization/ engineering department. Anything that distracts it from a dead run towards an MVP is jeopardizing the entire business. So build a services organization, not a contract engineering organization. And by that I mean: don’t let services dollars dictate what your product engineers do; that should still be dictated by the entrepeneur’s vision and all the signals you’re getting around product-market fit. But it’s all too common that a startup wooed by the particular needs of a single or few large clients encumbers themselves with one-off development work — losing sight of the big picture and bigger market they’re going for — and is therefore unable to respond when the market shifts or the competitive environment heats up.

• Building a profitable services organization is not the point. For the companies that do lean into services, I find they often try and optimize too early and often at the cost of customer engagement. The point of this post is not that services are a good business. The point is that collecting service dollars can help with customer engagement. Often I see entrepreneurs obsess about margins in the services business, justifying that to limit customer engagement, even though the company broadly is burning cash. Once you have a mature business with predictable growth and positive unit economics, you can start to worry about services margin if you plan to keep the business. Know why and when and how you’re doing it, and don’t build a services organization by accident.

Of course, many startups today do have a small services business. The standard advice is to keep services to less than 20% of total revenue. While that works for some products selling to some verticals, I’ve seen many successful enterprise products have services that accounted for over 40% of revenue early on.

As always, my point here is not to give formulaic, one-size-fits-all advice. If you can get by without the operational pressure of building out a services organization, that’s great. Less complex products — or those that don’t drastically change costumer behavior — can for sure get by with relatively little services. But that blanket advice doesn’t fit every startup. So if you’re in a place where more services would help, I’d think seriously about being more aggressive with them… as long as you’re being disciplined about how you do it, and when to stop. I certainly won’t judge you; heck, I may even view it as an asset when implemented at the right time and with the right strategic planning mindset behind it.

Featured Image: Blend Images/Shutterstock