Mental models for building products people love ft. Stewart Butterfield

Stewart ButterfieldThis is 2014. That was the year that Slack actually launched. I was interviewed by MIT Technology Review and asked if we were working to improve Slack. I said, "I feel like what we have right now is just a giant piece of shit. It's just terrible and we should be humiliated that we offer this to the public."

To me that was like, "You should be embarrassed." If you can't see almost limitless opportunities to improve, then you shouldn't be designing the product.

Lenny RachitskySlack was famous for being one of the early, consumerized B2B SaaS products.

Stewart ButterfieldAt more than one company all hands, I made everyone in the company repeat this as a chant. In the long run, the measure of our success will be the amount of value that we create for customers, and you can put effort into demonstrating that you have created this value and stuff like that, but there's no substitute for actually having created it.

Lenny RachitskySomething else I heard that you often espouse is friction in a product experience is actually often a good thing?

Stewart ButterfieldIt became an assumption that it should always be trying to remove friction when the challenge is really comprehension. If your software stops me and asks me to make a decision and I don't really understand it, you make me feel stupid. If people could get over the idea of reducing friction as a number of goal or reducing the number of clicks or taps to do something, and instead focus on how can I make this simple? How do I prevent people from having to think in order to use my software?

Lenny RachitskyYou started two companies, both famously pivoted. I imagine many people come to you for advice on pivoting.

Stewart ButterfieldThe decision is about have you exhausted the possibilities? Creating the distance so that you can make an intellectual rational decision about it rather than an emotional decision is essential. And the reason I say you have to be coldly rational about it is because it's fucking humiliating.

Lenny RachitskyToday, my guest is Stewart Butterfield, a founder and product legend who rarely does podcasts. Stewart founded Flickr and then Slack, which he sold to Salesforce in one of the biggest acquisitions in tech history at the time. There is so much product and leadership wisdom locked away in his head. I feel like our conversation just scratched the surface. We chat about utility curves, something he calls the owner's delusion, a hilarious pattern he sees at companies he calls hyperrealistic work-like activities, what he's learned about product and craft and taste and Parkinson's law, why you need to obsess with not making your users think, the backstory on his legendary we don't sell saddles here memo, and so much more. A huge thank you to Noah Weiss, Chris Cordell, Ali Rael, and Johnny Rogers for suggesting topics and questions for this conversation. This is a really special one and I really hope to have Stewart back to delve even deeper.

Here's a puzzle for you. What do OpenAI, Cursor, Perplexity, Vercel, Plaid and hundreds of other winning companies have in common? The answer is they're all powered by today's sponsor, WorkOS. If you're building software for enterprises, you've probably felt the pain of integrating single sign-on, SCIM, RBAC, audit logs, and other features required by big customers. WorkOS turns those deal blockers into drop-in APIs with a modern developer platform built specifically for B2B SaaS.
Whether you're a seed-stage startup trying to land your first enterprise customer or a unicorn expanding globally, WorkOS is the fastest path to becoming enterprise-ready and unlocking growth. They're essentially Stripe for enterprise features. Visit WorkOS.com to get started or just hit up their Slack support where they have real engineers in there who answer your questions superfast. WorkOS allows you to build like the best with delightful APIs, comprehensive docs, and a smooth developer experience. Go to workos.com to make your app enterprise-ready today.
Stewart, thank you so much for being here and welcome to the podcast.

Stewart ButterfieldThank you for having me. I'm excited.

Lenny RachitskyI'm even more excited. I'm so honored to have you here. I never told you this, but you've been towards the very top of my wish list of guests I have on this podcast ever since I started this podcast a few years ago, so I'm very excited that we're finally making this happen. I have so many questions for you. My first question is just what the heck are you up to these days? I feel like ever since you left Slack, we haven't heard much from Stewart. I'm curious what you're up to you hopefully or just chilling.

Stewart ButterfieldI'm mostly just chilling. I left Salesforce two and a half years ago and I have a two and a half year old, so she was actually born three days after my last day, so a lot of time with family and it's an enormous privilege to be able to spend time with young kids while they're young. No new company to announce or anything like that. I do get a lot of emails and texts. Basically every three to six weeks there's this cycle because Cal Henderson who's the CTO of Slack and who also, we worked together on Flickr, so have worked together now for 23 years, have been talking about what we want to do next if there is something.

But honestly, the big challenge has been I think these things are destroying the world and what we're good at is making software. So you find some way to make software that helped people use their phones less often, then that would be a big winner, but haven't come up with anything good. A lot of philanthropic work, nothing to announce there yet, but there's some cool projects that I'm working on, and a lot of just personal creative art projects and supporting other artists and stuff like that.

Lenny RachitskyTo prep for this chat, I talked to so many people that have worked with you over the years to try to figure out what you taught them about building product, building teams, building companies that most stuck with them, that most helped them build amazing products. The first is a concept called utility curves. This came up a bunch across so many people that have worked with you. Talk about what is a utility curve, how you use that to build better products.

Stewart ButterfieldThis is pretty easy because it's a very familiar S-curve where you have, it's flat and it starts arcing up and then there's a really steep part and then it levels off again. And on the horizontal axis, you can think of cost or effort and on the vertical axis, it's value or convenience. It depends exactly what you're talking about, but the idea is the first bit of effort you put into something doesn't result in a huge amount of value. And then there's some magic threshold where it produces an enormous amount of value and then continued investment doesn't really pay off. The most basic example I can think of is let's say you're making a hammer, and on that bottom axis, it's now quality, and if the hammer has a handle that breaks with any impact, then is totally useless. And if you make it a little bit stronger, it's still pretty useless and it's like junk, junk, junk, junk, junk. Okay, good, great. Then it doesn't matter anymore.

If you're making an app, okay, this app's going to have users and so let's make a user's table and a database, and so far you have generated no value. The reason I felt like this was so important is because we would talk about a feature, and usually features are thought of as a binary. You either have this feature or you don't. The argument I guess was have we just not invested enough in this or have we got all the value or convenience or quality or whatever that we could get out of this? And we had pointed diminishing returns and it just doesn't matter.
I think in many cases, people will add a feature, it's not good enough and so people don't use it or appreciate it, but now you've added some complexity to the app and then people give up or take it back or they try something in testing and they don't get the results they want, and so they decide that this a thing is worth doing. We would try to really investigate and decide whether we were on the first shallow part of the curve, the second shallow part of the curve, or we're just coming up to it. So I think it's a lot easier to understand the value of this when you're talking about a specific app and a specific feature, but I think it was ultimately helpful in getting people to understand whether something was worth it or not.

Lenny RachitskySo just to mirror back what I'm hearing, there's this, if you visualize this curve at the bottom, it's like I don't even know what this is. And then up the curve is like, okay, I sort of get it. And then at the top is, okay, I can't live without this now that I understand what this is for, it feels like it's a really a different way of thinking about getting to the aha moment for someone where they see, okay, saved items, I get it, I need to use this constantly. It feels like this works both for a specific feature and also just for Slack, getting people to even understand here's what Slack can do for you. And then now I can't live without Slack. And essentially this is a lens you use to figure out where to spend product resources because if you don't get up that curve to I get it and I can't live without it, nothing else matters. Is that the framework?

Stewart ButterfieldYeah, and I think then you layer on another concept like the, Bezos used the term divine discontent. The line actually moves because once people are familiar with a piece of software or the way a feature is implemented or something like that, their standards go up, and so there's this competition. And again, this axis can be, utility is the best general term for it, but it could be quality, convenience, speed, it could be any number of things, but as you improve your search capability or as you improve your login experience or your forget password experience or your checkout experience or whatever everyone else is as well. And so there's this continued investment and when forget about thinking about a new feature, you're looking at how the product works overall and usually things get implemented once, and then if they're lucky, they get improved upon periodically. Most things get improved upon very infrequently and some things get improved upon never.

I want to give an example at the absolute extreme because I actually don't know how long this has been, but I try not to criticize other people's software so much because I'm very familiar with the trade-offs and prioritization and how hard it can be and blah, blah, blah, blah. But okay, so most people have the Gmail Calendar app on their phone. I travel a fair bit. I'm mostly in the Eastern Time Zone, sometimes in Mountain Time, sometimes in Pacific, sometimes in English time, and sometimes in Japan, Central Europe. There's maybe 10 time zones, 12 time zones that I would ever choose. When you hit the option to set the time zone on an event in Google Calendar, on the iOS app, it presents all the time zones in the world in alphabetical order. And I mean, there's probably worse orderings, but there's no value in that.
And even when you start searching, it still presents them in alphabetical order by country with that turn. So if I'm in California and I'm trying to set the appointment for next week when I'm back in New York and I type in E-A-S-T and I get a bunch of garbage, okay, Eastern, and then the first one is Eastern Australia, New South Wales, and then Eastern Australia, Queensland, and then Eastern Australia, Daylight Savings and Eastern Australia standard time. And then you're like, "Well, fuck, I can't remember which one is Daylight Savings and which one is standard time?" I could keep going like this for a while. This is an app that's used by at least hundreds of millions of people, presumably every single Google employee. It's bananas how bad it is. There's so many, there's all these clever things you could do. Like you know me, I'm on the West Coast, first option should be the East Coast and vice versa. But it definitely shouldn't be that every time zone is presented with equal value. I don't a couple hundred time zones. I grew up in Canada. Newfoundland has its own time zone, which is offset by half an hour. The population of Newfoundland has about half a million people. Not that many people go to visit Newfoundland, maybe a million people in all of history so like a million and a half out of 8 billion people. And there's Newfoundland, the same with China time, which is like 25% of the world's population in this.
Anyway, that was a little bit longer than I intended to go on this example, but it's crazy because no one's going to switch to Gmail or to G Suite, Google Calendar from Outlook Exchange because the time zone picker is good, so maybe in some sense it doesn't matter, but at the same time there's a real value in delighting customers and there's an emotional connection that they form or don't form. And in some cases that could be really positive like they would recommend it. And when they switch companies or decide to start their own company, they're going to choose to use this product or advocate for it because of that emotional connection and vice versa.
They'll also be like, "I hate this thing that drives me bananas. I really think we should stop using it," or advocate for the alternative. And I think people just don't appreciate or come back to those things often enough. And then there's this category of really essential parts of the app again like account creation, sign up, forgot password, things like that, that for most organizations very infrequently get a lot of love and iteration and improvement despite the fact that the quality bar has gone up across the board and continually goes up.

Lenny RachitskyLet's go down that rabbit hole a little bit more around delight and craft. Slack was famous for being one of the early, let's say consumerized B2B SaaS products. Slack leaned into delight and experience and craft and a great experience. And you just as a product leader, I'd say are known as very taste forward, very craft oriented leader, which is pretty rare and I think continues to be rare. So there's a few things I want to talk about here. One is taste. I heard at a talk, you gave a talk on taste and you have a really unique perspective on just what taste is, what product taste looks like. Can you share that?

Stewart ButterfieldThere is a lot of you going back to the utility curves again, people who are obsessed with this one little thing and keep on adding more and more detailed improvements beyond the point where it makes much of a difference. But I guess a couple of things about taste. So one is can you learn to develop it? I think so because the word literally comes from experiencing food and putting stuff in your mouth. And can people become better chefs with training? Yes, absolutely. Undoubtedly, some people have a natural advantage and are born with this ability to make discernments that are difficult for other people to make and stuff like that. But you can definitely practice and you can definitely get better. The second thing I'd say is you can create a real advantage for yourself, for your product, for your company by leaning into it because most people don't have good taste and don't invest. You're probably familiar with, again, Jeff Bezos line, your margin is my opportunity and pretty obvious what he meant by that.

I would tell the story at Slack over and over again. It actually made it part of the new hire welcome. I'm in Vancouver at our Vancouver office and I'm going for a walk with Brandon Velestuk who's our, at the time creative director for product development, I think that was his title. And we're in the Yaletown neighborhood in Vancouver so there's really narrow sidewalks because it used to be a warehouse district and now it's fancy restaurants and nail salons and boutiques and stuff. And as it does in Vancouver, it starts to rain. We don't have umbrellas. We're walking back to the office and most people have umbrellas and we're on these narrow sidewalks with people coming towards us with umbrellas. We noticed how few people would move their umbrella out of the way. And of course, the other person, their umbrella, the pokey bits are exactly at eye level for people walking towards them. We would get forced off the sidewalk or having to duck down or whatever.
It became a game like we were guessing is this person going to tilt their umbrella out of the way so we can pass or not? And something like one-third of the people would do it. And we had this conversation about it where it's like, okay, I can think of three reasons why people wouldn't do it. One is they have very few avenues in their life to exercise power and this is one of them. And they're just, want to get out there and dominate people and cause suffering. Shouldn't ascribe to malice that which can be ascribed to ignorance so that probably is the explanation for a tiny, tiny, tiny percentage of people.
But the other two explanations aren't that great either. One is that they see it's happening, they see they're pushing other people off the sidewalk or poking them in the eye or whatever, and they're just like, "Fuck, that's too bad. I wish there was something I could do about that, but I can't think of anything." And the last reason is they just don't notice it all. They're just oblivious to their impact on other people. And they're so in their head, and I can't really think of any other explanations for it besides that.
And so we would say it's not like tilting your umbrella is our opportunity. That's not a great rephrase of your margin is my opportunity, but your failure to really be consider it exercise this courtesy and really be empathic about other people's experience is an advantage that you can create a critical advantage. I think that there's many reasons why Slack was successful at the moment. It was successful and we think we had a bunch of really wonderful tailwinds and all of that stuff, but it wouldn't have grown the way it did without those little conveniences which caused people to form an emotional connection because a lot of our growth came from startup A uses Slack, and then someone leaves startup A for startup B, and startup B doesn't use Slack yet. And they would be like, "Oh my God, you guys, you really, this is so good. We got to try it." And the spread was driven by that and people really genuinely advocating for it.

Lenny RachitskyThat is an amazing metaphor. I love that one moment became a value of product craftsmanship at Slack.

Stewart ButterfieldTilt your umbrella was a very common saying on company swag and stuff like that.

Lenny RachitskyIs there an example, I imagine there are many, but from the time of building Slack, especially in the early days where you chose to go big on craftsmanship and experience and delight versus speed where you thought looking back that was a really great idea and worth really core just to success.

Stewart ButterfieldHere's a bunch of little examples. Someone else came up with this idea, and I'm trying to remember who it was, but let's see, maybe Andrea Torres, maybe Ben Brown, something like that who was like, "Why did we ask people for email address and password if their ownership of the email address was the thing that allowed them to create the account in the first place? Why don't we just ask them for their email address and then send them a link?"

And so when Slack's first version of the mobile app came out, we're like, "Typing your password on your phone if you have any minimal threshold of password hygiene is a terrible experience." Capital H, lowercase Q, six, caret, period. So let's just have them enter the email address. We'll send them a link. The link will automatically open the app and authenticate them. And so there's one, a little example.

Lenny RachitskyWow. So you guys invented the magic link experience.

Stewart ButterfieldSomeone else invented. I want to be clear that I had seen that idea somewhere else, someone else, a blog post about it or something like that. But we were the first ones, to my knowledge, that really scaled that and made it a standard. There is another one which we really puzzled about in the very early days where people have a long history of using messaging apps from AOL Instant Messenger to SMS to WhatsApp, where their expectation is they get a notification for every message that's received. And in the case of Slack, that doesn't make as much sense because you're a member of many channels and the messages may not be for you, and so that's why we have the @ tagging people. And we certainly didn't invent that, that was Twitter.

But what we realized was people were signing up for Slack, and it's one engineer on this team inside of this larger organization, inside this larger company, and they would pull in the person next to them and they would say, "Let's try it out."
And then they would send a message and then one person would be like, "I didn't get a notification. This is bullshit."
We reluctantly decided that we had to send notifications for every single message as the default for new accounts. But once you had, I don't remember what the threshold would happen, I think it's once you had received 10 messages, we would pop up this little thing that says, "Hey, you have our default settings for notifications. We don't want Slack to be noisy for you. Would you like to switch to our-"

Stewart Butterfield... For notifications. We don't want Slack to be noisy for you. Would you like to switch to our recommended settings? And then they would just click a link and it would have what should be the default, which is, you only get a notification if it's a DM or someone tags you. But we realized it was worth that investment to get people over the hump. I'll give one more simple one and then one kind of more complex. One, people would just like the, I can't remember if it's called urgent or important, but the flag in Outlook, set the priority of a message for the recipients always got abused inside of every company. As soon as someone does it, everyone's like, "Okay, I'm going to do that too for my message."

And so all of your messages have the little flag and it becomes useless. We have @everyone, which causes a notification to be sent to every member of the channel when the message is sent and people would start, someone would find this feature inside of a organization. They would @everyone, everyone would get a notification and then the next person to send a message who was like, " Well, my thing's more important than Bob's thing. I'm going to also @everyone." And it became really obnoxious and people would complain about it, but it was, I don't know, I guess tragedy of the commons. It's not quite exactly the same thing, but it was this real dynamic that happened over and over again.
So we came up with what was called the shouty rooster, and internally we said, "Don't be a cock." But we didn't obviously say that publicly when you @everyone, a little rooster would pop up and it would have you sound waves coming out of its mouth and being really obnoxious and say, "Hey, this is going to cause a notification for 147 people in eight different time zones. Are you sure you want to send this message with the @everyone?" And of course, that worked amazingly and it dropped off. And again, it was really trying to shape people's behavior so that they used, one is not to be very flexible, but we knew that there was ways to use it that would be annoying and difficult for everyone. And so try to shape the communication culture inside the organization to take best advantage on it.

Lenny RachitskyThat feature still exists. I see that rooster all the, no, I don't see it all, well, actually I do @channel, because I run a big Slack, so I see that rooster, that survived.

Stewart ButterfieldYeah. Yeah, that survived and good because it was a trivially easy thing to implement and made a really big difference. But it also taught people how the product worked, because people probably didn't know that @everyone or @channel... Didn't think about the cost, at least.

Lenny RachitskyGenius.

Stewart ButterfieldYeah. Here's one more. So we decided we were going to Do Not Disturb as a feature. And we had this, not conundrum, but you're trying to take into account all the different uses of Slack because by the time we implemented this, 2017, there was tens of thousands of paying customers, the organizations, hundreds of probably millions of users, maybe hundreds of thousands of organizations. I don't remember how many. And everyone had set up stuff the way that they liked it, including things like ops alerts going into channels for on-call engineers for some of the biggest systems and apps in the world. And so we couldn't just deploy it right away. We realized that some of the decision-makers, the owners of the organizations were going to have really strong opinions about this. We also realized that some of the end users are going to have strong opinions, and we wanted to figure out a way to balance the concerns and give people appropriate means of control.

So we came up with this really elaborate system for the rollout, which was, we told everyone, I'm sorry, every Slack administrator that this was coming weeks before it came. And we told them that we were going to set a default for their organization, which I believe was either 7:00 P.M. to 7:00 A.M. in their local time zone, or 8: 00 A.M. to 8:00 P.M., I can't remember which it was, but also that they could override that default, and also that the individual end users could override that system owner default. And finally, that the system owner could, if they changed the default again, would override all of the end user's preferences and then the end users could override them again. And it wasn't to create this dynamic where people were at war, but so that you could change a policy and then people could still customize and stuff like that.
But this was a much longer and more convoluted process, but it allowed the millions of people who were using Slack to get the feature without creating a bunch of conflict and without people turning it off automatically. And I think critically, with setting a bunch of defaults, because if we didn't set the default, most people wouldn't turn it on at all. If we didn't default you to Do Not Disturb from 8:00 P.M. to 8:00 A.M. you probably, if you're the average person, wouldn't ever do it yourself. So that's another elaborate example where I think that investment made sense because it was a critical feature for a lot of people. And if we hadn't done it that way, I think it would've caused a lot of complaints and conflict and stuff like that.

Lenny RachitskyThose are amazing examples. I very much appreciate that Do Not Disturb feature when you guys launched that. I still remember that coming out. I'm sure a lot of people are very thankful for that.

Stewart ButterfieldYeah.

Lenny RachitskySomething else I heard that you often espouse, which is counterintuitive to a lot of people is about friction, friction in the product experience. That friction is actually often a good thing. It's a feature, not a bug a lot of times if you use it well. Talk about your experience there.

Stewart ButterfieldYeah. So yes, and there's also another issue around friction, which is it became like a mantra or just kind of an assumption that you should always be trying to remove friction. And in some cases that's true. We would talk about it in Slack. It was hard to market. It was hard to explain what it was if you had never used it before. You could say a messaging app for businesses or whatever, but a critical disadvantage to Slack doing out-of-home advertising, putting up a billboard versus beer or cars is, no one needs to be explained why they would want a car or beer, but everyone will have to explain one day why they want Slack. And so the problem there is comprehension, and this will come up an enormous amount. So now imagine you want to get tickets to the Taylor Swift concert in San Francisco and you go to the Ticketmaster website.

If you think about both your comprehension, it's perfect to this case. And that translates into the specificity of your intent and the degree of your intent is also kind of maxed out. So look, I really want to get these tickets. I know exactly what they are. They're Taylor Swift tickets for this date at this venue. And so in that scenario, it doesn't really matter if Ticketmaster's website is slow, it doesn't really matter if the payments page errors out, you're going to persist and get through it. So obviously they're better to reduce friction, but in some sense there's not a huge amount of value in doing that. For most creators of products, there are a handful of cases where that really is true for you as well. And they include things like user registration, authentication, checkout flows for e-commerce. I am significantly more likely to buy something if there's Apple Pay or Shop Pay or something like that.
I'm significantly less likely to carry through the purchase of something if I have to manually enter all of the fields of my address one at a time rather than having one of those address pickers. It's crazy, but the issue is my intent isn't always 100%, and the specificity of my intent isn't always 100%. So if your thing is direct to consumer T-shirts and you acquire customers through Instagram ads, all of them know what T-shirts are. It's like, "This looks like a good T-shirt to me." But I'm rarely 100% intent. I might have a very specific intent, but my intent's like 70%. So if you're, the amount of friction is above that, I'm not going to do it. But now, okay, people coming to Slack.com, some friend had mentioned Slack and talked their ear off at some point months ago, and then they saw a news article and then they saw someone's tweet and then they saw an ad on about the website they were visiting and they finally said, "Okay, I'm going to go to this website."
So their intent is at the absolute minimum threshold, it was before that last event happened, they were below and now they're above, but they're just above. The specificity of their intent like, "I need to get Taylor Swift concerts for this date at this venue." Is also very low, because they're like, "It's a work thing. I'm not sure it's a spreadsheet or a calendar or exactly what it is." So they were coming in at 0.1% over these critical thresholds. What was the challenge? It wasn't friction, because it's not like they were aiming for something and they knew what they were aiming for and they were just trying to get themselves to that point.
What we had to worry about was creating comprehension and in two senses, what is this thing? And what am I supposed to do next? And that creation of comprehension in the sense of explaining stuff, that creation of comprehension in the sense of the design of the UI, of the screen, of the page or whatever, and the visual hierarchy and the affordances that are there and the indication of things to interact with and which thing should be the next thing to do and all that stuff, that becomes really critical.
And I think very, very few people recognize that. They're like, "I want to get people who come to my webpage to the sign up form as quickly as possible." But if they don't know what they're signing up for and they don't know what it's going to do after, is it going to spam them? They don't know, "Am I going to have to pay on the next step or what?" Then they're just going to back out. And this was a lifelong battle because the remove friction orientation is so deep in people. Again, it really makes a difference in those cases where people do have an intent and they do know what they're trying to do is a poor approach when the challenge is really comprehension, and I think the secret is most, 70%, 80% or whatever of a product design is in that comprehension step because people, if they do ever open the preferences tab and look at all the options, rarely have an idea.
And if you can't teach them or make it possible for them to discover what the capabilities are, then they're not going to take advantage of them and they're not going to get as much out of it. And I think that the trick is for most of the unique parts of any application, most of the specific things that your app, your product, your software does are areas where the challenge is going to be comprehension inside of friction. It really could be anything Shopify, the purpose of the service for its end users is generally going to be kind to clear. But most people, most first-time store openers don't know that they can get reports or if they know that they can get reports, they don't know what kinds of reports. And if they know what kinds of reports they can get, they don't know how they can tweak them and what the timing should be and which things that are more important to display.
And I could go on and on and on and on, and people just don't recognize that. So I want to see if this is still true. I'm just going to open my phone and clock app. And they had the craziest description for alarms. It's a little bit different, but people can look at their own phone. So I have, it says alarms and it says sleep and a vertical bar, wake up and says, no alarm, and a button that says change. And then if you hit it, it says sleep is off. In order to automatically turn on sleep features and edit your schedule, you need to turn sleep on. So obviously sleep was a good name for this thing if you already had a way of getting people to understand it. If you don't, it's ungrammatical and incomprehensible and why would you ever do it? And I got to guess, it's been like this for years, 90 plus percent and maybe 98% of people just do what I do, which is that you just create, "I want the alarm on and I'm going to set the time for it."
And I don't know what turning sleep on does, but it's just the lack of comprehension prevents people from getting the value. And I'm sure that there's a bunch of value behind turning sleep on, whatever that means and people spend a lot of time on those features and it integrates with biometrics and your watch or who knows. Again, I still don't know because turning sleep on is like, what does that do? And what is it going to cost me? And what impact it's going to have? Those examples are just to me all over the place. And the reason I don't use most software where there was an actual choice point or the reason I don't use most features where there was a choice point for me is because I didn't understand what they were going to do and I don't give a shit. And if there is one mantra that I would use to replace that it's, Don't Make Me Think, I don't know if you remember that book.

