Crossing the Enterprise Chasm

This post is adapted from our CEO Michael Grinich's talk (embedded below) at SaaS School. Slides can be found here.

For B2B Cloud SaaS apps, the Enterprise Chasm separates small early-adopter users from larger enterprise customers, adapted from Geoffrey Moore’s bestselling Crossing the Chasm. Crossing this chasm quickly and efficiently is key to winning your product category across the market.

In this blog post, we’d like to share why you should cross the enterprise chasm, what makes this leap so difficult, and how you can make your app enterprise-ready.

Why should you cross the enterprise chasm?

The benefits of crossing the enterprise chasm are many, but here are some of the ones that stand out:

• Increased product defensibility - By providing enterprise-grade security features, you’ll further differentiate yourself from your competitors.
• Decreased customer churn - The enterprise customers you will gain as a result of implementing the below features will have significantly better net dollar retention and you’ll benefit from a more predictable sales motion.
• Expanded market size - By including enterprise customers in your Total Addressable Market (TAM), you’ll have more room to grow your customer base - both in logos and dollars.

Waiting to cross this enterprise chasm is a big risk. While you work to innovate your product and educate the market, a competitor can piggy-back off your existing work and capture the lucrative enterprise segment first. This is an extremely difficult territory to recover. In fact, Box probably wouldn’t exist today if Dropbox had crossed the enterprise chasm quickly and efficiently. We’re seeing the same battle play out now with Slack and Microsoft Teams fighting for the enterprise market share.

Crossing the enterprise chasm increases your product defensibility, decreases customer churn, and expands your market size. With these benefits, it’s easy to understand why companies would want to cross the enterprise chasm. The next section of this post will cover why companies struggle to make this leap.

Why is this difficult?

• Enterprise features aren’t capital h “Hard,” but they are complicated, which means they take a long time. There’s a lot of small details, fragmented protocols, and large surface areas for bugs. Be prepared to invest - a low estimate for integrating these features will take you around a year and 1-6 million dollars of investment.
• These features aren’t visible to their end users, they’re not the features demoed at all-hands or at board meetings. So they’re de-prioritized by product teams and engineers. It’s hard to motivate your team to focus on security features, because these features aren’t something you can build once and leave alone - they require updating and maintaining. Enterprise-readiness is not a single sprint.
• Feature prioritization is hard - the only way to do this well is to conduct deep technical user interviews with IT administrators. There’s a potential selection bias in these interviews, because your goal is to build for your customers one year in the future, or even five - not only the one you’re serving to right now.
• Splitting focus is necessary. If you don’t integrate these features, a competitor can swoop in and steal your enterprise market - this is partly why Microsoft Teams was able to capture a lot of Slack’s market share. If you focus on building enterprise-ready features, a new startup can pull existing customers with new shiny features. So you need to balance - which a) sucks and b) is very frustrating.

So what are enterprise-ready features?

There are many Go-To-Market changes you’ll need to make in order to become enterprise-ready: positioning, pricing, packaging, sales strategies, security, compliance, partnerships. For the sake of keeping this blog post digestible, we’ll talk about product changes you need to make.

To determine these enterprise-ready product changes, we interviewed many enterprise IT managers. From our research, Enterprise IT Managers ask the following three questions when determining if an app is enterprise-ready:

• Visibility - Can they see what’s going on in your app?
• Control - Can they control what can and can’t happen in your app (and who can do these things)?
• Trust - Can they trust your software based on contractual and product communication guarantees?

Visibility = Audit Logs

The easiest way to provide visibility into what’s going on in your app is via Audit Logging. Audit logs serve as an activity stream of every event that’s happened in your app. To successfully instrument audit logs:

• Instrument events inside your app to give IT visibility into what’s going on in real time. An event is a structured record that provides contextual information about an action. Common events include user.login, document.shared, document.created, etc.
• Match common schema. The standard event schema is (target, actor, action, metadata). Examples here.
• Events should be searchable & filterable. This functionality allows IT admins to identify suspicious activity or malfunctions.
• Events should be exportable. Most IT admins use tools like Splunk, so your audit logs need to be easily exportable to formats like CSV, Splunk, Amazon S3 buckets (for longevity’s sake). You can’t use something like Segment or Mixpanel to build this off-the-shelf. This data won’t be used internally, it will be collected and given to your enterprise customer.

Control = SSO/SAML

Enforce Single Sign On(SSO)/SAML. SSO allows end users to login with their company’s Identity Provider (IDP). This is often required to enforce enterprise IT security policies. Because authentication is handled through a third-party IDP, IT doesn’t have to deal with a growing complexity of password management - and they have more control over user access.

The important thing to note here is that there is no single standard for which Identity Provider an enterprise needs to use, so you could be looking at eventually building and maintaining integrations for these common Identity Providers and more:

• Okta
• GSuite
• OneLogin
• Azure Active Directory
• Microsoft’s Active Federation Directory Services (ADFS)
• Ping
• Gluu

In addition to SSO, consider also building Directory Sync. Directory Sync allows support for automatic user provisioning/de-provisioning based on the directory service your customer uses. The SCIM protocol and services like Azure AD are most common. Companies with upwards of 500 employees aren’t going to go into your app to add or remove a user manually - you have to meet them at their source of (user) truth with integrations like SCIM and Directory Sync.

Trust = Security Policy

To earn the trust of enterprise IT managers, fill out Vendor Security Questionnaires (VSQ). These codify your security policies on how you deal with data, ship code, and basically express what you do operationally. Common examples of questionnaires you might have to fill out include:

• Google Vendor Security Alliance Questionnaire VSAQ. This is the most common - many Silicon Valley companies are part of this alliance.
• Cloud Security Alliance - Consensus Assessments Initiative Questionnaire (CAIQ). Basically a big Excel spreadsheet.
• Center for Internet Security - Critical Security Controls (CSC)
• Shared Assessments Group - Standardized Information Gathering Questionnaire. Not as standard as the name would suggest.

To verify that your security practices are compliant and airtight, enterprise customers will ask for compliance verification. Depending on your industry and service area - these can vary widely. Some common ones include:

• SOC: 1, 2, 3
• ISO-270001
• GDPR
• HIPPA

Another often-asked policy is a Service Level Agreement (SLA), which usually covers guarantees around your app’s uptime, support, and pricing adjustments should you not meet those standards.

Conclusion

In this blog post, we discussed the benefits and difficulties of becoming enterprise-ready, as well as exploring key product changes you can make in order to begin crossing the enterprise chasm.

In summary, crossing the enterprise chasm allows you to differentiate your product and unlock more revenue and a bigger market size, but it’s difficult because it's a complicated, ongoing, difficult-to-balance commitment. It's also risky to wait to integrate these changes. If a competitor gets to the enterprise segment first, you'll have a tough time recovering that lost ground.

Enterprise IT managers determine if your app is enterprise-ready by measuring the amount of visibility, control, and trust they have in your app. These decisions are often made by considering the availability and quality of features like SSO, audit logging, and security policies.

Sound like a lot to tackle? It is, and this is just the tip of the iceberg. We would know - we help B2B cloud SaaS apps cross this enterprise chasm every day.