A chimpanzee & other Slack stories
Tomorrow, Slack will become a public company. In a move that’s very “Slack”, the company is doing it via a direct sale for employees and investors, not a banker-led IPO. This willingness to carve its own path (or maybe, an inability to follow someone else’s path) is a defining characteristic of Slack’s culture, and responsible for much of its success.
I’ll never forget our first product offsite. CEO and founder Stewart Butterfield gave a presentation to our team about product through an interdisciplinary lens, kicking off with a YouTube clip of a chimpanzee being wowed by a magic trick to illustrate the role of expectations in creating surprise and delight to guide our own approach to our Slack customers. This unusual approach was typical of a product-focused CEO who was more likely to begin a design review by asking you, “What do you know about 14th century China?” than he was to drill into the usage metrics of a recently released feature.
I’ve been reflecting on this a lot lately — both the company Slack was when I joined, and the company it had become by the time I left, nearly three years later. When I started, Slack had around 500,000 active daily users. When I left in mid-2017, that number had grown to almost 6 million. Now it has over 10 million daily active users.
Here are three stories about Slack — lessons I learned helping to build and grow Slack — that have influenced the way I evaluate products and how I think about investing.
You can always make it better.
Long before I ever became an employee, I loved using Slack. The attention to detail in the user experience spoke to me — people who love to build things made this thing. From two prior experiences — as product manager at CouchSurfing and director of product management at Gigwalk — I’d also learned that messaging needs to be the core of any system where people work together. Think of any time you have to submit a request just to answer a question. People need to talk to each other. Messaging platforms outscale other systems.
I loved experiencing Slack as a user and wanted to help build it. After a lot of encouragement from my husband, I asked Joi Ito, an investor in my and Stewart’s first companies (both game studios) and now Director of the MIT Media Lab, to recommend me.
Stewart and I met up at the Slack office in San Francisco on a rainy day in November 2014. I offered to work on whatever part of Slack he thought I’d be a good fit for and he suggested the new user experience — a part of the product that needs consistent, playful improvement.
This is when we first talked about emergent complexity as a design principle; experiences should start out simple and reveal complexity when people look for it. We returned to this principle many times over the years. It was something I repeated to everyone working on growth and much of the product team.
After that meeting I put together a plan for what I’d work on if I got the job. I came to my interview with a bunch of ideas for how to improve the user experience.
When I was hired, there wasn’t a specific role for me, per se. I was one PM too many for a company that was still running as a single development team. So I spent my first few months learning Slack’s product and voice by answering support tickets. I ran a design sprint with Google Ventures. I instrumented the existing new user experience and prototyped a new one working closely with Stewart and the head of design.
This attitude — that I should obsess about the product and find ways to constantly improve it — was quintessentially “Slack”. I fit in there in a way I hadn’t fit in anywhere. Within six months, I found my calling managing the product team and new user experience.
Know who your customer is.
Almost everyone who worked at Slack in 2015 belonged to multiple Slack teams; some were work related, others more social. People used Slack to plan Burning Man camps and weddings. They ran open source communities and interest groups. I used Slack to launch Women in Product in September of that year.
As a result of all of this “extracurricular” activity on Slack, nearly everyone had ideas for how to deepen Slack’s social feature set. This led to a particularly contentious discussion in 2016 about whether to add a blocking or muting feature. These talks took place in #culture, where our most intense conversations took place.
Within any consumer networked product, users need the ability to block or mute each other. Blocking is how we peacefully coexist on the internet (er, sometimes) and it’s our industry’s primary defense against bad actors.
But a tool that’s essential when building a consumer product could prove extremely harmful when applied in a commercial context. The ability for teams to block individual members could exacerbate bad behavior and thwart legal systems designed to regulate workplaces.
To resolve the question of to block or not to block, we went back to the core beliefs Stewart and other founding members based the company on:
- Slack is for groups of people working toward a shared goal.
- Despite its freemium model, Slack is a product people will pay for.
Social groups rarely paid for Slack. Few people planning a wedding or a Burning Man camp were unlikely to encounter the limits of the free version. They would never need to become SOC2 compliant, enable SSO, or invite a contractor as a guest into a channel. These people were not our customers.
These two truths outweighed the obvious product/market fit we had with social teams and helped us make many thousands of small decisions.
In a lot of ways, the people who advocated for Slack to build the block feature were not wrong. But it was product fit in the wrong market, and doing so would have been utterly distracting and not in the best interest of our core customer.
You need both product intuition and data.
By the end of 2015, Slack had grown to hundreds of employees, most of them in our San Francisco office on Fifth Street. Our daily active user count was tipping over 2 million people. At this time, I shifted my focus entirely to improving Slack’s growth.
Formalizing a growth practice was a contradictory move for Slack’s intuition-driven product culture, and one that I was wary of tackling. Until I’d started measuring the rate of activation, no product team at Slack was measured against whether people used the features they shipped. We were much more interested in feedback coming in from Twitter and Zendesk. Our practice of Everyone Does Support (which is just what it sounds like — every engineer, designer, and PM spent hours each week responding to support tickets) ensured that we were all in touch with how people felt about the product. But we were out of touch with the overall adoption of features, not to mention their long-term business outcome.
For the last year, I’d started and ended most days talking to Stewart. “As soon as you’ve decided what it is, you’ve lost something,” Stewart told me in one of our sessions. What I believe he meant was that it — the number your team focuses on hitting — can take over the culture of your team, causing them to make wildly un-Slacklike changes to the product.
I knew he was looking for an intuitive, human-focused development process and outcome. But I also knew that we wouldn’t get far if we didn’t focus everyone on one, quantifiable thing.
We had an overarching, quantifiable goal: Drive the rate of team activation. But we also had design principles to guide the work toward a Slack-like outcome.
One of these principles was: It does what it says on the tin. Practically this meant that interest testing was off-limits. If we put a button in the product that said “See purple pandas,” that button better produce purple pandas and not be a test for gauging interest in a feature we hadn’t already built. The timid, Do people want this? attitude of interest testing would never fly at Slack. You had to have some intuition of what people wanted.
Rocket ships become space stations.
Everyone wants to join a rocket ship startup. But what happens next? No one talks about the fact that rocket ships become space stations. So congrats to Slack on making the journey and successfully becoming where work happens every day for millions of workers.
It’s been amazing to see the evolution. I helped build Slack, but Slack also helped build me. I hope the many lessons I learned in the engine room of the rocket ship will be helpful to others as more outlier founders build outlier companies.