Lenny RachitskyAbsolutely.

Stewart ButterfieldYeah. And honestly, it's been many more than 10 years since I read it, so I don't even remember all of the examples in the book, but as a mantra that was up there with utility curves because for two reasons. One is it's just like it's expensive to make a decision. You literally burn glucose. There's a metabolic action. There's ATP created in the mitochondria and your neurons and a bunch of stuff is happening and people do get decision fatigue and there is cognitive cost of all these things. But also there's an emotional aspect, which is, if your software stops me a second and asks me to make a decision and I don't really understand it, you make me feel stupid. I'm like, "I don't understand this."

Some people, maybe their orientation is, "Okay, the software is stupid." But I think most people are like, "Oh, I'm dumb." And if you ever talk to people who aren't especially technologically savvy, the canonical example is people who are under 50 talking to their parents about using some piece of software and what they're supposed to do, the parents always feel stupid like they're the ones that are wrong. And so if you're causing people to think, in the best case, it's unnecessary use of their biological resources, and in the worst case you've now made them feel bad, emotionally bad, and they're going to associate that with the product forever. And these are things that are just kind of rolling one into the other.
So I'm going to keep going with one last thing, because they just kind of come together, which is along with reduced friction, it's like reduce the number of clicks or taps it takes for someone to accomplish something which is almost always exactly the wrong thing. It's the easiest way you could make any action in your app, a single click or tap by just exposing every single possibility on one screen that scrolls for thousands and thousands and thousands and thousands of pages. And obviously that's terrible. So why do people think that a little bit of that is good? And here's an example. You open a menu, there's 14 things that people might want to do.
Level one is group them into like items and put a vertical, sorry, horizontal divider between them so at least people can kind of chunk and see what there is. Step two is present the two or three most common things or the five most common things, whatever and then have some form of other and then you go to a sub menu that has more items and the decision of how to tune that becomes incredibly important. I'm going to pick on Google again just because it is, I feel like I'm Donald Trump here, but I'm going to interrupt myself again with a story. It's-

Lenny RachitskyYeah, let's do it.

Stewart ButterfieldAt some conference or event, I don't remember what it was, and this is probably eight years ago and we're in the bar after the sessions ended at this thing. John Collison from Stripe is there and Sundar, CEO of Google is there. And John, sorry, Patrick goes up to Sundar and they can talk about anything. Stripe wasn't the behemoth, it was now at that point, but it was still a significant company, was up and coming. And what does Patrick want to talk to the Sundar about? It's in the Gmail app, the dragging of people. When you reply all to a message, you often want to change the two recipient to CC and move someone from CC to two or something like that. And just how physically the degree of dexterity that's required to do that inside of the Gmail app is very high.

It still hasn't been fixed, but it really struck me that Patrick could have asked for anything. It could have been any talk, it could have been a partnership. It was so irritating to him that it worked like this, he couldn't quite get over it. So anyway, back to bashing on Google, who in many respects do an incredible job and there's all kinds of amazing stuff they do on blah, blah, blah, but the Gmail actions on an individual email are broken into two very long menu items that are different. And one of them doesn't exist on either menu. There is an unlabeled icon is the only way to do it, and that's to mark something as unread once it's read. I have no idea why some of the actions are in one menu and some of the actions are in another menu. I think it's because some of them have to do with an individual email and some of them have to do with the whole thread, but it doesn't seem very consistent.
Every possible thing is listed there in one place. And so it becomes incredibly difficult to use because sometimes you have to tap in both menus, read all of the options, and say, "Okay, I've used the process of elimination and it's not here, so it must be there." Uber doesn't work like this anymore, but when I first brought this up to people inside of Slack, there was a moment when the Uber app, when you opened it was just, "Where would you like to go?" And other. And other was everything like change your payment method, set your location, anything you could do in Uber. And that was perfect because almost all the time people just wanted to choose where they wanted to go. Sometimes you wanted to change where your pickup was because you weren't there yet or whatever. And that was just like, what could be simpler than, "I'm going to tell you where I want to go or I'm going to achieve something else."?
I really tried to push people to what is the thing that people, or what is the two things or what is maybe three things that people could want to do here and then put everything behind other. And then if it takes them eight clicks or taps to do something, but every single one is trivially easy, that's great. If you reduce that to two clicks or taps, but every part of it is this fraught decision where I'm opening all of the menus and trying to figure out which thing is the right thing, and the more, comparing three things to each other is this difficult four things, it's kind of geometrically more expensive to compare 15 different options all to the other to see if this is the one that you might want. That just becomes impossibly expensive. So to me, those are all really connected. And if people could get over the idea of reducing friction as the or reducing the number of clicks or taps to do something and instead focus on how can I make this simple? How do I prevent people from having to think in order to use my software? How can I make this trivially easy? One last example, because this was really influential for me. So I was going back and forth in Vancouver in San Francisco at the time when we were talking about all this inside of Slack, and I was behind a teenager in line aboard the plane and it was like, we're on the jet way. It took a long time. And I was watching her use Snapchat and it was insane.
She was tapping at least four times a second, sometimes six or seven times a second. It was like dismissing stories and doing stuff. But there was a fluidity to it because everything was like, do I want to see this again? Do I want to see the next story from this person? Do I want to switch to a different person? Instead, a notification came up, she answered someone's thing, she took a selfie of herself and everything was just like... So she was tapping four times a second for six minutes. I mean, probably there was some breaks in there. And that was the highest and best use of Snapchat for a 15 year old girl in 2016 or whenever that was. And imagine if the goal was to try to make her tap less, how much of an impediment it would've been to the experience that both her and Snapchat wanted to create?

Lenny RachitskyIt's so fun to listen to this and the examples you gave of, it gives us a lot of insight into the way your mind works of just constantly unsatisfied with the way other products work with your product. And I think that's core. Patrick is a good example of Stripe. I feel like that's a recurring theme with very successful product leaders is just constantly unsatisfied and unhappy with how things work.

Stewart ButterfieldYeah.

Lenny RachitskyI love just even the way you summarize this, just a really good reframing of, instead of obsessing with reducing friction and reducing steps, instead think, how do I reduce the amount of thinking the user has to do? I've never heard of it described as, you have to think about the ATP and glucose being used to actually think, and your goal is to reduce that versus let's just reduce friction, reduce clicks.

Stewart ButterfieldYeah. I think in my more cynical examples, I would say to people, " Stop what you're doing for a second, close-"
Stop what you're doing for a second. Close your eyes, take a couple of deep breaths, and then pretend that you're an actual human being. And open their eyes again, and then look at this thing and see, can you figure out what it's supposed to do or say. Or what action you're supposed to take or what the impact will be if you take that action. There's a whole nother related cycle. But before I get into it, I know that I am verbose. I want to wrap up your last example of people being unsatisfied.

So here's the quote that I was trying to find. This is 2014, so like that was the year that Slack actually launched officially in February. And this is now near the end of the year. I was interviewed by MIT Technology Review and asked if we were working to improve Slack. I said, "Oh God, yeah. I try to instill this into the rest of the team, but certainly I feel like what we have right now is just a giant piece of shit. It's just terrible and we should be humiliated that we offer this to the public. Not everyone finds that motivational though."
So I came into the office the next day and people had printed out on like 40 pieces of 8.5 by 11 paper that quote, and pasted it up on the wall. But to me that was like, you should be embarrassed by it. It should be a perpetual desire to improve. You should probably be like, "Oh, this is great," and you could be proud of individual pieces of work. But in the aggregate, if you can't see almost limitless opportunities to improve, then you shouldn't be designing the product, or you shouldn't be in charge of the company, or you shouldn't almost nothing.
Again, you could reduce it down to a tiny feature is anywhere close to perfect. And if A, that's acknowledged freely inside the organization. And B, people think about continually improving as the goal. And that could be like Six Sigma Toyota, Kaizen, that kind of side of thing. Or it could be that story that... I can't remember his name right now. The guy who started Bridgewater tells about Michael Jordan-

Lenny RachitskyRay Dalio.

Stewart ButterfieldYeah, Ray Dalio in his book talks about Michael Jordan learning to ski. Every time he messed up, he wanted the ski instructor to tell him exactly what he was doing wrong. Because to him, every one of those was a gem that he could collect, and he could actually become a good skier. And what he wanted to do was become a good skier. That requires a lot of trust inside the organization.

But if you can get to the point where like, "Hey, we are trying to find improvements. We're trying to be critical because you're trying to make this as great as it can possibly be." And not always, not with every person, but most of the time with most people, you can get them to the point where that really direct criticism is actually motivational. It is like people are grateful to have the feedback, whether that's coming from their peers inside the company or from end users of the product. Because you realize, oh yeah, that is bad and we should fix it.
Unlike NoCo Tools, Lovable isn't about static pages. It builds full apps with real functionality, and it's fast. What used to take weeks, months, or years, you can now do over a weekend. So if you've been sitting on an idea, now is the time to bring it to life. Get started for free at Lovable.dev. That's lovable.dev. This makes me think about, let's call it a rant that you have about how it takes a lot of work to make anything work at all. That just the default state is not working. Can you just share what you share there.

Stewart ButterfieldYeah. I mean, so this is a lot to do with, and maybe this is more recently, it shows up in politics a lot for me. But by the way, if anyone listening to this can help me find this tweet store from somewhere between 2016 and 2020, I don't have a precise idea. And it was this guy's thread about how hard it was to get a stop sign set up. And I believe it was in response to someone claiming that Bitcoin is going to replace US dollars, something about crypto. And his point was like, here's what happened when we tried to get a stop sign put up on a residential street in my neighborhood. And the literal years it took, and the number of agencies that were involved.

Like the engineering department, traffic planners, the HOA, and... I don't remember all of the organizations because, and I did that I could search better and find this again. Because it was truly a masterpiece of how difficult it is to get a stop sign put up in most places. The message that I hear from most politicians, and unfortunately this works really well, is things should be good. But they're not because someone is doing something bad, which is preventing the goodness.
So billionaires are making things unaffordable. Or immigrants are taking your jobs. Or lazy freeloaders are sucking off a government tea, and causing us all have to pay more taxes, or something like that. The reality is almost nothing works. It's actually another call. I said in this case, John has a great encapsulation of this and I'm sure you're familiar with it, like that. It ends with the world as a museum of passion projects. Because for anything to get done at all requires not just the resources and effort required to instantiate that thing in the real world, but all of the politicking and the sociology and the convincing.
And there's a book called Why Nothing Works Recently, which is like, it's not an... I'm sorry to the author, if they... I doubt they're listening, but just it's not like an amazingly written book. I found it a little bit repetitive, but the content was really incredible, just explaining why it's so hard. And how there's this progressive increase in the number of vetoes that are available for any kind of course of action and how difficult it is... And this shows up in permitting for new construction and stuff like that. But also shows up obviously inside of organizations.
And the challenge is that people, A, I think this is evolutionary biological. It's hard for us to understand the world, except by anthropomorphizing it. And so if it didn't rain this year, it's because a God is mad, and probably because we didn't sacrifice enough goats or something last year. It's hard for people to understand just that, wow, weather is incredibly complex and chaotic, and ecosystems and climatology, and all that.
Same thing with the world. Like if I am struggling to pay all of my bills and be able to afford a little bit of luxury in the sense of location or a present for my kids or whatever, it's got to be somebody's fault. There has to be a decision that's made somewhere. And the reality is everything is so complicated. Everything is so multivariate, it's not satisfying. It's a terrible political message.
It's much easier to say that there is like, oh, we understand why things are bad in the way that you're concerned about. And it's turns out that it's some someone's decision, and because of them it's bad. And so if we got rid of them or were able to overcome their decision, overturn it, and institute our own thing, then things would be good for you. And this really to me shows up inside of those organizations as well. I'll pause there.

Lenny RachitskyI know kind of along those lines, you're a big believer in something called Parkinson's Law.

Stewart ButterfieldYeah. So the original of that is, I think it's 1956. It's an article in The Economist by Parkinson. And the Maxim is work expands to fill the time available for its completion. And the way that it shows up, this is a little bit subtle. So like one of the things I found, since I don't have a job is there's much less time pressure. And that maxim, like if you want something done, give it to a busy person. The inverse is also true that like, if you're not that busy, wow, basic things take a really long time.

And so Parkinson actually starts out with his example of writing and posting a letter. And I don't remember who he used with the first example, but someone who's incredibly busy and has all these things they have to respond to. And then another case like a retired robot who has all the time in the world. It takes her a long time to write the letter. It takes her a long time to put it in the envelope, and then you go to the post office and post it.
But the real meat of it is, for me later when he talks about the size of the organization, and he uses a bunch of examples. This is again 1950s, and he's British, so he's looking at the Royal Navy. And specifically he's looking at a chart that shows the relationship between the number of capital ships in the Navy, the number of sailors, and the number of administrators. And very familiar graph for people looking at any part of government. Any part of the relationship between the number of administrators at a university and the number of students and faculty, teaching faculty. Where it's like, okay, the number of ships goes like this and the number of sailors is looking right along with it. And the number of administrators goes like this.
And the reason this ties into the work expands to fill the time available for its completion is people hire, and they train. And here's the sad truth for anyone running a company is there are exceptions. There's certain types of engineers that are an exception to this. But the overwhelming majority of people you hire want to hire more people who report to them. And it's not because they're evil, and it's not because they're stupid. In fact, they're smart because everyone knows that the number of people who report to you correlates with your career trajectory, the amount of money that you're paid. The amount of authority you have inside the organization and on and on and on.
So we would hire 27 Royal product managers in Slack who immediately want to hire someone. It's like, what the hell? What would that person do? And they articulate it this way, but essentially it's like, "Well, that person would do the product management and then I would do strategy."

Lenny RachitskyClassic.

Stewart ButterfieldIt's really, I think the essential thing to understand about this is it's not because people are evil, and it's not because they're stupid. And it's to me, very related to everything is complex. And if maybe this is my butterfly's law, I haven't thought about this way before. But I tweeted this a very, very long time ago like if you... Everything is simple if you have no idea what you're talking about. So the other side of that is like if something seems simple, probably you don't understand it. And there's obvious exceptions to that.

But for anything that involves a large organization or a lot of human beings, if the problem seems simple, you don't get it. So every budget process, no head of engineering know, head of sales, no CFO, no GC, who's ever going to come back and say, "Oh, I've actually think next year we can just hire fewer people. Or we're going to keep it flat or we're going to shrink through attrition because we don't need any more people to do what we're doing." Not because they're evil, not because they're stupid, but it's almost overpowering impulse inside the organization that often leads to disastrous results. And so there's an...
I'll give one example from Slack's history, and I have tried in the past to disguise this example so that no one feels bad about it but I... Unfortunately, the specifics are so important to the example that it's not disguised and so I'll just reiterate that the people involved aren't stupid or evil. And one example that's from the outside. So the example inside of Slack was we introduced threads, which was the ability to reply to a message inside of a channel. And let's say you, Lenny, post a message. I, Stewart reply to it. You will automatically get a notification. And now Sarah later on replies to the same message. Both you and I, as people who have push in that thread will receive a notification that there's been more activity, and so on. So like every single time anyone replies to it.
So when the feature first was released or like when we did the final product review before it was released, the input box was pre-populated with at the person before you in the thread. And I was using the feature and I would put the insertion point there, select all delete, and then start writing my message. And even if I wanted to add someone specifically, I almost never wanted to start my sentence with at that, because it just made it hard to reference what they were saying before. So I said, "Get rid of this because, A, I think most people won't use it. Or if they did want to add someone, they're not going to want to do it at the beginning of the sentence.
And by the way, you're teaching them to use the product wrong. Because it's important that everyone understand that every previous poster in this thread will automatically receive a notification unless they've figured it."
So okay, we release it. Six months goes by and suddenly the at thing comes back. And so I messaged someone around the team and I said, "Hey, there's been a regression. This is super weird. I don't know what happened. But the at thing came back." And they said, "Oh no, this is on purpose. We did a bunch of research." And so I was like, "What?" And I went through this and it was, if I recall correctly, it wasn't even P-95 certainty on this analysis. But it was something like when we do this, threads are 2.17 messages long, versus 2.14 messages long on average for when we don't do it.
And so first of all, why is a longer thread better? Like maybe a shorter thread is better? It can be fewer messages that people have to go back and forth. Also, that's such a tiny difference. Also, again, I don't remember the actual statistical analysis, so I'm not going to claim that it was incorrect. But I'm pretty sure this was outside the bounds of certainty that they can have. But the real thing was, oh my God, so you guys put flags into the product, you A-B tested it. You did the instrumentation. You created tables in the database or whatever we're using to record all of that.
You wrote queries to pull that. You created charts based on that data. You had meetings to discuss it. And just kind unpacking all of the things that would've had to happen for this to come back. And it's like thousands of person hours at a minimum, because any feature change at that scale of organization, it's involving like a dozen people. Engineering, QA, analytics teams, project managers, user research and stuff like that. The problem with that, so I think it was a bad idea, right? But the problem with that was the difference that you could possibly achieve between having this feature and not having this feature is like this much whatever units you want. The cost of doing the analysis was this much. So it's guaranteed to be a loser.
Like there's just, there's no world in which anyone could imagine putting the at previous respondent in the thread at the beginning of the message could possibly make that much of a difference to the quality of Slack, and how much utility it provides for people and all of that. But you know that to put the feature flags in, to ship new versions of the product, to put the instrumentation in. To have it all the API calls to record every action that people take to do all the analytics, to create the dashboard. To put paste a screenshot of that into a Google Slides presentation. To send the invitations to the meeting, to reschedule the meeting because someone couldn't make it. To have everyone sit down and look at the thing. Like guaranteed loser.
And I know that Fareed told you to ask me about this hyper realistic work-like activities. And so here's my grand theory. Hyper realistic work-like activities goes along with this other concept called known valuable work to do. And when I say known, I mean both you know what it is and you know that it's valuable. And the problem with almost every organization at the very beginning, you have an enormous amount of work that you know what to do, and you know that it's going to be valuable. So like starting a business, open a bank account. Because there's almost infinite general value of opening a bank account. You have to do it. It's very simple to do.
And so at the very beginning of any startup, they're like, "I'm creating a user's table, and I'm doing sorting passwords," and you're doing all the things that are kind of absolutely necessary. And everyone knows exactly what they are. And so everyone's going to work in the morning and they're like right on. And I have 10 things to do, and every single one of them is something I know how to do. And it's definitely going to be valuable. Time goes on. And the relationship between the supply of work to do and the demand for doing work just starts to change.
More and more people get hired. Every product manager wants to hire a junior product manager. Every new person, the first person you bring in on the risk and compliance team is like, "Oh my God, there's so many risks and things we have to be compliant with. We better hire more people on my team to do more risk and compliance work." Which probably to some degree is right. But we're going to have more and more of those people and they're going to call meetings with each other.
And now suddenly you have all these people with work to do and you've done all the easy obvious stuff. And now your questions are like, "God, should we do FedRAMP high and make a Slack version? Which is going to require us to have wholly separate physical infrastructure for the hardware that runs the software? And also a whole different operations team, which has only US citizens on it? What is the possible number of dollars that we could make from doing this? And how much complexity is going to be when we want to do updates to the software because we update two totally separate independent systems and rec."
It just gets out of whack, and so people end up... Like if you hire 17 product marketers, you're going to have 17 product marketers worth of demand for work to do. And if you don't have sufficient supply of product marketing work to do, they're just going to do other stuff. Again, very important, not because they're stupid, not because they're evil. But because they're like, I'm a product marketer and I want to be recognized for my work. And my spouse has criticized me because they take, I should have already got promoted in the last cycle, and they really got to demonstrate some wins here and whatever it is.
And so people are like calling meetings with their colleagues to preview the deck that they're going to show in the big meeting to get feedback on whether they should improve some of the slides. And that hyper-realistic work-like activity is superficially identical to work. Like we are sitting in a conference room and there's something being projected up there, and we're all talking about it. And that's exactly what work is. Hopefully not all of work for everyone inside of your company. But that's exactly what we do when we're working.
But this is actually a fake bit of work, and it's so subtle that I'll do it. Our board members will do it. Every executive will do it. And the further you are from having all of the context and all of the information and the decision-making authority and stuff like that, the easier it is to get trapped in this stuff. And people will just perform enormous amounts of hyper-realistic work-like activities, and have no idea that that's what they're doing. And the result of that, I guess, is that if you are a leader, if you're manager, director, an executive, you're the CEO, it's on you to ensure that there is sufficient supply of known valuable work to do. And there almost always is, but it's creating the clarity around that. Creating the alignment. Making sure everyone understands it, but that's what they're supposed to be doing, and then obviously doing it.

Lenny RachitskyAmazing. I could listen to Stewart's rants all day. Hyper- realistic work-life activities. We need to coin this-

Stewart ButterfieldUnfortunately, it doesn't make a good acronym. It's pretty ugly.

Lenny RachitskyOkay.

Stewart Butterfield.

Lenny RachitskyOkay. it a try. And just to close the loop on that, the solution is the leader recognizing this is happening and stopping it. Telling people why are we spending time on this thing that is not going to get us anywhere?

Stewart ButterfieldYeah. And what you just said probably isn't the best way because that sounds like you're chiding them, and they're dumb. When it's actually your responsibility to make sure that there's sufficient clarity around what the priorities are, and explicitly saying no to things upfront and stuff like that. Rather than merging and say like, "Hey, you guys are a bunch of idiots wasting your time on this thing that doesn't matter." Whose fault is it? It's the manager's fault. It's the VP of whatever's fault. It's the CX, whatever, it's the C... Ultimately, it's the leader of the organization that has the responsibility to make sure that there is sufficient known-valuable work to do. And that's actually harder than it might appear.

Lenny RachitskyOkay. Before we run out of time, I want to touch on two other topics. One is, when people think of Stewart Butterfield, I think a lot of people think of, We Don't Sell Saddles Here. Your legendary Medium post that is just, I don't know, it's become a historic piece of literature in the annals of product building and in startups. I haven't heard people ask you much about this recently. So let me just ask a couple of questions. What was the reason you put that out? What was the backstory on writing that memo? Why was it necessary?

Stewart ButterfieldWell, it really was an internal memo.

Lenny Rachitsky... Memo. Why was it necessary?

Stewart ButterfieldWell, it really was an internal memo and there's a bit of a digression. One of the crappy things about Slack is if all your corporate communication is on email, depending on exactly how it works and what system you use, you probably walk away with an archive of everything you said at Company X. If it's Slack, once you're turned off, you lose access to all that history. And so it's kind of like, "Oh, man. If I had only exported all of my messages before I left, I would have all this stuff," but that was absolutely verbatim. I did not change a word of what I said inside the company. Well, I think we were still eight people. Maybe at most 10, but I think it was eight people.

Lenny RachitskyIt was before Slack launched even.

Stewart ButterfieldYeah, it was before Slack launched. It was when we're doing private beta. And the point of it was to start to instill those ideas as early as possible and really create this alignment inside of that small team so that it could persist to survive as we grew and scaled. Yeah, that was the idea.

Lenny RachitskyAnd the gist, just for people that aren't super familiar with it, but we'll link to it, is just it's not enough just to build a great product. You just as much have to put effort into communicating what this does for them, the problem this is solving for them, the outcome this is going to achieve for them. Is that a good way to think about it?

Stewart ButterfieldYeah. And again, comparing it to beer or cars, beer goes back to pre-civilization. Cars were obviously , but at some point you had to convince people why they would want a car instead of a horse. For your new AI-based recruiting tool or your calendar app or whatever, there's some reason why you think that people should use yours instead of the thing that they're using now, which might be a wholesale one-for- one replacement, or more often is a change in the way that you're working that has a bunch of other adjacencies and you want to expand into these other categories. You're not just responsible for creating the product, but also, to a certain degree, creating the market.

There's this book, Positioning, which is an absolute classic. It's very short. I would recommend everyone read it, where the point of it is, from my perspective, it's almost impossible to create a new idea in someone's head. It's much easier to take a couple of existing ideas and put them together. So it's much easier to say it's like Jaws meets Star Wars, or it's Uber for Pets or something like that, than to come up with an actual new idea. But you have to do that because if your thing is different in any significant way from the alternatives, you're not just creating the product. You're creating the market. They're really kind of one and the same.

Lenny RachitskyThe reason I wanted to touch on it is I think still people continue to not listen to this advice and continue to over-invest in more features, more products, things like that. Just the specific example of, "We don't sell saddles here," just to quickly communicate this to folks, and correct me if I'm missing anything, is just instead of, "Hey, look at this amazing saddle we've bought," which you want to communicate as, "Here, go horseback riding. Look at this incredible experience you can have." And then they decide, "Oh, shit. I need to go buy a saddle to do that."

