We Don’t Sell Saddles Here

The memo below was sent to the team at Tiny Speck, the makers of Slack, on July 31st, 2013. It had been a little under seven months since development began and was two weeks before the launch of Slack’s ‘Preview Release’. It is presented verbatim, as written (including original pull-quotes), with two exceptions: the removal of an introductory section discussing launch logistics and replacement of a link which pointed to an internal company resource with the equivalent public link.

Build Something People Want

We know that we have built something which is genuinely useful: almost any team which adopts Slack as their central application for communication would be significantly better off than they were before. That means we have something people want.

However, almost all of them have no idea that they want Slack. How could they? They’ve never heard of it. And only a vanishingly small number will have imagined it on their own. They think they want something different (if they think they want anything at all). They definitely are not looking for Slack. (But then no-one was looking for Post-it notes or GUIs either.)

Just as much as our job is to build something genuinely useful, something which really does make people’s working lives simpler, more pleasant and more productive, our job is also to understand what people think they want and then translate the value of Slack into their terms.

A good part of that is “just marketing,” but even the best slogans, ads, landing pages, PR campaigns, etc., will fall down if they are not supported by the experience people have when they hit our site, when they sign up for an account, when they first begin using the product and when they start using it day in, day out.

Therefore, “understanding what people think they want and then translating the value of Slack into their terms” is something we all work on. It is the sum of the exercise of all our crafts. We do it with copy accompanying signup forms, with fast-loading pages, with good welcome emails, with comprehensive and accurate search, with purposeful loading screens, and with thoughtfully implemented and well-functioning features of all kinds.

“Marketing from Both Ends”

Much has been written about “product-market fit” in the last few years, probably as a result of the popularity of the lean startup movement (though the idea has been around much longer). The term refers to the degree to which a product could be successful, given sufficient promotion, appropriate pricing, adequate customer support and so on (before you find that fit, all the pushing in the world won’t get you up the hill).

In this classic post on Marc Andreessen’s old blog, he calls getting to product-market fit the “only thing that matters” for startups and offers a way of thinking about the life of the startup that divides it into two distinct phases: before product-market fit and after. Once the product fits the market, a company is able to step on the gas, spending to promote a product that will actually sell. The things you need to do before are very different from the things you need to do after (generally test & iterate vs scale & optimize).

We are right in the middle of that first phase. It seems we are doing well and there are many encouraging signs, but we’re definitely still in the first phase and it is very, very hard to tell how far we have to go to cross over into the promised land (the last 10% is 90% of the work, etc.) So, we should be working carefully from both the product end and the market end:

• Doing a better and better job of providing what people want (whether they know it or not)
• Communicating the above more and more effectively (so that they know they want it)

In the best case, there is a dialectic at play here: the product itself and the way people use it should suggest new ways of articulating the value — and refinements to how we communicate the value should lead to principles which clarify decision-making around product features and design.

Our position is different than the one many new companies find themselves in: we are not battling it out in a large, well-defined market with clear incumbents (which is why we can’t get away with “Other group chat products are poisonous. Slack is toasted.”). Despite the fact that there are a handful of direct competitors and a muddled history of superficially similar tools, we are setting out to define a new market. And that means we can’t limit ourselves to tweaking the product; we need to tweak the market too.

Sell the innovation, not the product

The best — maybe the only? — real, direct measure of “innovation” is change in human behaviour. In fact, it is useful to take this way of thinking as definitional: innovation is the sum of change across the whole system, not a thing which causes a change in how people behave. No small innovation ever caused a large shift in how people spend their time and no large one has ever failed to do so.

By that measure, Slack is a real and large innovation. It is not as eye-catching as self-driving cars or implantable chips — it is not basic research-y kind of stuff. But, for organizations that adopt it, there will be a dramatic shift in how time is spent, how communication happens, and how the team’s archives are utilized. There will be changes in how team members relate to one another and, hopefully, significant changes in productivity.

We are unlikely to be able to sell “a group chat system” very well: there are just not enough people shopping for group chat system (and, as pointed out elsewhere, our current fax machine works fine).

That’s why what we’re selling is organizational transformation.

