Understanding Users and Choosers through Customer Advisory Boards, with Slack VP Ilan Frank

Michael Grinich (00:02):

Welcome to Crossing the Enterprise Chasm, a podcast about software startups and their journey, moving upmarket to serving enterprise customers. I'm your host, Michael Greenwich. I'm the founder of WorkOS, which is a platform that helps developers quickly ship common enterprise features like Single Sign-On. On this podcast cast, you'll hear directly from founders, product leaders and early stage operators who have navigated building great products for enterprise customers. In every episode, you'll find strategies, tactics, and real world advice for ways to make your app enterprise ready and take your business to the next level.

Michael Grinich (00:38):

Today I'm joined by Ilan Frank VP of Enterprise Product at Slack. Slack is of course used by lots of small and medium size companies. But over the last several years, the product has also been adopted by very large organizations like Walmart, Nike, News Corp, and IBM. Along the way this meant Slack needed to become enterprise ready and build lots of new features and functionality for IT admins. We're going to dig into all this and more, and talk about the way Slack was able to move up market and cross the enterprise chasm. Ilan, let's get started by going back in time. Tell us about back when you joined Slack five years ago, what was the state of the enterprise business and product for those customers?

Ilan Frank (01:18):

It's actually been almost six years. It's crazy, time really flies by. So in early 2016, when I joined we had enterprise customers, but for the most part there were 20 people that were called account managers and we were taking orders. If the people didn't want to pay with credit card, if they were large organizations and they wanted to have some type of enterprise wide license agreement. Those 20 people would basically take down their information and really kind of work with them to structure some type of invoicing rather than credit card transaction. But that was kind of the state of our enterprise world. We really didn't have a sales team, certainly not a customer success team. And the product itself was also very immature from an enterprise perspective. The only thing that we had at that time from what we call enterprise features was SSO. That was the first feature that we developed. And that was about all we had at that point.

Michael Grinich (02:10):

Was that developed before you joined? Were you part of that, the SSO Feature?

Ilan Frank (02:13):

It was, the SSO feature was developed just before I joined that's right. In 2015, we launched SSO.

Michael Grinich (02:19):

Do you remember what folks were asking for at that time? You only had SSO. The buying motion was opposite, this is kind of an entire separate thing. Sales maturity around selling enterprise, but from a product functionality perspective, what we're folks asking for? Where was Slack maybe not up to par from there? What they needed?

Ilan Frank (02:36):

Quite a few things. I mean the first thing which doesn't necessarily relate to WorkOS, but Slack in general, is just reliability. I don't know if anyone has read any articles about 2015 in Slack, but if you had a team of larger than 5,000 or so people. Slack was not the most reliable platform to be on at that point. So that's the first thing is customers like IBM came to us and said, "Okay, we can't even hit 5,000 people. How are we going to get 400,000 people on this thing?"

Ilan Frank (03:02):

So that was one of our main focuses initially on the enterprise side is okay, "How do we actually re architect Slack?" Because it was built as a team tool, for a hundred people, the initial pitch deck was there's going to be teams of a hundred. And if you want more than that, you go create another team. But now how do we scale that from that to 400,000 people at IBM, all in one channel together for announcements or anything like that. So scalability was job one initially.

Ilan Frank (03:26):

And then I joked that in 2016, I said the word table stakes, or heard it more than any other time in my career. The tables stakes feature from enterprise were obviously expanding some of the SSO, so supporting other IDPs, we had to support SCIM for provisioning and de provisioning. So that was something that we developed in 2016 so that you can do that. We had to do all kinds of things around compliance. So everything from eDiscovery to DLP, data protection at data exports, anything like that was basically 2016 and that's when we started really that effort. And then finally some administration features basic administration features around users, permissions things like that. Those were kind of the table stakes features that people wanted that first year.

Michael Grinich (04:13):

How did you build intuition to know what to built here, or not even intuition, but how did you actually know what to build? Was it coming from the sales team, you connecting with IT, walk us through. I think many people listening are either at that similar spot or about to be at that spot. How do you assess what features to build? Or how did you build your roadmap around that?

Ilan Frank (04:33):