Stewart ButterfieldYeah. And 100%, that aspect of it is not original because I think that's something that marketers have done for a long time, certainly in the marcom and advertising. If you want to sell Harley-Davidson's, there are people who are going to geek out on the engines and stuff like that and the quality of the leather and stuff like that. But when you're selling the motorcycle, you're selling the open road and freedom and the wind in your hair. And if you're Lululemon, you are obviously selling yoga pants, but you're also selling health and aspiration and being the best version of yourself and a bunch of other stuff. Oh my God, I forgot the classic version of it.

Lenny RachitskyThere's the ship ...

Stewart ButterfieldYou're selling the screwdriver.

Lenny RachitskyOh, yeah. The nail.

Stewart ButterfieldYeah, the nail. Anyway.

Lenny RachitskyYeah, we missed that one. Well, there's the one I think about is instead of trying to convince men to build a ship, instill a yearning for the sea.

Stewart ButterfieldYes. Exactly. That's something that goes back in history.

Lenny RachitskyOkay. Let me ask you about pivoting. You are potentially the king of pivots. You started two companies both famously pivoted, both from video games, which is why I asked you about that at the beginning, into very successful companies. I imagine many people come to you for advice on pivoting. Let me just ask when folks come to you asking, "Should I stick with my idea? Should I pivot?" what sort of advice do you find most helps them?

Stewart ButterfieldYeah, I mean, I think it's partly an intuition because obviously the decision is about, "Have you exhausted the possibilities?" and in the case where we were working on Glitch, this game where we used IRC for internal communication and we added a bunch of IRC which became the Proto Slack. I think Slack had an enormous advantage in the fact that we are working on this for several years without actually explicitly working on it and only doing the minimum number of features that were absolutely guaranteed to be successful in the sense that it was so irritating that we couldn't stand it anymore or such an obvious improvement that we couldn't help but take advantage of it. We still had $ 9 million left and everyone still liked the game and we were all happy working on it, but I think by that point I had exhausted every non-verdiculous long shot idea to make it commercially successful, and so I decided to abandon it.

But the default advice for anyone in anything is persevere. It's like a kitten hanging off the branch and a poster says, "Hang in there." There's so many stories of, "So-and-so started out going door-to-door and was rejected by everyone and then suddenly there was Nike," or something like that and just, "If you stick with it long enough, you'll eventually be successful." I think you have to really be coldly rational. Some of this shows up in the book Thinking in Bets. Some of it's in Annie Duke's second book, the title of which I'm forgetting right now, but someone will know it.

Lenny RachitskyYeah, Thinking in Bets, and then what was the second? I forget.

Stewart ButterfieldShe actually uses Glitch and Slack as an example of a smart fold basically. My expected value here has diminished to the point where this alternative looks more attractive. And the reason I say you have to be coldly rational about it is because it's fucking humiliating. I convinced so many and you have to convince so many people to get a company off the ground. You have to go to investors. You have to go to early employees and say, "You should leave your other job and come work for this because here's the incredible feature we're imagining." You have to go to the press and you have to make all these promises and you have users and you've committed things to the users and you've convinced them to give up their time for this thing. And so I think for a lot of people, it feels better to just keep doing it until it dies of suffocation due to lack of capital or something like that. Then just to admit, "Okay, I was wrong. This didn't work," and it's humiliating. It's painful. It's wrenching. It has a bad impact.

When we shut down Glitch, there was a lot of people who loved it and would spend all of their free time and couldn't wait to get home from work to go play it more. And that was their community and the community just disappeared, all these people and all these identities that have been created. And obviously, people lost their jobs and people who had moved their families to a different city in order to take this job now weren't going to have a job anymore. So pivots aren't something I take lightly. I think it's very different to be like, "There's three of us and we started making this app and then we pivoted to a different app." That doesn't even really count. If you're six months into something, you're still messing around. You're trying to figure out what it is that you're building. It's not really a pivot. Obviously in this case, it worked out great and there's survivorship bias and that doesn't mean that everyone should pivot all the time. But I think creating the distance so that you can make an intellectual, rational decision about it rather than an emotional decision is essential.

Lenny RachitskyI love, also, your piece of advice of just exhaust. Once you've exhausted all the ideas, that's a really good time to see what else is out there.

Stewart ButterfieldYeah, just all the good ideas.

Lenny RachitskyAll the good ideas,

Stewart ButterfieldAll the realistic. Yeah.

Lenny RachitskyYeah. The point you made about just kind of persevering, I just had Melanie Perkins, CEO of Canva, in the podcast. 100 investors rejected her before somebody finally decided to invest and she just kept pushing.

Stewart ButterfieldYeah. I think that's a slightly different example, right? She eventually believed in the concept of the product and in the vision. It was just trying to figure out the right articulation to get investors who ended up being obviously very, very happy.

Lenny RachitskyExtremely happy. Oh, geez. Okay. Maybe a final topic depending on how time goes. I want to talk about generosity. I talked to a bunch of people, as I said, that have worked with you and the number one theme that came up again and again and again when I asked them about you and what has stuck most with them is just generosity. So I'm going to read a few examples that I heard from folks that are examples of your generosity over the years.

So one person shared that he needed a little money before Christmas and he said, "Stewart literally walked me out of the building, went to the cash machine, handed me $500, told me to go home to my family." Other folks shared that, when you talked about Glitch just recently when you had to lay people off, you cried real tears when you were laying people off and then you spent an incredible amount of time helping them find new jobs and extending their severance pay and just taking it extremely, extremely seriously, much more than I think most people feel like CEOs do. Someone else shared that you paid 100% of employees health insurance to give them just fewer things to think about.
When you went public, you basically created the best possible situation for employees, no lockup, direct listing. Also, with the structure of the Slack deal, people said that acquisition was very employee friendly. That's employees. There's also just the way you thought about customers. A few examples: You gave free credits to businesses who were struggling to pay the bills during COVID. You released this fair billing, which I think was very innovative at the time, where you stopped charging people for seats they weren't using, even though they signed a deal to charge for those seats. A lot of times, you slipped release schedules because you just wanted to make features better and better for people. And I'll end with this quote: "Stewart is a leader who takes the responsibility he feels for his employees personally, and to which he extends the most generous circumstances he could muster. That feels worth celebrating."
So first of all, I just want to celebrate you. I think it's really rare and inspiring to meet a leader like that. Clearly, you've had a lot of impact on a lot of people. I don't know exactly the question I want to ask, but I guess in what part is this intentional, just like, "This is how we win. I'm going to be very generous and help people because I know this will help long-term"? How much of this is just a and it's just the way you are as a person?

Stewart ButterfieldI think a lot of it is just the way I am as a person and I had wonderful parents who raised me right, but I think there is a little bit of a lesson there and I'm just going to assume people's familiarity with the prisoner's dilemma. The acts of generosity to me are, "Oh, I am demonstrating that I am going to cooperate as we iterate in this game." And if you do that, then people will also cooperate and you both benefit. Whereas if you never really know if the other person is going to defect at the first opportunity, then your best bet is to defect. And so there's a game theoretic aspect, usually in games that are much, much, much more complicated than the prisoner's dilemma.

I think one thing I didn't touch on before, but to me was important enough, is that at more than one company all hands, I made everyone in the company repeat this as a chant. It was, "In the long run, the measure of our success will be the amount of value that we create for customers." And I wanted to be super clear and explicit about that because it should be if anything you're doing feels like a little bit shady, a little bit cheating, a little bit maximizing at the wrong moment or taking advantage of a customer or anything like that, definitely shouldn't do it. Because to me, I mean I think it's literally true, but it's also an ethical way to run a business. And it's not just that the ethics are good. It's like there's advantages for you. You're able to attract a better class of employees. If all your employees are ethical, then it's going to be a better place for everyone to work and you're going to be happier and you're going to have fewer internal problems and all that stuff.
But I think it really is true that especially in the long run, you can't destroy value for your customers and expect to be successful. You have to actually make their lives better. And you could put effort into pointing it out to them and demonstrating that you have created this value and stuff like that, but there's no substitute for actually having created it. And I think that is incredibly important and that implies a real generosity, whether that's in negotiating terms with an enterprise deal or that's policy decisions. One time that it blew up in our face was our SLA was like, "For any downtime, you get 100 times your money back." Because from my perspective, it's like if we're down for two minutes, it's like pennies. It doesn't really make any difference. If we're down for 10 hours or something like that, then we have bigger problems than paying back people.
Fast-forward, we now have hundreds of millions of dollars in revenue and we've gone public. And shortly after we go public, we have one of the biggest outages we ever had. I don't remember how long it was, but it was many hours. But by the time we got that scale, 100 times the money back for the third of a day that we were down was $8 million or something like that. It didn't cost us any money because we just gave it to people in the form of credits, but it meant that a bunch of revenue that we had already anticipated for the next quarter wasn't going to show up because people's credits were going to offset what they would've otherwise paid us. And so we definitely changed the terms of service after that because being a public company is a little bit different. But in every other respect, I think they were all really important decisions that were helpful in us becoming successful.

Lenny RachitskyWas that policy ... It was automatic? You didn't even have to claim it. It was just automatically you get this credit?

Stewart ButterfieldAnd the default is you don't have to pay if you let us know. This was, "We will automatically, proactively, preemptively without any input from you ..."

Lenny RachitskyToo generous.

Stewart Butterfield"Apply this credit to your account, and just send you a message that it happened. And by the way, we will do it on the aggregate for downtime, even if the issue didn't affect you as a customer."

Lenny RachitskyWow. Too generous. You found the edge of where you want to be.

Stewart ButterfieldYeah.

Lenny RachitskyWhat was that mantra again that you had the company chant? I think this is a really nice way to end it.

Stewart ButterfieldIt was, "In the long run, the measure of our success will be the amount of value we create for customers."

Lenny RachitskyIncredible. I'm just trying to picture the entire team at Slack reciting this mantra.

Stewart ButterfieldIt was hundreds of people. It felt very like, Kim Jong-Un or Stalin or something like that.

Lenny RachitskyWell, on that note, most people don't know this about you, but your actual name when you were born was not Stewart. It was Dharma.

Stewart ButterfieldYeah.

Lenny RachitskyAnd this all makes sense as you learn that.

Stewart ButterfieldYeah. My name is Dharma Jeremy Butterfield, so my parents named me. And when I was 12, I changed it because I just really wanted to be normal and for some reason I thought Stewart was a normal name. And by the way, you'll notice this now that I said it. Any character except for Stuart Little the mouse, anytime you see a character in a movie, a novel, TV show or whatever, there's only the loser Stewart and the asshole Stewart. It's obviously, in the collective consciousness, a terrible name and I shouldn't have chosen it and I regret it. But by the time I realized that, Dharma and Greg had already come out and it would've seemed like I was bandwagon jumping. And people thought it was a girl's name, even though in India it's obviously only a boy's name.

I'm going to add just one last little tidbit because I forgot about this earlier on and I think it helps tie things together, and it's called the owner's delusion. And this is based on something I posted on Twitter. The person who came up with the name later deleted their account and so I have no idea who it was and who to credit for this. But what I had posted was, and this was a long time ago when restaurant websites have gotten better and it doesn't really matter because Google Local was taking over everything, but this is, let's say, 10 years ago.
There's five things you could possibly want when you go to a restaurant's website and it's their street address, their phone number, the menu, the hours of operation ... Oh my God, I'm forgetting the fifth thing. Oh, and making a reservation, how to make a reservation. And again, this problem has to some extent taken care of it's itself or at least improved, but what you would get was this super slow loading photo, the Ken Burns effect as it ...

Lenny RachitskyThe flashed.

Stewart ButterfieldAnd then fading in and then some music starts playing. And then if they show you the phone number, it's not clickable.

Lenny RachitskyImage.

Stewart ButterfieldIt's not even text that you can copy because yes, it's an image. And they don't have the hours. They don't put the address or whatever and it's just like, "What?" For sure, whoever made this website for the restaurant owner and the restaurant owner themselves have definitely been in the position where they went to somebody else's restaurant website because they wanted to get the address or the opening hours or the phone number or whatever. So why does it end up like this and what should we call this?

And whoever replied to the tweet, she said, "We should call it the owner's delusion," and I was like, "Oh my God. That's perfect." And I think that is incredibly powerful and what ends up with the result, like Apple naming whatever that feature is called Sleep, which it's too hard to understand what that can possibly mean. And that's why people anticipate, despite the fact that when they get to your website for the first time, their intent is absolutely the minimum number of micro points above the threshold required from them to actually take that action.
You're like, "All right. Welcome to my website," and there's a bunch of BS and there's a bunch of stuff that doesn't make any sense and the buttons are inscrutable. And it's unclear what to do next because I think that my thing is so important and I don't recognize that you are at work and you were late this morning and you have to go to the bathroom and you're just a regular human being who has stuff going on, that you're concerned that your kid is a fuck-up and they're getting in trouble at school and stuff like that. They're not subjects who paid money to go to your play and are sitting in the audience and waiting for that curtain to go out. They're people who are going to bounce in a fraction of a second. And so everyone should always be conscious of the owner's solution.

Lenny RachitskyI love that. What's the solution? Is it have other people look at it and give you feedback?

Stewart ButterfieldYeah, and recognize it. And unfortunately, it's one of those things like Murphy's Law.

Lenny RachitskyYeah.

Stewart ButterfieldEven you can go wrong even when you take into account Murphy's Law.

Lenny RachitskyThat's right.

Stewart ButterfieldBut if you don't name it and recognize it and discuss it and train yourself to think that way, take a breath, pretend you're a regular person, and then look at this again and see if it makes sense, then you're screwed.

Lenny RachitskyI love that. I love that you threw this in here. I have a billion other questions I'm going to ask you in part two when we do this someday. Stewart, thank you so much for doing this. Thank you so much for being here.

Stewart ButterfieldYeah. Thank you for having me, Lenny. I really enjoyed it.

Lenny RachitskySame here. Bye, everyone. Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennyspodcast.com. See you in the next episode.

Stewart ButterfieldThis is 2014. That was the year that Slack actually launched. I was interviewed by MIT Technology Review and asked if we were working to improve Slack. I said, "I feel like what we have right now is just a giant piece of shit. It's just terrible and we should be humiliated that we offer this to the public."

To me that was like, "You should be embarrassed." If you can't see almost limitless opportunities to improve, then you shouldn't be designing the product.

Lenny RachitskySlack was famous for being one of the early, consumerized B2B SaaS products.

Stewart ButterfieldAt more than one company all hands, I made everyone in the company repeat this as a chant. In the long run, the measure of our success will be the amount of value that we create for customers, and you can put effort into demonstrating that you have created this value and stuff like that, but there's no substitute for actually having created it.

Lenny RachitskySomething else I heard that you often espouse is friction in a product experience is actually often a good thing?

Stewart ButterfieldIt became an assumption that it should always be trying to remove friction when the challenge is really comprehension. If your software stops me and asks me to make a decision and I don't really understand it, you make me feel stupid. If people could get over the idea of reducing friction as a number of goal or reducing the number of clicks or taps to do something, and instead focus on how can I make this simple? How do I prevent people from having to think in order to use my software?

Lenny RachitskyYou started two companies, both famously pivoted. I imagine many people come to you for advice on pivoting.

Stewart ButterfieldThe decision is about have you exhausted the possibilities? Creating the distance so that you can make an intellectual rational decision about it rather than an emotional decision is essential. And the reason I say you have to be coldly rational about it is because it's fucking humiliating.

Lenny RachitskyToday, my guest is Stewart Butterfield, a founder and product legend who rarely does podcasts. Stewart founded Flickr and then Slack, which he sold to Salesforce in one of the biggest acquisitions in tech history at the time. There is so much product and leadership wisdom locked away in his head. I feel like our conversation just scratched the surface. We chat about utility curves, something he calls the owner's delusion, a hilarious pattern he sees at companies he calls hyperrealistic work-like activities, what he's learned about product and craft and taste and Parkinson's law, why you need to obsess with not making your users think, the backstory on his legendary we don't sell saddles here memo, and so much more. A huge thank you to Noah Weiss, Chris Cordell, Ali Rael, and Johnny Rogers for suggesting topics and questions for this conversation. This is a really special one and I really hope to have Stewart back to delve even deeper.

Here's a puzzle for you. What do OpenAI, Cursor, Perplexity, Vercel, Plaid and hundreds of other winning companies have in common? The answer is they're all powered by today's sponsor, WorkOS. If you're building software for enterprises, you've probably felt the pain of integrating single sign-on, SCIM, RBAC, audit logs, and other features required by big customers. WorkOS turns those deal blockers into drop-in APIs with a modern developer platform built specifically for B2B SaaS.
Whether you're a seed-stage startup trying to land your first enterprise customer or a unicorn expanding globally, WorkOS is the fastest path to becoming enterprise-ready and unlocking growth. They're essentially Stripe for enterprise features. Visit WorkOS.com to get started or just hit up their Slack support where they have real engineers in there who answer your questions superfast. WorkOS allows you to build like the best with delightful APIs, comprehensive docs, and a smooth developer experience. Go to workos.com to make your app enterprise-ready today.
Stewart, thank you so much for being here and welcome to the podcast.

Stewart ButterfieldThank you for having me. I'm excited.

Lenny RachitskyI'm even more excited. I'm so honored to have you here. I never told you this, but you've been towards the very top of my wish list of guests I have on this podcast ever since I started this podcast a few years ago, so I'm very excited that we're finally making this happen. I have so many questions for you. My first question is just what the heck are you up to these days? I feel like ever since you left Slack, we haven't heard much from Stewart. I'm curious what you're up to you hopefully or just chilling.

Stewart ButterfieldI'm mostly just chilling. I left Salesforce two and a half years ago and I have a two and a half year old, so she was actually born three days after my last day, so a lot of time with family and it's an enormous privilege to be able to spend time with young kids while they're young. No new company to announce or anything like that. I do get a lot of emails and texts. Basically every three to six weeks there's this cycle because Cal Henderson who's the CTO of Slack and who also, we worked together on Flickr, so have worked together now for 23 years, have been talking about what we want to do next if there is something.

But honestly, the big challenge has been I think these things are destroying the world and what we're good at is making software. So you find some way to make software that helped people use their phones less often, then that would be a big winner, but haven't come up with anything good. A lot of philanthropic work, nothing to announce there yet, but there's some cool projects that I'm working on, and a lot of just personal creative art projects and supporting other artists and stuff like that.

Lenny RachitskyTo prep for this chat, I talked to so many people that have worked with you over the years to try to figure out what you taught them about building product, building teams, building companies that most stuck with them, that most helped them build amazing products. The first is a concept called utility curves. This came up a bunch across so many people that have worked with you. Talk about what is a utility curve, how you use that to build better products.

Stewart ButterfieldThis is pretty easy because it's a very familiar S-curve where you have, it's flat and it starts arcing up and then there's a really steep part and then it levels off again. And on the horizontal axis, you can think of cost or effort and on the vertical axis, it's value or convenience. It depends exactly what you're talking about, but the idea is the first bit of effort you put into something doesn't result in a huge amount of value. And then there's some magic threshold where it produces an enormous amount of value and then continued investment doesn't really pay off. The most basic example I can think of is let's say you're making a hammer, and on that bottom axis, it's now quality, and if the hammer has a handle that breaks with any impact, then is totally useless. And if you make it a little bit stronger, it's still pretty useless and it's like junk, junk, junk, junk, junk. Okay, good, great. Then it doesn't matter anymore.

If you're making an app, okay, this app's going to have users and so let's make a user's table and a database, and so far you have generated no value. The reason I felt like this was so important is because we would talk about a feature, and usually features are thought of as a binary. You either have this feature or you don't. The argument I guess was have we just not invested enough in this or have we got all the value or convenience or quality or whatever that we could get out of this? And we had pointed diminishing returns and it just doesn't matter.
I think in many cases, people will add a feature, it's not good enough and so people don't use it or appreciate it, but now you've added some complexity to the app and then people give up or take it back or they try something in testing and they don't get the results they want, and so they decide that this a thing is worth doing. We would try to really investigate and decide whether we were on the first shallow part of the curve, the second shallow part of the curve, or we're just coming up to it. So I think it's a lot easier to understand the value of this when you're talking about a specific app and a specific feature, but I think it was ultimately helpful in getting people to understand whether something was worth it or not.

Lenny RachitskySo just to mirror back what I'm hearing, there's this, if you visualize this curve at the bottom, it's like I don't even know what this is. And then up the curve is like, okay, I sort of get it. And then at the top is, okay, I can't live without this now that I understand what this is for, it feels like it's a really a different way of thinking about getting to the aha moment for someone where they see, okay, saved items, I get it, I need to use this constantly. It feels like this works both for a specific feature and also just for Slack, getting people to even understand here's what Slack can do for you. And then now I can't live without Slack. And essentially this is a lens you use to figure out where to spend product resources because if you don't get up that curve to I get it and I can't live without it, nothing else matters. Is that the framework?

Stewart ButterfieldYeah, and I think then you layer on another concept like the, Bezos used the term divine discontent. The line actually moves because once people are familiar with a piece of software or the way a feature is implemented or something like that, their standards go up, and so there's this competition. And again, this axis can be, utility is the best general term for it, but it could be quality, convenience, speed, it could be any number of things, but as you improve your search capability or as you improve your login experience or your forget password experience or your checkout experience or whatever everyone else is as well. And so there's this continued investment and when forget about thinking about a new feature, you're looking at how the product works overall and usually things get implemented once, and then if they're lucky, they get improved upon periodically. Most things get improved upon very infrequently and some things get improved upon never.

I want to give an example at the absolute extreme because I actually don't know how long this has been, but I try not to criticize other people's software so much because I'm very familiar with the trade-offs and prioritization and how hard it can be and blah, blah, blah, blah. But okay, so most people have the Gmail Calendar app on their phone. I travel a fair bit. I'm mostly in the Eastern Time Zone, sometimes in Mountain Time, sometimes in Pacific, sometimes in English time, and sometimes in Japan, Central Europe. There's maybe 10 time zones, 12 time zones that I would ever choose. When you hit the option to set the time zone on an event in Google Calendar, on the iOS app, it presents all the time zones in the world in alphabetical order. And I mean, there's probably worse orderings, but there's no value in that.
And even when you start searching, it still presents them in alphabetical order by country with that turn. So if I'm in California and I'm trying to set the appointment for next week when I'm back in New York and I type in E-A-S-T and I get a bunch of garbage, okay, Eastern, and then the first one is Eastern Australia, New South Wales, and then Eastern Australia, Queensland, and then Eastern Australia, Daylight Savings and Eastern Australia standard time. And then you're like, "Well, fuck, I can't remember which one is Daylight Savings and which one is standard time?" I could keep going like this for a while. This is an app that's used by at least hundreds of millions of people, presumably every single Google employee. It's bananas how bad it is. There's so many, there's all these clever things you could do. Like you know me, I'm on the West Coast, first option should be the East Coast and vice versa. But it definitely shouldn't be that every time zone is presented with equal value. I don't a couple hundred time zones. I grew up in Canada. Newfoundland has its own time zone, which is offset by half an hour. The population of Newfoundland has about half a million people. Not that many people go to visit Newfoundland, maybe a million people in all of history so like a million and a half out of 8 billion people. And there's Newfoundland, the same with China time, which is like 25% of the world's population in this.
Anyway, that was a little bit longer than I intended to go on this example, but it's crazy because no one's going to switch to Gmail or to G Suite, Google Calendar from Outlook Exchange because the time zone picker is good, so maybe in some sense it doesn't matter, but at the same time there's a real value in delighting customers and there's an emotional connection that they form or don't form. And in some cases that could be really positive like they would recommend it. And when they switch companies or decide to start their own company, they're going to choose to use this product or advocate for it because of that emotional connection and vice versa.
They'll also be like, "I hate this thing that drives me bananas. I really think we should stop using it," or advocate for the alternative. And I think people just don't appreciate or come back to those things often enough. And then there's this category of really essential parts of the app again like account creation, sign up, forgot password, things like that, that for most organizations very infrequently get a lot of love and iteration and improvement despite the fact that the quality bar has gone up across the board and continually goes up.

Lenny RachitskyLet's go down that rabbit hole a little bit more around delight and craft. Slack was famous for being one of the early, let's say consumerized B2B SaaS products. Slack leaned into delight and experience and craft and a great experience. And you just as a product leader, I'd say are known as very taste forward, very craft oriented leader, which is pretty rare and I think continues to be rare. So there's a few things I want to talk about here. One is taste. I heard at a talk, you gave a talk on taste and you have a really unique perspective on just what taste is, what product taste looks like. Can you share that?