What we are selling is not the software product — the set of all the features, in their specific implementation — because there are just not many buyers for this software product. (People buy “software” to address a need they already know they have or perform some specific task they need to perform, whether that is tracking sales contacts or editing video.)

However, if we are selling “a reduction in the cost of communication” or “zero effort knowledge management” or “making better decisions, faster” or “all your team communication, instantly searchable, available wherever you go” or “75% less email” or some other valuable result of adopting Slack, we will find many more buyers.

That’s why what we’re selling is organizational transformation. The software just happens to be the part we’re able to build & ship (and the means for us to get our cut).

We’re selling a reduction in information overload, relief from stress, and a new ability to extract the enormous value of hitherto useless corporate archives. We’re selling better organizations, better teams. That’s a good thing for people to buy and it is a much better thing for us to sell in the long run. We will be successful to the extent that we create better teams.

To see why, consider the hypothetical Acme Saddle Company. They could just sell saddles, and if so, they’d probably be selling on the basis of things like the quality of the leather they use or the fancy adornments their saddles include; they could be selling on the range of styles and sizes available, or on durability, or on price.

Or, they could sell horseback riding. Being successful at selling horseback riding means they grow the market for their product while giving the perfect context for talking about their saddles. It lets them position themselves as the leader and affords them different kinds of marketing and promotion opportunities (e.g., sponsoring school programs to promote riding to kids, working on land conservation or trail maps). It lets them think big and potentially be big.

Because the best possible way to find product-market fit
is to define your own market.

This isn’t a new idea. There are many brands whose marketing activities or positioning has them selling something other than (and usually larger than) their product: Harley Davidson sells motorcycle riding, but it especially sells freedom and independence. Most luxury brands sell something that comes down to “being better than you are” (richer, better looking, more attractive to those you find desirable, etc.)

My favorite recent example is Lululemon: when they started, there was not a large market for yoga-specific athletic wear and accessories. They sold yoga like crazy: helping people find yoga studios near their homes, hosting free classes, sponsorships and scholarships, local ambassadors and training, etc. And as a result, they sold just under $1.4 billion worth of yoga-specific athletic wear and accessories in their most recent fiscal year.

But going back to the Acme Saddle Company, the better analogy to what we are doing now is to imagine them selling horseback riding … about 4,000 years ago. It is almost inevitable that centralized internal communication systems will gradually replace email for most organizations over the next 10-20 years and we should do what we can to accelerate the trend and “own it”. We are at the beginning of a transition. We have an opportunity to both define the category and push hard for the whole market’s growth. We’d be crazy not to take it, because the best possible way to find product-market fit is to define your own market.

Who Do We Want Our Customers to Become?

A few months ago, I read a fairly mediocre ebook called “Who Do You Want Your Customers to Become?” (available here). It was mediocre because it was nearly 70 pages when it could have been 20, not because the ideas were bad: in fact, the core ideas of the piece are fascinating and, I think, very useful to us as we think about the next year or so of Slack.

A central thesis is that all products are asking things of their customers: to do things in a certain way, to think of themselves in a certain way — and usually that means changing what one does or how one does it; it often means changing how one thinks of oneself.

We are asking a lot from our customers. We are asking them to spend hours a day in a new and unfamiliar application, to give up on years or even decades of experience using email for work communication (and abandon all kinds of ad hoc workflows that have developed around their use of email). We are asking them to switch a model of communication which defaults to public; it is an almost impossibly large ask. Almost.

To get people to say yes to a request that large, we need to (1) offer them a reward big enough to justify their effort and (2) do an exceptional, near-perfect job of execution.

The best way to imagine the reward is thinking about who we want our customers to become:

• We want them to become relaxed, productive workers who have the confidence that comes from knowing that any bit of information which might be valuable to them is only a search away.
• We want them to become masters of their own information and not slaves*, overwhelmed by the neverending flow.
• We want them to feel less frustrated by a lack of visibility into what is going on with their team.
• We want them to become people who communicate purposively, knowing that each question they ask is actually building value for the whole team.

This is what we have to be able to offer them, and it is the aim and purpose of all the work we are doing. We need to make them understand what’s at the end of the rainbow if they go with Slack, and then we have to work our asses off in order to ensure they get there.