So a couple ways. Certainly we had a product gaps type of process where sales people and SEs could report what they're hearing as show stoppers from the field. And so we wanted to pay attention to that, but we actually, from a product perspective, we actually did our own TAM analysis. And looked at the market and looked at these features around compliance and security as ways to really unlock TAM. And so the basic ones were basically we're at multiple organizations, almost any public organization is going to need the features that I just spoke about. From SSO to provisioning and de provisioning, specifically, some type of device management to the ability to manage devices. And so there's like a basic level of kind of Maslow's hierarchy that you just need to meet in order to really be taken seriously in the enterprise.

Ilan Frank (05:25):

And then there are other features that you have to be careful about because they sound enterprisey, but they really are pertaining to a specific geography or a specific industry. And those are the ones that you have to be careful not to rush off and do right away. I would hold those off into later years. So for example, we have a lot of requirements around FINRA and financial services. Regulation around compliance, data archiving, legal holds, different types of formats of data export. Which financial services companies like Goldman Sachs will say, "This is a must have." And they're probably right. It is a must have, but it is a must have for the financial service's industry, not for every single organization.

Ilan Frank (06:05):

So you have to really think, what is this going to open up for me as an organization? Are we ready to take on financial services or healthcare? The same thing with healthcare? I advise companies that I work with who look at obviously high tech first then after that media, companies like the Netflix's, HBOS, CBS, Hulu, Disney. These are going to be companies that are usually forward looking then the professional services type organizations. Or organizations that provide a service and only fourth is financial services. So the Capital Ones, American Expresses they're going to be forward looking for financial services. But they're not forward looking compared to all of the other companies that are going to come before it, on those other industries.

Speaker 3 (06:52):

Is that kind of just TAM analysis as you're talking to that?

Ilan Frank (06:53):

Yeah.

Speaker 3 (06:54):

Like those comp... Okay.

Ilan Frank (06:55):

Took a look at basically our TAM knowledge workers inside financial services. How big is that in the US? Because US financial services is going to be very different from European, going to be very different from APAC. And so thinking about the different types of data residency and things like that, that are much more important in APAC than they are here in the US. Maybe because most data centers are already in the US, but also from a regulatory perspective, that's not something that we typically hear. But these are different features that you need as you kind of approach these different geographies and different industries.

Michael Grinich (07:26):

I wanted to pack something you said about the SCIM integration, being kind of the one that you guys built relatively soon after SSO. What did that add to Slack? What did you see in terms of the product changes or the value that, that brought to Slack as a product?

Ilan Frank (07:39):

Well, a couple things. Provisioning is obviously one of the first things that people do with your software. They just bought your software and now they're ready to set it up. And if you make provisioning difficult, that's a first bad experience so that's not a good thing. And then from a security perspective, any company that is larger than let's say 200 or so is going to want de provisioning. So that when the person leaves the company, it could be automatically de provisioned. That person could be automatically de provisioned and everything immediately basically gets locked down for that individual. Those are two extremely important features.

Ilan Frank (08:12):

Beyond that we certainly allowed you to integrate into profile fields. And a lot of customers use that. The way that they use that initially actually, in 2017, was actually for deployment analysis. So large enterprise corporation, they just spent a whole bunch of money with your tool and they rolled it out. And Sue Smith, who leads your tool at the company, is going to be asked, "ow is this working? How is Slack? Has it been adopted? Which departments are using it?" And the easier you make it for Sue to export that information and be able to analyze that information, the easier your renewals are going to be. And so we early on allowed for the SCIM extraction and made actually department and cost center two fields that were defaulted. So that you could actually get those, if they exist in your IDP, we'll just automatically bring those in.

Michael Grinich (09:03):

I've heard this generally called reporting as a admin feature. Like, "We want reporting," and it's like, "Well, who's using it? How much are they using it?"

Ilan Frank (09:11):