Stewart ButterfieldThere is a lot of you going back to the utility curves again, people who are obsessed with this one little thing and keep on adding more and more detailed improvements beyond the point where it makes much of a difference. But I guess a couple of things about taste. So one is can you learn to develop it? I think so because the word literally comes from experiencing food and putting stuff in your mouth. And can people become better chefs with training? Yes, absolutely. Undoubtedly, some people have a natural advantage and are born with this ability to make discernments that are difficult for other people to make and stuff like that. But you can definitely practice and you can definitely get better. The second thing I'd say is you can create a real advantage for yourself, for your product, for your company by leaning into it because most people don't have good taste and don't invest. You're probably familiar with, again, Jeff Bezos line, your margin is my opportunity and pretty obvious what he meant by that.

I would tell the story at Slack over and over again. It actually made it part of the new hire welcome. I'm in Vancouver at our Vancouver office and I'm going for a walk with Brandon Velestuk who's our, at the time creative director for product development, I think that was his title. And we're in the Yaletown neighborhood in Vancouver so there's really narrow sidewalks because it used to be a warehouse district and now it's fancy restaurants and nail salons and boutiques and stuff. And as it does in Vancouver, it starts to rain. We don't have umbrellas. We're walking back to the office and most people have umbrellas and we're on these narrow sidewalks with people coming towards us with umbrellas. We noticed how few people would move their umbrella out of the way. And of course, the other person, their umbrella, the pokey bits are exactly at eye level for people walking towards them. We would get forced off the sidewalk or having to duck down or whatever.
It became a game like we were guessing is this person going to tilt their umbrella out of the way so we can pass or not? And something like one-third of the people would do it. And we had this conversation about it where it's like, okay, I can think of three reasons why people wouldn't do it. One is they have very few avenues in their life to exercise power and this is one of them. And they're just, want to get out there and dominate people and cause suffering. Shouldn't ascribe to malice that which can be ascribed to ignorance so that probably is the explanation for a tiny, tiny, tiny percentage of people.
But the other two explanations aren't that great either. One is that they see it's happening, they see they're pushing other people off the sidewalk or poking them in the eye or whatever, and they're just like, "Fuck, that's too bad. I wish there was something I could do about that, but I can't think of anything." And the last reason is they just don't notice it all. They're just oblivious to their impact on other people. And they're so in their head, and I can't really think of any other explanations for it besides that.
And so we would say it's not like tilting your umbrella is our opportunity. That's not a great rephrase of your margin is my opportunity, but your failure to really be consider it exercise this courtesy and really be empathic about other people's experience is an advantage that you can create a critical advantage. I think that there's many reasons why Slack was successful at the moment. It was successful and we think we had a bunch of really wonderful tailwinds and all of that stuff, but it wouldn't have grown the way it did without those little conveniences which caused people to form an emotional connection because a lot of our growth came from startup A uses Slack, and then someone leaves startup A for startup B, and startup B doesn't use Slack yet. And they would be like, "Oh my God, you guys, you really, this is so good. We got to try it." And the spread was driven by that and people really genuinely advocating for it.

Lenny RachitskyThat is an amazing metaphor. I love that one moment became a value of product craftsmanship at Slack.

Stewart ButterfieldTilt your umbrella was a very common saying on company swag and stuff like that.

Lenny RachitskyIs there an example, I imagine there are many, but from the time of building Slack, especially in the early days where you chose to go big on craftsmanship and experience and delight versus speed where you thought looking back that was a really great idea and worth really core just to success.

Stewart ButterfieldHere's a bunch of little examples. Someone else came up with this idea, and I'm trying to remember who it was, but let's see, maybe Andrea Torres, maybe Ben Brown, something like that who was like, "Why did we ask people for email address and password if their ownership of the email address was the thing that allowed them to create the account in the first place? Why don't we just ask them for their email address and then send them a link?"

And so when Slack's first version of the mobile app came out, we're like, "Typing your password on your phone if you have any minimal threshold of password hygiene is a terrible experience." Capital H, lowercase Q, six, caret, period. So let's just have them enter the email address. We'll send them a link. The link will automatically open the app and authenticate them. And so there's one, a little example.

Lenny RachitskyWow. So you guys invented the magic link experience.

Stewart ButterfieldSomeone else invented. I want to be clear that I had seen that idea somewhere else, someone else, a blog post about it or something like that. But we were the first ones, to my knowledge, that really scaled that and made it a standard. There is another one which we really puzzled about in the very early days where people have a long history of using messaging apps from AOL Instant Messenger to SMS to WhatsApp, where their expectation is they get a notification for every message that's received. And in the case of Slack, that doesn't make as much sense because you're a member of many channels and the messages may not be for you, and so that's why we have the @ tagging people. And we certainly didn't invent that, that was Twitter.

But what we realized was people were signing up for Slack, and it's one engineer on this team inside of this larger organization, inside this larger company, and they would pull in the person next to them and they would say, "Let's try it out."
And then they would send a message and then one person would be like, "I didn't get a notification. This is bullshit."
We reluctantly decided that we had to send notifications for every single message as the default for new accounts. But once you had, I don't remember what the threshold would happen, I think it's once you had received 10 messages, we would pop up this little thing that says, "Hey, you have our default settings for notifications. We don't want Slack to be noisy for you. Would you like to switch to our-"

Stewart Butterfield... For notifications. We don't want Slack to be noisy for you. Would you like to switch to our recommended settings? And then they would just click a link and it would have what should be the default, which is, you only get a notification if it's a DM or someone tags you. But we realized it was worth that investment to get people over the hump. I'll give one more simple one and then one kind of more complex. One, people would just like the, I can't remember if it's called urgent or important, but the flag in Outlook, set the priority of a message for the recipients always got abused inside of every company. As soon as someone does it, everyone's like, "Okay, I'm going to do that too for my message."

And so all of your messages have the little flag and it becomes useless. We have @everyone, which causes a notification to be sent to every member of the channel when the message is sent and people would start, someone would find this feature inside of a organization. They would @everyone, everyone would get a notification and then the next person to send a message who was like, " Well, my thing's more important than Bob's thing. I'm going to also @everyone." And it became really obnoxious and people would complain about it, but it was, I don't know, I guess tragedy of the commons. It's not quite exactly the same thing, but it was this real dynamic that happened over and over again.
So we came up with what was called the shouty rooster, and internally we said, "Don't be a cock." But we didn't obviously say that publicly when you @everyone, a little rooster would pop up and it would have you sound waves coming out of its mouth and being really obnoxious and say, "Hey, this is going to cause a notification for 147 people in eight different time zones. Are you sure you want to send this message with the @everyone?" And of course, that worked amazingly and it dropped off. And again, it was really trying to shape people's behavior so that they used, one is not to be very flexible, but we knew that there was ways to use it that would be annoying and difficult for everyone. And so try to shape the communication culture inside the organization to take best advantage on it.

Lenny RachitskyThat feature still exists. I see that rooster all the, no, I don't see it all, well, actually I do @channel, because I run a big Slack, so I see that rooster, that survived.

Stewart ButterfieldYeah. Yeah, that survived and good because it was a trivially easy thing to implement and made a really big difference. But it also taught people how the product worked, because people probably didn't know that @everyone or @channel... Didn't think about the cost, at least.

Lenny RachitskyGenius.

Stewart ButterfieldYeah. Here's one more. So we decided we were going to Do Not Disturb as a feature. And we had this, not conundrum, but you're trying to take into account all the different uses of Slack because by the time we implemented this, 2017, there was tens of thousands of paying customers, the organizations, hundreds of probably millions of users, maybe hundreds of thousands of organizations. I don't remember how many. And everyone had set up stuff the way that they liked it, including things like ops alerts going into channels for on-call engineers for some of the biggest systems and apps in the world. And so we couldn't just deploy it right away. We realized that some of the decision-makers, the owners of the organizations were going to have really strong opinions about this. We also realized that some of the end users are going to have strong opinions, and we wanted to figure out a way to balance the concerns and give people appropriate means of control.

So we came up with this really elaborate system for the rollout, which was, we told everyone, I'm sorry, every Slack administrator that this was coming weeks before it came. And we told them that we were going to set a default for their organization, which I believe was either 7:00 P.M. to 7:00 A.M. in their local time zone, or 8: 00 A.M. to 8:00 P.M., I can't remember which it was, but also that they could override that default, and also that the individual end users could override that system owner default. And finally, that the system owner could, if they changed the default again, would override all of the end user's preferences and then the end users could override them again. And it wasn't to create this dynamic where people were at war, but so that you could change a policy and then people could still customize and stuff like that.
But this was a much longer and more convoluted process, but it allowed the millions of people who were using Slack to get the feature without creating a bunch of conflict and without people turning it off automatically. And I think critically, with setting a bunch of defaults, because if we didn't set the default, most people wouldn't turn it on at all. If we didn't default you to Do Not Disturb from 8:00 P.M. to 8:00 A.M. you probably, if you're the average person, wouldn't ever do it yourself. So that's another elaborate example where I think that investment made sense because it was a critical feature for a lot of people. And if we hadn't done it that way, I think it would've caused a lot of complaints and conflict and stuff like that.

Lenny RachitskyThose are amazing examples. I very much appreciate that Do Not Disturb feature when you guys launched that. I still remember that coming out. I'm sure a lot of people are very thankful for that.

Stewart ButterfieldYeah.

Lenny RachitskySomething else I heard that you often espouse, which is counterintuitive to a lot of people is about friction, friction in the product experience. That friction is actually often a good thing. It's a feature, not a bug a lot of times if you use it well. Talk about your experience there.

Stewart ButterfieldYeah. So yes, and there's also another issue around friction, which is it became like a mantra or just kind of an assumption that you should always be trying to remove friction. And in some cases that's true. We would talk about it in Slack. It was hard to market. It was hard to explain what it was if you had never used it before. You could say a messaging app for businesses or whatever, but a critical disadvantage to Slack doing out-of-home advertising, putting up a billboard versus beer or cars is, no one needs to be explained why they would want a car or beer, but everyone will have to explain one day why they want Slack. And so the problem there is comprehension, and this will come up an enormous amount. So now imagine you want to get tickets to the Taylor Swift concert in San Francisco and you go to the Ticketmaster website.

If you think about both your comprehension, it's perfect to this case. And that translates into the specificity of your intent and the degree of your intent is also kind of maxed out. So look, I really want to get these tickets. I know exactly what they are. They're Taylor Swift tickets for this date at this venue. And so in that scenario, it doesn't really matter if Ticketmaster's website is slow, it doesn't really matter if the payments page errors out, you're going to persist and get through it. So obviously they're better to reduce friction, but in some sense there's not a huge amount of value in doing that. For most creators of products, there are a handful of cases where that really is true for you as well. And they include things like user registration, authentication, checkout flows for e-commerce. I am significantly more likely to buy something if there's Apple Pay or Shop Pay or something like that.
I'm significantly less likely to carry through the purchase of something if I have to manually enter all of the fields of my address one at a time rather than having one of those address pickers. It's crazy, but the issue is my intent isn't always 100%, and the specificity of my intent isn't always 100%. So if your thing is direct to consumer T-shirts and you acquire customers through Instagram ads, all of them know what T-shirts are. It's like, "This looks like a good T-shirt to me." But I'm rarely 100% intent. I might have a very specific intent, but my intent's like 70%. So if you're, the amount of friction is above that, I'm not going to do it. But now, okay, people coming to Slack.com, some friend had mentioned Slack and talked their ear off at some point months ago, and then they saw a news article and then they saw someone's tweet and then they saw an ad on about the website they were visiting and they finally said, "Okay, I'm going to go to this website."
So their intent is at the absolute minimum threshold, it was before that last event happened, they were below and now they're above, but they're just above. The specificity of their intent like, "I need to get Taylor Swift concerts for this date at this venue." Is also very low, because they're like, "It's a work thing. I'm not sure it's a spreadsheet or a calendar or exactly what it is." So they were coming in at 0.1% over these critical thresholds. What was the challenge? It wasn't friction, because it's not like they were aiming for something and they knew what they were aiming for and they were just trying to get themselves to that point.
What we had to worry about was creating comprehension and in two senses, what is this thing? And what am I supposed to do next? And that creation of comprehension in the sense of explaining stuff, that creation of comprehension in the sense of the design of the UI, of the screen, of the page or whatever, and the visual hierarchy and the affordances that are there and the indication of things to interact with and which thing should be the next thing to do and all that stuff, that becomes really critical.
And I think very, very few people recognize that. They're like, "I want to get people who come to my webpage to the sign up form as quickly as possible." But if they don't know what they're signing up for and they don't know what it's going to do after, is it going to spam them? They don't know, "Am I going to have to pay on the next step or what?" Then they're just going to back out. And this was a lifelong battle because the remove friction orientation is so deep in people. Again, it really makes a difference in those cases where people do have an intent and they do know what they're trying to do is a poor approach when the challenge is really comprehension, and I think the secret is most, 70%, 80% or whatever of a product design is in that comprehension step because people, if they do ever open the preferences tab and look at all the options, rarely have an idea.
And if you can't teach them or make it possible for them to discover what the capabilities are, then they're not going to take advantage of them and they're not going to get as much out of it. And I think that the trick is for most of the unique parts of any application, most of the specific things that your app, your product, your software does are areas where the challenge is going to be comprehension inside of friction. It really could be anything Shopify, the purpose of the service for its end users is generally going to be kind to clear. But most people, most first-time store openers don't know that they can get reports or if they know that they can get reports, they don't know what kinds of reports. And if they know what kinds of reports they can get, they don't know how they can tweak them and what the timing should be and which things that are more important to display.
And I could go on and on and on and on, and people just don't recognize that. So I want to see if this is still true. I'm just going to open my phone and clock app. And they had the craziest description for alarms. It's a little bit different, but people can look at their own phone. So I have, it says alarms and it says sleep and a vertical bar, wake up and says, no alarm, and a button that says change. And then if you hit it, it says sleep is off. In order to automatically turn on sleep features and edit your schedule, you need to turn sleep on. So obviously sleep was a good name for this thing if you already had a way of getting people to understand it. If you don't, it's ungrammatical and incomprehensible and why would you ever do it? And I got to guess, it's been like this for years, 90 plus percent and maybe 98% of people just do what I do, which is that you just create, "I want the alarm on and I'm going to set the time for it."
And I don't know what turning sleep on does, but it's just the lack of comprehension prevents people from getting the value. And I'm sure that there's a bunch of value behind turning sleep on, whatever that means and people spend a lot of time on those features and it integrates with biometrics and your watch or who knows. Again, I still don't know because turning sleep on is like, what does that do? And what is it going to cost me? And what impact it's going to have? Those examples are just to me all over the place. And the reason I don't use most software where there was an actual choice point or the reason I don't use most features where there was a choice point for me is because I didn't understand what they were going to do and I don't give a shit. And if there is one mantra that I would use to replace that it's, Don't Make Me Think, I don't know if you remember that book.

Lenny RachitskyAbsolutely.

Stewart ButterfieldYeah. And honestly, it's been many more than 10 years since I read it, so I don't even remember all of the examples in the book, but as a mantra that was up there with utility curves because for two reasons. One is it's just like it's expensive to make a decision. You literally burn glucose. There's a metabolic action. There's ATP created in the mitochondria and your neurons and a bunch of stuff is happening and people do get decision fatigue and there is cognitive cost of all these things. But also there's an emotional aspect, which is, if your software stops me a second and asks me to make a decision and I don't really understand it, you make me feel stupid. I'm like, "I don't understand this."

Some people, maybe their orientation is, "Okay, the software is stupid." But I think most people are like, "Oh, I'm dumb." And if you ever talk to people who aren't especially technologically savvy, the canonical example is people who are under 50 talking to their parents about using some piece of software and what they're supposed to do, the parents always feel stupid like they're the ones that are wrong. And so if you're causing people to think, in the best case, it's unnecessary use of their biological resources, and in the worst case you've now made them feel bad, emotionally bad, and they're going to associate that with the product forever. And these are things that are just kind of rolling one into the other.
So I'm going to keep going with one last thing, because they just kind of come together, which is along with reduced friction, it's like reduce the number of clicks or taps it takes for someone to accomplish something which is almost always exactly the wrong thing. It's the easiest way you could make any action in your app, a single click or tap by just exposing every single possibility on one screen that scrolls for thousands and thousands and thousands and thousands of pages. And obviously that's terrible. So why do people think that a little bit of that is good? And here's an example. You open a menu, there's 14 things that people might want to do.
Level one is group them into like items and put a vertical, sorry, horizontal divider between them so at least people can kind of chunk and see what there is. Step two is present the two or three most common things or the five most common things, whatever and then have some form of other and then you go to a sub menu that has more items and the decision of how to tune that becomes incredibly important. I'm going to pick on Google again just because it is, I feel like I'm Donald Trump here, but I'm going to interrupt myself again with a story. It's-

Lenny RachitskyYeah, let's do it.

Stewart ButterfieldAt some conference or event, I don't remember what it was, and this is probably eight years ago and we're in the bar after the sessions ended at this thing. John Collison from Stripe is there and Sundar, CEO of Google is there. And John, sorry, Patrick goes up to Sundar and they can talk about anything. Stripe wasn't the behemoth, it was now at that point, but it was still a significant company, was up and coming. And what does Patrick want to talk to the Sundar about? It's in the Gmail app, the dragging of people. When you reply all to a message, you often want to change the two recipient to CC and move someone from CC to two or something like that. And just how physically the degree of dexterity that's required to do that inside of the Gmail app is very high.

It still hasn't been fixed, but it really struck me that Patrick could have asked for anything. It could have been any talk, it could have been a partnership. It was so irritating to him that it worked like this, he couldn't quite get over it. So anyway, back to bashing on Google, who in many respects do an incredible job and there's all kinds of amazing stuff they do on blah, blah, blah, but the Gmail actions on an individual email are broken into two very long menu items that are different. And one of them doesn't exist on either menu. There is an unlabeled icon is the only way to do it, and that's to mark something as unread once it's read. I have no idea why some of the actions are in one menu and some of the actions are in another menu. I think it's because some of them have to do with an individual email and some of them have to do with the whole thread, but it doesn't seem very consistent.
Every possible thing is listed there in one place. And so it becomes incredibly difficult to use because sometimes you have to tap in both menus, read all of the options, and say, "Okay, I've used the process of elimination and it's not here, so it must be there." Uber doesn't work like this anymore, but when I first brought this up to people inside of Slack, there was a moment when the Uber app, when you opened it was just, "Where would you like to go?" And other. And other was everything like change your payment method, set your location, anything you could do in Uber. And that was perfect because almost all the time people just wanted to choose where they wanted to go. Sometimes you wanted to change where your pickup was because you weren't there yet or whatever. And that was just like, what could be simpler than, "I'm going to tell you where I want to go or I'm going to achieve something else."?
I really tried to push people to what is the thing that people, or what is the two things or what is maybe three things that people could want to do here and then put everything behind other. And then if it takes them eight clicks or taps to do something, but every single one is trivially easy, that's great. If you reduce that to two clicks or taps, but every part of it is this fraught decision where I'm opening all of the menus and trying to figure out which thing is the right thing, and the more, comparing three things to each other is this difficult four things, it's kind of geometrically more expensive to compare 15 different options all to the other to see if this is the one that you might want. That just becomes impossibly expensive. So to me, those are all really connected. And if people could get over the idea of reducing friction as the or reducing the number of clicks or taps to do something and instead focus on how can I make this simple? How do I prevent people from having to think in order to use my software? How can I make this trivially easy? One last example, because this was really influential for me. So I was going back and forth in Vancouver in San Francisco at the time when we were talking about all this inside of Slack, and I was behind a teenager in line aboard the plane and it was like, we're on the jet way. It took a long time. And I was watching her use Snapchat and it was insane.
She was tapping at least four times a second, sometimes six or seven times a second. It was like dismissing stories and doing stuff. But there was a fluidity to it because everything was like, do I want to see this again? Do I want to see the next story from this person? Do I want to switch to a different person? Instead, a notification came up, she answered someone's thing, she took a selfie of herself and everything was just like... So she was tapping four times a second for six minutes. I mean, probably there was some breaks in there. And that was the highest and best use of Snapchat for a 15 year old girl in 2016 or whenever that was. And imagine if the goal was to try to make her tap less, how much of an impediment it would've been to the experience that both her and Snapchat wanted to create?

Lenny RachitskyIt's so fun to listen to this and the examples you gave of, it gives us a lot of insight into the way your mind works of just constantly unsatisfied with the way other products work with your product. And I think that's core. Patrick is a good example of Stripe. I feel like that's a recurring theme with very successful product leaders is just constantly unsatisfied and unhappy with how things work.

Stewart ButterfieldYeah.

Lenny RachitskyI love just even the way you summarize this, just a really good reframing of, instead of obsessing with reducing friction and reducing steps, instead think, how do I reduce the amount of thinking the user has to do? I've never heard of it described as, you have to think about the ATP and glucose being used to actually think, and your goal is to reduce that versus let's just reduce friction, reduce clicks.

Stewart ButterfieldYeah. I think in my more cynical examples, I would say to people, " Stop what you're doing for a second, close-"
Stop what you're doing for a second. Close your eyes, take a couple of deep breaths, and then pretend that you're an actual human being. And open their eyes again, and then look at this thing and see, can you figure out what it's supposed to do or say. Or what action you're supposed to take or what the impact will be if you take that action. There's a whole nother related cycle. But before I get into it, I know that I am verbose. I want to wrap up your last example of people being unsatisfied.

So here's the quote that I was trying to find. This is 2014, so like that was the year that Slack actually launched officially in February. And this is now near the end of the year. I was interviewed by MIT Technology Review and asked if we were working to improve Slack. I said, "Oh God, yeah. I try to instill this into the rest of the team, but certainly I feel like what we have right now is just a giant piece of shit. It's just terrible and we should be humiliated that we offer this to the public. Not everyone finds that motivational though."
So I came into the office the next day and people had printed out on like 40 pieces of 8.5 by 11 paper that quote, and pasted it up on the wall. But to me that was like, you should be embarrassed by it. It should be a perpetual desire to improve. You should probably be like, "Oh, this is great," and you could be proud of individual pieces of work. But in the aggregate, if you can't see almost limitless opportunities to improve, then you shouldn't be designing the product, or you shouldn't be in charge of the company, or you shouldn't almost nothing.
Again, you could reduce it down to a tiny feature is anywhere close to perfect. And if A, that's acknowledged freely inside the organization. And B, people think about continually improving as the goal. And that could be like Six Sigma Toyota, Kaizen, that kind of side of thing. Or it could be that story that... I can't remember his name right now. The guy who started Bridgewater tells about Michael Jordan-

Lenny RachitskyRay Dalio.

Stewart ButterfieldYeah, Ray Dalio in his book talks about Michael Jordan learning to ski. Every time he messed up, he wanted the ski instructor to tell him exactly what he was doing wrong. Because to him, every one of those was a gem that he could collect, and he could actually become a good skier. And what he wanted to do was become a good skier. That requires a lot of trust inside the organization.

But if you can get to the point where like, "Hey, we are trying to find improvements. We're trying to be critical because you're trying to make this as great as it can possibly be." And not always, not with every person, but most of the time with most people, you can get them to the point where that really direct criticism is actually motivational. It is like people are grateful to have the feedback, whether that's coming from their peers inside the company or from end users of the product. Because you realize, oh yeah, that is bad and we should fix it.
Unlike NoCo Tools, Lovable isn't about static pages. It builds full apps with real functionality, and it's fast. What used to take weeks, months, or years, you can now do over a weekend. So if you've been sitting on an idea, now is the time to bring it to life. Get started for free at Lovable.dev. That's lovable.dev. This makes me think about, let's call it a rant that you have about how it takes a lot of work to make anything work at all. That just the default state is not working. Can you just share what you share there.

Stewart ButterfieldYeah. I mean, so this is a lot to do with, and maybe this is more recently, it shows up in politics a lot for me. But by the way, if anyone listening to this can help me find this tweet store from somewhere between 2016 and 2020, I don't have a precise idea. And it was this guy's thread about how hard it was to get a stop sign set up. And I believe it was in response to someone claiming that Bitcoin is going to replace US dollars, something about crypto. And his point was like, here's what happened when we tried to get a stop sign put up on a residential street in my neighborhood. And the literal years it took, and the number of agencies that were involved.