How Do We Do It?

We do it really, really fucking good.

The reason for saying we need to do ‘an exceptional, near-perfect job of execution’ is this: When you want something really bad, you will put up with a lot of flaws. But if you do not yet know you want something, your tolerance will be much lower. That’s why it is especially important for us to build a beautiful, elegant and considerate piece of software. Every bit of grace, refinement, and thoughtfulness on our part will pull people along. Every petty irritation will stop them and give the impression that it is not worth it.

That means we have to find all those petty irritations, and quash them. We need to look at our own work from the perspective of a new potential customer and actually see what’s there. Does it make sense? Can you predict what’s going to happen when you click that button or open that menu? Is there sufficient feedback to know if the click or tap worked? Is it fast enough? If I read the email on my phone and click the link, is it broken?

None of the work we are doing to develop
the product is an end in itself.

It is always harder to do this with one’s own product: we skip over the bad parts knowing that we plan to fix it later. We already know the model we’re using and the terms we use to describe it. It is very difficult to approach Slack with beginner’s mind. But we have to, all of us, and we have to do it every day, over and over and polish every rough edge off until this product is as smooth as lacquered mahogany.

Each of you knows “really good”. Each of you is able to see when things are not done well. Certainly we all complain enough about other people’s software, and we all know how important first impressions are in our own judgements. That is exactly how others will evaluate us.

Putting yourself in the mind of someone who is coming to Slack for the first time — especially a real someone, who is being made to try this thing by their boss, who is already a bit hangry because they didn’t have time for breakfast, and who is anxious about finishing off a project before they take off for the long weekend — putting yourself in their mind means looking at Slack the way you look at some random piece of software in which you have no investment and no special interest. Look at it hard, and find the things that do not work. Be harsh, in the interest of being excellent.

Why?

There’s no point doing this to be small. We should go big, if only because there are a lot of people in the world who deserve Slack. Going big also means that it will have to be really, really good. But that’s convenient, since there’s also no point doing it if it is not really, really good. Life is too short to do mediocre work and it is definitely too short to build shitty things.

To do this well, we need to take a holistic approach and not just think about a long list of individual tasks we are supposed to get through in a given week. We get 0 points for just getting a feature out the door if it is not actually contributing to making the experience better for users, or helping them to understand Slack, or helping us understand them. None of the work we are doing to develop the product is an end in itself; it all must be squarely aimed at the larger purpose.

Consider the teams you see in action at great restaurants, and the totality of their effort: the room, the vibe, the timing, the presentation, the attention, the anticipation of your needs (and, of course, the food itself); nothing can be off. There is a great nobility in being of service to others, and well-run restaurants (or hotels, or software companies) serve with a quality that is measured by its attention to detail. This is a perfect model for us to emulate.

Ensuring that the pieces all come together is not someone else’s job. It is your job, no matter what your title is and no matter what role you play. The pursuit of that purpose should permeate everything we do.

But Slack is a bit more complicated than a restaurant (at least in some ways). Since it is new and less familiar, we are less able to fall back on well-established best practices. That means we need to listen, watch & analyze carefully. We’ll need to build tools to capture users’ behaviour and reactions. And then we’ll need to take all that information and our best instincts and be continuously improving.

We are an exceptional software development team. But, we now also need be an excellent customer development team. That’s why, in the first section of this doc, I said “build a customer base” rather than “gain market share”: the nature of the task is different, and we will work together to understand, anticipate and better serve the people who trust us with their teams’ communications, one customer at a time.

The answer to “Why?” is “because why the fuck else would you even want to be alive but to do things as well as you can?”. Now: let’s do this.

Slack’s preview release began two weeks after this document was sent, on August 14th, 2013. A little under six months later, on February 12th, 2014, it was officially launched. You can sign up at slack.com to begin using it and follow us on Twitter @slackhq.

* Update: Aug 18th, 2021: I’m using the words “master” and “slave” in the specific context where one is in control (master) and the other is powerless (slave). I want to acknowledge that some readers may find the words “master” and “slave” offensive when used in this way.