I know that you're not going to ask questions too much about the reporting side, but if I can just give two cents on that. I wouldn't over invests in reporting, but what I call... There's three levels of reporting. And I don't want to get into that right now because it'll take us on a tangent. But the first level is what I call deployment analytics. Which is, is the deployment successful? Those are pretty simple. It's really what department is using it? How much are people using it? Kind of what general benefit are they getting from this? That's where you want to invest first and you want to do as little as possible. So even if you have just an API or a data export or a CSV export or something like that. So they can open it up in power BI or Tableau or anything like that. You've already basically checked the box for most of your customers. I wouldn't go off and build something too fancy with custom visualizations and all that type of stuff right away.

Michael Grinich (09:58):

What's funny is I've seen something very similar with group management for Directory Sync. Some companies go down the path of building this whole sophisticated group membership, drag and drop, different tagging or different groups of users. And then you actually roll it out to IT and they say, "Hey, we don't want any of that. We just want to plug it into the existing tools. We already have active directory." Same thing with the BI tool.

Ilan Frank (10:20):

100%. Group management especially in large organizations I would say, let's say a thousand employees maybe 5,000 employees and above, and that range. When you start getting into what we call large enterprise, they're going to have their own tool. They already have it. They don't want to create their own custom groups inside. We have a feature called user groups, which does not get used that extensively in large organizations. Basically because it's an ad hoc in Slack user group type of definition that people really don't want to do. They want to map their existing groups.

Michael Grinich (10:53):

I guess, despite the incremental product value of that, it doesn't outweigh the kind of operational overhead needed to manage that in multiple places.

Ilan Frank (11:01):

That's right. There is syncing of groups and then there is using groups. And so I think that I would start with what are groups going to be used for? And where are they most important? Like for example, this is only seven years later, but we are now starting to offer role based permissioning around groups. So that you could take a group of people and give them a specific role, like channel creators. Maybe we should have done that a little bit sooner. But if I had to do it over again, I would hold off on it again versus the Apple's form of group. Where we map a group to a channel, which is something that we did very early on.

Michael Grinich (11:37):

I know you guys released a blog post. I think it was earlier this year about the new RBAC system and how you built that. And I actually talked to the engineer and it sounds like it was quite the technical undertaking to do it too. You knew what you needed to do for a long time, but it was just a very big challenge.

Ilan Frank (11:51):

I will take my statement back in one way. Which is that if you are brand new and just starting a brand new company. And you can create an RBAC system rather than a flat set of permissions that map directly to end users. I would do that. Because doing it on day one is probably way, way cheaper than going back. And taking every permission that's been built in Slack over seven years and then mapping it back to an RBAC system.

Speaker 3 (12:14):

At scale. Unraveling the ball of twine. Let's go back to the IT admin. I want to ask about this more. So, early on you joined Slack, first few months there, you're hearing about sales objections. You're like, "What deals are we losing." Building that spreadsheet of TAM opportunity. Slack, as I remember it the primary user, wasn't IT admins. In terms of the product team, thinking about who we're building for I remember it was small teams using it and that end user delight. Here, you have this other stakeholder coming in, this other person, IT admin, that the team might not have been familiar with and not really known. I see this a lot with startups they're very familiar with their end user, but this IT persona they kind of haven't, interacted with. How did Slack build empathy with that group? Or just understanding, how did you connect with them? It's a very different audience. Just if you could talk through that.

Ilan Frank (13:05):

100%. So I talk a lot about this in my fictitious blog posts that I haven't written. About in enterprise you have a chooser and a user. A lot of people who come from consumer world and then kind of start their first enterprise company really are focused on the end user. And what does that end user experience? And that's great and it's really super important. Probably more important, I say to many people, that's way more important in the first year, first two years, while you're looking for product market fit than anything on the enterprise side.

Ilan Frank (13:32):

But after that, you really got to focus on that chooser because that is the person who realistically is actually going to make the buying decision. That's the person who's going to be accountable for the success of your software. It's not going to be the end users. And so the way we approach them is with the same type of empathy that we approached the users. So I set a customer advisory board, a CAB, as one of the first things that I did at Slack.

Ilan Frank (13:55):

But unlike other customer advisory boards for enterprise software, what I wanted is people that are really close to the software. A lot of times what you do is the actual person who writes the check that's the person that you invite to the CAB. A lot of times that's someone who's maybe the VP of infrastructure, the person who is next up in line to the CIO, or maybe even the CIO, him or herself. That is not the right person, in my opinion, to invite to the CAB.

