Silicon Slopes Tech Summit Speaker Digest — Stewart Butterfield
Last week Silicon Slopes put on a kick-ass, 2-day Tech Summit that I (and 14k other people) attended in Salt Lake City. I was blown away by the polish and programming of this conference, which is only in its 2nd year (last year had 5k attendees) and only cost me $100 to attend, which, for a guy bootstrapping a fund, was a very nice.I decided to write a five part series covering sessions from the following:
I remember reading a memo from Stewart to his team four years ago at 5 am in my kitchen. At the time, I was a first-time CEO with a new product in a new (to me) market; in other words, I was in over my head.Stewart was a CEO with a $100M exit already under his belt (Flickr), enviable backing from top tier VC’s in Silicon Valley and a clarity and confidence in conveying his vision to his team that was simultaneously inspiring and disheartening (because I couldn’t see myself having the same conviction). Try this excerpt on for size:
“How Do We Do It? We do it really, really fucking good.“
Taken in isolation that snippet screams hubris and bravado, but when contextualized it conveys urgency and Stewart’s belief in the need to deliver an exceptional experience to a market that does not yet know it needs his offering.Coming into Stewart’s session, I expected a brash, hyperbolic Silicon Valley CEO on stage. What I encountered (and welcomed) was a thoughtful, deep thinker who has: 1) a lot of questions, 2) a long-held interest in human-technology interaction and 3) a vision for how he wants to impact the future of work.
Session Notes:
On Creativity:
Have Constraints.
Stewart talked about the benefit of having constraints when creating. It’s a lot harder to create without constraints. He referenced 2-ink design challenges, 48-hour filmmaking challenges and the constraints inherent in poetry (meter, verse form) and music (key, scale) as examples. It’s something I have not really thought about beyond the blue ocean challenge and fallacy of choice when whittling down a market opportunity / idea set. Stewart’s thinking here interested me, and I like his examples from different art forms.
On Product Design (UX):
“Owner’s Delusion” as the antithesis of customer-centric design.
Stewart gave the example of visiting a restaurant’s website and being greeted by scrolling imagery, auto-play music and other experience-seeming UI elements when all you really want is the menu and contact information so you can order some damn food.He raised the question of why is this the case? He believes it’s pretty universal that restaurant website visitors just want to be able to conjure up an order and then order it. And given that restaurant owners are themselves consumers of other restaurants and probably go to other restaurants’ websites to place orders, shouldn’t they just be providing what would they would want as a customer? The problem is they’re thinking as an owner, not a customer and therein lies their delusion and ultimately non customer-centric design tendencies.
Principal-Agent Problem in Enterprise Software.
The principal-agent problem occurs when one person or entity (the “agent”) is able to make decisions on behalf of, or that impact, another person or entity: the “principal” (thanks Wikipedia).Stewart postulates that this problem exists in enterprise software due to the fact that the purchaser of the software is not the end user. Ever heard of procurement? Given that the purchasers are not the end users, the best UX does not necessarily win. Hence, the shittiness of so much enterprise software employees foisted upon poor end users. Stewart learned this problem first-hand after he sold Flickr to Yahoo! And was forced to interact with a panoply of various terribly designed, internal systems (think payroll, benefits systems).
Dogfooding FTW.
In addition to a principal-agent problem, enterprise software generally suffers from the fact that the engineers building a lot of enterprise software never really end up using the software as a true consumer of the product. The product suffers as a direct result as it does not have a built in user base capable of recognizing and addressing its problems. Stewart used the example of engineers building payment gateways and the Hawaii missile defense system.Now, compare this to Slack, which Stewart admits is an edge case in terms of being able to dog food its own product. Slack engineers use the product, so that benefits the product on an ongoing basis in terms of being able to move it forward rapidly.
On Risk Taking:
Getting People to Take Risk.
Stewart talked about how as Slack continues to grow as an organization with more and more people, it as at risk of taking less risk and thereby being less innovative (basically innovator’s dilemma).Risk tolerance decreases with more people on board because you now have a lot of people who perceive the personal stakes of failure to be too high to warrant taking the risk.If they fail in a risky endeavor, they make lose the esteem of their peers or get a negative performance review. But, if they play it safe (“nobody ever got fired for choosing IBM”), they can carry on as solid contributors. Given that, they will tend to take better odds of success over higher potential returns with associated higher potential for failure.Stewart wants to combat this. “Most stuff will be wrong” he says and that’s ok. It doesn’t mean we shouldn’t all be trying stuff.
Viewing Risk Like a Video Game.
Stewart is a failed video game designer. Slack was a pivot from a supposed-to-be video game company that was running out of its $16mm in venture capital from Andresseen Horowitz.He may suck at designing video games, but he provided a great analogy for taking risks and failing to to playing a video game. It goes like this…When you play a video game, you try things and you die. Then you try more things, then you die. Then you try some other things, then you die. See a pattern? Well, eventually you win, which feels good.What you don’t do is try to rationalize your deaths, which are failures. You don’t feel ashamed about it. You just keep on going and playingthe game.This is not the case professionally. We rationalize, we avoid talking about it, we are embarrassed by failure. We should change this.
Book Suggestion.
Stewart referenced “Thinking Fast and Slow”. I don’t recall the context, but best believe, I’ve thrown it onto my Goodreads want to read shelf.
On Messaging:
Woe is Stewart 😉
It’s refreshing to hear the CEO of a $100M revenue company say that he feels that he can’t effectively explain the experience/benefit of his product. If one can get to $100M without being able to do so, he/she must be providing a product that’s pretty good at explaining itself. After all, the best marketing is a product that sells itself.Stewart said that for 90% of people that end up using Slack, their introduction to the product will be annoying because they’re not the initial adopter. These are people that see Slack as just another tool that has been forced upon them. It’s not immediately viewed as some Godsend problem solver. They’ve got real work to do, and a messaging app is not going to get it done for them.Slack is actively working to figure out how to talk about their product and its benefits. They’re not sitting around huddled around a conference table with post it notes. They’re out in market with their customers trying to figure it out via user interviews.
Vision
Stewart wrapped his session with a vision for what Slack is trying to accomplish. He compared giving a knowledge work Slack to that of giving a ditch digger a backhoe when previously he was using a shovel. He envisions the future version of his product (of course with AI) not taking that knowledge workers job but instead making it easier, more productive and more enjoyable. That makes sense when you think of working with a backhoe as compared to a shovel.That’s it for my Stewart digest. Looking forward to seeing him speak again in a couple weeks at SaaStr, thanks Jason M. Lemkin. Next up, Omar Johnson, Former CMO @ Beats by Dre.Claps/subscribes/share appreciated if you appreciated. Thanks, BrianSlackbot Image Source: https://brandfolder.com/slack
Other Commentary
By Brian Parks
January 23, 2018
Silicon Slopes Tech Summit Speaker Digest — Stewart Butterfield
Last week Silicon Slopes put on a kick-ass, 2-day Tech Summit that I (and 14k other people) attended in Salt Lake City. I was blown away by the polish and programming of this conference, which is only in its 2nd year (last year had 5k attendees) and only cost me $100 to attend, which, for a guy bootstrapping a fund, was a very nice.I decided to write a five part series covering sessions from the following:
Digest 1: Stewart Butterfield, CEO Slack
Primer:
I remember reading a memo from Stewart to his team four years ago at 5 am in my kitchen. At the time, I was a first-time CEO with a new product in a new (to me) market; in other words, I was in over my head.Stewart was a CEO with a $100M exit already under his belt (Flickr), enviable backing from top tier VC’s in Silicon Valley and a clarity and confidence in conveying his vision to his team that was simultaneously inspiring and disheartening (because I couldn’t see myself having the same conviction). Try this excerpt on for size:
Taken in isolation that snippet screams hubris and bravado, but when contextualized it conveys urgency and Stewart’s belief in the need to deliver an exceptional experience to a market that does not yet know it needs his offering.Coming into Stewart’s session, I expected a brash, hyperbolic Silicon Valley CEO on stage. What I encountered (and welcomed) was a thoughtful, deep thinker who has: 1) a lot of questions, 2) a long-held interest in human-technology interaction and 3) a vision for how he wants to impact the future of work.
Session Notes:
On Creativity:
Have Constraints.
Stewart talked about the benefit of having constraints when creating. It’s a lot harder to create without constraints. He referenced 2-ink design challenges, 48-hour filmmaking challenges and the constraints inherent in poetry (meter, verse form) and music (key, scale) as examples. It’s something I have not really thought about beyond the blue ocean challenge and fallacy of choice when whittling down a market opportunity / idea set. Stewart’s thinking here interested me, and I like his examples from different art forms.
On Product Design (UX):
“Owner’s Delusion” as the antithesis of customer-centric design.
Stewart gave the example of visiting a restaurant’s website and being greeted by scrolling imagery, auto-play music and other experience-seeming UI elements when all you really want is the menu and contact information so you can order some damn food.He raised the question of why is this the case? He believes it’s pretty universal that restaurant website visitors just want to be able to conjure up an order and then order it. And given that restaurant owners are themselves consumers of other restaurants and probably go to other restaurants’ websites to place orders, shouldn’t they just be providing what would they would want as a customer? The problem is they’re thinking as an owner, not a customer and therein lies their delusion and ultimately non customer-centric design tendencies.
Principal-Agent Problem in Enterprise Software.
The principal-agent problem occurs when one person or entity (the “agent”) is able to make decisions on behalf of, or that impact, another person or entity: the “principal” (thanks Wikipedia).Stewart postulates that this problem exists in enterprise software due to the fact that the purchaser of the software is not the end user. Ever heard of procurement? Given that the purchasers are not the end users, the best UX does not necessarily win. Hence, the shittiness of so much enterprise software employees foisted upon poor end users. Stewart learned this problem first-hand after he sold Flickr to Yahoo! And was forced to interact with a panoply of various terribly designed, internal systems (think payroll, benefits systems).
Dogfooding FTW.
In addition to a principal-agent problem, enterprise software generally suffers from the fact that the engineers building a lot of enterprise software never really end up using the software as a true consumer of the product. The product suffers as a direct result as it does not have a built in user base capable of recognizing and addressing its problems. Stewart used the example of engineers building payment gateways and the Hawaii missile defense system.Now, compare this to Slack, which Stewart admits is an edge case in terms of being able to dog food its own product. Slack engineers use the product, so that benefits the product on an ongoing basis in terms of being able to move it forward rapidly.
On Risk Taking:
Getting People to Take Risk.
Stewart talked about how as Slack continues to grow as an organization with more and more people, it as at risk of taking less risk and thereby being less innovative (basically innovator’s dilemma).Risk tolerance decreases with more people on board because you now have a lot of people who perceive the personal stakes of failure to be too high to warrant taking the risk.If they fail in a risky endeavor, they make lose the esteem of their peers or get a negative performance review. But, if they play it safe (“nobody ever got fired for choosing IBM”), they can carry on as solid contributors. Given that, they will tend to take better odds of success over higher potential returns with associated higher potential for failure.Stewart wants to combat this. “Most stuff will be wrong” he says and that’s ok. It doesn’t mean we shouldn’t all be trying stuff.
Viewing Risk Like a Video Game.
Stewart is a failed video game designer. Slack was a pivot from a supposed-to-be video game company that was running out of its $16mm in venture capital from Andresseen Horowitz.He may suck at designing video games, but he provided a great analogy for taking risks and failing to to playing a video game. It goes like this…When you play a video game, you try things and you die. Then you try more things, then you die. Then you try some other things, then you die. See a pattern? Well, eventually you win, which feels good.What you don’t do is try to rationalize your deaths, which are failures. You don’t feel ashamed about it. You just keep on going and playing the game.This is not the case professionally. We rationalize, we avoid talking about it, we are embarrassed by failure. We should change this.
Book Suggestion.
Stewart referenced “Thinking Fast and Slow”. I don’t recall the context, but best believe, I’ve thrown it onto my Goodreads want to read shelf.
On Messaging:
Woe is Stewart 😉
It’s refreshing to hear the CEO of a $100M revenue company say that he feels that he can’t effectively explain the experience/benefit of his product. If one can get to $100M without being able to do so, he/she must be providing a product that’s pretty good at explaining itself. After all, the best marketing is a product that sells itself.Stewart said that for 90% of people that end up using Slack, their introduction to the product will be annoying because they’re not the initial adopter. These are people that see Slack as just another tool that has been forced upon them. It’s not immediately viewed as some Godsend problem solver. They’ve got real work to do, and a messaging app is not going to get it done for them.Slack is actively working to figure out how to talk about their product and its benefits. They’re not sitting around huddled around a conference table with post it notes. They’re out in market with their customers trying to figure it out via user interviews.
Vision
Stewart wrapped his session with a vision for what Slack is trying to accomplish. He compared giving a knowledge work Slack to that of giving a ditch digger a backhoe when previously he was using a shovel. He envisions the future version of his product (of course with AI) not taking that knowledge workers job but instead making it easier, more productive and more enjoyable. That makes sense when you think of working with a backhoe as compared to a shovel.That’s it for my Stewart digest. Looking forward to seeing him speak again in a couple weeks at SaaStr, thanks Jason M. Lemkin. Next up, Omar Johnson, Former CMO @ Beats by Dre.Claps/subscribes/share appreciated if you appreciated. Thanks, BrianSlackbot Image Source: https://brandfolder.com/slack
Share on:
Recent posts
Capital Provider Market Sentiment Survey
The Importance of Strong Revenue Health
SaaS Distilled Pt. 5: What is ARR?
Zonos: From Bootstrapped in the Basement to Solving…
Bigfoot Capital Announces Summer 2021 Investment Activity
SaaS Distilled Pt. 4: Understanding SaaS Quick Ratio
Programming School
Featured posts