Saying No Nicely
Sitting next to the money agrees. Saying dates; always listening. From product strategy to business practice. Slack in 2014.
So, new year, new job, new title — must have been a total change, right? Well, yeah, not so much. More like a progression.
I started in January, 2014 as a full-time Slack employee as Director, Accounts. And the job was pretty much the same as it had been in December, 2013, when I’d been a consultant doing marketing. Such is the nature of small, early-stage startups: you have to do what needs doing.
For me, that meant primarily that I worked with customers. I did calls and demos. I emailed and emailed and emailed. I helped them get what Slack could do for them.
I still managed a few marketing projects because I wanted to see them get done and no one else was going to do them. I wrote so many emails from scratch and from templates. I collected feedback from all these places. I managed the Slack socks and the Wall of Love (more on those later).
On a personal front, my wife had been more than right. My apprehension at moving to Sales (Accounts!) proved to be unfounded. Yes, ultimately, I was selling people a product. But not in any sort of aggressive way and not in any way that the customers didn’t want.
This was really the key: they wanted the product. They wanted to try it out. They wanted the experience. They wanted to believe in the promise that Slack held to Be Less Busy. They wanted a better world of teamwork and teammates than they knew with email (or whatever cobbled-together, random tools they used).
So I didn’t have to create a need for them. They were clamouring for a better way to work together. Helping people use Slack successfully was the best kind of sales of all because it really was just helping them be successful.
And in helping people I tried all kinds of things — demos, written guides, webinars, videos. But one of the best tactics turned out to be Saying No, in the nicest possible way of course. What I came to call, Saying No Nicely.
How to Say No Nicely
Saying No Nicely wasn’t too hard but it had a few flavours.
First, sometimes it was simply saying, “No.” with some context on why the answer was “No.” Here are some examples that came up often.
Q: Can we use Slack on our own servers? We only use on-premises software systems.
A: No. That’s not something we’ve built or something we’re intending to build. Slack is meant to be used live online and we feel like this is the direction the world is headed.
…
Q: Does Slack have a Windows mobile client?
A: No. Slack has iOS and Android versions and you can run Slack in any browser on your device.
I think that Saying No Nicely to customers struck them as refreshing and honest. It simplified the mental model of Slack for them. Instead of using it for all kinds of things in all kinds of different contexts, you used it to communicate online, which everyone thought of as simple and hardly anyone did well.
It also meant an easier transition to Slack for customers. Wait, easier? Well, maybe not easier always. But clearer and more direct. They just had to move their communication from email / Skype / HipChat / Flowdocs to Slack and life got better.
Second, sometimes a customer asked about something we had considered or were building so it was moreso saying “Not yet” rather than Saying No Nicely.
Q: Can I invite a freelancer into Slack and only give them access to one or two channels? I don’t want them to know we’re going to fire them.
A: Not yet but we are working on a guest access feature for limited access to specific channels. You can also use private channels today to control who has access to specific information.
As a testament to the quality of our team, many of the questions I received were ones we had already considered and the engineering team had invested some thought in. Perhaps the features already existed on our roadmap and a customer question offered an opportunity to deepen the conversation and learn more about their needs.
So that became the third way type of Saying No Nicely — restating what we could say yes to today and learning about what we might be able to say yes to in the future.
For example, people wanted Slack to work with their heterogeneous security set ups.
Q: Can I have Slack sync with my identity management system (IDP) so people don’t have to log in with whatever email address / password they want?
A: Today you can use Slack with Google’s GAuth as an identity provider and we’re looking to add SAML-based options in the future. What IDP are you using?
Asking a question in response to their question opened up a conversation about identity providers (IDPs) and we could start to get a sense of the market and what products we wanted to integrate with.
We also got a chance to ask questions about how other products they already used integrated with their IDPs and whether that additional functionality required an upgrade in plan. Why yes it did. Hmmm. Good to know.
The use of a SAML-based IDP proved to be a key distinguishing feature between small businesses and medium-sized businesses and a great feature set to include in a higher-priced plan for us. Our customers were helping us solve our segmentation problem of who needed what features.
Never Say Dates; Always Be Listening
A key part of the second way of Saying No Nicely (saying “not yet”) was backing up the answer with some notion of timing, yet never saying a specific date for a feature to be released.
We had a hard rule never to say a date. Instead, I replied with ideas of timing set around tranches of time for features likeliness.
Something “not yet” that was coming was weeks away, or within the next quarter, or a few months out. It sounded both to me and customers less flimsy than coming soon, or next release. And it was more sound. They got a sense of timing and almost always that proved to be most of what they sought. They were saying, just give us an idea of when to expect it.
Much of the time I found the richest way to work with a customer and understand what they were seeking was in answering a question with a question. This isn’t earth shattering to say, but it’s worth repeating because it’s not well practiced.
So much of sales turned out to be not talking but listening. When I used How and What questions the conversations with customers flowed and lots of details got shared. We each got a chance to learn. When it really worked well it often felt like together with our customers we were discovering what was essential to have in Slack, and what wasn’t Slack.
Often early on customers asked about features that lived outside what we conceived of as Slack’s product space: task lists, documents, systems monitoring, project management. I had to build up some knowledge of adjacent product spaces to understand their question. Then mentioning a few product options helped confirm what they sought and how they thought about Slack.
That kind of create a fourth way to Say No Nicely, with a redirection. Right, so that’s the core of Slack but here are some other products to add to Slack, like a task manager for teams or a word processor for lawyers or a project management application for construction. Again, just asking how they imagined a specific thing working for them, or what they used today for that job, let them share their needs and led me to better understand what they sought to achieve.
Going through these conversations, we started to really see how work interconnected for our customers. Often they’d need to chain together tools to get things done — monitoring software for alerts, something else for doing diagnostics, another tool for analytics, knowledge management, code repositories, version controls, testing and quality assurance. They had to orchestrate complex patterns, with tools and teammates, and we positioned Slack as the place they could conduct that orchestration. Communication linked together all the steps.
From Product Strategy to Business Practice
Saying No Nicely started for us as a product philosophy. Then it extended beyond how we looked at our product to how we looked at our work and our business overall.
It meant we didn’t have a Facebook page. Or maybe we had a Facebook page to hold the namespace and prevent anyone else using it, but it just said to check our Twitter feed :).
And we said no to so many things. We didn’t run any advertising. We didn’t have an email newsletter. We didn’t do events or gated white papers or outbound calling or webinars. We didn’t do lots of things that we could have done to try to drive our growth. We were small and swamped already. Instead, we tried to do a few things that seemed to be driving our growth as well as we could, and simply omit the other things from our attention.
This philosophy of Saying No Nicely was a revelation to me. It contradicted my prior work experience where it seemed as if esteem and status went to the employee doing the most things. Long To Do lists had meant I was busy and important. Saying No Nicely meant that status at Slack accrued to those doing a job as well as possible, not for doing as many jobs as possible.
I can see how in any workplace Saying No Nicely could be powerful. But in a software company it was even more powerful because one of the amazing things about software is how flexible it can be. When a customer asked or an internal engineer imagined – Can Slack do this specific thing I’m wondering about for my specific situation? The answer almost always was probably, yes. It could.
Talented software engineers and designers could make the code and interactions do pretty much anything. They’d built a game before Slack and found themselves in one of the classic traps of software — because it is flexible it can lose the centre of its purpose. It can stop being focused on doing the big job it was made to do.
Though it was never explicitly discussed, Saying No Nicely at Slack felt driven from a deep desire for the team to do work they would feel proud of. Work they were happy to put their name on.
Doing too many things meant that each thing only got done in a half assed manner. Doing fewer things meant needing to do each them very well. The added bonus of doing things well in a software world was that things done well stood up well to time and iterations of the surrounding software. Things done poorly were brittle and then required more work to maintain and keep running.
So what was Slack in 2014?
If you’re reading this you probably already know Slack. But you know a later version of Slack, and it’s hard to remember the early version we launched with and grew through with our early customers.
So join me in the Time Machine again back to Slack in 2014. What was it?
Messaging, at its core. Yes, just writing and managing words. ~90+% of our customers’ time was spent on messaging — the simple composition, organization and reading of messages. That seems pretty simple, right? Lots of other products also had messaging in them or messaging comprised the whole product.
But what we realized is that messaging a incredibly high engagement activity essential to doing digital work. It’s demanding and greedy of its users attention. Try texting and talking and you’ll see how greedy. It eats all your brain. So it needs to be rewarding to use and simple and powerful, all at once. It also as a result tends to pull in a big range of requirements because of its heavy use and (as mentioned above) it linked together all the diverse / weird / heterogeneous steps of digital work.
As soon as people used Slack a lot to express themselves they wanted better ways to express themselves. How to do formatting to emphasize, denote meaning or add 🤜 nuance 🤛 to writing? How to quote text? How to include code? Links? Documents? And that’s not even considering how to incorporate messages from computers, images, videos, audio snippets and the essential animated gifs. People expected all of that from messaging in 2014.
Then if you’ve got people expressing themselves and investing their attention in your software, how can you care for their attention? How do you let people alert each other and at the same time manage their own focused time? What do they need to know when first using the product? What do they need to know when they are power users? What about for topics they only want to skim versus topics they need to know everything about?
Saying No Nicely started as a product philosophy, spread to a business philosophy, and realistically functioned as the only coping mechanism that we could use to keep up and keep our heads on straight. On calls I often had to tell people Slack was an iceberg product — what you see at any moment is only a fraction of what’s happening.
When people doubted how complex it was to do messaging well, I might have shared some detail with them. For example, here’s a workflow drawing from a specific point in time (because this changed quite a lot over time) that sets the rules of whether Slack notifies someone or not.
Simple, right? It’s just messaging. It’s just putting text on a screen in chronological sequence. Yes, and, as I was helping customers use Slack we started it realize messaging was going to be the way nearly all computer work got done in the future.
Being Part Guide and Part Guard
I found pretty quickly in my new role as Director, Accounts at Slack that I needed to be part guide and part guard — a guide to help orient our customers and set them up for success; a guard to help keep them on the path of adoption and to protect our internal people from the complexity of demands of the real world.
And can I say how much fun it was to realize that? Super fun.
Years later I stood on stage at a software event in Dublin. I had recently moved to Ireland to help open Slack’s European HQ and we needed to get the word out that we’d opened shop and sought to hire.
The event moved into an audience Q&A and the mic landed in the hands of someone who asked about a free version of Slack for open source projects. This was a good idea! We liked open source projects and used open source code extensively in Slack. We’d also talked extensively internally about how to create an open source plan, and come up with no good way to do it.
I didn’t say all of this onstage but I did Say No Nicely. I told the questioner that we at Slack find it’s really hard to do software in the first place, and to do it to the standard we expect and that our customers expect.
Adding one additional feature or business model like an open source version of Slack may seem easy to consider, (make it free, make it scale!) but we’ve found it’s very hard to do in practice. It’s one more thing to build, integrate, debug, support and more.
My answer basically consisted of our Saying No Nicely approach, applied to an open source version of Slack. The questioner listened and basically agreed. Software was hard! Adding additional requirements made it harder, and harder to do well.
More years later, after we had grown to hundreds and more in our sales organization, Saying No Nicely evolved into a phrase we repeated often: Focus drives results. We understood focus to mean both intensity of approach to something as well as occlusion of all other things.
In other words: Saying No to them. Hopefully nicely.
Up next:
Socks, Slack Socks – From a small budget, a surprise hit for stylish feet. Early and later versions. A little nostalgia. The world is changeable.