Ilan Frank (14:19):

What I wanted was the lowest level person that is not an end user. Basically the person who really feels the pain of deploying Slack at a large organization. That's their job and anything that we do that doesn't help them, it hurts or they feel it the most and we listened. We brought them in physically pre pandemic. We brought them into the office for an entire day, with a dinner at the end and really listened to them. What were their pain points? What was going well? What was not going well? And it was a very therapeutic conversation. This was not a salesy conversation.

Ilan Frank (14:49):

In fact, I advise several companies. There was one company I was just advising on a CAB and the salespeople, the head of sales and several other salespeople wanted to attend the CAB. And I told them, absolutely not like salespeople are not even invited to the CAB and thats nothing against salespeople. I love salespeople. But the reason why is I don't want to feel salesy. When these account manager come into the room, I don't want the person they're associating with basically selling to them, even in the room. I want this to be a frank conversation where we really talk about what is happening with the software and what we can do, better.

Ilan Frank (15:23):

And then the other thing that's really important to CAB, this obviously goes without saying, is following up. So we wrote down everything that they asked for. The next time we met, initially it was every six months we met, we would show them. Here are the things that you asked for we did this many, some of these other ones are in progress. But some of these other ones, we just decided not to do, frankly. Thank you for letting us know, but we decided for whatever reason that we're not going to do it. We're going to focus in another area. But we didn't just leave them and let them linger, brush them under the rug.

Michael Grinich (15:54):

Thinking back on those first few meetings with the customer advisory board, is there anything that stands out that was surprising to hear or maybe unexpected? Either something you expected them to say, and they didn't or counterpoint where they're like, "We really got to have this," and you're like, "Wow, I would've never imagined."

Ilan Frank (16:09):

Yeah. You and I talked about this several times I think actually in our meetings. We normally didn't allow customers in that weren't actually already users of Slack. This was one customer that we allowed in that was very, very bought into Slack and wanted Slack throughout their entire organization. They were very, very large organization that you would definitely know of, but they needed EKM enterprise key management in order to roll out Slack. That was their standard. And they just could not roll it out without it. We tried all kinds of things. We have security policies, look at how we rotate our own keys and all that stuff. All that stuff didn't work. They needed EKM.

Ilan Frank (16:43):

At lunchtime this person basically went to other people who were on the CAB and convinced them that EKM was the most important thing. Even though these were already existing customers. And at the end of the day, when we did our ranking, it was almost like a mob of like chanting "EKM, EKM, EKM."

Ilan Frank (16:59):

And that was really the beginning of when I started to change my mind on it. Initially, I thought this is a silly thing that people are asking for, but eventually they'll drop it. And it'll be fine and they'll use Slack without it. But at that point, really, I started changing my opinion on it. And started going towards really investigating realistically at what it would cost us to put in the product. And eventually about a year later, we had released it.

Michael Grinich (17:22):

And that was a legitimate feature need. It wasn't just a mob with the pitch forks.

Ilan Frank (17:26):

If it was...

Michael Grinich (17:26):

Convincing the other folks.

Ilan Frank (17:29):

If it was not feature need, I would hope that I would not be swayed by just the mob, but they made a compelling argument.

Michael Grinich (17:34):

Well, it's funny seeing Slack, having built EKM and Quip did it as well. Now you're part of the same kind of sales force family at Slack. It does seem to be like a feature that's on the horizon for a lot of other SaaS companies. Eventually, eventually.

Ilan Frank (17:47):

Eventually it's not the first thing that I would build again, the security features... Reliability, number one, you just cannot ship software if it's not reliable. And by that, I mean, reliable and scalable beyond what your customers can do right now. Not scalable well beyond that. If your customers are 10,000 users, don't build a million, but it has to be able to, that's number one. Number two is definitely the security table stakes. Number three, compliance, to start getting into other industries other geographies. Number four is where I would get into EKM. And number five admin features. That's how I would rate those enterprise features basically any day for almost every company.

Michael Grinich (18:23):

