The Five Requirements of Enterprise Readiness
Ilan Frank is a productivity and collaboration product veteran with more than two decades of experience scaling software, ranging from building enterprise portals at Plumtree to SAP’s version of enterprise social networks to most recently, Slack and Airtable. More notably, he is THE enterprise software expert, handpicked by Slack’s former CPO April Underwood and the founders of Airtable to guide each company through the process of enterprise readiness so that the software at each company could scale with the largest and most strategic of customers.
He had so much rich knowledge on the topic of enterprise readiness, we decided to share his insights in a series of articles. See below for Part 1: The Five Requirements of Enterprise Readiness.
The 5 Requirements of Enterprise Readiness
Most companies mistake enterprise features as one giant product requirement they need to check to satisfy the IT organization for their largest customers. This is a mistake (read that again). Building enterprise-grade software is actually mastering 5 separate requirements.
Scale and performance go hand and hand. Making sure your software is as equally performant for a handful of users as it is for 10K, 100K, and 1M users is equally as critical. Companies will often launch their product at large organizations without properly testing for scale. Unfortunately, this usually backfires, making it very hard to rebound if the customer has a subpar experience. Slack had a mishap in 2015 where Uber considered it for 5K employees and ended up making their performance testing results public. For years, customers did not believe Slack could scale beyond 5K users even though it had released its scaled edition, Slack Enterprise Grid, about 1 year after Uber’s tests. After many years of focus on performance and scale, and after many customer proof points including Amazon which has 2M employees, the narrative is completely different. But it took a lot of time to fix the customer perception of Slack’s scale because the company didn’t properly prepare for it beforehand.
Separately at Airtable, when Ilan started advising the company prior to joining, the company only supported 25K rows. Right now, the company just released 100K rows in a table but Ilan wants to bring it up to several million.
“When you have too many customers that are saying ‘we can’t use your product, we have to use a competitor of yours because of your scale.’ That’s a real big problem. You need to stay ahead of your customers, not your competitors. If you look at Asana, Smartsheets, Monday.com, they support fewer rows than Airtable. Just by that measure, Airtable seems to be doing fine. But if you look at what our customers need (millions of records per table), it’s a completely different ballgame.”—Ilan
There are different levels of providing security depending on the scale of the enterprise you are servicing. There is mandatory security that is necessary to provide for all companies as soon as they hit 100-200 people. These are things like SSO, 2FA, basically anything that the first IT security personnel is going to demand on their checklist. Then there is a level of security that is going to be required as soon as you service public companies or companies that have tens of thousands of users. These are things like SCIM for provisioning and de-provisioning access, enterprise key management (EKM) to encrypt all the data inside the database and audit logs to detect misuse. The lesson here is just because you are taking on security does not mean you have to rush all into security at once.
Compliance features (Data Loss Prevention or DLP, eDiscovery, etc.) open up new industries. For most companies, they are not serving regulated industries, and the industries they serve early on (high-tech, services, media, etc.) are happy to use the software initially without these requirements. But once you’re ready to go into financial services, or federal, or international and get into some markets like Germany or Japan, it’s going to be very difficult if you don’t have any DLP, eDiscovery, or data residency type capability.
Administration features such as workflows for granting permissions, monitoring, insights into usage, etc. only truly benefit a small handful of people within an organization.
“I use the terms in enterprise software, user and chooser. In PLG we want to focus as much as possible (especially in the early days) on the user. This requires the difficult act of saying “no” to the chooser who is asking for valid feature requests.”—Ilan
Because it doesn’t serve a great number of people, it’s better to focus on requirements 1, 2, and 3 initially (aka first scale, then a bare minimum in security, and then compliance to open up new industries). Then, you can turn your focus to administration features. When Ilan first joined Slack, he actually paused the build on administration features for three years for the reasons listed above. Slack had these champions who brought the software into their companies and was forced to tell them “not now” on great feature requests for usage insights, bulk administration, and granular roles. Eventually, in 2018 after shipping a mature security and compliance offering, Slack turned their attention to administration features.
This refers to specific usability features for large organizations, not the usability of the software broadly.
The background here is that even the best PLG software requires some special features to work best within large organizations. For example, a new employee may need to find their “team” or workspace. Extra attention may need to be spent on areas of the product such as search, sharing, and content organization due to the amount of available data or knowledge. For most of the 6 years Ilan was at Slack, he avoided and even disbanded efforts to address these usability areas. This may seem backward to the principles of PLG; however, the argument is that your limited core product experience team should focus on the commonalities between employees at large and small companies through screen and task efficiency, delight, and basic usability.
In Part Two of our series with Ilan, we’ll explore Customer Advisory Boards, and why they are foundational to understanding and prioritizing the product roadmap for enterprise software creation. Stay tuned!