Like the engineering department, traffic planners, the HOA, and... I don't remember all of the organizations because, and I did that I could search better and find this again. Because it was truly a masterpiece of how difficult it is to get a stop sign put up in most places. The message that I hear from most politicians, and unfortunately this works really well, is things should be good. But they're not because someone is doing something bad, which is preventing the goodness.
So billionaires are making things unaffordable. Or immigrants are taking your jobs. Or lazy freeloaders are sucking off a government tea, and causing us all have to pay more taxes, or something like that. The reality is almost nothing works. It's actually another call. I said in this case, John has a great encapsulation of this and I'm sure you're familiar with it, like that. It ends with the world as a museum of passion projects. Because for anything to get done at all requires not just the resources and effort required to instantiate that thing in the real world, but all of the politicking and the sociology and the convincing.
And there's a book called Why Nothing Works Recently, which is like, it's not an... I'm sorry to the author, if they... I doubt they're listening, but just it's not like an amazingly written book. I found it a little bit repetitive, but the content was really incredible, just explaining why it's so hard. And how there's this progressive increase in the number of vetoes that are available for any kind of course of action and how difficult it is... And this shows up in permitting for new construction and stuff like that. But also shows up obviously inside of organizations.
And the challenge is that people, A, I think this is evolutionary biological. It's hard for us to understand the world, except by anthropomorphizing it. And so if it didn't rain this year, it's because a God is mad, and probably because we didn't sacrifice enough goats or something last year. It's hard for people to understand just that, wow, weather is incredibly complex and chaotic, and ecosystems and climatology, and all that.
Same thing with the world. Like if I am struggling to pay all of my bills and be able to afford a little bit of luxury in the sense of location or a present for my kids or whatever, it's got to be somebody's fault. There has to be a decision that's made somewhere. And the reality is everything is so complicated. Everything is so multivariate, it's not satisfying. It's a terrible political message.
It's much easier to say that there is like, oh, we understand why things are bad in the way that you're concerned about. And it's turns out that it's some someone's decision, and because of them it's bad. And so if we got rid of them or were able to overcome their decision, overturn it, and institute our own thing, then things would be good for you. And this really to me shows up inside of those organizations as well. I'll pause there.

Lenny RachitskyI know kind of along those lines, you're a big believer in something called Parkinson's Law.

Stewart ButterfieldYeah. So the original of that is, I think it's 1956. It's an article in The Economist by Parkinson. And the Maxim is work expands to fill the time available for its completion. And the way that it shows up, this is a little bit subtle. So like one of the things I found, since I don't have a job is there's much less time pressure. And that maxim, like if you want something done, give it to a busy person. The inverse is also true that like, if you're not that busy, wow, basic things take a really long time.

And so Parkinson actually starts out with his example of writing and posting a letter. And I don't remember who he used with the first example, but someone who's incredibly busy and has all these things they have to respond to. And then another case like a retired robot who has all the time in the world. It takes her a long time to write the letter. It takes her a long time to put it in the envelope, and then you go to the post office and post it.
But the real meat of it is, for me later when he talks about the size of the organization, and he uses a bunch of examples. This is again 1950s, and he's British, so he's looking at the Royal Navy. And specifically he's looking at a chart that shows the relationship between the number of capital ships in the Navy, the number of sailors, and the number of administrators. And very familiar graph for people looking at any part of government. Any part of the relationship between the number of administrators at a university and the number of students and faculty, teaching faculty. Where it's like, okay, the number of ships goes like this and the number of sailors is looking right along with it. And the number of administrators goes like this.
And the reason this ties into the work expands to fill the time available for its completion is people hire, and they train. And here's the sad truth for anyone running a company is there are exceptions. There's certain types of engineers that are an exception to this. But the overwhelming majority of people you hire want to hire more people who report to them. And it's not because they're evil, and it's not because they're stupid. In fact, they're smart because everyone knows that the number of people who report to you correlates with your career trajectory, the amount of money that you're paid. The amount of authority you have inside the organization and on and on and on.
So we would hire 27 Royal product managers in Slack who immediately want to hire someone. It's like, what the hell? What would that person do? And they articulate it this way, but essentially it's like, "Well, that person would do the product management and then I would do strategy."

Lenny RachitskyClassic.

Stewart ButterfieldIt's really, I think the essential thing to understand about this is it's not because people are evil, and it's not because they're stupid. And it's to me, very related to everything is complex. And if maybe this is my butterfly's law, I haven't thought about this way before. But I tweeted this a very, very long time ago like if you... Everything is simple if you have no idea what you're talking about. So the other side of that is like if something seems simple, probably you don't understand it. And there's obvious exceptions to that.

But for anything that involves a large organization or a lot of human beings, if the problem seems simple, you don't get it. So every budget process, no head of engineering know, head of sales, no CFO, no GC, who's ever going to come back and say, "Oh, I've actually think next year we can just hire fewer people. Or we're going to keep it flat or we're going to shrink through attrition because we don't need any more people to do what we're doing." Not because they're evil, not because they're stupid, but it's almost overpowering impulse inside the organization that often leads to disastrous results. And so there's an...
I'll give one example from Slack's history, and I have tried in the past to disguise this example so that no one feels bad about it but I... Unfortunately, the specifics are so important to the example that it's not disguised and so I'll just reiterate that the people involved aren't stupid or evil. And one example that's from the outside. So the example inside of Slack was we introduced threads, which was the ability to reply to a message inside of a channel. And let's say you, Lenny, post a message. I, Stewart reply to it. You will automatically get a notification. And now Sarah later on replies to the same message. Both you and I, as people who have push in that thread will receive a notification that there's been more activity, and so on. So like every single time anyone replies to it.
So when the feature first was released or like when we did the final product review before it was released, the input box was pre-populated with at the person before you in the thread. And I was using the feature and I would put the insertion point there, select all delete, and then start writing my message. And even if I wanted to add someone specifically, I almost never wanted to start my sentence with at that, because it just made it hard to reference what they were saying before. So I said, "Get rid of this because, A, I think most people won't use it. Or if they did want to add someone, they're not going to want to do it at the beginning of the sentence.
And by the way, you're teaching them to use the product wrong. Because it's important that everyone understand that every previous poster in this thread will automatically receive a notification unless they've figured it."
So okay, we release it. Six months goes by and suddenly the at thing comes back. And so I messaged someone around the team and I said, "Hey, there's been a regression. This is super weird. I don't know what happened. But the at thing came back." And they said, "Oh no, this is on purpose. We did a bunch of research." And so I was like, "What?" And I went through this and it was, if I recall correctly, it wasn't even P-95 certainty on this analysis. But it was something like when we do this, threads are 2.17 messages long, versus 2.14 messages long on average for when we don't do it.
And so first of all, why is a longer thread better? Like maybe a shorter thread is better? It can be fewer messages that people have to go back and forth. Also, that's such a tiny difference. Also, again, I don't remember the actual statistical analysis, so I'm not going to claim that it was incorrect. But I'm pretty sure this was outside the bounds of certainty that they can have. But the real thing was, oh my God, so you guys put flags into the product, you A-B tested it. You did the instrumentation. You created tables in the database or whatever we're using to record all of that.
You wrote queries to pull that. You created charts based on that data. You had meetings to discuss it. And just kind unpacking all of the things that would've had to happen for this to come back. And it's like thousands of person hours at a minimum, because any feature change at that scale of organization, it's involving like a dozen people. Engineering, QA, analytics teams, project managers, user research and stuff like that. The problem with that, so I think it was a bad idea, right? But the problem with that was the difference that you could possibly achieve between having this feature and not having this feature is like this much whatever units you want. The cost of doing the analysis was this much. So it's guaranteed to be a loser.
Like there's just, there's no world in which anyone could imagine putting the at previous respondent in the thread at the beginning of the message could possibly make that much of a difference to the quality of Slack, and how much utility it provides for people and all of that. But you know that to put the feature flags in, to ship new versions of the product, to put the instrumentation in. To have it all the API calls to record every action that people take to do all the analytics, to create the dashboard. To put paste a screenshot of that into a Google Slides presentation. To send the invitations to the meeting, to reschedule the meeting because someone couldn't make it. To have everyone sit down and look at the thing. Like guaranteed loser.
And I know that Fareed told you to ask me about this hyper realistic work-like activities. And so here's my grand theory. Hyper realistic work-like activities goes along with this other concept called known valuable work to do. And when I say known, I mean both you know what it is and you know that it's valuable. And the problem with almost every organization at the very beginning, you have an enormous amount of work that you know what to do, and you know that it's going to be valuable. So like starting a business, open a bank account. Because there's almost infinite general value of opening a bank account. You have to do it. It's very simple to do.
And so at the very beginning of any startup, they're like, "I'm creating a user's table, and I'm doing sorting passwords," and you're doing all the things that are kind of absolutely necessary. And everyone knows exactly what they are. And so everyone's going to work in the morning and they're like right on. And I have 10 things to do, and every single one of them is something I know how to do. And it's definitely going to be valuable. Time goes on. And the relationship between the supply of work to do and the demand for doing work just starts to change.
More and more people get hired. Every product manager wants to hire a junior product manager. Every new person, the first person you bring in on the risk and compliance team is like, "Oh my God, there's so many risks and things we have to be compliant with. We better hire more people on my team to do more risk and compliance work." Which probably to some degree is right. But we're going to have more and more of those people and they're going to call meetings with each other.
And now suddenly you have all these people with work to do and you've done all the easy obvious stuff. And now your questions are like, "God, should we do FedRAMP high and make a Slack version? Which is going to require us to have wholly separate physical infrastructure for the hardware that runs the software? And also a whole different operations team, which has only US citizens on it? What is the possible number of dollars that we could make from doing this? And how much complexity is going to be when we want to do updates to the software because we update two totally separate independent systems and rec."
It just gets out of whack, and so people end up... Like if you hire 17 product marketers, you're going to have 17 product marketers worth of demand for work to do. And if you don't have sufficient supply of product marketing work to do, they're just going to do other stuff. Again, very important, not because they're stupid, not because they're evil. But because they're like, I'm a product marketer and I want to be recognized for my work. And my spouse has criticized me because they take, I should have already got promoted in the last cycle, and they really got to demonstrate some wins here and whatever it is.
And so people are like calling meetings with their colleagues to preview the deck that they're going to show in the big meeting to get feedback on whether they should improve some of the slides. And that hyper-realistic work-like activity is superficially identical to work. Like we are sitting in a conference room and there's something being projected up there, and we're all talking about it. And that's exactly what work is. Hopefully not all of work for everyone inside of your company. But that's exactly what we do when we're working.
But this is actually a fake bit of work, and it's so subtle that I'll do it. Our board members will do it. Every executive will do it. And the further you are from having all of the context and all of the information and the decision-making authority and stuff like that, the easier it is to get trapped in this stuff. And people will just perform enormous amounts of hyper-realistic work-like activities, and have no idea that that's what they're doing. And the result of that, I guess, is that if you are a leader, if you're manager, director, an executive, you're the CEO, it's on you to ensure that there is sufficient supply of known valuable work to do. And there almost always is, but it's creating the clarity around that. Creating the alignment. Making sure everyone understands it, but that's what they're supposed to be doing, and then obviously doing it.

Lenny RachitskyAmazing. I could listen to Stewart's rants all day. Hyper- realistic work-life activities. We need to coin this-

Stewart ButterfieldUnfortunately, it doesn't make a good acronym. It's pretty ugly.

Lenny RachitskyOkay.

Stewart Butterfield.

Lenny RachitskyOkay. it a try. And just to close the loop on that, the solution is the leader recognizing this is happening and stopping it. Telling people why are we spending time on this thing that is not going to get us anywhere?

Stewart ButterfieldYeah. And what you just said probably isn't the best way because that sounds like you're chiding them, and they're dumb. When it's actually your responsibility to make sure that there's sufficient clarity around what the priorities are, and explicitly saying no to things upfront and stuff like that. Rather than merging and say like, "Hey, you guys are a bunch of idiots wasting your time on this thing that doesn't matter." Whose fault is it? It's the manager's fault. It's the VP of whatever's fault. It's the CX, whatever, it's the C... Ultimately, it's the leader of the organization that has the responsibility to make sure that there is sufficient known-valuable work to do. And that's actually harder than it might appear.

Lenny RachitskyOkay. Before we run out of time, I want to touch on two other topics. One is, when people think of Stewart Butterfield, I think a lot of people think of, We Don't Sell Saddles Here. Your legendary Medium post that is just, I don't know, it's become a historic piece of literature in the annals of product building and in startups. I haven't heard people ask you much about this recently. So let me just ask a couple of questions. What was the reason you put that out? What was the backstory on writing that memo? Why was it necessary?

Stewart ButterfieldWell, it really was an internal memo.

Lenny Rachitsky... Memo. Why was it necessary?

Stewart ButterfieldWell, it really was an internal memo and there's a bit of a digression. One of the crappy things about Slack is if all your corporate communication is on email, depending on exactly how it works and what system you use, you probably walk away with an archive of everything you said at Company X. If it's Slack, once you're turned off, you lose access to all that history. And so it's kind of like, "Oh, man. If I had only exported all of my messages before I left, I would have all this stuff," but that was absolutely verbatim. I did not change a word of what I said inside the company. Well, I think we were still eight people. Maybe at most 10, but I think it was eight people.

Lenny RachitskyIt was before Slack launched even.

Stewart ButterfieldYeah, it was before Slack launched. It was when we're doing private beta. And the point of it was to start to instill those ideas as early as possible and really create this alignment inside of that small team so that it could persist to survive as we grew and scaled. Yeah, that was the idea.

Lenny RachitskyAnd the gist, just for people that aren't super familiar with it, but we'll link to it, is just it's not enough just to build a great product. You just as much have to put effort into communicating what this does for them, the problem this is solving for them, the outcome this is going to achieve for them. Is that a good way to think about it?

Stewart ButterfieldYeah. And again, comparing it to beer or cars, beer goes back to pre-civilization. Cars were obviously , but at some point you had to convince people why they would want a car instead of a horse. For your new AI-based recruiting tool or your calendar app or whatever, there's some reason why you think that people should use yours instead of the thing that they're using now, which might be a wholesale one-for- one replacement, or more often is a change in the way that you're working that has a bunch of other adjacencies and you want to expand into these other categories. You're not just responsible for creating the product, but also, to a certain degree, creating the market.

There's this book, Positioning, which is an absolute classic. It's very short. I would recommend everyone read it, where the point of it is, from my perspective, it's almost impossible to create a new idea in someone's head. It's much easier to take a couple of existing ideas and put them together. So it's much easier to say it's like Jaws meets Star Wars, or it's Uber for Pets or something like that, than to come up with an actual new idea. But you have to do that because if your thing is different in any significant way from the alternatives, you're not just creating the product. You're creating the market. They're really kind of one and the same.

Lenny RachitskyThe reason I wanted to touch on it is I think still people continue to not listen to this advice and continue to over-invest in more features, more products, things like that. Just the specific example of, "We don't sell saddles here," just to quickly communicate this to folks, and correct me if I'm missing anything, is just instead of, "Hey, look at this amazing saddle we've bought," which you want to communicate as, "Here, go horseback riding. Look at this incredible experience you can have." And then they decide, "Oh, shit. I need to go buy a saddle to do that."

Stewart ButterfieldYeah. And 100%, that aspect of it is not original because I think that's something that marketers have done for a long time, certainly in the marcom and advertising. If you want to sell Harley-Davidson's, there are people who are going to geek out on the engines and stuff like that and the quality of the leather and stuff like that. But when you're selling the motorcycle, you're selling the open road and freedom and the wind in your hair. And if you're Lululemon, you are obviously selling yoga pants, but you're also selling health and aspiration and being the best version of yourself and a bunch of other stuff. Oh my God, I forgot the classic version of it.

Lenny RachitskyThere's the ship ...

Stewart ButterfieldYou're selling the screwdriver.

Lenny RachitskyOh, yeah. The nail.

Stewart ButterfieldYeah, the nail. Anyway.

Lenny RachitskyYeah, we missed that one. Well, there's the one I think about is instead of trying to convince men to build a ship, instill a yearning for the sea.

Stewart ButterfieldYes. Exactly. That's something that goes back in history.

Lenny RachitskyOkay. Let me ask you about pivoting. You are potentially the king of pivots. You started two companies both famously pivoted, both from video games, which is why I asked you about that at the beginning, into very successful companies. I imagine many people come to you for advice on pivoting. Let me just ask when folks come to you asking, "Should I stick with my idea? Should I pivot?" what sort of advice do you find most helps them?

Stewart ButterfieldYeah, I mean, I think it's partly an intuition because obviously the decision is about, "Have you exhausted the possibilities?" and in the case where we were working on Glitch, this game where we used IRC for internal communication and we added a bunch of IRC which became the Proto Slack. I think Slack had an enormous advantage in the fact that we are working on this for several years without actually explicitly working on it and only doing the minimum number of features that were absolutely guaranteed to be successful in the sense that it was so irritating that we couldn't stand it anymore or such an obvious improvement that we couldn't help but take advantage of it. We still had $ 9 million left and everyone still liked the game and we were all happy working on it, but I think by that point I had exhausted every non-verdiculous long shot idea to make it commercially successful, and so I decided to abandon it.

But the default advice for anyone in anything is persevere. It's like a kitten hanging off the branch and a poster says, "Hang in there." There's so many stories of, "So-and-so started out going door-to-door and was rejected by everyone and then suddenly there was Nike," or something like that and just, "If you stick with it long enough, you'll eventually be successful." I think you have to really be coldly rational. Some of this shows up in the book Thinking in Bets. Some of it's in Annie Duke's second book, the title of which I'm forgetting right now, but someone will know it.

Lenny RachitskyYeah, Thinking in Bets, and then what was the second? I forget.

Stewart ButterfieldShe actually uses Glitch and Slack as an example of a smart fold basically. My expected value here has diminished to the point where this alternative looks more attractive. And the reason I say you have to be coldly rational about it is because it's fucking humiliating. I convinced so many and you have to convince so many people to get a company off the ground. You have to go to investors. You have to go to early employees and say, "You should leave your other job and come work for this because here's the incredible feature we're imagining." You have to go to the press and you have to make all these promises and you have users and you've committed things to the users and you've convinced them to give up their time for this thing. And so I think for a lot of people, it feels better to just keep doing it until it dies of suffocation due to lack of capital or something like that. Then just to admit, "Okay, I was wrong. This didn't work," and it's humiliating. It's painful. It's wrenching. It has a bad impact.

When we shut down Glitch, there was a lot of people who loved it and would spend all of their free time and couldn't wait to get home from work to go play it more. And that was their community and the community just disappeared, all these people and all these identities that have been created. And obviously, people lost their jobs and people who had moved their families to a different city in order to take this job now weren't going to have a job anymore. So pivots aren't something I take lightly. I think it's very different to be like, "There's three of us and we started making this app and then we pivoted to a different app." That doesn't even really count. If you're six months into something, you're still messing around. You're trying to figure out what it is that you're building. It's not really a pivot. Obviously in this case, it worked out great and there's survivorship bias and that doesn't mean that everyone should pivot all the time. But I think creating the distance so that you can make an intellectual, rational decision about it rather than an emotional decision is essential.

Lenny RachitskyI love, also, your piece of advice of just exhaust. Once you've exhausted all the ideas, that's a really good time to see what else is out there.

Stewart ButterfieldYeah, just all the good ideas.

Lenny RachitskyAll the good ideas,

Stewart ButterfieldAll the realistic. Yeah.

Lenny RachitskyYeah. The point you made about just kind of persevering, I just had Melanie Perkins, CEO of Canva, in the podcast. 100 investors rejected her before somebody finally decided to invest and she just kept pushing.

Stewart ButterfieldYeah. I think that's a slightly different example, right? She eventually believed in the concept of the product and in the vision. It was just trying to figure out the right articulation to get investors who ended up being obviously very, very happy.

Lenny RachitskyExtremely happy. Oh, geez. Okay. Maybe a final topic depending on how time goes. I want to talk about generosity. I talked to a bunch of people, as I said, that have worked with you and the number one theme that came up again and again and again when I asked them about you and what has stuck most with them is just generosity. So I'm going to read a few examples that I heard from folks that are examples of your generosity over the years.

So one person shared that he needed a little money before Christmas and he said, "Stewart literally walked me out of the building, went to the cash machine, handed me $500, told me to go home to my family." Other folks shared that, when you talked about Glitch just recently when you had to lay people off, you cried real tears when you were laying people off and then you spent an incredible amount of time helping them find new jobs and extending their severance pay and just taking it extremely, extremely seriously, much more than I think most people feel like CEOs do. Someone else shared that you paid 100% of employees health insurance to give them just fewer things to think about.
When you went public, you basically created the best possible situation for employees, no lockup, direct listing. Also, with the structure of the Slack deal, people said that acquisition was very employee friendly. That's employees. There's also just the way you thought about customers. A few examples: You gave free credits to businesses who were struggling to pay the bills during COVID. You released this fair billing, which I think was very innovative at the time, where you stopped charging people for seats they weren't using, even though they signed a deal to charge for those seats. A lot of times, you slipped release schedules because you just wanted to make features better and better for people. And I'll end with this quote: "Stewart is a leader who takes the responsibility he feels for his employees personally, and to which he extends the most generous circumstances he could muster. That feels worth celebrating."
So first of all, I just want to celebrate you. I think it's really rare and inspiring to meet a leader like that. Clearly, you've had a lot of impact on a lot of people. I don't know exactly the question I want to ask, but I guess in what part is this intentional, just like, "This is how we win. I'm going to be very generous and help people because I know this will help long-term"? How much of this is just a and it's just the way you are as a person?

Stewart ButterfieldI think a lot of it is just the way I am as a person and I had wonderful parents who raised me right, but I think there is a little bit of a lesson there and I'm just going to assume people's familiarity with the prisoner's dilemma. The acts of generosity to me are, "Oh, I am demonstrating that I am going to cooperate as we iterate in this game." And if you do that, then people will also cooperate and you both benefit. Whereas if you never really know if the other person is going to defect at the first opportunity, then your best bet is to defect. And so there's a game theoretic aspect, usually in games that are much, much, much more complicated than the prisoner's dilemma.

I think one thing I didn't touch on before, but to me was important enough, is that at more than one company all hands, I made everyone in the company repeat this as a chant. It was, "In the long run, the measure of our success will be the amount of value that we create for customers." And I wanted to be super clear and explicit about that because it should be if anything you're doing feels like a little bit shady, a little bit cheating, a little bit maximizing at the wrong moment or taking advantage of a customer or anything like that, definitely shouldn't do it. Because to me, I mean I think it's literally true, but it's also an ethical way to run a business. And it's not just that the ethics are good. It's like there's advantages for you. You're able to attract a better class of employees. If all your employees are ethical, then it's going to be a better place for everyone to work and you're going to be happier and you're going to have fewer internal problems and all that stuff.
But I think it really is true that especially in the long run, you can't destroy value for your customers and expect to be successful. You have to actually make their lives better. And you could put effort into pointing it out to them and demonstrating that you have created this value and stuff like that, but there's no substitute for actually having created it. And I think that is incredibly important and that implies a real generosity, whether that's in negotiating terms with an enterprise deal or that's policy decisions. One time that it blew up in our face was our SLA was like, "For any downtime, you get 100 times your money back." Because from my perspective, it's like if we're down for two minutes, it's like pennies. It doesn't really make any difference. If we're down for 10 hours or something like that, then we have bigger problems than paying back people.
Fast-forward, we now have hundreds of millions of dollars in revenue and we've gone public. And shortly after we go public, we have one of the biggest outages we ever had. I don't remember how long it was, but it was many hours. But by the time we got that scale, 100 times the money back for the third of a day that we were down was $8 million or something like that. It didn't cost us any money because we just gave it to people in the form of credits, but it meant that a bunch of revenue that we had already anticipated for the next quarter wasn't going to show up because people's credits were going to offset what they would've otherwise paid us. And so we definitely changed the terms of service after that because being a public company is a little bit different. But in every other respect, I think they were all really important decisions that were helpful in us becoming successful.

Lenny RachitskyWas that policy ... It was automatic? You didn't even have to claim it. It was just automatically you get this credit?

Stewart ButterfieldAnd the default is you don't have to pay if you let us know. This was, "We will automatically, proactively, preemptively without any input from you ..."

Lenny RachitskyToo generous.

Stewart Butterfield"Apply this credit to your account, and just send you a message that it happened. And by the way, we will do it on the aggregate for downtime, even if the issue didn't affect you as a customer."

Lenny RachitskyWow. Too generous. You found the edge of where you want to be.

Stewart ButterfieldYeah.

Lenny RachitskyWhat was that mantra again that you had the company chant? I think this is a really nice way to end it.

Stewart ButterfieldIt was, "In the long run, the measure of our success will be the amount of value we create for customers."

Lenny RachitskyIncredible. I'm just trying to picture the entire team at Slack reciting this mantra.

Stewart ButterfieldIt was hundreds of people. It felt very like, Kim Jong-Un or Stalin or something like that.

Lenny RachitskyWell, on that note, most people don't know this about you, but your actual name when you were born was not Stewart. It was Dharma.

Stewart ButterfieldYeah.

Lenny RachitskyAnd this all makes sense as you learn that.

Stewart ButterfieldYeah. My name is Dharma Jeremy Butterfield, so my parents named me. And when I was 12, I changed it because I just really wanted to be normal and for some reason I thought Stewart was a normal name. And by the way, you'll notice this now that I said it. Any character except for Stuart Little the mouse, anytime you see a character in a movie, a novel, TV show or whatever, there's only the loser Stewart and the asshole Stewart. It's obviously, in the collective consciousness, a terrible name and I shouldn't have chosen it and I regret it. But by the time I realized that, Dharma and Greg had already come out and it would've seemed like I was bandwagon jumping. And people thought it was a girl's name, even though in India it's obviously only a boy's name.