I think when I've seen EKM it's in that realm of, not even seven figure deals like eight figure deals really is what you're talking. Pretty large dollar numbers that get blocked by it.

Ilan Frank (18:32):

That's right. It has a significant halo effect. I don't think I'm allowed to say exactly how much of Slack enterprise is driven by EKM. But let's just say they were right, that CAB was right. It's had a significant halo effect. I don't know how many other people that have purchased it. We sell it separately, but more importantly, it's part of Enterprise Grid. And so, like you said, it's those large deals, where it's part of those large deals and it enables those large deals. I don't know how many people of those are show stoppers. It would just not come onto Slack. But certainly the fact that we have it, is just a great kind of proof point of the enterprise focus that we have at Slack.

Michael Grinich (19:08):

That was the feature to be precise that meant Slack didn't have to do on-prem also, right?

Ilan Frank (19:14):

That's right EKM is enterprise key management. That's when customers can bring their own key and encrypt the data that you store for them with their key. So that your engineers can't go and just decrypt it basically. And you're completely right, Michael, that two big companies that really push for EKM, they typically deploy only on-premise. And this was the feature that allowed them to say, "Okay, we..." For both of them, Slack was one of their first SaaS tools that they deployed in the cloud.

Michael Grinich (19:43):

Well, thank you for paving the way for the rest of us. I also want to ask about team structure. So as Slack evolved in those early days, just SSO, probably didn't have a whole enterprise product team, enterprise engineering focus. How did the team evolve? I want to hear about this from not just kind of engineering a product, but also kind of like marketing, how you thought about that and messaging? The story around Slack enterprise is a little bit different than the story around the more consumer product led growth side of Slack.

Ilan Frank (20:12):

Yeah. From a team structure... First of all, when I joined, we had a hundred engineers and we had 10 people that we had basically amassed inside enterprise. And now we have about a thousand in PDE in product design and engineering, and about a hundred on enterprise, roughly. We run at around 10%, 15% at times, we scaled out Enterprise Grid in 2017, but roughly there. And I think that that's the right investment level for something like enterprise in most SaaS companies.

Ilan Frank (20:41):

From a go to market perspective, I think that the most important thing is just to really be connected to the sales organization. So I will have to drop off exactly at the top of the hour because I'm going to a customer event, for example. I still remain very, very engaged with customers to this day. And I think that, that's something that's really important. So as you think about enterprise and getting into enterprise, it's more of a customer visit, in the old sense you, can stay at home now, but it's the customer visit type of go to market. And it's important to have an enterprise leader I think that takes that on. Can connect with customers, can get that feedback and bring it back to the team. But also be able to really kind of co-sell with the sales team because it is a team effort.

Michael Grinich (21:24):

I've heard in the past also that you guys would get on planes, go to customers, go sit down with them. Actually show up at their office in old school style.

Ilan Frank (21:32):

Old school style. Yeah, that's right. Luckily, it's not so old school. I didn't have to wear a suit other than in Japan, but we definitely used to do that in the pre pandemic days.

Michael Grinich (21:42):

So we have just a few minutes left. I got two more questions for you that I want to dive into. We'll make sure to let you go for customer event. Along the way, what did you all choose not to build? I'm curious what didn't make the cut in terms of saying, "Ah, that's actually not a need." And similarly, are there any features that you regret building. Or things that you were like missteps where that calculation was maybe just a little bit off. Didn't have the same kind of return on investment that you were expecting in terms of thinking through TAM and impact?

Ilan Frank (22:08):

Yeah. I think that one of them is generic. The other one is I think, more specific to Slack itself. So the one area that we decided not to build, and I mentioned it in my stack rank is really a lot of admin features. And those CAB meetings were spicy, because these are the people that are really feeling the pain. And what they're asking for are features to help them out, to help them manage and govern and deploy Slack.

Ilan Frank (22:34):

And we provided them, many of them APIs and said here you can code around this. If you want to deploy multiple people into a channel, you can do that, but we're not going to give you an interface to very nicely do it. Now we've built all those in the last year, but we held out for many, many years. I don't regret that. These were painful conversations to have with customers.

