This is part two of our six-part guide for tech companies looking to move up and start selling into the enterprise sector. In part one of this series, we assessed whether your company is ready to make going enterprise a company-wide priority. Now, we can discuss how your company can accomplish it. Let’s start with the functional areas of your company, and the organizational ideas you’ll need to consider to start selling into larger organizations. Your product and engineering organizations are an ideal entry point here.

PRODUCT

We’ve already made the assumption that your ideal customer profile (ICP) includes enterprise companies. If that’s the case, first you need to assess is whether your product is enterprise-ready. Here are some key considerations:

Privacy

To sell into enterprise orgs you’ll need some standard data-privacy certifications. The first is GDPR, General Data Protection Regulation. These data privacy regulations were adopted in the EU starting in 2018. Regardless of where a company resides, if any part of its customer base is in Europe, those customers will need you to be GDPR-compliant.

Next is SOC2, which is a process for software companies and data service providers on how they securely manage client data and privacy. There are different levels of SOC compliance.

Other considerations may apply beyond these two biggies. If you handle credit cards/payment info, you may need to have “payment-card industry” (PCI) compliance. There are various International Organization of Standardization (ISO) certifications for industrial/hardware-focused vendors. And California has its own version of GDPR, the California Consumer Privacy Act (CCPA).

And one last stumbling block. Most enterprise buyers have a company-specific data-protection agreement (DPA) they ask you to sign. Many software companies eventually create their own DPA agreement and make it an optional addendum to their master services agreement (MSA).

Enterprise-Scale Product

The biggest area to consider when moving to the enterprise is your product scale and durability. Do you have the right foundation for a true enterprise customer to use your product?

Many products take some “seasoning” to become enterprise-ready and stable, so this is an important milestone to get right. Landing a big customer and then losing them is worse than not getting them at all. How many companies purport to “sell” to the enterprise, but the sales team is scared to death of the downstream hits it could take? At the same time, a very common scenario is that a company “punches above its weight class” and actually lands a big-time customer with high usage demands. This can be a great way to learn to be big. It’s a way to focus the entire company on what it takes to be successful in the enterprise.

Enterprise Functionality

I can offer two riffs on this . . . one as advice and one as a bit of a rant from a revenue leader’s perspective.

First the advice: You’ll need to start thinking about what separates your enterprise product from your core product. Initially you probably have one single product. That’s totally fine, but you’ll need to start planning R&D to build specific functionality applicable to your biggest customers. You’ll need to spend cycles going through pricing and packaging (covered in the marketing section of this guide) and functionality that is priced specifically for your big customers.

Now for the rant: Single sign-on, APIs, security, etc., do NOT constitute enterprise products/readiness to a head of sales. They are table stakes. Test this yourself—go find a series A or B company website that has tiered pricing and look at their top tier. If all that’s listed are the aforementioned items like higher-level support, upgraded security etc., as the differentiator between the vendor’s middle tier and its enterprise tier, then I can guarantee you that company has a miffed VP of sales. That may be the first step of your march into the enterprise (and again, that’s totally fine), but you need to be thinking about how your product unlocks real value for your biggest customers. And real value is not calculated in security and sign-ons. It’s calculated on how your product solves enterprise pains.

Chief product officers will often break up their internal roadmaps into themes: scale/speed, ubiquitous features, UI/UX. And they’ll often call out the enterprise-focused development. This is a great way to stay intentional and maintain focus. For more thoughts on this concept, see my recent piece, “Happy Birthday…to the Product Organization?”

When I say security and sign-ons are table stakes, I mean they’re not optional. If you send your sales team into real enterprise deals without those basic requirements, you will burn a lot of time for nothing. And that’s the rub—as a CEO, these requirements take development cycles to build, so some founders get territorial. They’ll scream: “We spent a lot of R&D to build these for you, and now you’re telling me our product isn’t enterprise enough?” Yes, that’s exactly what I am telling you, boss.

Key takeaway: enterprise requirements should not be considered the same as enterprise functionality. Enter these on your product roadmap under two categories: enterprise requirements and enterprise functionality.