I'm going to add just one last little tidbit because I forgot about this earlier on and I think it helps tie things together, and it's called the owner's delusion. And this is based on something I posted on Twitter. The person who came up with the name later deleted their account and so I have no idea who it was and who to credit for this. But what I had posted was, and this was a long time ago when restaurant websites have gotten better and it doesn't really matter because Google Local was taking over everything, but this is, let's say, 10 years ago.
There's five things you could possibly want when you go to a restaurant's website and it's their street address, their phone number, the menu, the hours of operation ... Oh my God, I'm forgetting the fifth thing. Oh, and making a reservation, how to make a reservation. And again, this problem has to some extent taken care of it's itself or at least improved, but what you would get was this super slow loading photo, the Ken Burns effect as it ...

Lenny RachitskyThe flashed.

Stewart ButterfieldAnd then fading in and then some music starts playing. And then if they show you the phone number, it's not clickable.

Lenny RachitskyImage.

Stewart ButterfieldIt's not even text that you can copy because yes, it's an image. And they don't have the hours. They don't put the address or whatever and it's just like, "What?" For sure, whoever made this website for the restaurant owner and the restaurant owner themselves have definitely been in the position where they went to somebody else's restaurant website because they wanted to get the address or the opening hours or the phone number or whatever. So why does it end up like this and what should we call this?

And whoever replied to the tweet, she said, "We should call it the owner's delusion," and I was like, "Oh my God. That's perfect." And I think that is incredibly powerful and what ends up with the result, like Apple naming whatever that feature is called Sleep, which it's too hard to understand what that can possibly mean. And that's why people anticipate, despite the fact that when they get to your website for the first time, their intent is absolutely the minimum number of micro points above the threshold required from them to actually take that action.
You're like, "All right. Welcome to my website," and there's a bunch of BS and there's a bunch of stuff that doesn't make any sense and the buttons are inscrutable. And it's unclear what to do next because I think that my thing is so important and I don't recognize that you are at work and you were late this morning and you have to go to the bathroom and you're just a regular human being who has stuff going on, that you're concerned that your kid is a fuck-up and they're getting in trouble at school and stuff like that. They're not subjects who paid money to go to your play and are sitting in the audience and waiting for that curtain to go out. They're people who are going to bounce in a fraction of a second. And so everyone should always be conscious of the owner's solution.

Lenny RachitskyI love that. What's the solution? Is it have other people look at it and give you feedback?

Stewart ButterfieldYeah, and recognize it. And unfortunately, it's one of those things like Murphy's Law.

Lenny RachitskyYeah.

Stewart ButterfieldEven you can go wrong even when you take into account Murphy's Law.

Lenny RachitskyThat's right.

Stewart ButterfieldBut if you don't name it and recognize it and discuss it and train yourself to think that way, take a breath, pretend you're a regular person, and then look at this again and see if it makes sense, then you're screwed.

Lenny RachitskyI love that. I love that you threw this in here. I have a billion other questions I'm going to ask you in part two when we do this someday. Stewart, thank you so much for doing this. Thank you so much for being here.

Stewart ButterfieldYeah. Thank you for having me, Lenny. I really enjoyed it.

Lenny RachitskySame here. Bye, everyone. Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennyspodcast.com. See you in the next episode.

Stewart Butterfield这是 2014 年，也就是 Slack 真正发布的那一年。我当时接受 MIT Technology Review 采访，对方问我们是不是还在努力改进 Slack。我说，我感觉我们现在这东西就是一大坨垃圾，糟透了。我们居然把这种东西拿给公众用，应该感到羞耻。

在我看来，这就是“你应该为此感到难堪”。如果你看不到几乎无限的改进空间，那你就不该去设计产品。

Lenny RachitskySlack 之所以出名，是因为它是最早一批“消费化”的 B2B SaaS 产品之一。

Stewart Butterfield在不止一次全员会上，我都让整个公司一起喊这句话：从长远看，我们成功的衡量标准，是我们给客户创造了多少价值。你当然可以花很多力气去证明自己创造了价值，但真正的价值，必须是你真的创造出来了，别无替代。

Lenny Rachitsky我还听说过，你经常强调的一点是：产品体验里有摩擦，很多时候其实不是坏事？

Stewart Butterfield后来大家默认一件事就是，产品应该一直去消除摩擦。但真正的问题往往是“理解”，不是摩擦。如果你的软件突然停下来，让我做一个决定，而我又根本不明白发生了什么，那你其实是在让用户觉得自己很蠢。要是人们能跳出“减少摩擦”这种把点击数、操作步数越压越低的思路，转而去想：我怎么把这件事做得足够简单？我怎么避免用户为了使用我的软件还得先动脑子？

Lenny Rachitsky你创办过两家公司，而且都很有名地经历了转向。很多人来找你，应该也是想听你聊聊 pivot 这件事。

Stewart Butterfield这个决定的核心是：你是不是已经把所有可能性都试尽了？你必须把自己拉开一点距离，才能做出理性、冷静的判断，而不是情绪化的决定。我之所以说这件事必须冷静理性，是因为它真的他妈很羞耻。

Lenny Rachitsky今天的嘉宾是 Stewart Butterfield，一位很少上播客的创始人和产品传奇。Stewart 创办了 Flickr，后来又创办了 Slack，并在当时科技史上最大级别的收购之一里把 Slack 卖给了 Salesforce。他脑子里装着太多产品和领导力的智慧，我感觉我们这次只是碰到冰山一角。我们聊了 utility curves，他称之为“老板的幻觉”的东西，他在公司里看到的一类很滑稽的模式，叫 hyperrealistic work-like activities，他对产品、工艺、品味和 Parkinson 定律的理解，为什么你必须 obsess 到“不让用户去思考”，以及那句传奇的 “we don't sell saddles here” 备忘录背后的故事，等等。非常感谢 Noah Weiss、Chris Cordell、Ali Rael 和 Johnny Rogers 帮忙提了这次对话的话题和问题。这期真的很特别，我也真心希望以后还能再请 Stewart 来，聊得更深一些。

给你出个谜题：OpenAI、Cursor、Perplexity、Vercel、Plaid 以及数百家别的赢家公司，有什么共同点？答案是，它们都在用今天的赞助商 WorkOS。要是你在做面向企业的软件，大概率都体会过把单点登录、SCIM、RBAC、审计日志以及大客户要求的各种能力接进去有多痛。WorkOS 把这些会卡单的功能变成了可直接接入的 API，而且是专门为 B2B SaaS 打造的现代开发平台。
不管你是刚起步、想拿下第一个企业客户的种子轮公司，还是已经成长为独角兽、准备全球扩张，WorkOS 都是最快让你具备企业级能力、打开增长空间的路径。它本质上就是企业功能版的 Stripe。去 WorkOS.com 就能开始使用，或者直接找他们 Slack 里的支持团队，里面是真工程师，回答问题特别快。WorkOS 让你能像最好的团队一样开发，API 顺手、文档完整，开发体验也很流畅。今天就去 workos.com，让你的应用具备企业级能力。
本期节目由 Metronome 赞助。你刚发布了一个崭新的 AI 产品，定价页看起来很漂亮，但背后其实全是临时拼出来的胶水代码、乱七八糟的表格，以及为了算账到处跑的临时查询。客户拿到的账单看不懂，工程师在追 billing bug，财务也没法顺利结账。用了 Metronome，这一切都可以交给真正靠谱的实时计费基础设施。稳定、灵活，而且会随着业务一起成长。Metronome 能把原始使用事件变成准确账单，让客户看得懂，也让所有团队实时保持同步。无论你是在做按用量计费、管理企业合同，还是推出新的 AI 服务，Metronome 都帮你把最重的活干掉，让你把精力放回产品上，而不是计费上。这也是为什么 OpenAI、Anthropic 这些全球增长最快的公司都把账单跑在 Metronome 上。去 metronome.com 了解更多。
Stewart，非常感谢你来，欢迎做客播客。

Stewart Butterfield谢谢邀请，我很兴奋。

Lenny Rachitsky我比你还兴奋。能请到你我真的很荣幸。我以前没跟你说过，但从我几年前开始做这个播客起，你就一直是我最想请到的嘉宾名单里排得非常靠前的一位。所以现在终于成了，我特别高兴。我有太多问题想问你。我的第一个问题很简单，你这些年到底在忙什么？自从你离开 Slack 之后，我们好像就很少听到 Stewart 的消息了。我很好奇你是在忙什么，还是主要在休息。

Stewart Butterfield我基本上就是在休息。我两年半前离开了 Salesforce，我还有一个两岁半的孩子，她其实是在我离职后三天出生的，所以我花了很多时间陪家人。能在孩子还小的时候陪着他们长大，这是非常难得的幸运。暂时也没有什么新公司要宣布之类的。确实会收到很多邮件和短信。基本上每三到六周就会有一轮，因为 Slack 的 CTO Cal Henderson 也跟我一起做过 Flickr，我们现在已经合作 23 年了，一直在聊如果有下一步，我们到底想做什么。

但说实话，真正的大问题是，我觉得这些东西正在毁掉世界，而我们擅长的事情是做软件。所以如果能做出一种软件，帮助人们少看手机一点，那大概会是个大赢家，只是我们还没想到什么特别好的点子。我也做了很多慈善相关的事，暂时还没什么可宣布的，但手头确实有一些挺酷的项目；另外也做了很多个人创作类的艺术项目，还在支持一些其他艺术家，差不多就是这些。

Lenny Rachitsky为了准备这次对话，我找了很多年跟你共事过的人，想弄清楚你到底教会了他们什么：关于怎么做产品、怎么带团队、怎么建公司，哪些东西最让他们受用，哪些最帮助他们做出很棒的产品。第一个被反复提到的概念叫 utility curves。很多跟你合作过的人都提到了它。你能聊聊什么是 utility curve，以及你是怎么用它来做更好的产品的吗？

Stewart Butterfield这个其实很好理解，因为它就是很常见的 S 曲线。横轴可以理解成成本或者投入，纵轴是价值或者便利性，具体看你在讨论什么。它的意思是：一开始投入一点 effort，不会马上带来很大的价值。然后会出现某个神奇的门槛，过了那个点之后，价值会猛地往上冲；但再继续投入，收益就没那么明显了。我能想到的最基础例子是做一把锤子。横轴现在可以理解成质量。如果锤柄稍微一受力就断，那它完全没用；你把它做得稍微强一点，它还是很没用，还是垃圾、垃圾、垃圾、垃圾、垃圾。然后某一刻，行了，够了，已经很好了，再往上加也无所谓了。

如果你在做一个 App，好，我们先给这个 app 做一个用户表，再建一个数据库，结果到这一步你还没有创造出任何价值。我之所以觉得这件事特别重要，是因为我们讨论一个功能时，通常会把功能想成一个二元判断：要么有这个功能，要么没有。但问题其实是，我们是不是还没在这里投入足够多，还是说我们已经把能拿到的价值、便利性、质量等等都拿满了？如果已经到了边际收益递减的地方，那再加也没什么意义。
我觉得很多时候，人们加了一个功能，但这个功能还不够好，所以没人用、也没人觉得有价值；可与此同时，App 又被加进了一些复杂度，然后用户要么放弃，要么把它撤掉，要么在测试里试了一下，结果没拿到想要的结果，于是他们就决定这玩意儿不值得做。我们会非常认真地去研究，到底我们现在是在曲线的第一段平缓区，第二段平缓区，还是刚刚开始爬坡。我觉得把这个价值讲清楚，放到某个具体 App、某个具体功能上时会更容易理解，但它最终帮助人们判断一件事到底值不值得做。

Lenny Rachitsky我把我听到的总结一下：如果你把这条曲线画出来，最底下那段就是“我甚至都不知道这是什么”；往上走就是“好吧，我大概懂了”；到了顶上就是“好，我理解了，而且现在我离不开它”。听起来，这其实是在用一种完全不同的方式思考让用户抵达 aha 时刻。比如说，saved items 这种功能，用户一旦懂了，就会觉得自己必须一直用它。这个框架既适用于某个具体功能，也适用于 Slack 本身。你得先让人弄懂 Slack 能帮他做什么，然后他才会觉得离不开它。换句话说，这就是你拿来判断该把产品资源投到哪里的一个 lens，因为如果你上不去那条曲线，走不到“我懂了、而且我离不开它”，其他事都不重要。这个理解对吗？

Stewart Butterfield对，而且我觉得还可以再叠加一个概念，比如 Bezos 用过的那个词，叫 divine discontent。那条线其实是在移动的，因为一旦人们熟悉了一款软件，或者熟悉了某个功能的实现方式，标准就会跟着抬高，所以这里面一直存在竞争。而且这条轴也一样，utility 只是最通用的说法，它也可以是质量、便利性、速度，或者别的很多东西。你把搜索做得更好，登录体验做得更顺，找回密码做得更顺，结账流程做得更顺，别人也都在做。于是就会有持续投入。等你不再是在想一个新功能，而是在看整个产品怎么运作时，你会发现大多数东西其实只实现一次，然后如果运气好，才会定期被改进。大多数东西改进得都很少，有些甚至根本没改过。

我想拿一个最极端的例子来讲，因为我其实也不知道这个问题存在多久了。不过我尽量不太去批评别人的软件，因为我很清楚里面的取舍、优先级排序、事情有多难，等等等等。好，很多人手机里都有 Gmail Calendar。我经常出差。我大多在东部时区，有时在山地时区，有时在太平洋时区，有时在英国时间，有时在日本、欧洲中部时间。我自己可能真正会选的时区也就十来个，最多十二个。可你在 Google Calendar 的 iOS App 里给某个事件设置时区时，它会把全世界所有时区按字母顺序全部列出来。我是说，也许还有更糟的排序方式，但这种排序毫无价值。
就算你开始搜索，它还是按国家字母顺序来显示。比如我人在加州，想给下周回纽约时的一个会面设时间，我输入 E-A-S-T，结果出来一堆乱七八糟的东西。先是 Eastern，然后第一个是 Eastern Australia, New South Wales，接着是 Eastern Australia, Queensland，再接着是 Eastern Australia, Daylight Savings 和 Eastern Australia standard time。然后你就会想，“操，我怎么记得住哪个是夏令时，哪个是标准时间？”我可以一直这么说下去。这是一个至少被几亿人使用的 App，估计每个 Google 员工都在用，居然能烂成这样，真是离谱。明明有那么多聪明的做法可以用。你知道我的，我在西海岸，第一选项应该先给东海岸，反过来也一样。但绝不该是所有时区被一视同仁地摆在那里。我不需要那几百个时区。我是在加拿大长大的。纽芬兰自己就有一个时区，而且还差半小时。纽芬兰的人口大概五十万，历史上去纽芬兰旅游的人也没那么多，可能一辈子也就一百万。也就是说，算起来大概一百五十万，放到全球八十亿人口里根本没多少。还有中国时间，它在这里又是另一种情况，因为差不多占了全球 25% 的人口。
总之，这个例子讲得比我原本预想的长了一点，但这件事真的很疯狂，因为没有人会因为 Gmail 或 G Suite 的时区选择器做得好，就从 Outlook Exchange 换过去。某种意义上说，这事也许没那么重要，但另一方面，取悦客户是有真实价值的，用户会因此形成情感连接，或者不会。某些情况下，这种连接会非常正向，比如他们会主动推荐它。等他们换公司、或者自己创业时，也会因为这种情感连接而选择继续用这个产品，或者替它说话。反过来也一样。
他们也会说，“我讨厌这玩意儿，它烦死我了，我真觉得我们该停掉它。”或者转而去支持别的方案。我觉得人们对这些事的重视，或者说回头再看这些事，还是太少了。然后还有一类 App 里特别关键的部分，比如注册、创建账号、忘记密码这类功能，对大多数组织来说，几乎很少得到足够的关照、迭代和改进，尽管整体质量标准早就在持续提高，而且一直在提高。

Lenny Rachitsky我们再往“愉悦感”和“工艺感”这个方向深入一点。Slack 之所以出名，就是因为它是最早一批把 B2B SaaS 做得很“消费级”的产品之一。Slack 很强调愉悦感、体验、工艺和整体感受。而你作为产品领导者，我会说你一直以很重视品味、很重视工艺而著称，这其实很少见，而且我觉得现在也还是很少见。所以这里我想聊几个点。第一个是品味。我记得你在一场演讲里专门讲过品味，而你对“品味是什么”、“产品品味长什么样”有一套非常独特的看法。你能分享一下吗？

Stewart Butterfield这里面有很多东西，又回到了 utility curve 上。很多人会痴迷于某一个小点，然后不断往里塞更多、更细的改进，直到已经过了明显的收益点。不过关于品味，我先说两件事。第一，品味是可以学习、可以培养的吗？我觉得可以，因为这个词本来就来自于吃东西、把东西放进嘴里。那人能不能通过训练成为更好的厨师？当然可以，绝对可以。毫无疑问，有些人天生就更有优势，生下来就更容易做出别人很难做出的判断之类的东西。但你确实可以练，你也确实可以变得更好。第二，我会说你可以通过拥抱品味，给自己、给产品、给公司制造出真正的优势，因为大多数人其实没有好品味，也不会在这上面投入。你大概也熟悉 Bezos 那句老话：你的利润空间，就是我的机会。意思也很明显。

我在 Slack 一遍又一遍地讲这个故事，后来它甚至成了新员工入职欢迎内容的一部分。我当时在温哥华办公室，和 Brandon Velestuk 一起出去散步。他那会儿是产品开发的创意总监，应该是这个头衔。我们在温哥华的 Yaletown 区，那边人行道特别窄，因为以前是仓储区，现在变成了高档餐厅、美甲店、精品店之类的地方。然后像温哥华常见的那样，开始下雨了。我们没带伞，正往办公室走。很多人都打着伞，而我们走在狭窄的人行道上，迎面又有人打着伞走过来。我们注意到，很少有人会把伞往旁边挪一下。偏偏对面那个人的伞尖，正好就在迎面行走者的眼睛高度。我们不是被挤出人行道，就是得低头躲过去，诸如此类。
这最后变成了一个游戏，我们会猜这个人会不会把伞稍微偏一下，好让我们过去。大概只有三分之一的人会这么做。我们当时也讨论过，为什么有人不会这么做。我能想到三种原因。第一种是，他们人生中能行使权力的场景太少了，而这就是其中一个。他们就是想出去支配别人、制造痛苦。我们不该把能归因于无知的东西归因为恶意，所以这大概只适用于极少数、极少数人。
但另外两种解释也没好到哪去。第一种是，他们看得到发生了什么，看得到自己在把别人挤出人行道、戳到别人眼睛，之类的，但他们只是觉得：“操，这真糟，我也不知道能做点什么。”最后一种原因就是，他们根本没注意到。他们完全没意识到自己对别人的影响，整个人都活在自己脑子里。我实在想不出别的解释了。
所以我们会说，倾斜你的伞，不只是一个小动作，也不只是“你的利润空间就是我的机会”的另一种说法。真正的意思是：如果你没能足够体贴、没能真正替别人着想，没能对别人的体验抱有共情，那这就是你可以创造出来的一个关键优势。我觉得 Slack 之所以在当时成功，有很多原因，我们也确实赶上了很多很好的顺风，但如果没有这些小小的便利，它不可能长成后来的样子。因为我们很多增长都来自这样的场景：A 初创公司在用 Slack，然后有人从 A 离职去了 B，而 B 还没用 Slack。那个人就会说：“天啊，你们一定要试试，这东西真的太好了。”产品传播就是这么发生的，是真正有人在主动推荐。

Lenny Rachitsky这个比喻太棒了。我特别喜欢，它把某一瞬间直接变成了 Slack 的产品工艺价值观。

Stewart Butterfield“Tilt your umbrella” 这句话当时在公司的周边产品上特别常见，大家会拿它做成 T 恤、贴纸之类的东西。

Lenny Rachitsky我想问一个例子。我知道这种例子一定很多，但在做 Slack 的时候，尤其是早期，有没有哪一件事，是你们刻意在工艺、体验和愉悦感上多投入了一点，而不是一味追求速度？事后回看，你会觉得那真是个好决定，而且对成功至关重要？

Stewart Butterfield我给你讲几个小例子。这个想法不是我最早想到的，我得想想是谁提的，也许是 Andrea Torres，也许是 Ben Brown，类似这样的人。他说的是：如果邮箱地址本身就是让用户创建账号的凭证，那我们为什么还要同时要邮箱地址和密码？为什么不只要邮箱地址，然后给他发一个链接？

所以当 Slack 的手机 App 第一个版本出来的时候，我们就想，人在手机上输入密码，如果你对密码卫生有哪怕一点点要求，这体验都糟透了。大写 H、小写 q、6、脱字符、句号，谁受得了。所以干脆只让用户输入邮箱地址，我们把链接发过去。那个链接会自动打开 App 并完成认证。就这么一个小例子。

Lenny Rachitsky哇，所以是你们发明了 magic link 这种体验？

Stewart Butterfield这个想法不是我们发明的。先说清楚一点，我以前在别的地方见过这个点子，可能是某篇博客文章之类的。但据我所知，真正把它做大、做成标准的是我们。还有一个我们在最早期特别纠结的问题，是很多人对消息 App 的期待，都是每收到一条消息就要弹通知，这个习惯从 AOL Instant Messenger 一直延续到 SMS、WhatsApp。可在 Slack 里，这就不太合理，因为你是很多频道的成员，消息不一定是发给你的，所以我们才有 @ 这种提到人的机制。这个也不是我们发明的，是 Twitter。

但我们很快意识到，用户注册 Slack 的时候，往往只是某个大组织里某个团队里的一个工程师，然后他们会把旁边的人拉进来，说：“来试试这个。”
然后他们发一条消息，结果对方就会说：“我怎么没收到通知？这也太烂了。”
我们不得不很不情愿地决定，新账号默认要给每一条消息都发通知。但只要你收到过，我记不清具体是几条，应该是收到 10 条消息之后，我们就会弹出一个小提示，说：“嘿，你现在还在用默认通知设置。我们不希望 Slack 变得很吵。你要不要切换到我们推荐的设置？”
……用来控制通知。我们不想让 Slack 对你来说太吵。你要不要切换成我们推荐的设置？然后用户点一下链接，就会变成本来就应该默认的设置，也就是只有在 DM 或者有人 tag 你时才会通知。我们觉得，为了让人跨过这个门槛，这笔投入是值得的。再举一个简单点的例子，再说一个稍微复杂一点的。先说一个，Outlook 里那个标记邮件重要性、紧急性的旗标，不记得叫 urgent 还是 important 了，反正它在每家公司里都会被滥用。只要有人开始用，别人就会想：“行，那我也给我的消息加一个。”
于是所有消息都带上了小旗子，最后这个功能就没用了。Slack 里有 @everyone，它会在消息发送时给频道里的每个成员发通知。有人在某个组织里先找到这个功能，@everyone 一下，所有人都会收到通知；然后下一个发消息的人就会觉得：“我的事比 Bob 的事重要，我也要 @everyone。”这就变得特别烦，大家也开始抱怨。但我不知道算不算典型的公地悲剧，不过确实是一个反复出现的真实动态。
所以我们做了一个叫 shouty rooster 的东西，内部还会说“别当个 cock”，但显然不会公开这么说。你一旦 @everyone，屏幕上就会跳出一只小公鸡，嘴里还会冒出声音波纹，看起来特别烦人，同时会提示：“嘿，这会让 8 个不同时区里的 147 个人都收到通知。你确定要带着 @everyone 发出去吗？”结果这招特别有效，滥用一下子就少了。再说一次，我们真的是在试着塑造用户的行为。一方面不想把产品做得太死，但我们知道有些用法会让每个人都很烦、很难受，所以我们尽量塑造组织内部的沟通文化，让它能把这个功能用到最好。

Stewart Butterfield然后他们发出一条消息，其中一个人马上就会说：“我怎么没收到通知？这什么破玩意儿。”

于是我们很不情愿地决定，新账号默认必须对每一条消息都发通知。但当你收到的消息到达某个阈值后，我记不清具体是多少了，印象里大概是收到 10 条消息之后，系统就会弹出一个小提示，说：“你现在用的是默认通知设置。我们不想让 Slack 变得太吵。要不要切换到我们的……”

Stewart Butterfield……推荐通知设置？我们不希望 Slack 对你来说太吵。你点一下链接，就会切到我们真正认为合理的默认设置，也就是只有收到私信，或者有人 @ 你时，才会通知你。但我们后来意识到，为了先帮用户跨过最初那个门槛，这笔投入是值得的。再举一个简单一点的例子，然后再讲一个稍微复杂一点的。先说简单的。Outlook 里有个功能，我忘了具体叫 urgent 还是 important，总之就是给消息加个优先级标记。这个功能在几乎所有公司里都会被滥用。只要有一个人开始用，其他人就会想：“行，那我也给我的消息加上。”