Ilan Frank (22:52):

I don't regret that because what we were building were what I consider the show stoppers. That were not allowing us to break into larger organizations or different industries. Mobile security, different type of authentication, controls and so EKM, obviously that we invested in, IDR so data residency. We invested in all these, which again, I don't regret. But these were difficult conversations to have with people that you developed a relationship with over years.

Ilan Frank (23:19):

The second area, the area that I wish we would've invested in more, but this is really more Slack specific is in Slack Connect. It's another area that I lead now and I think that it's an area that is just so exciting. When you think about Slack, the external connections that I wish from a Slack perspective, that we invested more in that area.

Michael Grinich (23:40):

We are very, very heavy users of Slack Connect as well. I work with... I know many people on this call also, we have shared Slack channels with.

Ilan Frank (23:46):

If you have any feature requests, I'm sure we have a Slack Connect channel where...

Michael Grinich (23:49):

You probably have dozens. Last question for you before we wrap up what's next for Slack enterprise? As much as you can talk about where you see stuff going? You obviously were early to the party with EKM. Having forecasted that as being a momentous feature, anything that you can speak to what's next for that? And maybe just wider across the ecosystem as you see it beyond Slack.

Ilan Frank (24:11):

I can speak to that. On the enterprise side, which is a side that we're thinking about again, large organizations or ones that are multinational. It's starting to define the boundaries of Slack beyond just knowledge workers. And so like task workers, retail workers we're already deployed.

Ilan Frank (24:29):

I think this has already been talked about, so I'm not spilling anything, but Target is a large organization. They're speaking at Dreamforce right now, but this is already starting to be deployed at stores there. If you go to an Apple Store and go look at the Genius Bar they have stock behind the counter. So we're starting to do that.

Ilan Frank (24:45):

And this actually circles nicely back to WorkOS and security. That is largely a security question. So those employees, for example, don't have email addresses typically, because email is too expensive to roll out to those employees. So you have to do authentication that's not email based for example. Those employees sometimes have regulations around using your software outside of the store. So you have to have some type of either geolocation or some type of integration into a calendar system. So that as soon as their shift ends, they don't have access to it.

Ilan Frank (25:14):

But this is the area. I think that enterprise, as we're doing our planning for the next year is going to focus on next. In addition to more control around device management. Endpoint protection is a really, really big issue for customers. And we no longer can just rely on them to just put different types of endpoint protection on their laptop. We need to provide them more tools that are built into Slack in order to protect those laptops or mobile devices in case they are hacked into.

Michael Grinich (25:44):

Any last comments for the SaaS ecosystem, advice for founders that might be going through this, Slack circa 2012, maybe-

Ilan Frank (25:52):

We were...

Michael Grinich (25:53):

2014.

Ilan Frank (25:54):

I was fortunate. I should say that, we hit product market fit before I came on board. And I think that that's important, for anyone going through this right now is to really focus on that product market fit almost exclusively. I always tell companies that I advise don't hire someone like me until you need that person. That's not a good hire that you want to do first day or even potentially in your first year. You really got to focus on that end user and then bring in someone and separate them to focus on the chooser. So that's one of the things that Slack did really well is we almost had two different organizations for product. One focused on the enterprise and one focused on the user.

Michael Grinich (26:33):

I think that's really sage advice. We often talk about after you get product market fit, then go get enterprise ready. It's kind of the second chapter of your growth and just as important. With that, we can wrap up. Thanks so much for joining. I know you're a busy guy. This is really fun conversation really, really appreciate it.

Ilan Frank (26:48):

It's always fun to see you.

Michael Grinich (26:50):

Likewise. You just listened to Crossing the Enterprise Chasm a podcast about software startups and their journey. Moving up market to serving enterprise customers. Want to learn more about becoming enterprise ready? The WorkOS blog is full of tons of articles and guides outlining best practices for adding features like Single Sign-on, SCIM provisioning and more to your app. Also, make sure to subscribe to this podcast. So you're first to hear about new episodes with more founders and product leads of fast growing startups. I'm Michael Greenwich, founder of WorkOS thanks so much for listening and see you next time.