Values of the Slack Product: Part 2
Finding what large customers needed. Becoming carrier grade. Launching a new product called Enterprise Grid.
(Values of the Slack Product: Part 1 precedes this section. Reading that should help with context, if you need.)
A few months before our new product launch Stewart tried out a metaphor with a few folks. The way I remember, it went something like this.
“Did you ever play with Lego and get the platform sheets you could build on? You could join them together to create a grid and they formed the base for what you built? What do you think about using that to describe multiple joined Slack workspaces?”
Hunh. Yes, I’d played with Lego. Yes, I knew the platform sheets. Yes, I thought it could work as a base metaphor to tell the story of joining multiple Slacks.
Oh, okay, I understood after a few seconds, that’s going to be the name of the new Slack product focused on appealing to large enterprise customers. Yes, that could work.
Slack at BigCos
Before we launched Enterprise Grid, it wasn’t like we hadn’t been working with big companies. We’d launched the Plus plan for larger customers in the fall / winter of 2014 / 2015. It included additional security features and controls that our larger customers’ IT teams had been requesting. We positioned it as the same Slack they knew and used and loved, with some added BigCo features to keep IT happy. And it worked well to do just that.
But Enterprise Grid aspired to be a totally different product proposition, purposefully reimagined and built specifically for large customers. Instead of adding features for a single Slack instance, Grid proposed to create an interlinked network of multiple Slack instances, all connected to each other, but also with separate spaces for specific purposes.
We aimed to strike a happy balance between independence and cohesion. You had a small place to work with just your team. You had a big place to work with your whole organization. Maybe you also had some medium-sized places to work cross functionally with other groups too, like project teams, or internal services like finance or HR. And all those various-sized places co-existed within a single Slack Grid.
The Enterprise Grid initiative started in response to three perspectives in Slack’s business that are worth digging into:
What existing customers needed
What prospective new customers had told us they needed and
What we needed as a company
Let’s whip through each of them in order then get to how Grid changed Slack.
1. What Existing Customers Needed
We started using the phrase ‘Champagne problems’ to describe problems we felt lucky enough to have. Our sales leader Bob Frati introduced the phrase and it reached wide adoption because we had lots of them problems.
Growth beyond what a single Slack workspace could really handle? Certainly one of them. We were very lucky to have that problem, yet it still remained a problem for many of our large existing customers.
They had run up against the practical and technical limits of Slack as a single instance. Comcast had 30,000 people in a single Slack instance. IBM had 40,000. No wait, now closer to 45,000. Many other customers had thousands or tens of thousands of people using Slack all day every day. And it wasn’t necessarily a great experience for them. Imagine searching for a colleague among 8,000 colleagues or trying to find a specific channel for just your team among 650 channels. Imagine seeking a file named ‘final-presentation.ppt’ and finding 232 of them. Derp!
Workarounds had been found. Customers started creating multiple workspaces, logging in to each one of them individually and switching between them when they needed to. These daisy-chained workspaces seemed okayish but pretty clunky too. Each needed its own administration, its own user management, its own set up and configuration, its own login in and notification settings and on and on. Lots of small problems grated on people. Some confusion resulted for our customers. The whole enterprise seemed held together with bailer twine and gumption.
And even with really good people working really hard to keep it held together it turned pretty quickly into a bit of a clustercuss that required a lot more work from both us and our customers to keep coherent.
The metaphor that comes to mind here is: Imagine trying to move 400 people from London to Edinburgh, all while working together, and using buses to do it. Each person might get to the destination, eventually, in the midst of gas stops and bio breaks and some missed turns, but what you really needed was to run a train.
2. What Prospective New Customers Needed
We talked with Goldman Sachs who told us they couldn’t use Slack, except they somehow did have many teams on Slack. We talked with Two Sigma investments who were using Slack but on the down low because it wasn’t officially sanctioned. Citadel Securities? Same story. Morgan Stanley? Yes. Millennium? Check.
I started counting and found 65 of the Fortune 100 largest companies in the US were using Slack. We had done an amazing job gaining traction in large customers. Our challenge was to convert that early traction into real, sustained, valuable usage of Slack. See? Them Champagne problems.
We got asked all the time by BigCos, how quickly could we ship them the features they needed to keep using Slack? To expand their use of Slack? We had PayPal as a customer but they restricted Slack use to only their engineering teams, mostly, except they didn’t, actually.
So you get the idea. Our customers needed something different than what we offered them. They needed to keep some of their employees separate from other employees. They needed to track employees for compliance. They needed to know what content appeared in Slack.
In our discussions I learned an alphabet soup of IT acronyms: eDiscovery, Data Loss Prevention (DLP), Enterprise Key Management (EKM), GDPR, SOC, HIPAA, FINRA, FedRAMP.
The phrase “Enterprise Grade” rose in prominence as a catch-all basket for these features, coded with meaning for a narrow and influential audience of CIOs, CTOs and CISOs who had wide ranging powers and mandates to manage software use at their organizations. And, if needed, kill it.
In finance and banking (an industry we coveted traction in) prospective customers described a ‘Chinese wall’ that needed to exist between researchers and traders, for example.
In healthcare (an industry we coveted less but where we consistently found companies seeking us out to help them) information regulation was tight. Patient records needed to remain in patient record systems and not intermingle. They needed ways to track and remove any information cross-mingling.
Government organizations and organizations that worked with governments needed security badges and attestations. They needed to know citizenship details of Slack employees and compliance with export requirements and taxation details.
And on and on. Reality! It has a surprising amount of detail.
3. What Slack Needed
As a company, we needed to keep pushing into new industries as well as deepening our customer base in existing industries. We needed to keep our existing customers happy, meeting their evolving needs and expanding their Slack use.
We also needed to protect the beachhead we’d established and prepare for a world with more competition, especially from Microsoft, who we knew at some point would launch their Teams product.
To someone outside the company that all may seem like the usual capitalist appetites for unending growth. And it was. Land and expand. Customer renewals and annual recurring revenues. Competitive moats. Yes and yes. Blah, blah.
But inside the company it also felt like a natural extension to the path we followed. We did still feel some of that pull of being missionary focused, and venture-funded software was designed to grow as quickly as possible. Our customers signed up and got value from Slack and we wanted to serve them as well as we could.
We still felt a lot of conviction that Slack could be a force for good inside companies, helping them work better together and improving life for tons of people. None of us ever wanted to go back to an email-driven workplace and none of our customers did either (that I can recall or have any record of speaking with).
We still had a feeling that the product we put out into the world and helped people use did truly make their work lives better. Simpler, more pleasant, more productive, as we said. So shouldn’t we try to do that for as many people as possible?
Yes, obviously, was the only answer. But getting the thing done? Let’s just say the expression “the devil is in the details” resonates.
A Declaration of Intent
We launched Slack Enterprise Grid on January 31, 2017, at a splashy livestreamed event. Representative leaders from different parts of our business spoke on stage. We had customers join us on stage too, such as Jeff Smith, the CIO of IBM, saying things about IBM like:
“Teams are using Slack for all kinds of discussion, from delivery to operations. With this, we guarantee that everyone is receiving the same information and it’s all saved for future reference.
…
Collective intelligence will always outweigh individual insights.”
Pretty solid endorsement, right?
But if we peel back the layers of promotion and promise, and get back finally to the values of the Slack product, I think it’s pretty clear the launch of Enterprise Grid was more than the launch of a new product. It was the launch of a different product with different values. It was a statement of intent to our market of BigCos saying: we hear what you need and we’ve built it (or are building it).
New logo and imagery? New product architecture and tooling? New pricing and go-to-market motion and support agreement and uptime guarantees? Check, check and check.
And right, the same great Slack productivity benefits that your employees love. You bet. And values? Well, right.
Two Slack Products and Two Products’ Values
Now flashback to the top 3 Slack product values I covered in part 1:
Default to Trust and Openness
A Shared Reality
Compassion Through Service
And consider, are those BigCo values? I’d say No, Yes, Maybe. No, a default to trust and openness is not a BigCo value. Yes, a shared reality is definitely a BigCo value. And maybe, compassion through service might be, for the right BigCos.
Ask around at a hypothetical BigCo corporate retreat (in perhaps Davos or Aspen or Sonoma) and you might find the actual top 3 BigCo acceptable values would be different, more like:
Control and monitoring
Risk management
Contracted guarantees
And that’s pretty different right?
What I’m getting at is that the system of Slack for Enterprise Grid more closely reflected BigCo values. It didn’t totally overwrite the values of Slack’s original product values, but I’d say it clearly grafted on new values that had to co-exist.
And when there we conflicts, like whether individual users could delete or edit their own messages or change their user names or create a new channel, the BigCo values prevailed. Controls were put in place to centralize all of these options because that’s what BigCos wanted.
Holistic and Prescriptive Technologies
In the first part of this series on the values of the Slack product, we wandered down a pretty academic road with The Real World of Technology, and how that influenced me to think about “the system of Slack” beyond just the application itself.
I’d like to return there now because I think a second concept from the book is helpful to think about how Slack’s product values changed with Enterprise Grid — Holistic and Prescriptive Technologies.
According to Franklin, technology is not a set of neutral tools, methods or practices. She asserts that various categories of technology have markedly different social and political effects. She distinguishes for example, between work-related and control-related technologies. Work-related technologies, such as electric typewriters, are designed to make tasks easier. Computerized word processing makes typing easier still. But when computers are linked into work stations—part of a system—word processing becomes a control-related technology. "Now workers can be timed," Franklin writes, "assignments can be broken up, and the interaction between the operators can be monitored."
My mental shorthand for this distinction is:
Holistic technologies equal work-related technologies, focused on making a task easier for an individual or team.
Prescriptive technologies equal control-related technologies, focused on enabling power structures and linear processes.
And I think the best way to think about Franklin’s model of Holistic and Prescriptive Technologies is as a continuum, with a specific technology tending moreso towards one end or the other, rather than as a binary, with a specific technology being either Holistic or Prescriptive. Labels are easy but actually seeing where it fits is hard.
It’s easy to see how the same technology, like the system of word processing in the example above, can be both task enabling and power enabling, and can change over time.
Now look back to the alphabet soup of acronyms that shipped as part of Slack Enterprise Grid and see where they might land on Franklin’s continuum.
eDiscovery — allows for the legal archiving, searching and discovery of data and its associated metadata (date created, edited, user access, etc.).
Data Loss Prevention (DLP) — detects and blocks the extraction of corporate data from corporate accounts, for example, sending an email to your personal account with attached company information.
Enterprise Key Management (EKM) — enables customers to hold the encryption keys to their Slack data so they held exclusive access to its unencrypted form.
GDPR, SOC, HIPAA, FINRA, FedRAMP — all these are data management standards and controls to meet a the needs of a regulated location or industry or jurisdiction.
All those seem pretty biased towards the Prescriptive or power-enabling end of the continuum to me. Or, put another way, building a product for BigCos meant building a product for BigCo values.
Sure, Slack still positioned itself as the informal, fun, connective app for your team — a reverse mullet of marketing, party in the front, business in the back. But we needed folks to know we also knew big business and we meant business.
How Grid Changed Slack
I don’t mean to sound like a software hipster here, nostalgic for the good old days when Slack was authentic and weird and small and only for the people (fists up!).
Slack grew up and started paying bigger taxes on being different, then realized it was paying taxes on being different and got more conservative to get conservative customers. It became aligned with where it wanted to go. It started to reflect the organizations it wanted to attract, and stopped giving them reasons to say no.
And in doing so, it became much more palatable as a vendor to BigCos and as an acquisition target to BigCos. The product values as they changed over time acted as one clear way to see that change.
With the launch of Grid, Slack moved up market, added features for those customers, dropped features that didn’t fit those customers, and gradually became much more closely aligned with the BigCos. Easter eggs disappeared. Channel management options increased. Administrators were given many surveillance and tracking features. Values changed.
By the time Slack went public in June, 2019, BigCos on Enterprise Grid made up half of revenues. Grid basically doubled the size of Slack and inserted it as an essential tool into the life of BigCos. It legitimized Slack as Enterprise Grade and paved the way for its growth into a billion dollar company.
Up next — An Irish Goodbye: Drawing our Irish adventure to an end. Seeing what has changed. Finding what is next.