Lenny's Podcast: Product | Career | Growth - Slack founder: Mental models for building products people love ft. Stewart Butterfield
Episode Date: November 20, 2025Stewart Butterfield is the co-founder of Slack and Flickr, two of the most influential products in internet history. After selling Slack to Salesforce in one of tech’s biggest acquisitions, he’s b...een focused on family, philanthropy, and creative projects. In this rare podcast appearance, Stewart shares the product frameworks and leadership principles that most contributed to his success. From “utility curves” to “the owner’s delusion” to “hyper-realistic work-like activities,” his thoughts on craft, strategy, and leadership apply to anyone building products or leading teams.We discuss:1. Hyper-realistic work-like activities2. The owner’s delusion3. Utility curves4. “Don’t make me think”5. “We don’t sell saddles here”6. Tilting your umbrella7. When to pivot—Brought to you by:WorkOS—Modern identity platform for B2B SaaS, free up to 1 million MAUsMetronome—Monetization infrastructure for modern software companiesLovable—Build apps by simply chatting with AI—Transcript: https://www.lennysnewsletter.com/p/slack-founder-stewart-butterfield—My biggest takeaways (for paid newsletter subscribers): https://www.lennysnewsletter.com/i/178320649/my-biggest-takeaways-from-this-conversation—Where to find Stewart Butterfield:• X: https://x.com/stewart• LinkedIn: https://www.linkedin.com/in/butterfield—Where to find Lenny:• Newsletter: https://www.lennysnewsletter.com• X: https://twitter.com/lennysan• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/—In this episode, we cover:(00:00) Introduction to Stewart Butterfield(04:58) Stewart’s current life and reflections(06:44) Understanding utility curves(10:13) The concept of divine discontent(15:11) The importance of taste in product design(19:03) Tilting your umbrella(28:32) Balancing friction and comprehension(45:07) The value of constant dissatisfaction(47:06) Embracing continuous improvement(50:03) The complexity of making things work(54:27) Parkinson’s law and organizational growth(01:03:17) Hyper-realistic work-like activities(01:13:23) Advice on when to pivot(01:18:36) The importance of generosity in leadership(01:26:34) The owner’s delusion—Referenced:• Slack: https://slack.com• Flickr: https://www.flickr.com• Cal Henderson on LinkedIn: https://www.linkedin.com/in/iamcal• Blok: https://blok.so• Brandon Velestuk on LinkedIn: https://www.linkedin.com/in/brandon-velestuk-6018721b• Magic Link: https://en.wikipedia.org/wiki/Magic_Link• Ticketmaster: https://www.ticketmaster.com• John Collison on X: https://x.com/collision• Patrick Collison on X: https://x.com/patrickc• Sundar Pichai on LinkedIn: https://www.linkedin.com/in/sundarpichai• Three Questions with Slack’s CEO: https://www.technologyreview.com/2014/11/21/170330/three-questions-with-slacks-ceo• Six Sigma: https://www.6sigma.us• What is kaizen and how does Toyota use it?: https://mag.toyota.co.uk/kaizen-toyota-production-system• John Collison’s post on X about passion projects: https://x.com/collision/status/1529452415346302976• Parkinson’s law: https://www.economist.com/news/1955/11/19/parkinsons-law• We Don’t Sell Saddles Here: https://medium.com/@stewart/we-dont-sell-saddles-here-4c59524d650d• Glitch: https://en.wikipedia.org/wiki/Glitch_(video_game)• IRC: https://en.wikipedia.org/wiki/IRC• This will make you a better decision-maker | Annie Duke (author of “Thinking in Bets” and “Quit,” former pro poker player): https://www.lennysnewsletter.com/p/making-better-decisions-annie-duke• The woman behind Canva shares how she built a $42B company from nothing | Melanie Perkins: https://www.lennysnewsletter.com/p/the-making-of-canva• Prisoner’s dilemma: https://en.wikipedia.org/wiki/Prisoner%27s_dilemma• Stewart Little: https://en.wikipedia.org/wiki/Stuart_Little• Dharma and Greg: https://en.wikipedia.org/wiki/Dharma_%26_Greg• Stewart’s post on X referencing “the owner’s delusion”: https://x.com/stewart/status/1223286626991796224—Recommended books:• Principles: Life and Work: https://www.amazon.com/Principles-Life-Work-Ray-Dalio/dp/1501124021• Why Nothing Works: Who Killed Progress―and How to Bring It Back: https://www.amazon.com/Why-Nothing-Works-Killed-Progress_and/dp/154170021X• Positioning: The Battle for Your Mind: https://www.amazon.com/Positioning-Battle-Your-Al-Ries/dp/0071373586• Quit: The Power of Knowing When to Walk Away: https://www.amazon.com/Quit-Power-Knowing-When-Walk/dp/0593422996—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@lennyrachitsky.com.—Lenny may be an investor in the companies discussed. To hear more, visit www.lennysnewsletter.com
Transcript
Discussion (0)
This 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 it.
Slack was famous for being one of the early consumerized B2B SaaS products.
at more than one company all hands,
and 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.
Something else I heard that you often espouse
is friction in the product experience
is actually often a good thing.
It became an assumption that you should always be
trying to remove friction
when the challenge is really comprehension.
If your software kind of 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 our goal or reducing the number of flexor taps or 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?
You started two companies both famously pivoted.
I imagine many people come to you for advice on pivoting.
The decision is about, like, have you exhausted the possibilities?
Creating the distance so that you can make an intellectual, rational decision about it.
other than an emotional musician is essential.
And the reason I say you have to be coldly rational about it is because it's fucking humiliating.
Today, my guest is Stuart 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 the companies. He calls hyper-realistic 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 Caudill, Allie Rail, 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. If you enjoy this podcast, don't forget to subscribe.
and followed in your favorite podcasting app or YouTube.
It helps tremendously.
And if you become an annual subscriber of my newsletter,
you get 17 incredible products for free for an entire year,
including Devon, Lovable, Replit, Bolt, In-N-A-N-Ear superflued,
Gamer Perflexity, Warped, Granola, Magic Patterns,
Raycast, CHAPRD, and Mobbin.
Head on over to Lenny's newsletter.com and click Product Pass.
With that, and bring you Stuart Butterfield,
after a short word from our sponsors.
Here's a puzzle for you.
What do OpenAI, Cursor, Perplexity, Versal,
Platt, 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,
skim, Rback, 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 strike 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 super fast.
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.
This episode is brought to you by Metronome.
You just launched your new shiny AI product.
The new pricing page looks awesome.
But behind it, last minute glue code, messy spreadsheets,
and running ad hoc queries to figure out what to bill.
Customers get invoices they can't understand.
Engineers are chasing billing bugs.
Finance can't close the books.
With Metronome, you hand it all off to the real-time billing infrastructure
that just works.
reliable, flexible, and built to grow with you.
Metronome turns raw usage events into accurate invoices,
gives customers bills they actually understand,
and keeps every team in sync in real time.
Whether you're launching usage-based pricing,
managing enterprise contracts,
or rolling out new AI services,
Metronome does the heavy lifting
so that you can focus on your product, not your billing.
That's why some of the fastest growing companies in the world,
like OpenAI and Anthropic,
run their billing on Metronome.
Visit Metronome.
to learn more. That's metronome.com.
Stuart, thank you so much for being here and welcome to the podcast.
Thank you for having me. I'm excited.
I'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 to have on this podcast ever since I started
this podcast a few years ago. So I'm very excited. They'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 you're just chilling.
I'm mostly just chilling. I left Salesforce two and a half years ago, and I have a two and a half year old.
She was actually born three days after my last day, so a lot of time with family, and it's like 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, like basically like every three to six, six,
weeks. There's this cycle because Cal Henderson, who's the CTO up Slack and who also, we work
together on Flickr, so I've worked together now for 23 years. I've been talking about what we
want to do next if there is something. But you know, honestly, the big challenge has been
I think these things are kind of destroying the world. And what we're good at is making
software. So you can find some way to make software that helped people use their phone.
less often than 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 like some cool
projects I'm working on, and a lot of like just personal creative art projects and supporting
other artists and stuff like that. To prep for this chat, I talk to so many people that
have worked through the 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 are
most help them build amazing products. The first is a concept called utility curves. This came
of a bunch across so many people that have worked with you. Talk about what is the utility
curve, how you think use that to build better products. This is pretty easy because it's a very
familiar S curve where you know, 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 kind of 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 access,
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 kind of like 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 users table on 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 like
a feature. And usually features are thought of as binary, like you either have this feature or you
do. And so 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've had a point
of diminution returns. And it just doesn't matter. And I think in many cases, people will add a feature. It's not
good enough. And so people don't use it or appreciated. 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 is a thing we're doing.
And so we would try to really investigate and decide whether we were on the first chelot part
of the curve, the second chelot 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
on a specific feature, but I think it was ultimately helpful in getting people to, like,
understand whether something was worth it or not.
Okay, so just to mirror back what I'm hearing, there's kind of 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 like a really, it's 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, like 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 way, is that the framework?
Yeah, yeah. And I think then you layer on another concept like the basis, you use.
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 like 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, you know, forget about thinking about a new feature, you're looking at how the product
works overall.
And usually things get kind of 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.
And 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 tradeoffs 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 times, sometimes in Pacific,
sometimes in English time, and sometimes in Japan, Central Europe.
There's like maybe 10 time zones, 12 timesones 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 that's like, 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 an appointment for next week when I'm back in New York,
and I type in E-A-S-T, that I get a bunch of garbage.
Okay, East Urn, ERN, ERN.
And then the first one is Eastern Australia, New South Wales.
And then Eastern Australia,
Daylight Savings and Eastern Australia, Standard Time.
And then you're like, well, fuck, what, I can't remember which one is Daily
Savings and which one is standard time.
And, you know, I could keep going like this for a while.
This is an app that's used by at least hundreds and millions of people,
presumably every single Google employee.
It's bananas, how bad it is.
There's so many, like, 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.
There's a couple hundred times zones.
I grew up in Canada.
There's a Newfoundland has its own time zone, which is offset by half an hour.
The population of Newfoundland is about half a million people.
Not that many people go to visit Newfman, maybe.
a million people in all of history, so like a million and a half out of eight billion people.
And there's Newfoundland, you know, like the same with China time, which is like 25% of the
world's population in this time. Anyway, I, that was a little bit longer than I intended to go on
this example, but it is, 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. It 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 like really essential parts at the app. Again,
like account creation, sign up, forgot password, you know, 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.
Let'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.
What is taste?
I heard of 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?
There is a lot of,
going back to the utility curves again,
people who are obsessed with this one little thing
and, you know,
keep on adding more and more detail improvements
beyond the point where it makes much of a difference.
But I guess a couple 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 or, you know, 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...
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. And so you're probably familiar with the,
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 and actually made it part of the
new hire welcome. So I'm going, I'm in Vancouver at our Vancouver office and I'm going for a
walk with Brandon Velostock, 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
like really narrow sidewalks because it used to be a warehouse district. And now it's like,
you know, 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 kind of on these narrow sidewalks with people coming towards us with umbrellas.
And we noticed how few people would move their umbrella out of the way.
And of course, you know, the other person, their umbrella, the pokey bits are exactly
at eye level for people walking towards them.
And we would get like, you know, forced off the sidewalk or like 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.
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. What is,
they have very few avenues in their life to exercise power, and this is one of them, and they're
just like want to get out there and dominate people and cause suffering. So you shouldn't ascribe
to malice, that which can be ascribed to ignorance. So that's probably
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 is something I could do about that, but I can't think of anything.
And the last reason is they just don't notice at all.
They're just oblivious to their impact on other people.
and they're sew in their head.
And I can't really think of any other explanations for it besides that.
And so we would say, at Slack, 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 considerate and exercises courtesy and really be empathic
about other people's experience is an advantage.
You can create a critical advantage.
And I think that there's many reasons why Slack was successful at the moment.
It was successful.
And I 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 Stratub B doesn't use Slack yet.
And they would be like, oh, my God, you guys, this is.
This is so good. We've got to try it. And the spread was driven by that cross-pollination and people are really genuinely advocating for it.
That is an amazing metaphor. I love that one moment became like a value of product craftsmanship.
And so tilt your umbrella with business. It was a very common saying on company swag and stuff like that.
Is 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 it were really gorgeous success.
Here's a bunch of little examples.
So someone else came up with this idea, and I'm trying to remember who it was.
Maybe Andrea Torres, maybe Ben Brown, something like that,
who was like, why do 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,
say you capital H, lowercase Q, 6, correct, 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.
Wow, so you guys invented the magic link experience.
Someone else invented.
I want to be clear that.
I had seen that idea somewhere else, like 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 like 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, it 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 that at 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 like 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, well, personally, be like, I didn't get a notification.
This is bullshit.
So 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
with the threshold to what happened.
I think 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 recommended settings?
And then they would just click a link
and it would, you know, 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 hub.
a much more, well, here's, I'll get one, 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, in outlook that, like, you know, set the priority of a message for the recipients,
always got abused inside of every company. As soon as someone does it, like, 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's become useless. We have at everyone, which causes a,
notification to be sent to every member of the channel when the message is sent and people would
start, you know, someone would find this feature inside of an organization. They would at everyone.
Everyone would get a notification. And then the next person to send a message, it was like,
well, my thing is more important than Bob saying, I'm going to also at everyone. And it became
really obnoxious if people would complain about it. But it was a, I don't know, I guess tragedy of the
Commons is not quite exactly the same thing. But it was this real dynamic that happened over and over again.
And 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 at everyone, a little rooster would pop up and have like these 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 that at 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 use, we want us not to be very flexible.
But we knew that there was ways to use that that would be annoying and difficult for everyone.
And so trying to shape the communication culture inside the organization to take best advantage on it.
My feature still exists.
I see that.
I see that all.
Well, actually, I do at channel because I've run a big slack.
So I see that rooster.
So that survived.
Yeah.
Yeah, that survived and good.
because it was a trivially easy thing to implement and made a really big difference,
but also taught people how the product worked,
because people probably didn't know that at everyone or at Channel,
didn't think about the cost, at least.
Genius.
Yeah.
Here's one more.
So we decided we were going to do Do Not Distar as a future.
And we had this conundrum, but you're trying to take into account all the different uses of that.
Because at the time we implemented this, like 2017, there was, you know, tens of thousands of paying customers, the organizations, hundreds of 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, you know, some of the biggest
systems and apps in the world. And so we couldn't just like deploy it right away. We realized that
some of the decision makers, the owners of the organizations, we're 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 kind of 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 p.m. to 7 a.m. to 7 a.m. in their local time zone or 8 a.m. to 8 p.m. And I can remember
which was, but also that they could override that default. And also that,
that the individual end users could override that system owner default.
And finally, that the system owner could, if they change the default again, would override
all of the end users' 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 that people could still customize and stuff like that.
But this was, you know, 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. You know, look, there wasn't, if we didn't default you to do not disturb from
8 p.m. to 8 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 future for a lot of people.
And if we hadn't done it that way, I think it would have caused a lot of complaints and conflict and stuff like that.
Those are amazing examples.
I very much appreciate that.
I 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.
Yeah.
Something 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.
Yeah, well, so yes.
And there's also another issue around friction,
which is it became like a mantra
or just like a kind of an assumption
that you should always be trying to remove friction.
And in some cases, that's true.
You know, we would talk about in Slack, like, it was hard to market.
It was hard to explain what it was if you had never used to before.
You could say a messaging app for businesses or whatever.
But, you know, like 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 would have to be explained one day, but 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 day at this venue. And so in that scenario,
It doesn't really matter if ticket pester's website is slow.
It doesn't really matter if the payments page airs out.
You're going to persist and get through it.
So obviously, they're better to reduce friction,
but in some sense, it doesn't.
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.
Like, 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, like, the issue is my intent isn't always 100%, right?
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 like 100% intent.
I might have like very specific intent, but I may intents like 70%.
So if you're, the amount of friction is above that, I just, I'm not going to do it.
But now, okay, people coming to Slack.com, they had some,
A friend had mentioned Slack and kind of 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 a
website they were visiting, and they finally said, okay, I'm going to go to this website.
So their intent is, like, at the absolute minimum threshold.
Like, it's just, 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 it.
date of this venue is also very low because they're like, it's a work thing.
I'm not sure it's a spreadsheet or like a calendar or do you look exactly what it is.
So they were coming in at, you know, 0.1% over these critical thresholds.
What was the challenge?
It wasn't friction, right?
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 site up for them as quickly as possible.
But if they don't know what they're signing up for,
they don't know what it's going to do after,
is it going to spam them?
They don't know if they can have to pay on the next app
or what, then they're just going to back out.
And this was like a lifelong battle because the remove friction kind of 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.
It is a poor approach when the challenge is really a 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 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 and set of friction.
It really could be anything. Like Shopify, the purpose of the service for its end users
is generally going to be kind of 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 how they can, you know, 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 like the, I want to see if this is still true. I'm just not open my iPhone and the clock app.
And they had the most, the craziest description for alarms. Okay. It's still, it's a little bit
different. People can look at their own phone. And so I have.
It says alarms, and then 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, they 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 like 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, like, 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 like 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, like, biometrics in 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 is 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.
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. And if you remember that book. Absolutely. Yeah. And honestly,
it's been many more than 10 years since I read it. So I don't even remember all the examples
in the book. But as a mantra, that was like up there with utility curves. Because for two reasons.
One is it's just like it's expensive to make a decision. Like you literally burn glucose. Like there's a
metabolic action. There's like ATP created in the mitochondria and your neurons and like a bunch
of stuff is happening and people do get decision fatigue and there is like, you know, cognitive
cost of all these things. But also there's an emotional aspect, which is if you, if your software
kind of stops me a second and asks me to make a decision and I don't really understand it,
you make me feel stupid, right? I'm like, I don't understand this. Some people are, or,
you know, maybe their orientation is, okay, that the software.
is stupid. But I think most people are like, oh, I'm dumb. And if you ever talk to them who
aren't especially technologically savvy, you know, like the canonical example is like 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 always feel stupid. They're the ones that are that are wrong.
And so if you're causing people to think, in the best case, it's like unnecessary use of
their biological resources.
And in the worst case, you've now made them feel bad, like emotionally bad,
and they're going to associate that with the product forever.
And these are things are just kind of rolling one into the other.
So I'm 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.
Like, it's the easiest way, like, 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 of pages, right?
And obviously, that's terrible.
So why do people think that a little bit of that is good?
And here's an example.
Like, you open a menu, there's 14 things that people might want to do.
Okay, 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,
wherever, and then have some form of other.
And then you go to a sub menu that has more items.
And the decision of like 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 mean, interrupt myself again with a story.
It's, I met some conference or event
and Aramor wrote it was,
and this is probably eight years ago,
and we're in the bar
after the sessions ended at this thing,
and John Collison from Stripe is there,
and Sundar, CEO of Google, is there,
and John,
Patrick goes up to the Sundar,
And they can talk about anything, right?
Like, you know, strike wasn't the behemoth it was now at that point, but it's still like, you know, a significant company was up and humming.
And what does Patrick want to talk to this, who know about?
It's in the Gmail app, the dragging of people, like you, 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, like 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, like, you know, Patrick could have asked for anything.
It could have been any topic.
It could have been a partnership.
It was like it was so irritating to him that it worked like this.
They 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 and 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 that individual email.
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.
Talk about it is read all 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, say your location, if you'd be, 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 choose 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 then eight clicks or taps to do something,
but every single one is trivially easy, that's great. If it, you know, 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 like the more comparing three things to each other
is this difficult for things. It's kind of like geometrically more expensive to compare 15 different
options all to the other to see if this is the one that you might want. That, you know,
just becomes impossibly expensive. So to me, those are all really connected. And if people could
get over the idea of reducing friction as a number of goal or reducing the number of flexor taps
and do something and instead focus on how.
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 trivial easy?
One last example, because this was really influential for me.
So I was going back and forth in Vancouver and San Francisco at the time when we were talking
about all this inside of Slack.
And I was behind a teenager in lying aboard the plane.
And it was like, you know, we're on the jet way.
It took a long time.
And I was watching her use Snapchat.
And it was insane.
Like she was tapping at least four times a second, sometimes like 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 a dead,
do you want to see this again?
Do I want to see the next story
from this person, do I ask her to a different person?
Instead, she, a notification, she 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 were some breaks in there.
And that was like 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 cap less, you know, like how much of an
impediment it would have been to the experience that both her and Snapchat wanted to create.
It's so fun to listen to this and the examples you gave of, it gives us a lot of insight
to the way your mind works of just constantly unsatisfied with the way other products work.
with your product.
And I think that's core.
Like 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.
Yeah.
I love just even the way you summarize this,
just like 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 like
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. Yeah, I think in my more cynical
examples, I would say to people like, stop what you're doing for a second, close your eyes,
take a couple 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 in supposed to take
or what the impact will be
if you take that action,
there's a whole another related cycle.
But before I get into it,
because I know that I'm 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 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.
Like, 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 like and paste us.
it on the law.
But to me, that was like,
you should be embarrassed by it.
Like, it should be a perpetual desire to improve.
You should never be like, oh, this is great.
And you could be proud of individual pieces of work.
But in the abrogate, 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, you know,
almost nothing, you know,
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, like, continually improving as the goal.
And that could be like Six Sigma Toyota, Kaisen, like 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 Mike.
Ray Dalio.
Yeah, 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 like 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
you're trying to be critical because you're trying to make this
as great as it can possibly be
not always, not with every person,
but most of the time, with most people,
you can get them to the point where that, like,
really direct criticism is actually motivational.
It is like, you know, people are grateful to have, like,
the feedback, whether that's coming from their peers
inside the company or from end users or the product,
because you realize, oh, yeah, that is bad,
and we should fix it.
This episode is brought to you by Lovable.
Not only are they the fact.
fastest growing company in history.
I use it regularly and I could not recommend it more highly.
If you've ever had an idea for an app but didn't know where to start,
Lovable is for you.
Lovable lets you build working apps and websites by simply chatting with AI.
Then you can customize it at automations and deploy it to live domain.
It's perfect for marketers spinning up tools, product managers prototyping new ideas,
and founders launching their next business.
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.com.
This makes me think about a, 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.
You just share, share what you share there.
Yeah. 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 any of your, everyone listening to this can help me find this tweet storm 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. I think, I believe it was in response to someone claiming that Bitcoin is going to replace.
US dollars.
There's 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 H-OA, I don't remember all of the organizations, because
if 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 for 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, like, almost nothing works.
It's actually another call us, and in this case, John has a great encapsulation of this.
I'm sure you're familiar with it, like that it ends with the world is a museum of passion projects,
because for anything to get that at all requires, like, not just the resources and effort, you know, 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 doubt they're listening, but it's not like an amazingly written book.
I found it like 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 knowledge.
of vetoes that are available for any kind of course of action and how difficult 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 on the channel.
Just the, wow, weather is incredibly complex and chaotic and ecosystems and climatology.
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, like,
or present for my kids or whatever.
It's got to be somebody's fault.
Like, 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 turns out that it's someone's decision.
And because of them, it's bad.
So if we got rid of them or, you know, we're 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 organizations as well.
You know, I'll pause there.
I know kind of along those lines, you're a big believer in something called Parkinson's Law.
Yeah, 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 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 real.
a really long time. And so Parkinson actually starts off with his example of, like, you know,
writing and posting a letter. And I don't remember who he uses for the first example,
but someone is like, you know, 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 rule,
then it takes her a long time to write the letter. It takes her a long time to put it in the
envelope and then 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. He uses a bunch of examples. This is,
again, in 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, like,
any part of government, any part, like the relationship between the number of administrators,
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 kind of sad truth for anyone running a company is there are exceptions.
There's like certain types of engineers that are accepting 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 like 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 like, we would hire 27-year-old product managers in Slack who immediately want to hire
someone.
It's like, what the hell?
what would that person do?
And like, they articulate it this way, but essentially it's like, well, that person would do
the product management and then I would do strategy.
Classic.
It'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 that everything is complex.
And if you, maybe this is my Butterfield'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, you know, 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, no head of sales, no CFO, no G.C.
Is ever going to come back and say, like, oh, I 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 an almost overpowering impulse inside the organization that often leads to disasters or self.
And so there's a, I'll give one example from Slack's history.
And I, you know, I have tried in the past to disguise this example so that no one feels bad about it.
But fortunately, 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, replied 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 posted that thread,
will receive a notification that there's been more activity.
And so what?
So, like, you know, 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 like put the insertion point there,
select all, delete, and then start writing my message.
And it's, even if I wanted to at someone specifically,
I almost never wanted to start my sentence with at,
because it just made it hard to, you know,
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 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 eithered it.
So, okay, we release it, six months goes by, and suddenly the hat thing comes back.
And so I messaged someone around the team.
I said, hey, there's been a regression.
This is super weird.
I don't know what happened, but the app thing came back.
And we said, oh, no, this is some 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 like P95 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.
And it could 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.
I appreciate this was outside the bounds of certainty that they could have had.
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 were using to record all that.
You wrote queries to pull that.
You created charts based on that data.
You had meetings to discuss it.
And just like kind of unpacking all of the things that would have had to happen for this to come back.
And it's like, you know, thousands of person now.
kind of at a minimum, because any feature change at that scale of organization, it's involving
like a dozen people, engineering, QA, analytics, teams, product managers, user research,
and stuff like had 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
responding in the thread at the beginning of the message could possibly make that much of a
difference to the quality of Slack and the, how much utility it provides for people and all
that.
But you know that to like 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 that, you know, paste the 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, you know, guaranteed loser.
And I know that Farid 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 see
known, I mean both you know what it is and you know that it's valuable. And that 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.
like starting a business, open a bank account because like there's almost infinite genital
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 like creating a user's table and I'm like doing
salting passwords and like you're doing all the things that are kind of absolutely necessary
and everyone knows exactly what they are. And so that's like everyone's going to work and
wearing, they're like, right on. And like, I have 10 things to do. And every single one of them is like
something you know how to do. And it's like 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 got hired. Every product manager wants to hire junior product manager.
Every new person, you know, the first person you bring on 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 of risk compliance work, which probably, you know, 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 Gov Slack
version, which is going to require us to have a wholly separate physical infrastructure for the
hardware that runs the software, and also a whole different operations team, which has only U.S.
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, can be updating two
totally separate independent systems and 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, because they're still.
not because they're evil, but because they're like, I'm a product marketer and I want to, like,
be recognized for my work and my spouse has criticized me because they think, like, I should
have already got promoted in the last cycle, and I really got to demonstrate some wins here
and whatever it is. And so people are like calling meetings with their colleagues to preview
the depth that they're going to show in the big meeting to get feedback on whether they should, like,
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.
You know, our board members will do it.
Every exact will do it.
And the further you are from, like, having all of the contacts 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, you know, the result of that, I guess, is that if you are a leader, if you're a manager,
a director, an executive, the CEO, it's on you to ensure that there is sufficient supply
enough and non-valuble work to do. And there almost always is, but, you know, it's creating
the clarity around that, creating the alignment, making sure everyone understands it. That's what
they're supposed to be doing and then obviously doing it. Amazing. I could listen to Stuart Rans all day,
hyper-realistic work-like activities. We need to claim this. Unfortunately, it doesn't make a good
acronym. It's pretty ugly.
Okay. I don't even 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? Yeah. And that, what you just said probably isn't the best
way, because that sounds like they're, you know, you're chiding them and they're dumb when it's
actually your responsibility to make sure that there's, you know, sufficient clarity around
what the priorities are and, you know, explicitly say no to things.
up front and stuff like that, rather than
where Janians have like, hey, you guys are
much idiots wasting your time on this thing that doesn't matter.
Whose fault is it?
You know, it's the manager's fault.
It's the VP of whatever's fault.
It's the CX, whatever.
Ultimately, it's like, it's the leader of the organization
that has the responsibility to make sure
that there is sufficient, no, invaluable work to do.
And that's actually harder than it might appear.
Okay.
Before we run out of time, I want to touch on two.
other topics. One is, when people think of Stuart Butterfield, I think a lot of people think of
we don't sell saddles here, your legendary medium post that has just, I don't know, it's become a
historic piece of literature in the annals of product building and startups. I haven't heard people
ask you much about this recently. Let me just ask a couple questions. What was the reason you put that
out? What was the backstory on writing that memo? Why was it necessary? Well, 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.
What I think we were still eight people, maybe, I had most 10, but I think it was eight people.
It was before Slack launched even.
Yeah, before Slack launched, it was like when we were doing prior beta, and the point of it was to like to start to instill those ideas as early as possible and really create this alignment inside of that small team so that it could present.
process to survive as we grew and scaled.
And yeah, that was the idea.
And 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?
Yeah. And again, you know, comparing it to beer or cars,
Beares,
goes back to pre-civilization.
Cars were obviously, I didn't.
At some point, you had to convince people
why they would win a car instead of a horse.
For your new
AI-based recruiting tool
or your calendar app or whatever,
there's some reason why people,
you'd think that people should use yours
instead of the thing that they're using now,
which might be like a wholesale one-for-one replacement
or more often is like 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
and creating, you know, 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 net 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 meet Star Wars or it's Uber for pets or something like that
than to come up with like 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.
The reason I want to touch on it is I think still people can see.
to not listen to this advice and continue to overinvest 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 us here,
go horseback riding. Look at this incredible experience you can have, and then they decide,
oh, should I need to go buy a saddle to do that? Yeah. And 100% that aspect of it is not
original because I think that's something that marketers have done for a long time,
surely in the Marcom and advertising.
Like 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 where you're selling something on the motorcycle,
you're showing like the open road and freedom and the wind in your hair.
And if you're Lula Lemon,
you are obviously selling yoga pants,
but you're also selling like health and aspiration
and being the best version of yourself and, you know,
a bunch of other stuff.
So selling that, oh my God.
I forgot the classic version.
of it, you know, like...
There's the ship?
Yeah, instead of...
The screwdriver.
Oh, yeah, the nail.
Yeah, the nail.
Anyway.
Yeah, what is that one?
There's the...
Well, there's the one I think about is instead of trying to convince men to build a ship,
I'm still a yearning for the sea.
Yes, exactly.
It's something that goes back in history.
Okay, 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?
Yeah, I mean, I think it's partly an intuition.
Because, like, obviously the decision is about, like,
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-SLAC.
And I think Slack had an enormous advantage
in the fact that we were 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 on it.
We still had like $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 decided to abandon it.
But, you know, the default advice for anyone in anything is persevere.
It's like, you know, kitten hanging off the branch and the poster says, hang in there.
And, you know, I think there's an idea that you just like, and then there are so many
stories of like 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 they just, if you stick out, stick it with it long enough, you'll eventually be
successful. I think you have to really be coldly rational. And some of this shows up in the book,
thinking about some of it's in Annie Duke's second book, the title of which I'm forgetting right now,
but someone will know it. Yeah, she actually uses... Yeah, it was the last second I forget.
She actually uses glitch and Slack as an example of like a smart fold, basically.
Like, 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.
You know, like, we, I convinced so many, and you have to convince so many people to get a company out of the ground.
You have to go to investors.
You have to go to early employees and say, like, you should leave her other job and come work for this because, you know, here's the incredible future we're imagining.
You have to go to the press and you have to make all these promises and you have users and you feel like committed things to the users and you convince them to give up their time for this thing.
And so it's, 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 to admit like, okay, I was wrong.
This didn't.
This didn't work.
And it's humiliating.
It's painful.
it's like it's wrenching. It has a bad impact. You know, like there's, when we shut down glitch,
there's a lot of people who loved it and who spent 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
like disappeared. All these people and all these identities have been created. And obviously
people lost their jobs and people who had like moved their families to a different city in order
to take this job. Now we're going to have a job anymore. So pivots aren't something I take
lightly, and you shouldn't be, 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. You know, like if you're six months into something, you're just, 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
Pivot all the time.
But I think it is
creating the distance
so that you can make an
intellectual, rational
decision about it rather than
an emotional decision is essential.
I 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. Yeah, exhaust all the
good ideas. All the good ideas. All the
good ideas. All the realistic, yeah.
Yeah. The point you made about
just kind of persevering, I just had
Melanie Perkins, C of Canva in the podcast. They went through a hundred investors rejected her
before somebody finally decided to invest, and she just kept pushing.
Yeah. I think that's a slightly different example, right? Because she believed in the,
yeah, and she believed in the concept of the, in the product and like in the vision.
It was just trying to figure out the right articulation to get investors who and Labine, obviously,
very, very happy.
Extremely 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
about you and what they, what has stuck most with them is, 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 you, 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, that you cried real tears when you were laying people off, and then he spent an incredible
amount of time helping them find new jobs and extending their severance pay and just taking
it extremely seriously much more than I think most people feel like CEOs do.
So when I'll share that you paid 100% of employees health insurance to give them,
I haven't 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 the acquisition is very employee-friendly.
There's also just a bunch of, 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 didn't charge.
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 just you slipped release schedules because you just wanted to make features better and better for people.
And I'll end with this quote.
Stuart 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.
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 was this, is this like, 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 is just in this, just the way you are as a person?
I 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's also, 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 a way of 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 de facto at the first opportunity,
then your best bet
is to defect. And so, you know,
there is a game theoretic aspect,
usually in games that are much, much, much more complicated than the prisoner's dilemma.
I think another thing, you know, one thing we, I didn't touch on before, but to me was important
enough that had more than one company all hands, I made everyone in the company like 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 like maximizing at the wrong moment or taking advantage of a customer or anything like that, we definitely shouldn't do it.
because to me it was just like, I mean, I think it's literally true, but it's also like 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. Like you're able to attract a better class of employee. Like 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 there's no, like, especially in the long run, you can't, like, destroy
value for your customers and expect to be successful. You have to actually make their lives
better. And you can put effort into, like, pointing out to them and demonstrating that you have
created this value and stuff like that. But there's no substitute for actually having creating
it. And I think that is incredibly important. And that implies a real generosity, whether that's
negotiating terms with an enterprise deal or that's like policy decisions.
Sometimes, I'll say one time that it blew up in our face was our SLA was like for any downtime,
you get 100 times your money back, which was like, because from my perspective, it's like,
if we're down for two minutes, it doesn't, it's like pennies.
It doesn't really make any difference.
If we're down for like 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 adages we ever had.
I don't remember how long it was,
but it was like many hours.
But by the time we got that scale,
a hundred times the money back
for like the third of a day that we were down
was like $8 million or something like that,
which had to be,
It didn't cost us any money because we just gave it to people the former 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 have 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 there were all really important decisions that were helpful in us becoming successful.
Was that policy? It was automatic? Like you didn't even have to claim it? It was just automatically get this credit. And the default is you don't have to pay if you let us know. And this was we will automatically, like, proactively, preemptively, without any input from you.
Too generous. Apply this credit to your account and just like send you a message and 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.
Too generous. You found the edge of where you might want to be.
Yeah.
What was that mantra again that you had the company chant?
I think this is a really nice way to end it.
In the long run, the measure of our success would be the amount of value we create for customers.
Incredible. I'm just trying to picture the entire team at Slack.
There's hundreds of people. It felt very like Chinjolong or like Stalin or something like that.
Well, on that note, most people don't know this about you, but your actual name when you were born is not Stuart.
It was Dharma.
Yeah.
And this all makes sense as you've learned that.
Yeah.
It's like I had, my name is Dharma Jeremy Butterfield, so my parents named me.
And when I was 12, I changed it because I just like, 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, whatever, there's only the loser, Stuart and the asshole, Stuart.
It's like, 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 Darmah and Greg had already come out, it would have seemed like I was like, you know, bandwagon jumping, and people thought it was a girl's name even now 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.
It's true.
And it's called the owner's illusion.
And this is based on something that I posted on Twitter, the person who came up.
up with the name later deleted their account. And so I have no idea who it was of who to credit
for this. But what I had posted was, and this is a long time ago, when restaurant websites have
gotten better and it doesn't really matter because Google Local was taken over everything.
But this is like, let's say 10 years ago. There's five things you could possibly want when
you go to a restaurant's website. And is their street address, their phone number, the menu,
the hours of operation. Oh, my God, I don't know if I'm getting the fifth thing.
Oh, and making a reservation.
How to make your reservation.
And again, this problem has, like, to some extent, taking care of itself, or at least a brute.
But what you would get was, like, this super slow-loading photo, the Ken Burns effect as it got on and, like, RIA, and then, like, fading in.
And then some music starts playing.
And then if they show you the phone number, it's not a clickable edit-term image.
It's not even text that you can copy because it's, 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,
I don't know what?
For sure,
whoever made this website
for the restaurant owner
and the restaurant owner themselves
have definitely been in a 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 whoever replied to the tweet,
she said,
you should call it the owner's delusion.
And I said, 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 is like, it's too hard to understand what that can possibly
mean, and that's why, like, people anticipate, despite the fact that when they get to your website
for the first time, their intent is absolutely the minimum number of micropoints above the
threshold required from there actually take that action, you're like, all right, like, welcome to my
website. And there's, there's a bunch of, like, BS and there's a bunch of, like, 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 like, you're just like a regular human
being who has like stuff going on. You're concerned that your kids are fuck up and they
can't in trouble at school, stuff like that. They don't, they're not like subjects who paid
money to go to your play and are sitting in the audience and waiting for that curtain to go
up. They're like people who are going to bounce in a fraction in a second. And so everyone
shall always be conscious of the owner's solution. I love that. What's the solution? Is it,
have other people look at and give you feedback? Is it? Yeah. And like recognize it. And unfortunately,
it's one of those things like Murphy's Law, like even when you go wrong when you take into account
Murphy's Law. But if you don't name it and recognize it and discuss it and like train yourself
to think in that way that, you know, take a breath, pretend you're a regular person and then
look at this again and see if it makes sense. Then I love that. You're screwed. 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. Stuart, thank you so much for doing this. Thank you so much for being here.
Yeah, thank you for having me, Leine. I really enjoyed it.
Same 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 Lenny's Podcast.com.
See you in the next episode.