As you grow your company into the enterprise, critical to your thesis should be that your product can create increased value inside an enterprise company.

An Enterprise Checklist

Assess your team on the following:

• We want to go into the enterprise—check
• Our product works (i.e. scales) in the enterprise—check
• We meet standard enterprise infosec needs (SOC2, single sign-on, etc.)—check
• Does our product perform or work differently in the enterprise in a way that provides greater value than the core version?—kick this around as a management team

Many companies that forge their path to the enterprise are not that intentional initially about differentiating their product for the enterprise. It’s more of a market motion that takes them upstream as opposed to a product motion. Said another way, your product is probably not organically ready to go to the enterprise when you make the sales and marketing decision to actually do it. And that is perfectly fine. But BE DELIBERATE about fixing this! Start planning items on the roadmap that are reserved only for enterprise customers (meaning you will re-package your product to have tiers).

Roadmap

When you move to the enterprise, it’s critical for an enterprise team to “sell the roadmap.” When your company is being evaluated by enterprise buyers, a typical part of the cycle involves a roadmap presentation. When you move enterprise, set internal expectations that the product teams need a published roadmap for four quarters. Sales and finance already build annual plans; product should be held to the same expectation.

A lot of early organizations really mess up the roadmap. They get too tactical and show features—resist this urge. Your roadmap should tell a story of where the company is going. A roadmap reveals how you’re a thought creator—you’re building the future. For those who haven’t read Clayton M. Christensen’s The Innovator’s Dilemma, now is a good time.

Some guidelines on who should tell this story. If you’re earlier stage, like series A, B, or C, it’s okay to keep your roadmap tight to the chest. The roadmap should be delivered under NDA, typically by the head of product, CTO, or CEO. But don’t get too restrictive with it—this lacks transparency.

Here’s a pass/fail test: If your sales organization asks for the roadmap, does that entail a mad-dash scramble? That suggests your organization doesn’t really have a roadmap; it also means someone is afraid to commit. As you get bigger, your roadmap should become more readily available and a leader from the product/technical team should be on deck to deliver.

DevOps

Remember the enterprise readiness test and the BMW scenario above? Going enterprise is surprisingly similar to going international. They’re not identical motions, but there’s considerable overlap.

All enterprise companies are global and therefore you may face unique data requirements for storing and sending data. Some countries like Iceland have very strict data-protection laws. Many countries have GDPR or GDPR-like regulations. Some countries like Australia have strict email marketing rules with massive penalties for breaching them.

This should provoke two key questions:

• What level of info-security skills do I have in my org? If you don’t have the role of a chief information security officer (CISO), that’s alright. But you will need some skills to help you navigate these issues.
• If going enterprise, and then by nature international, will you need servers outside your home country? Performance of your app may be the primary driver for why you need servers in international locations, so use this as a strategic reason to research where you put your servers.

When you build international teams, one of the first asks will be around having servers in-country. The truth is companies definitely prefer this, as it makes ticking that box on an RFP or in a sales deal that much easier. But the reality is that unless you’re selling to financial services and/or healthcare, you can likely delay putting your servers in other countries. And “delay” is the operational word. I’ve found that by showing the international servers have at least made it onto a company’s roadmap, that usually moves the dialogue along.

Translations

The other very global enterprise topic is about translating your product. English is the language of business globally, so your first product (if you’re a U.S.-based company) will have both headers and fields in English. The majority of SaaS products created today are built with double-byte characters to accommodate non-English characters, so getting the data converted in the fields should be reasonably easy. But you will eventually get asked if you have plans to develop a fully translated version of the product.

If you’re planning to do significant business in a non-English-speaking nation, you should think about this. Much like standing up servers outside your home country, this is something you can postpone for a while. In Japan, for instance, communicating when you plan to have a local server and sharing translation plans on the roadmap tends to advance the sales cycle.

As stated earlier, growing into the enterprise is a team sport, so starting with the product team is an obvious way in. The next post in this series will delve into marketing and sales development.

Read part 3: marketing and sales development here.