结果最后所有消息都带着那个小旗子，这个功能也就彻底废了。Slack 里有个 `@everyone`，一发出去，频道里的每个人都会收到通知。于是总会有人先发现这个功能，在组织里用一次 `@everyone`，所有人都被震一下；接着下一个要发消息的人就会想：“我的事情可比 Bob 的重要，我也要 `@everyone`。”然后事情就会变得特别烦人，大家开始抱怨。我不知道这算不算严格意义上的“公地悲剧”，但它确实是一种反复出现的真实模式。
所以我们做了一个叫 `shouty rooster` 的东西，内部会半开玩笑地说“别当个 cock”，当然公开场合不会这么说。当你输入 `@everyone` 时，界面上会跳出一只吵吵嚷嚷的小公鸡，嘴边还带着声波效果，看起来就很烦，然后提示你：“这条消息会让 8 个时区里的 147 个人都收到通知。你确定还要带着 `@everyone` 发出去吗？”结果这招出奇地有效，滥用立刻少了很多。说到底，我们其实是在有意识地塑造用户行为。一方面产品要足够灵活，但另一方面我们也知道，有些用法一定会让所有人都觉得烦、都变得更难受。所以我们想尽量把组织内部的沟通文化往更好的方向带，让这个功能被用在最合适的地方。

Lenny Rachitsky这个功能现在还在。我现在还经常看到那只公鸡。不对，也不是经常……但其实我确实会 `@channel`，因为我管着一个挺大的 Slack 社区，所以那只公鸡我还真经常见，它活下来了。

Stewart Butterfield对，它保留下来了，而且保留得很值。因为这玩意儿实现起来几乎没什么成本，但带来的改善非常大。它还有一个作用，就是顺便教会用户产品是怎么工作的。很多人之前可能根本没意识到，`@everyone` 或 `@channel` 背后到底意味着什么，至少他们没有认真想过它的代价。

Lenny Rachitsky太妙了。

Stewart Butterfield再说一个。我们那时决定要做 `Do Not Disturb` 这个功能。这里面有个不算难题、但确实要非常小心处理的地方，就是你得考虑 Slack 的各种真实用法。因为到 2017 年我们实现这个功能时，已经有成千上万家付费客户了，背后是大量组织、海量用户。我记不清具体数字，但总之规模已经非常大。每个组织都已经按自己的偏好把系统配好了，包括一些世界上最大系统和应用的值班工程师，会把运维告警打进特定频道。也就是说，我们不能直接一上线就完事。我们意识到，组织里的决策者、管理员，肯定会对这件事有很强的看法；同时，一线用户自己也会有强烈意见。我们得想办法在这些关切之间找到平衡，并给大家足够合适的控制权。

所以我们设计了一套相当复杂的上线机制。首先，在功能真正上线前好几周，我们就提前通知了所有 Slack 管理员。并且告诉他们，我们会给各自组织设一个默认值。我记得大概是按本地时区设成晚上 7 点到早上 7 点，或者晚上 8 点到早上 8 点，具体哪个我忘了。与此同时，管理员也可以覆盖这个默认值；个人用户也可以覆盖组织管理员设的默认值；最后，如果管理员之后再次修改默认值，还可以把终端用户之前改过的设置重新盖掉，而用户当然之后又可以再改回来。我们不是想制造一种“双方互相打架”的动态，而是希望组织在调整策略时，个人依然保有自定义空间。
整个过程更长，也更绕，但它让数以百万计的 Slack 用户最终顺利拿到了这个功能，同时没有引发一堆冲突，也没有让人一上来就把它关掉。我觉得这里面特别关键的一点，是我们给了大家一组默认值。因为如果我们不设默认值，大多数人根本不会主动去打开。要是系统默认不是晚上 8 点到早上 8 点免打扰，普通用户多半一辈子都不会自己去配置。所以这是另一个比较复杂的例子，但我觉得这笔投入非常值，因为对很多人来说这是个关键功能。如果当时不是这么做，我想最后一定会招来很多抱怨和摩擦。

Lenny Rachitsky这些例子太好了。你们当时上线 `Do Not Disturb` 的时候，我真的非常感激。我到现在都还记得那个功能刚出来时的感觉，估计很多人都一样。

Stewart Butterfield对。

Lenny Rachitsky我还听说过你一个很多人会觉得反直觉的观点，就是关于产品体验里的“摩擦”。很多时候，摩擦其实是好事；如果用得好，它更像一个 feature，而不是 bug。你能讲讲你在这方面的经验吗？

Stewart Butterfield对，确实。而且围绕“摩擦”还有另一个问题，就是它后来几乎变成了一句口号，或者说一种默认假设：你永远都应该努力消除摩擦。在某些场景下这当然是对的。我们在 Slack 内部也讨论过，Slack 很难被营销，很难向没用过的人解释它到底是什么。你可以说它是“企业版消息应用”，类似这样，但 Slack 做户外广告、比如投一个广告牌时，有一个天然劣势：没人需要别人解释为什么他想要一辆车，或者想喝啤酒；但几乎每个人都需要被解释，为什么自己会想要 Slack。所以这里真正的问题，其实是“理解”，不是“摩擦”。这一点后面还会反复出现。你可以想象一下，你现在特别想买 Taylor Swift 在旧金山演唱会的票，于是你打开 Ticketmaster 网站。

在这个场景里，你的理解度几乎是满格的，意图的明确程度和强度也几乎拉满了。你很清楚自己想要什么，我就是要这一天、这个场馆的 Taylor Swift 演唱会门票。在这种情况下，Ticketmaster 网站慢一点，其实问题不大；支付页偶尔报错，问题也不大，因为你还是会咬牙继续，直到把票抢到手。所以当然，减少摩擦还是更好，但某种意义上它带来的额外价值没那么大。对大多数产品来说，真正符合这种情况的场景其实只有少数几个，像注册、登录认证、电商结账流程等等。我自己就会明显更愿意下单，如果页面支持 Apple Pay、Shop Pay 之类的一键支付。
反过来，如果我得手动一项一项填地址，而不是用地址自动补全那种选择器，我就会显著更不愿意把购买走完。听起来很夸张，但原因就在于，我的购买意图并不总是 100%，我的意图明确度也不总是 100%。如果你卖的是面向消费者的 T 恤，客户是从 Instagram 广告引流过来的，那他们当然都知道 T 恤是什么，也会觉得“这件看起来不错”。但大多数时候，他们的购买意愿并没有百分之百，也许只有 70%。如果你的流程摩擦超过了那 70%，我就直接不买了。可再看 Slack.com 的访问者，可能是几个月前某个朋友跟他安利过 Slack，后来又看到一篇新闻、一条推文、一个广告，最后他才说：“好吧，我去看看这个网站。”
所以他的意图其实只是刚刚越过门槛。在最后那个触发点发生之前，他还在门槛以下；发生之后，他只是勉强跨了过去。而且他的意图明确度，跟“我要买某天某地的 Taylor Swift 演唱会门票”完全不是一个级别。他只是 vaguely 觉得：也许这个东西和团队沟通、协作、消息相关，可能值得看一眼。也正因为如此，Slack 这类产品最难的地方通常不是“少点几下”，而是“你能不能让人理解它到底能干什么”。如果你没法教会用户，或者没法让用户自己发现产品能力，他们就不会用上这些能力，也拿不到这个产品真正的价值。

Stewart Butterfield如果你没法教会用户，或者没法让他们自己逐步发现这些能力，那他们就不会去利用它们，自然也就得不到产品能带来的全部价值。我觉得真正的关键在于：任何应用里那些独特的部分，那些只有你的产品、你的软件才会做的事情，绝大多数时候，难点都不是“摩擦”，而是“理解”。几乎任何产品都这样。拿 Shopify 来说，对它的目标用户而言，这个服务大概是做什么的，通常还算容易说清楚。但大多数第一次开店的人，并不知道自己能看报表；就算知道有报表，也不知道具体有哪些报表；就算知道报表类型，也不知道该怎么调、什么时候看、哪些指标更值得优先展示。

这种例子我可以一直讲下去，但很多人就是意识不到这一点。我想看看这件事现在是不是还成立，所以我现场打开一下手机里的时钟 App。里面对闹钟的描述特别离谱，虽然不是完全一样的问题，但每个人都可以拿自己的手机看看。我这里看到的是：页面写着 `alarms`，然后是 `sleep | wake up`，再写着 `no alarm`，旁边有个 `change` 按钮。你点进去后，它又说：`sleep is off. In order to automatically turn on sleep features and edit your schedule, you need to turn sleep on.` 也就是说，如果你本来就知道这套东西在讲什么，那 `sleep` 这个名字也许还行；可如果你不知道，它既不合语法，也完全让人摸不着头脑。谁会知道自己为什么要开这个？我猜这状态已经持续很多年了，90% 以上，可能甚至 98% 的人，都会像我一样，直接说：“我就想开个闹钟，把时间设好就行了。”
我直到现在都不知道“turning sleep on” 到底会做什么。但正因为用户不理解，他们就拿不到背后的价值。我敢肯定，那个所谓的“打开 sleep”后面一定藏着不少能力，也一定有很多团队花了很多时间做这些功能，它可能还接了生物识别、手表之类的一堆东西。可我到现在还是不知道，因为“打开 sleep” 这句话本身就会让我想：这到底会干嘛？我要付出什么？会对我造成什么影响？这种情况在软件世界里到处都是。为什么很多软件我在真正面临一个选择点时干脆不用，或者很多功能我看见了也不点？原因就是我根本没看懂它要干什么，而我也懒得管。如果要让我用一句话去替代“减少摩擦”这个口号，那就是《Don’t Make Me Think》。你应该记得那本书吧？

Lenny Rachitsky当然记得。

Stewart Butterfield对。说实话，我上次读它已经是十几年前了，里面具体举了哪些例子我都快忘了。但它之所以能和 utility curves 一样，成为我脑子里非常重要的一条原则，是因为至少有两个原因。第一，做决定本身就是有成本的。你真的会消耗葡萄糖。这里面有实打实的代谢过程，线粒体在产生 ATP，神经元在活动，一堆事情都在发生。人是真的会决策疲劳，认知是有成本的。第二，还有情绪层面的影响。如果你的软件突然打断我，让我做一个决定，而我又根本没理解它在说什么，那你给我的感觉就是：我是不是很蠢？我会想，“我怎么没看懂？”

当然，也有人会直接觉得“这软件有病”。但我觉得大多数人的第一反应其实是：“是不是我太笨了？”你只要跟那些没那么擅长技术的人聊过，就会知道这有多常见。最典型的场景就是 50 岁以下的人在教父母用软件、解释某个操作应该怎么做，父母几乎总会觉得是自己不对，是自己太笨。所以如果你让用户不得不去“想”，最好情况下，你是在白白消耗他们的生理资源；最糟情况下，你还让他们情绪上不舒服，而这种不舒服会永远和你的产品绑定在一起。这些问题其实都是连着的。
我再补最后一点，因为这些事情本来就是一体的。除了“减少摩擦”之外，还有一个常见说法是：要减少用户完成某件事所需的点击或轻触次数。但大多数时候，这恰恰是错的。你要想让 App 里的任何操作都只用一次点击，最简单的办法是什么？就是把所有可能性都摊在一个页面上，让它一直滚、一直滚、一直滚，滚上成千上万屏。显然这很糟糕。那为什么人们会觉得“稍微这么做一点”就是好的呢？举个例子：你打开一个菜单，里面有 14 个用户可能想做的操作。
第一层优化，是先把相近的操作分组，中间用横线隔开，让用户至少能分块理解、看清里面有什么。第二层优化，是把最常见的两三个，或者五个常见操作先摆出来，再加一个类似 `other` 的入口，点进去才看到更多子菜单。这里面最关键的，就是你怎么调这个结构。我又要拿 Google 开刀了，我现在都快像 Donald Trump 了，不过我先插个故事。

Lenny Rachitsky来吧。

Stewart Butterfield大概八年前吧，在某个会议还是活动上，我记不清了。那天所有 session 结束后，我们在酒吧里聊天。Stripe 的 John Collison 在场，Google 的 CEO Sundar 也在。John，不对，是 Patrick，走过去和 Sundar 聊天。他本来可以聊任何事情。那时候 Stripe 还没到今天这种巨头体量，但也已经是一个非常重要、势头很猛的公司了。结果 Patrick 想跟 Sundar 聊什么？聊 Gmail App 里拖拽收件人的体验。你在 `reply all` 一封邮件时，经常会想把某个主收件人移到 CC，或者把某个 CC 拉回主收件人，但在 Gmail App 里做这件事，对手指操作精细度的要求高得离谱。

到现在这事都还没修好。最打动我的是，Patrick 明明可以借这个机会聊任何事，可以谈合作，可以聊战略，但这个体验真的把他烦到了，他就是过不去。所以说回来，继续吐槽 Google。Google 在很多方面真的做得很棒，有很多很厉害的东西，这都没问题。但 Gmail 单封邮件上的操作，被拆成了两个很长、彼此不同的菜单，而且有个操作两个菜单里都没有，唯一做法是点一个没标签的图标，那就是把已读重新标成未读。我完全搞不明白为什么有些操作在一个菜单里，有些在另一个菜单里。我猜可能一个是针对单封邮件，一个是针对整个线程，但整体上看非常不一致。
所有可能的操作都被堆在各自的地方，于是它就变得特别难用。因为你有时得两个菜单都点开，把里面所有选项看一遍，然后用排除法想：“好，这里没有，那它应该在另一个地方。”Uber 现在已经不是这样了，但我最早在 Slack 内部提这件事时，Uber App 曾经有一段时间打开后只有一句话：`Where would you like to go?`，再加一个 `other`。而 `other` 里装着所有别的事情，比如改支付方式、改上车地点，或者任何其他你在 Uber 里能做的事。那套设计几乎是完美的，因为绝大多数时候，人们只是想选自己要去哪里。偶尔你想改上车点，因为你人还没到那里之类的。但从心智上说，还有什么比“我要告诉你我要去哪，或者我要做别的事”更简单？
所以我一直在推动大家去想：用户此刻最可能想做的那件事是什么？或者最可能的两件、三件事是什么？然后把其他所有东西都藏到 `other` 后面。哪怕最后用户为了完成某件事要点 8 下，但如果每一步都极其简单，那也很好。相反，如果你把它压缩成 2 下，可每一步都是那种令人焦虑的判断题，要不断打开菜单、猜到底哪个才是对的，那体验就会糟得多。比较三个选项已经挺费劲了，比较四个更难；而把 15 个选项彼此来回比较，想判断“是不是这个”，认知成本几乎是几何级上升的，贵得离谱。所以在我看来，这些问题全都连在一起。只要大家能跳出“减少摩擦”或者“减少点击次数”这种执念，转而真正去想：我怎么把这件事做得简单？我怎么避免用户为了用我的软件还得先动脑子？我怎么让它变得毫不费力？最后再举一个特别影响我的例子。当时我们在 Slack 内部反复讨论这些问题，我在温哥华和旧金山之间来回飞。有一次我在登机廊桥排队，前面站着一个十几岁的女孩，我看她在用 Snapchat，真的惊到了我。
她至少每秒点四下，有时候每秒六七下，在不停地划掉 story、切各种内容。但整个过程特别流畅，因为每一步判断都极轻：我要不要再看一遍？要不要继续看这个人的下一条？要不要切去另一个人？然后突然来了一条通知，她回一下；又自拍一下；整个过程就是那种非常顺的流。她大概连续这样操作了六分钟，中间可能有一点停顿，但整体就是一直在飞快地用。对于一个 2016 年左右的 15 岁女孩来说，那就是 Snapchat 最好、最自然的使用方式。你想想看，如果产品目标是“尽量让她少点几下”，那对她想要的体验、对 Snapchat 想创造的体验，会构成多大的阻碍。

Lenny Rachitsky听你讲这些真的很过瘾。你举的这些例子，让人特别能看出你的大脑是怎么运转的。你对别的产品、甚至对自己的产品，始终都处于一种不满足的状态。我觉得这就是核心。Patrick 也是个很好的例子。像 Stripe 这样的公司，我感觉一个反复出现的共同点就是：那些特别成功的产品领导者，往往都对现状长期不满，对“怎么会这样工作”这件事始终不爽。

Stewart Butterfield对。

Lenny Rachitsky而且我特别喜欢你刚刚那种总结方式。不是去执着“减少摩擦”“减少步骤”，而是想：怎么减少用户不得不思考的量。我以前从没听人把这件事解释到 ATP 和葡萄糖这个层面，说你真正要减少的是用户为了思考所消耗的生理资源，而不只是点击次数。

Stewart Butterfield对。我有时候更刻薄一点时，会直接跟大家说：“先把你手上的事停一下，闭上眼，深呼吸几次，然后假装自己真的是一个正常人。”

Stewart Butterfield先停下你手头正在做的事。闭上眼，深呼吸几次，然后假装自己真的是一个普通人。再把眼睛睁开，重新看看眼前这个东西：你能看懂它到底想表达什么吗？你知道自己应该做什么动作吗？你知道做完这个动作之后会发生什么吗？这里其实还牵出另一个相关循环。不过在讲那个之前，我知道我已经说得很长了，我先把你刚刚那个“为什么优秀产品人总是不满足”的问题收一下。

我刚刚想找的那句话是这个。那是 2014 年，也就是 Slack 在 2 月正式发布的那一年。到年底时，我接受 MIT Technology Review 采访，对方问我我们是不是还在继续改进 Slack。我说：“天啊，当然啊。我一直想把这种心态灌输给团队其他人，但就我个人而言，我觉得我们现在手上的东西就是一大坨垃圾，糟透了。我们居然把这种东西拿给公众用，简直应该感到羞耻。当然，也不是每个人都会觉得这种说法很有激励作用。”
结果我第二天一进办公室，大家已经把这句话打印成大概 40 张 A4 纸，贴满了整面墙。可对我来说，这句话真正的意思就是：你就该为它还不够好感到不满足。你应该永远想继续把它做得更好。你当然可以为某个具体作品感到骄傲，可以说“这部分做得真不错”。但从整体上看，如果你已经看不到几乎无穷无尽的改进空间，那你可能就不该来设计这个产品，甚至不该来负责这家公司，说重一点，几乎什么都不该负责。
再往小了说，哪怕缩到一个极小的功能，也几乎没有哪个功能真的接近完美。只要 A，这一点能在组织内部被坦率承认；同时 B，大家把“持续改进”当成目标去想，那就会完全不一样。这可以是更偏 Six Sigma、Toyota、Kaizen 那一路的做法；也可以是另一个故事，我一时想不起那个人的名字了，就是 Bridgewater 的创始人讲 Michael Jordan 学滑雪那个故事。

Lenny RachitskyRay Dalio。

Stewart Butterfield对，Ray Dalio。他在书里写 Michael Jordan 学滑雪时，每次出错，都希望滑雪教练明确告诉他自己到底哪里做错了。因为在他看来，每一个错误点，都是可以捡起来的一颗宝石，攒起来以后，他就真的能变成一个好滑雪者。而他的目标也很清楚，就是要成为一个好滑雪者。这种状态在组织内部其实需要很高的信任。

但如果你能把团队带到这样一个状态：“我们是在认真找可以改进的地方。我们之所以挑剔、之所以批评，是因为我们想把这件事做到尽可能好。”那虽然不是对每个人、每个时刻都有效，但大多数时候，对大多数人来说，那种很直接的批评其实是有激励作用的。人们会真心感谢这类反馈，不管它来自公司内部的同事，还是来自产品终端用户。因为你会意识到：对，这里确实做得不好，我们应该修。

Lenny Rachitsky这一期节目由 Lovable 赞助。它不只是历史上增长最快的公司之一，我自己也经常用，而且真的非常推荐。如果你脑子里一直有个 App 点子，但不知道从哪里开始，那 Lovable 很适合你。你只需要和 AI 聊天，它就能帮你搭出可以工作的 App 和网站；之后你还能继续自定义、加自动化，再部署到正式域名上。它特别适合营销团队快速做工具、产品经理做原型，也适合创始人去启动下一个业务。

和很多 NoCode 工具不一样，Lovable 不是拿来做静态页面的，它做的是有真实功能的完整应用，而且速度非常快。以前得花几周、几个月甚至几年做出来的东西，现在一个周末就能跑起来。所以如果你脑子里一直压着一个想法，现在就是把它做出来的时候。去 lovable.dev 就能免费开始。也正因为这个，我想起你另一个可以算是“吐槽”的观点：任何东西要真正运转起来，都需要大量工作。默认状态其实就是“不工作”。你能展开讲讲吗？

Stewart Butterfield对。这个跟很多事都有关系，而且可能是近些年我越来越常想到的一件事，在政治里尤其明显。顺便说一句，如果有谁在听这一期，能帮我找到一条 2016 到 2020 年之间的推文串就太好了，我记不清具体年份。那是一位网友写的长线程，讲他们社区想在一条住宅街上立一个停牌到底有多难。我记得它好像是在回应一个说“比特币会取代美元”之类的加密话题。他的意思大概是：你先看看我们只是想在社区街道上加个 stop sign，都经历了什么，光这件事就花了好几年，还牵涉到一大堆机构。

像工程部门、交通规划、业委会之类的……我现在记不清所有机构了，不然我应该能搜得更准一点。因为那条线程真的是个杰作，把“在大多数地方，想装一个停牌到底有多难”这件事讲得淋漓尽致。而我从大多数政治人物那里听到的信息，偏偏又非常容易奏效，大意都是：事情本来应该是好的；之所以现在不好，是因为有人在做坏事，挡住了这种“好”。
比如说，是亿万富翁让生活变得越来越负担不起；或者是移民抢走了你的工作；或者是那些偷懒占便宜的人在吸政府的血，害得所有人都得多交税，诸如此类。可现实其实是：几乎没有什么东西是天然能顺畅运转的。某种意义上，这也呼应了另一个说法。我记得 John 有个特别好的概括，你应该也听过，大意最后落在一句：这个世界本质上是一座“激情项目博物馆”。因为任何一件事想真正落地，不光要有把它在现实世界里做出来所需要的资源和努力，还得处理其中所有的政治、社会关系、说服和协调。
最近还有一本书叫《Why Nothing Works》。先跟作者说声抱歉，虽然我估计他也不会听到这段，但实话说，这本书在写作上不算特别出色，我甚至觉得有点重复。不过里面的内容非常精彩，它讲清楚了为什么很多事情会这么难做：为什么任何行动路径上，可被行使的否决权会越来越多，事情又因此变得多么艰难。这在新建项目审批、施工许可之类的问题上体现得特别明显，当然，在组织内部也一样。
难点在于，人类从进化和生物学层面上，就很难不用拟人化的方式去理解世界。比如今年没下雨，我们就会倾向于觉得：是不是某个神生气了？是不是去年祭的羊不够多？人很难接受“天气系统本来就极其复杂、混沌，生态和气候学更是如此”这种解释。
现实世界也是一样。如果我现在连账单都快付不起了，连一点点体面的生活都保不住，比如住的地方好一点，或者给孩子买份礼物，那一定得是谁的错吧？总得有某个地方、某个人做了一个决定，才让我变成这样吧？可真实情况是，一切都太复杂了。变量太多了。这种解释一点都不爽，也是一种非常糟糕的政治叙事。
更容易卖出去的话术总是这样：“我们知道你为什么痛苦，也知道为什么事情会变坏。归根结底，是某个人做了某个决定，所以才变成这样。只要我们把他换掉，或者推翻他的决定，改成我们这套，事情就会重新变好。”而在我看来，这种逻辑在公司和组织内部其实也会不断重演。先停在这里吧。

Lenny Rachitsky顺着这个话题，我知道你也很相信一个概念，叫 Parkinson's Law。

Stewart Butterfield对。它最早应该是 1956 年，《经济学人》上一篇 Parkinson 写的文章。里面那句名言是：工作会膨胀，直到填满为完成它而分配的全部时间。它在现实里怎么体现，其实有点微妙。比如我现在没正式工作，时间压力比以前小很多，我就切身体会到了这一点。那句“想把事办成，就交给忙人去做”反过来也成立：如果你根本没那么忙，天哪，一些极其基础的事情也会拖得特别久。

Parkinson 一开始举的例子，就是写信和寄信。我忘了他第一个例子用的是谁，大概是那种特别忙、手上堆满事情要回复的人；然后另一边，是一个拥有无限时间的退休老太太。她会花很久写那封信，又花很久把信装进信封里，然后再慢慢去邮局寄掉。
但对我来说，真正精彩的部分，是他后来谈组织规模的时候，举了很多例子。这毕竟是 1950 年代，他又是英国人，所以他看的是英国皇家海军。具体来说，他看的是一张图：皇家海军里，主力舰数量、水兵数量，以及行政人员数量之间的关系。这种图对今天任何研究政府体系的人来说都很熟悉；看大学行政人员和学生、教师数量关系时，也常见这种图。画出来大概就是：舰船数量这样走，水兵数量差不多也跟着走，而行政人员数量是这么一路冲上去。
它之所以和“工作会膨胀到填满可用时间”连在一起，是因为人会继续招人，也会继续培养人。这里有个对所有经营公司的人来说有点残酷的现实。确实有例外，某些类型的工程师不太一样。但绝大多数你雇来的人，都会想继续招更多向自己汇报的人。这不是因为他们邪恶，也不是因为他们蠢。恰恰相反，他们很聪明，因为人人都知道：向你汇报的人越多，你的职业前景往往越好，薪酬越高，组织里的权力越大，后面一连串事情都会跟着变化。
所以我们在 Slack 招来一个资深产品经理，他几乎立刻就想再招个人。你会想，搞什么？这个人来干嘛？他们嘴上不一定这么直说，但本质上意思往往是：“那个人来做具体产品管理，我来做战略。”

