After Michael Grinich left Nylas to work on a new company, he interviewed dozens of cloud companies. He found that—when companies moved from a self-serve product & go-to-market strategy to a hybrid model of self-serve + scalable enterprise—they consistently reported many of the same things. From these repeated lines, Grinich concluded that enterprise companies need to do more than crossing the chasm to really succeed.
What did the companies report? Three main items:
- Startups wait too long to talk to enterprise companies: founders viewed GTM as a binary decision to start either self-serve vs. top-down sales. Most start with a self-serve strategy that’s most compatible with engineering, product and design founders, especially ones coming from a high growth consumer company
- Product & Engineering teams inaccurately forecasted the time and budget required to build enterprise-required features ie: SSO/SAML, audit logs, etc.
- GTM teams required a significant shift in company strategy and team priorities: pricing, positioning, packaging, sales collateral and an appropriate team structure that meets both self-serve and enterprise customer demands
While consumer companies cross the chasm by scaling from early adopters into mass market adoption with essentially the same product, enterprise founders have to take a more strategic approach and continuously ship new enterprise-grade features in parallel as they continue to iterate on the core self-serve product.
Enterprise startups don’t simply cross the chasm; they bridge the chasm with a balanced self-serve and enterprise-grade platform with multiple reinforcements.
Startups entering a large market with little competition have the ability to stay self-serve for as long as possible, but for most enterprise founders the ability to build enterprise features while still shipping new, innovative self-serve features will be their greatest competitive advantage.
Does Crossing the Chasm Work for Enterprise? Take it from Slack…
A Product Manager at Slack told Grinich: "I would guess we've spent $30M building enterprise features...and we're probably only halfway done."
While this interview was conducted nearly a decade into Slack’s journey (shortly after the launch of Microsoft Teams), it serves as:
- A positive reinforcement that David Sack’s bottom-up playbook to sales for startups is a strong launchpad for startups
- A reminder that self-serve is a starting point and not an end point. Self-serve leaves whitespace for new entrants and market incumbents to fast follow with an unfair distribution advantage.
Eventually Slack moved upmarket, built their Enterprise Grid, and won over large corporations after nearly a decade of attracting startups and small businesses while incrementally scaling into larger companies. Slack serves as a good reminder that the move into enterprise may:
- Bring unpredicted costs
- Cause structural and cultural team changes
- Wage war with a large challenger, in Slack’s case Microsoft
For most early stage companies who solve a known problem for a specific buyer with a single product, a self-serve motion needs to be met with an expansion strategy into new use cases, products or verticals. Companies working towards venture-scale growth have to move upmarket and sell to enterprise customers who provide repeatable annual recurring revenue, are less likely to churn, and historically, endure in times of economic downturn.
Crossing the Chasm Framework
Despite the potential upside, many self-serve businesses hesitate to transition from self-service to enterprise-grade SaaS. Why? There’s a chasm between points A and B, as pointed out by Geoffrey A. Moore in his bestselling book Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers.
Below you can take a look at Moore’s crossing the chasm chart for more insight into his theory.
While Moore is right about the problem, he’s wrong about the solution: the gap between self-serve and enterprise sales can’t be crossed; it must be bridged. “Crossing the chasm” won’t cut it for these teams, because the crossing the chasm framework doesn’t account for everything that they’re up against.
There’s a common misconception that enterprise companies are either self-serve or bottom-up. This fallacy creates a fairly large psychological hurdle for early stage companies who view the decision as a binary outcome with immediate impact on engineering, product, and design teams, not to mention noticeable changes to company culture as the team begins to hire for marketing, sales and customer success.
This is where Moore’s framework for Crossing the Chasm is easily misinterpreted by enterprise companies. Again, enterprise startups don’t cross the chasm; they bridge them by building a balanced self-serve and enterprise-grade platform with multiple reinforcements.
Grinich, now the Founder and CEO of WorkOS, has spent nearly a decade in the cloud, including working at Dropbox. He’s developed deep insights on how companies can win enterprise customers by bridging the Enterprise Chasm:
“In B2B cloud SaaS apps, there's something called the Enterprise Chasm that separates small early adopter users from large enterprise companies. Bridging this really efficiently and quickly is the most important key to winning a product category across the whole market.”
At SaaS School, an invite-only program for entrepreneurs to learn from leading experts at the fastest growing software companies, Grinich provides an insider look on what it takes to cross the Enterprise Chasm. He emphasizes that Founders don’t need to make an either-or decision––instead, startups can and should offer self-serve and enterprise options in tandem.
Grinich provides answers to three key questions that startups have before embarking on the quest to win their first enterprise sale:
- What makes crossing the chasm difficult for enterprise?
- Is bridging the Enterprise Chasm worth it?
- How can my company make our app-enterprise ready?
What makes crossing the chasm difficult for enterprise?
The self-serve SaaS model begins with bottom-up evangelism from early users and scales into highly efficient and low-effort revenue growth, combined with low operating costs, that allow companies to hire fewer and more senior people. Countless seed stage and Series A startups have adopted this model and found early success with relative ease. Unfortunately, adopting a model for enterprise sales isn’t quite as simple or straightforward.
Moving from “crossing the chasm” to bridging the chasm and moving from self-service to enterprise customers is challenging from multiple perspectives.
“From a leadership and management perspective, it's a big challenge to hold these two states in your mind and motivate the team with both. It's not easy –– there's technical challenges, there's organizational challenges, there's motivation challenges. Figuring out what to do is challenging and figuring out what the first steps are is really challenging. It can feel overwhelming...that's one reason why companies don't proactively do this and would rather go back to the safe place, which is building for themselves or building things for their friends, even to the detriment of the longer term business.”
To ready founders for the challenges that lie ahead, Grinich points to the common hurdles startups can anticipate as they go down the path toward the enterprise market. Here are a few:
- Enterprise features are complicated. Because there are so many details involved with building enterprise features, there’s a larger opportunity for bugs to crop up during the process. Developing complicated features takes a long time and requires a meaningful investment. If you want to gear up, make sure you’re ready to dedicate the time and money required. Building enterprise features is a marathon, not a sprint.
- Engineers don’t always like building enterprise features. In many cases, companies are dealing with legacy technology, and coding enterprise features isn’t fun for engineers. On top of this, these features aren’t visible to end-users; they’re only visible to IT managers. Enterprise requirements generally aren’t shiny or fancy features. Instead, they’re low-level integrations or security features. Engineers rarely get recognition or promotion for them, which means they’re not jumping up and down to work on them.
- Feature prioritization is hard. Figuring out the importance of different enterprise features can be daunting. It requires in-depth customer research with enterprise ITs to collect requirements and feedback to figure out which features get prioritized over others.
Grinich notes companies should prioritize features based on the needs of future potential customers––not just early-adopters:
“It's not based on who your current customers are, your current early adopters, but who you're going towards. You might not be talking to the right people... and build the wrong stuff for a long time. It's hard to develop confidence around knowing what to build when you're going [to the enterprise] market.”
The most significant difference between self-serve and enterprise-grade platforms is that the user is no longer the buyer. Your buyer is now somebody at an executive level that has different needs, priorities, and expectations. This adds a layer of complexity to the process.
Splitting focus is necessary. There’s a false dichotomy between self-serve and enterprise-grade SaaS. Not only can you have both, but having both is actually preferred.
If you don't build for enterprise, a competitor will come in, take that market, and make it nearly impossible to win it back. On the other hand, if you don’t keep building end-user features, a new startup can pull users away with shiny new features. Splitting focus, while difficult, is essential.
Is bridging—not crossing—the chasm worth it?
Transitioning from self-serve to enterprise is a daunting and challenging process. It requires time, money, and for companies to make a cultural shift. Is it worth bridging the chasm? In short: yes.
Bridging (Not Crossing) the Enterprise Chasm, comes with key benefits:
- Increased product defensibility. Introducing enterprise features means increasing product differentiation, which will help you build a moat around your business.
- Decreased customer churn. Enterprise deals bring stability, predictable sales motions, and a significantly lower churn rate. That means customers stick around longer so growth compounds over time.
- Expanded market size (TAM). If you’re selling mostly to SMBs, at some point, you’ll run out of customers. Getting your foot in the door of enterprise SaaS will open up room for growth.
- Accelerated revenue growth. Bridging the Enterprise Chasm will help you increase revenue and sit behind the steering wheel instead of being dependent on venture capital.
Unfortunately, the risk of not bridging the chasm isn’t simply inertia; it’s an eventual downward spiral. Not going upmarket (or waiting too long) leaves your startup vulnerable to your competitors. While you’re preparing for a seamless shift, challengers may enter the market and offer features that the lucrative enterprise segment finds appealing, after you’ve done the work of building an innovative product and educating the entire market.
“If you don't go up market to the larger segment, you can have the instance where a competitor is able to come in and capture those lucrative enterprise deals where you've done all the work to warm up the whole market.”
Formulating a strategy to cross the Enterprise Chasm opens up new opportunities while simultaneously defending your position against newcomers.
Enough of crossing the chasm. How can I make my app enterprise-ready?
Every transition needs adjustments and companies need to evolve holistically to cross the Enterprise Chasm. To successfully make the leap from A to B, companies need to be ready for some go-to-market changes related to the product, positioning, packaging, pricing, security, compliance, and many other aspects of their business. However, Grinich recommends that founders focus on one area first––product:
“You already have demand from people who are in enterprise environments that you can capture. And product changes are sort of the most universal...they're the same things across multiple product domains. Product wise, the requirements are relatively similar [for enterprise customers].”
Even though every business is unique, there are three commonalities across industries that enterprise IT managers want from a product:
- Visibility
- Control
- Trust
Visibility. Knowing what’s happening is one of the biggest concerns for enterprise IT managers. The easiest way you can address this need is to build an audit trail.
This is an activity stream that shows what’s happening in the application, and almost every enterprise SaaS product has this feature. When implementing this, make sure that the audit logs match standard schema, they’re searchable/filterable by IT admins, and they’re exportable in different formats (like CSV, Splunk, S3 buckets).
Control. Enterprise IT managers want to be in control and choose what can and can’t happen in the tool. The first thing to do is to allow users “Single-Sign-On” via their identity provider (e.g. Okta, G Suite, ADFS Microsoft, One Login, Ping, Gluu, WS02, Shibboleth, KeyCloak).
This is required to enforce their IT security policy, so if you want to play with the big companies (or nowadays even mid-market), you have to provide this feature.
Trust. Enterprise customers expect guarantees. To seal the deal, they want a partner they can trust––from reliable customer service and secure data management, to a commitment to quality of services (SLA).The first step is building your Security Policy document.
Aside from this, some of the surveys that customers might ask you to fill in during a vendor security assessment include things like:
- The Consensus Assessments Initiative Questionnaire (CAIQ)
- Critical Security Controls
- Standardized Information Gathering Questionnaire
- The Vendor Security Alliance Questionnaire (VSAQ) (most common in the Silicon Valley)
Aside from the technical nuts and bolts of the processes and procedures to create trust with enterprise customers, Grinich summarizes how startups should approach this process:
“What you're doing here is codifying your security practice and your security positions in a way that you can communicate it to them...This is not actually a product or technical thing. It's expressing what you do operationally inside the company to show that you're trustworthy.”
Leveraging WorkOS to cross the Enterprise Chasm
Grinich highlights specifics on building visibility, control, and trust into your company’s products to win enterprise customers, but emphasizes these are only the first steps of many:
“This is not an overnight process. It takes time, so be patient. You need a balance between talking to your really excited early adopters and getting a lot of feedback from them and trying to close them, but not reading too much into them and understanding there's a bigger, brighter world out there.”
Though preliminary, these first steps can be enough to garner several million dollars in enterprise ARR. Grinich recommends startups think early about moving from crossing the chasm to bridging the Enterprise Chasm if they want to unlock new opportunities and create a safety net:
“Getting a handful of enterprise deals can be enough to boost your revenue and push you into the next series B...If you don't think this applies to you and you're thinking, ‘Oh, we'll just do self-serve forever,’ I would really start questioning that and really think about the opportunity.”
Transitioning from a self-serve business to a balanced self-serve and enterprise-grade platform takes time and energy. Grinich’s company, WorkOS, is a developer API that helps products become enterprise-ready. This lets startups sell up-market and unlock revenue from large customers. Their SAML/SSO integration is completely free but still in private beta.
Watch Grinich’s full SaaS School talk for additional insights on why Box beat Dropbox in the game of enterprise and how the role of Product Manager needs to be adapted for bridging the Enterprise Chasm.
As always, I’d love to get your thoughts and feedback on Twitter.
Liked this? You’ll also like:
.jpg)
.png)