Lenny Rachitsky太经典了。

Stewart Butterfield我觉得这里最重要的理解还是：这不是因为他们坏，也不是因为他们笨。它跟前面说的“世界本来就复杂”其实是一回事。也许这都可以叫我的“蝴蝶法则”了，我以前还没这么想过。我很久以前发过一条推文，大意是：如果你根本不知道自己在说什么，那所有事情看起来都会很简单。反过来说，如果一件事看起来特别简单，那多半说明你还没真正理解它。当然，这里也有明显的例外。

Stewart Butterfield但只要事情牵涉到大型组织，或者牵涉到很多人，只要你觉得这个问题“很简单”，那通常说明你根本没看懂。所以任何预算流程里，不会有工程负责人、销售负责人、CFO、法务总顾问跑回来跟你说：“我认真想了想，明年我们其实可以少招点人。要不就维持不变，甚至靠自然流失收缩一下，因为我们手头的事根本不需要更多人。”这不是因为他们坏，也不是因为他们蠢，而是因为组织内部存在一种几乎压倒性的冲动，会把事情不断往“继续扩张”那边推，而且往往最后会带来灾难性的结果。

我举一个 Slack 历史上的例子。以前我尝试把这个例子里的具体人物模糊处理一下，免得谁听了不舒服，但很遗憾，这个案例里细节太重要了，模糊掉反而讲不清。所以我先再次强调：这里涉及的人既不笨，也不坏。这个例子一部分来自组织外部视角，一部分来自 Slack 内部。Slack 当时上线了 threads，也就是在频道消息下面继续回复的能力。比如你，Lenny，发了一条消息，我，Stewart，回了一句，那你会自动收到通知。之后 Sarah 又来回复同一条消息，那么你和我这两个已经参与过这个 thread 的人，都会再次收到这个线程有新活动的提醒。也就是说，只要有人继续回复，通知就会不断发。
所以这个功能最初发布时，或者准确说，在上线前最后一次产品评审时，输入框里会默认预填一个 `@`，直接带上线程里上一位发言的人。我自己在用时，每次都会先把光标点进去，全选、删除，再开始打字。因为即便我真的想特别点名某个人，我也几乎从不想把一句话的开头写成 `@某某`，那样会让你很难自然地接住对方前面说过的话。所以我当时就说，把这个去掉。第一，我觉得大多数人根本不会这么用；第二，就算他们真想 @ 某个人，也不太会想把它放在句首。
而且更关键的是，这其实是在教用户错误地使用产品。因为大家必须理解一件事：在这个 thread 里，之前所有发过言的人，本来就会自动收到通知，除非他们自己已经做了额外设置。
好，后来功能发出去了。过了六个月，那个默认 `@` 的东西突然又回来了。我就给团队里的人发消息，说：“诶，这里回归了，特别奇怪，我不知道发生了什么，但这个 `@` 怎么又冒出来了？”对方说：“不，不是 bug，这是故意加回来的。我们做了一堆研究。”我当时就愣了：什么？然后我去追这个过程。按我印象，这个分析连 P95 置信度都未必够。结论大概是：加上这个默认 `@` 时，线程平均长度是 2.17 条消息；不加的时候，是 2.14 条。
首先，为什么“线程更长”就是更好？说不定更短才更好呢？这意味着来回沟通的消息更少。其次，这个差异也太小了。再者，我现在已经记不清当时的统计分析细节了，所以我不想直接说它一定是错的，但我非常怀疑这其实已经超出了它能得出确定结论的边界。可真正让我崩溃的是：天啊，你们为了这件事，在产品里加了 feature flag，做了 A/B test，加了埋点，建了数据表或者其他记录结构。
你们写查询语句把数据拉出来，再基于这些数据画图，还开了会来讨论它。你只要把这整个链条拆开来看，就知道为了让这个默认 `@` 回来，到底发生了多少事情。至少是几千个工时，因为在这种规模的组织里，任何一个功能改动，都会卷进至少十来个人：工程、QA、数据分析、项目经理、用户研究，等等。问题在于，我觉得这个改动本身就是个坏主意，对吧？但更大的问题是：不管你想用什么单位来衡量，这个功能有和没有，能带来的差异就这么一点点；而分析它所花掉的成本却是这么大一截。所以这笔账从一开始就注定是亏的。
说白了，不存在任何一种现实，会让“在 thread 消息开头默认加上前一位回复者的 `@`”对 Slack 的整体质量、对它给用户创造的效用产生那么大的提升。可与此同时，你又很清楚，要做这件事，你得加 feature flag，发新版本，打埋点，记录每个用户动作的 API 调用，做所有分析，做 dashboard，截个图贴进 Google Slides，发会议邀请，再因为有人没空把会改期，最后让所有人坐下来一起盯着这张图看。无论怎么算，这都是一笔必输的买卖。
我知道 Fareed 跟你说过，想让我讲讲那个叫 `hyper-realistic work-like activities` 的概念。那我就说说我的整体理论。这个概念通常和另一个概念绑在一起，叫 `known valuable work to do`。我说的 `known`，意思是两层：你既知道这件事是什么，也知道它是有价值的。几乎所有组织在最早期，都会拥有海量这样的工作：你知道该做什么，也知道它一定有价值。比如创业时先去开个银行账户，这事对公司几乎有无限的一般性价值，而且你非做不可，也很明确。
所以在任何创业项目一开始，大家做的往往都是：“我来建用户表”“我来处理密码哈希”，全是那种绝对必要的事情。每个人都清楚自己在做什么，于是大家早上来上班时都会很有劲：太好了，我今天有 10 件事要做，而且每一件我都知道怎么做，也明确知道做完就有价值。可随着时间往后走，`工作供给` 和 `做事需求` 之间的关系就开始变了。
越来越多的人被招进来。每个产品经理都想再招个初级产品经理。风控合规团队刚进来的第一个人也会说：“天啊，我们有这么多风险、这么多合规要求，最好赶紧再多招几个人来处理。”这在某种程度上也许没错，但问题是，这类人会越来越多，然后他们就会彼此开会。
于是突然之间，你手里有了一大堆“想做事的人”，可那些容易、明显、确定该做的事，其实早就做完了。接下来你们讨论的问题就会变成：“天啊，我们要不要去做 FedRAMP High，搞一个专门版本的 Slack？那样的话，我们得为运行软件的硬件搭建一整套完全独立的物理基础设施，还得有一支完全不同的运维团队，而且只能由美国公民组成。那这件事到底可能给我们带来多少收入？同时，它会让以后更新软件变得多复杂？因为我们得维护两套完全独立的系统。”事情就会开始失衡。
最后结果就是，如果你招了 17 个产品营销，那你自然就会长出 17 个产品营销份额的“工作需求”。而如果你并没有足够多真正值得做的产品营销工作，他们就会开始去做别的事。这里再次强调，不是因为他们蠢，也不是因为他们坏。而是因为他们会想：我是产品营销，我得靠工作被看见。我太太前阵子还说我上个周期没升职，这一轮我必须做出点成绩、拿下一些 win，诸如此类。
于是人们就会开始约同事开会，提前过一遍他们准备在大会议上讲的 deck，看看哪几页还要不要改。问题是，这种 `hyper-realistic work-like activity`，也就是“高度逼真的类工作活动”，表面上看和真正的工作几乎一模一样。大家坐在会议室里，前面投着一份东西，我们围着它讨论。这不就是工作吗？至少在公司里，很多时候我们工作看起来就是这样。
但它其实是一种“假工作”，而且它微妙到什么程度呢？微妙到我自己会掉进去，我们的董事会成员会掉进去，每个高管都会掉进去。你离完整上下文、完整信息、决策权限越远，就越容易被这种东西困住。人们会花大量时间去做这种高度逼真的类工作活动，而且完全意识不到自己正在这么做。最后我想说的是：如果你是领导者，不管你是经理、总监、高管，还是 CEO，你的责任就是确保组织里始终有足够多的 `known valuable work to do`。这种工作其实几乎总是存在的，难的是你要把它讲清楚，要建立清晰度，建立对齐，确保每个人都明白自己真正该做的是什么，然后当然，还得真的去做。

Lenny Rachitsky太精彩了。我可以整天听 Stewart 吐槽。`Hyper-realistic work-like activities`，我们得把这个词真正推广起来。

Stewart Butterfield可惜它缩写起来不好听，长得太丑了。

Lenny Rachitsky好吧，那就先别缩写。顺着这个话题收一下，解决办法是不是就是领导者先识别出这种情况正在发生，然后及时把它叫停？比如直接指出：我们为什么还在这种不会带来结果的事上花时间？

Stewart Butterfield对，但你刚刚那种说法可能不是最好的处理方式，因为听起来像是在训人，好像是他们太笨了，才把时间浪费在这种事上。可实际上，责任在你。你得确保组织对优先级有足够清晰的认知，要更早明确地说“不”，把一些事情在前面就挡掉，而不是等大家都卷进去了，再出来说：“嘿，你们这群笨蛋，怎么把时间浪费在这种没意义的事上？”这是谁的责任？是经理的责任，是某个 VP 的责任，是 CXO 的责任，归根到底，是组织领导者的责任。你得保证团队里始终有足够多清晰、明确、真正有价值的工作可做。而且说实话，这件事比看上去要难得多。

Lenny Rachitsky对，我们刚刚把那个经典例子漏掉了。我自己常想到的另一个说法是：别去说服人们“来造一艘船”，而是先让他们对大海产生向往。

Stewart Butterfield对，完全没错。这种思路其实很早以前就有了。

Lenny Rachitsky好，那我来问问 pivot。你可能就是“转向之王”了。你创办过两家公司，两家都很有名地经历过 pivot，而且两次都是从视频游戏转过去的，所以我一开始才会问你那个问题。后来它们都变成了非常成功的公司。我猜很多人都会来找你请教 pivot。那我直接问吧，当别人来问你：“我该坚持现在这个想法，还是该 pivot？”你通常给什么建议最有帮助？

Stewart Butterfield我觉得这里面确实有一部分靠直觉，但核心判断其实很明确，就是：你是不是已经把所有可能性都试过了？拿我们做 Glitch 时的情况来说，那原本是个游戏，我们内部沟通用 IRC，后来又在 IRC 上加了很多东西，最后慢慢长成 Proto Slack。我觉得 Slack 最大的优势之一在于，我们其实在好几年时间里都“没有明确地在做 Slack”，但又一直在为它打基础。我们只会去做那些几乎可以 100% 确定值得做的功能：要么是某个痛点已经烦到我们受不了，要么就是某个改进明显到你不做都觉得亏。那时候我们账上其实还剩 900 万美元，大家也都还喜欢那个游戏，团队工作状态也不错。但到那个阶段，我觉得自己已经把所有不那么荒唐、还算现实的商业化思路都试得差不多了，所以我决定放弃它。

但大多数人默认给出的建议永远是“坚持住”。就像那种小猫抓着树枝的海报，上面写着“Hang in there”。我们从小听过太多这类故事：谁谁谁最开始挨家挨户推销，被所有人拒绝，后来突然就变成了 Nike，类似这种。好像只要你熬得够久，最后总会成功。我觉得做 pivot 判断时，你必须冷静到近乎无情。有些内容 Annie Duke 在《Thinking in Bets》里讲过，她第二本书里也讲过，我一时想不起书名了，但总会有人知道。

Lenny Rachitsky对，《Thinking in Bets》，然后第二本是什么来着？我也忘了。

Stewart Butterfield她其实就把 Glitch 和 Slack 当成一个 “smart fold” 的例子。也就是说，我这边的预期价值已经下降到某个点，以至于另一个备选项看起来更值得下注。我之所以说这件事必须冷酷理性，是因为它真的他妈特别丢脸。你要把一家公司做起来，前面得说服太多人了。你要去见投资人；你要去说服早期员工：“你应该辞掉原来的工作，来做这个，因为我们想象中的这个能力会非常了不起。”你还要面对媒体，对外许下各种承诺；你还会有用户，你答应过他们一些东西，也说服他们把时间投入到这个产品上。所以对很多人来说，一直硬撑下去，直到公司因为没钱而窒息死亡，都比亲口承认“好吧，是我错了，这东西没成”要容易。因为承认失败真的很羞耻，也很痛苦，很撕裂，会带来很真实的伤害。

我们关闭 Glitch 时，真的有很多人非常爱它。他们会把所有空闲时间都花在里面，下班后最期待的事就是赶紧回家继续玩。那是他们的社区，而那个社区突然就消失了，连同里面那些人、那些身份、那些关系一起消失。更不用说有人因此失去工作，还有一些人是带着家人搬去另一个城市才接下这份工作的，结果现在工作没了。所以我从来不会轻飘飘地看待 pivot。我觉得，“我们三个人做了个 App，六个月后换了另一个 App”，那种其实都不太算 pivot。你做了才半年，本来就还在摸，还在搞清楚自己到底在做什么。那不是真正意义上的转向。当然，我们这个案例最后结果很好，这里面也有幸存者偏差，这并不意味着所有人都应该动不动就 pivot。但我觉得，能不能把自己拉开一点距离，用理性的、智识上的判断去做决定，而不是被情绪拽着走，这件事至关重要。

Lenny Rachitsky我也很喜欢你那个建议：把能试的思路都试完。等你真的把所有办法都耗尽了，再去看还有没有别的路。这是个非常好的判断点。

Stewart Butterfield对，重点是把所有“好”的点子试完。

Lenny Rachitsky所有好点子。

Stewart Butterfield对，所有现实可行的好点子。

Lenny Rachitsky对。你刚刚说“坚持”这件事，我前阵子刚请了 Canva 的 CEO Melanie Perkins 上播客。她当年被 100 个投资人拒绝，最后才终于有人投她，但她就是一直往前推。

Stewart Butterfield对，但我觉得那是稍微不同的一类案例。她最终一直相信的是产品本身和整个愿景。她当时要解决的问题，更像是找到一种合适的表达方式，让投资人能够理解，而那些最后投进去的人显然也开心得不得了。

Lenny Rachitsky那何止是开心，简直开心坏了。好，时间如果还允许，我想聊最后一个话题：慷慨。我前面说过，我去找了很多跟你一起工作过的人聊，问他们你最让他们记住的是什么。结果反复出现的第一主题就是 generosity。我念几个例子给你听，都是别人跟我讲的。

有个人说，他圣诞节前手头有点紧，Stewart 直接陪他走出办公室，到取款机边取了 500 美元塞给他，说“回家陪家人吧”。还有人提到，Glitch 关停、你不得不裁员时，你是真的哭了，而且之后花了大量时间帮大家找新工作、延长遣散待遇，把这件事看得非常、非常重，比很多人印象里的 CEO 认真得多。还有人提到，你给员工承担 100% 的医疗保险，就是为了让大家少操一点心。
Slack 上市时，你几乎给员工设计了最友好的安排：没有 lockup，走的是 direct listing。还有人说 Slack 被收购时的交易结构，对员工也非常友好。除了对员工，你对客户的态度也是这样。举几个例子：COVID 期间，你给那些交账单困难的企业发过免费 credits；你推出过一种当时非常超前的 fair billing，不再向客户收取那些明明签了 seat 数、但实际上根本没在用的席位费用。还有很多次，你推迟功能发布时间，只因为你想把功能继续打磨得更好。我最后用一句别人的原话收一下：“Stewart 是那种会把自己对员工的责任看得非常个人化的领导者，而且他愿意尽自己所能，把最慷慨的条件给出来。这是值得被认真肯定的。”

Lenny Rachitsky所以首先，我只是单纯想为你喝个彩。我觉得像你这样的领导者真的很少见，也很鼓舞人。很明显，你已经影响了很多很多人。我不太确定自己到底想问什么，但大概是：这里面有多少是你有意识在做的，比如“这是我们赢的方法，我要足够慷慨、足够帮人，因为我知道长期看这会产生回报”；又有多少只是因为这就是你的天性、你本来就是这样的人？

Stewart Butterfield我觉得很大一部分确实就是我的性格本身。我有非常好的父母，他们把我教得不错。但我也觉得这里面确实有一点值得总结的东西。我先默认大家都熟悉“囚徒困境”。对我来说，慷慨这个动作，其实是在向外发出一个信号：我愿意在这个重复博弈里选择合作。如果你这么做，对方也更可能选择合作，最后双方都会受益。反过来，如果你始终不知道对方会不会在第一时间就背叛你，那最优策略往往反而是你先背叛。所以这里面其实有博弈论的一面，只不过现实中的博弈，通常比囚徒困境复杂太多太多了。

我前面没提到、但对我来说很重要的一件事是：在不止一次公司全员会上，我都让全公司一起喊一句话，像口号一样反复说。那句话是：“从长远看，我们成功的衡量标准，是我们为客户创造了多少价值。”我之所以要把这句话说得特别清楚、特别明确，是因为只要你正在做的事，哪怕带一点灰色地带、带一点投机、带一点在错误时机搞 maximize、带一点占客户便宜的味道，那最好就别做。因为在我看来，这不只是字面意义上是真的，它也是一种有伦理感的经营方式。更重要的是，伦理不只是“显得正确”而已，它对你自己也有实际好处。你能吸引来更高质量的员工；如果你的员工整体更有伦理感，这家公司本身也会变成一个更适合大家工作的地方，你会更开心，内部问题也会更少，后面一连串事情都会变好。
但我也真的相信，尤其从长期来看，你不可能一边摧毁客户价值，一边还指望自己成功。你必须真的让他们的生活变得更好。你当然可以花很多力气把这件事讲给他们听，向他们展示你创造了这些价值，但真正创造价值这件事，没有任何替代品。我觉得这点极其重要，而它天然就会导向一种真正的慷慨。无论是在企业合同谈判里，还是在具体政策设计上。我们也不是没因此吃过亏。有一次就出过问题：我们当时的 SLA 写的是，“只要出现宕机，你就能拿回 100 倍的费用补偿。”因为在我看来，如果我们只挂了两分钟，那基本也就值几分钱，几乎没差；如果我们挂了 10 小时，那我们的麻烦已经远不止赔钱这么简单了。
后来时间一跳，我们已经做到几亿美元收入，也上市了。就在上市后不久，我们经历了一次史上最大级别的宕机之一。我记不得具体多久了，但持续了很多个小时。问题在于，到那个体量以后，按照“宕机时长乘以 100 倍返还”那个规则，光是那次只占一天三分之一左右的宕机，就差不多得返 800 万美元。它并没有真的从现金流里掏走我们 800 万，因为我们是用 credit 的形式返给客户的，但它直接意味着下一季度原本已经算进预期收入的一大块不会出现了，因为客户会先用这些 credit 抵扣本来该付的钱。所以那次之后，我们确实修改了服务条款，因为上市公司毕竟又是另一回事。但除了这个例外，其他那些决定我都认为非常重要，而且确实帮助了我们变得成功。

Lenny Rachitsky那个政策是自动触发的？客户甚至都不用来 claim？系统自己就把 credit 发了？

Stewart Butterfield一般默认规则是：如果你告诉我们，我们就不收费。但当时我们的做法是：“不用你来提，我们会自动、主动、预先，在不需要你任何输入的情况下……”

Lenny Rachitsky太慷慨了。

Stewart Butterfield“……直接把这笔 credit 打到你的账户里，并发条消息通知你已经处理好了。顺便说一句，就算某次故障并没有实际影响到你这个客户，我们也会按整体宕机情况统一给 credit。”

Lenny Rachitsky哇，真的是太慷慨了。你算是摸到自己那条边界了。

Stewart Butterfield对。

Lenny Rachitsky你刚刚让公司一起喊的那句口号是什么来着？我觉得这句话特别适合作为今天的结尾。

Stewart Butterfield那句话是：“从长远看，我们成功的衡量标准，是我们为客户创造了多少价值。”

Lenny Rachitsky太好了。我现在脑子里都能想象出 Slack 整个团队一起把这句话念出来的画面。

Stewart Butterfield那时候已经有几百号人了。整个场面有点像金正恩，或者斯大林那种感觉。

Lenny Rachitsky那就顺着这个气氛收尾吧。很多人不知道，其实你出生时的名字不叫 Stewart，而是 Dharma。

Stewart Butterfield对。

Lenny Rachitsky这么一说，很多事情 suddenly 都说得通了。

Stewart Butterfield对，我的全名其实是 Dharma Jeremy Butterfield，那是我爸妈给我取的。后来我 12 岁时把名字改了，因为我当时特别想显得正常一点，不知道为什么我觉得 Stewart 是个很普通的名字。顺便说一句，你现在知道了以后就会发现：除了《Stuart Little》那只老鼠之外，你在电影、小说、电视剧里看到的 Stewart，不是 loser，就是 asshole。显然在集体潜意识里，这其实是个很糟糕的名字。我当年真不该选它，我现在是后悔的。可等我意识到这一点时，《Dharma and Greg》又已经播出了，如果我这时候改回去，就会显得像在蹭热度。而且很多人会以为 Dharma 是女孩名，虽然在印度这显然是个男孩名字。

最后我再补一个小东西，前面忘了提，但我觉得它能把很多点串起来，叫 `owner's delusion`。这个名字源自我以前发在 Twitter 上的一段东西。后来给它起名的那个人把账号删了，所以我现在也不知道该把 credit 给谁。我当时发的大意是，放在十年前左右吧，那时候餐厅网站虽然现在已经好多了，而且后来 Google Local 基本把这类需求都接管了，但在当时，你去一家餐厅的网站，真正可能想找的东西其实就五样：地址、电话号码、菜单、营业时间……天，我差点忘了第五样，还有怎么订位。
当然，这个问题后来多少自己缓解了一些，至少有所改善。但那时你打开的往往是一个加载巨慢的大图，还带着那种 Ken Burns 式的慢慢推拉效果……

Lenny Rachitsky还会闪一下。

Stewart Butterfield对，然后再慢慢淡入，接着还开始播音乐。更离谱的是，就算它给了电话号码，也不能点。

Lenny Rachitsky因为是张图。

Stewart Butterfield对，甚至都不是可复制的文字，因为那根本就是一张图。营业时间也没有，地址也不放，或者别的重要信息也不放。你就会想：“这到底在干嘛？”最荒谬的是，做这个网站的人、以及那家餐厅老板自己，百分之百都曾经去过别家餐厅网站，只为了找地址、营业时间、电话之类的信息。那为什么最后他们自己的网站还是会做成这样？我们该怎么称呼这种现象？

然后有个回复我推文的人说：“这就叫 `owner's delusion` 吧。”我当时立刻就想，天啊，太准了。这个概念真的非常有解释力。它最后会导向的结果，就像 Apple 把某个功能命名成 `Sleep` 一样。这个词太难让人一眼明白它到底指什么了。也正因为这样，大家才会忘记：用户第一次来到你的网站时，他的意图其实只是刚刚越过采取行动所需的最低门槛，连多一点点都没有。
而你却像在说：“好，欢迎来到我的网站。”然后上来就是一堆废话、一堆不知所云的东西，按钮也让人看不懂，下一步该干什么完全不清楚。因为你觉得“我的东西太重要了”，却没意识到用户此刻也许正在上班、今天早上还迟到了、还想赶紧去上个厕所，他只是个生活里一堆事缠身的普通人。他也许还在担心自己孩子是不是出了什么问题，在学校又惹事了。用户不是那种买了票坐在台下、等着你大幕拉开的观众，他们是会在一秒钟之内就关掉页面走人的人。所以每个人都该时刻警惕 `owner's delusion`。

Lenny Rachitsky我太喜欢这个说法了。那解决办法是什么？找别人来看、给你反馈吗？

Stewart Butterfield对，首先是要能识别它。不幸的是，这类东西有点像墨菲定律。

Lenny Rachitsky对。

Stewart Butterfield哪怕你已经把墨菲定律考虑进去了，最后还是可能翻车。

Lenny Rachitsky没错。

Stewart Butterfield但如果你连它都没命名、没识别、没拿出来讨论，也没训练自己按这个方式思考，没有先停下来吸口气，假装自己只是个普通人，然后再重新看看这个东西到底讲不讲得通，那你基本就完了。

Lenny Rachitsky太喜欢了。我很高兴你把这个点也补进来了。我脑子里还有一大堆问题，等我们以后做第二期时我再继续问。Stewart，非常感谢你来，真的谢谢你。

Stewart Butterfield也谢谢你邀请我，Lenny。我聊得很开心。

Lenny Rachitsky我也是。大家拜拜，感谢收听。如果你觉得这一期有价值，可以在 Apple Podcasts、Spotify，或者你常用的播客 App 里订阅这个节目；也欢迎给我们打分、留评论，这会帮助更多人发现这档播客。你可以在 lennyspodcast.com 找到过往所有节目，也可以了解更多播客信息。我们下期见。