O Slack dispensa apresentações, então vou direto ao assunto. Obrigado a Cal Henderson , Keith Adams e Ali Rayl por ajudar com isso.
Esta é uma edição do meu boletim informativo gratuito, Monolith . Escrevo sobre como as empresas de sucesso construíram seus produtos (e quebraram as regras) antes de terem um produto adequado ao mercado.
Breve história: o nascimento de Slack de uma empresa de videogame falida é a tradição de Valley neste momento. A narrativa comum, como acontece com todas as tradições, é sensacionalista.
Em 2009, os cofundadores Stewart Butterfield, Cal Henderson, Eric Costello e Serguei Mourachov começaram a construir um videogame que eles não conseguiram construir em 2002. Stewart e Cal em uma conferência em 2010: (transcrição):
Temos uma excelente chance de ser bem-sucedido porque já falhamos antes e as chances de falhar duas vezes na mesma coisa são muito baixas, sim, astronômicas. Em 2002, abrimos uma empresa chamada Ludicorp e estávamos tentando fazer um jogo chamado Game Neverending. A mesma coisa: um jogo multiplayer massivo baseado na web, exceto que era 2002. Muitas coisas eram diferentes. O principal deles era impossível arrecadar dinheiro para startups de Internet voltadas para o consumidor porque era pós-crash pontocom, pós 11 de setembro, WorldCom, Enron, você sabe, na verdade, um momento muito mais difícil para arrecadar dinheiro, então ficamos sem dinheiro quando estávamos no meio do processo de criação do jogo e tentamos fazer outra coisa, a tecnologia. Essa outra coisa era o Flickr. O Flickr foi comprado pelo Yahoo e passamos vários anos fazendo isso. Somos quatro da equipe do Flickr e começamos uma nova empresa, a Tiny Speck, e estamos fazendo o Glitch.
Com uma saída bem-sucedida e um ambiente diferente de captação de recursos, o dinheiro foi fácil: (transcrição):
Poderíamos levantar tanto dinheiro quanto quiséssemos. Então foi fácil. Nós nem fizemos um deck. Nós apenas dissemos “nós gostaríamos de algum dinheiro” e as pessoas nos deram dinheiro.
A equipe levantou $ 5 milhões da Accel em 2010 e outros $ 10 milhões da Accel e a16z em 2011. Glitch foi lançado em setembro de 2011. No final de 2012, estava claro que o jogo não iria funcionar. Eles fecharam o Glitch. Eles tinham $ 5 milhões sobrando e uma ferramenta de comunicação interna.
Desde o início, a equipe de Tiny Speck foi distribuída :
A equipe executiva de Tiny Speck estava baseada em diferentes cidades da América do Norte. Butterfield e Mourachov moravam em Vancouver, Henderson montou acampamento em San Francisco e Costello gerenciou o desenvolvimento de clientes na cidade de Nova York.
Para se comunicar com mais facilidade, eles construíram um sistema interno em torno do IRC: (transcrição):
Lentamente, desenvolvemos um sistema que foi a base de todas as formas de comunicação da empresa e foi realmente benéfico e percebemos, hein, nenhum de nós vai trabalhar sem algo assim nunca mais e outras equipes de 8 desenvolvedores de software provavelmente também gostariam . Então decidimos que era isso que iríamos fazer.
Os dois anos seguintes foram um foguete:
O Slack abriu o capital em 2019 com uma avaliação de US$ 15,7 bilhões.
A versão interna inicial do Slack era apenas um invólucro do IRC: o Internet Relay Chat (IRC) é um protocolo do final dos anos 80. A equipe do Tiny Speck usou o IRC, mas tinha algumas falhas importantes. O protocolo não suportava mensagens persistentes, pesquisa ou uploads de arquivos, então a equipe criou os recursos necessários em torno de um servidor IRC pronto para uso. De Stewart: (transcrição):
Havíamos desenvolvido um sistema que era o proto-Slack. Mais uma vez, em 1992, uma das ferramentas de rede que usei foi o IRC ou o Internet Relay Chat. Usamos o IRC no Tiny Speck, e é uma tecnologia muito antiga.
Com a maioria dos sistemas de mensagens, existe um conceito de armazenar e encaminhar. Se eu quiser enviar uma mensagem para você, mas não houver conexão com seu cliente, ela será retida e encaminhada para você na próxima vez que você se conectar. O IRC não tinha isso. Se você não estivesse conectado no momento em que enviei a mensagem, você simplesmente nunca a receberia. Então construímos um sistema para registrar as mensagens. Mas assim que tivéssemos as mensagens em um banco de dados, queríamos poder pesquisá-las. Então construímos a pesquisa. E então, pouco a pouco, recurso por recurso, construímos coisas para integrar com nosso servidor de arquivos para que, quando alguém carregasse um arquivo, ele fosse anunciado no IRC ou se um alerta disparasse no datacenter, ele seria colocado no IRC.
À medida que a equipe desenvolvia o Glitch, eles enviavam periodicamente um recurso extremamente necessário para aprimorar o IRC. Novamente de Stewart: (transcrição):
Quando havia uma oportunidade que era tão óbvia que não podíamos deixar de aproveitá-la, gastávamos o mínimo de minutos nisso e depois voltávamos a ela (desenvolvendo o Glitch). No final desse processo tínhamos esse produto totalmente desenhado que estávamos usando que era uma péssima implementação, não o que você faria se começasse do zero, mas era óbvio que isso era algo que tinha um valor enorme.
Quando a equipe mudou no final de 2012, eles continuaram a usar a versão interna do IRC por dois meses enquanto criavam o Slack do zero. Eles se mudaram assim que o produto estava pronto para ser usado internamente.
O MVP teve problemas de UX para equipes maiores que ~ 10: No começo, eles “imploraram e persuadiram” seus amigos de outras empresas a experimentá-lo e dar feedback. Eles começaram com seis a dez empresas. A Rdio é a maior com cerca de 120 funcionários. Ficou imediatamente claro que o produto funcionava de maneira muito diferente para equipes maiores do que a do Slack.
De Cal: (transcrição):
Aqueles primeiros dias sendo usado por outras pessoas foram um período de imenso e rico feedback. Havia tantas coisas nas quais não tínhamos pensado porque estávamos tão familiarizados com a maneira como estávamos trabalhando, mas também coisas realmente idiotas. Se você tivesse duas pessoas em sua empresa chamadas “Matt”, não havia como eliminar a ambiguidade entre elas, ou se você tivesse 20 pessoas em sua equipe, não havia listas rolantes porque éramos uma equipe de 8 pessoas.
A equipe do Slack incorporou esse feedback ao produto, integrou mais equipes e continuou a incorporá-lo ao produto. Esse ciclo iterativo de produto é algo que eles aprenderam com o Flickr.
Novamente de Cal: (transcrição):
Uma lição óbvia que tiramos do Flickr foi quando você olha para grandes produtos de software, os que são ótimos não começaram assim. Eles começaram de uma maneira muito diferente, o produto foi apresentado de maneira muito diferente, os usuários interagiram de maneiras diferentes e a equipe às vezes iterava massivamente para chegar onde está hoje. É tudo sobre esse ciclo de feedback para entender o que seus clientes estão fazendo, os problemas que estão tendo, o que estão tentando alcançar e colocar isso de volta no design do seu software e iterar em direção a um produto que pode ser ótimo e que as pessoas possam amar .
A arquitetura do Slack lembra a de um jogo online: os clientes do Slack armazenavam tudo em cache. Na inicialização, eles fariam uma única solicitação de API, chamada rtm start. Isso faria o download de tudo sobre o espaço de trabalho de um usuário, incluindo canais, membros e membros do canal. O cliente então abriria uma conexão WebSocket para enviar e receber atualizações para o cache local.
De Keith Adams, arquiteto-chefe do Slack de 2016 a 2020, falando sobre como a mídia gosta de contar a história do pivô do Slack a partir de um jogo online: (transcrição):
Normalmente as pessoas mencionam isso como uma coisa engraçada: “oh, eles eram uma empresa de jogos, não é engraçado como os biscoitos às vezes se desintegram?”. Isso é verdade, mas na verdade volta de certas maneiras. Se você apertar os olhos e inclinar a cabeça, a arquitetura real do Slack se assemelha à arquitetura de um jogo on-line massivamente multiplayer. Você meio que tem seu “mundo” em que opera, que é sua equipe, e para fazer esse mundo parecer persistente e interativamente mutável com outras coisas no mundo, você acaba fazendo um cache bem grosso do que está acontecendo esse mundo e, em seguida, você tem uma maneira de obter atualizações de baixa latência para as mudanças nesse mundo. Esse tipo de paradigma mental de “oh, é como um jogo online” explica muito sobre o Slack. É por isso que temos telas de carregamento, por exemplo. É a mesma razão pela qual os videogames tendem a ter telas de carregamento.
O Slack foi criado para resolver seu próprio problema. Semelhante ao Nomad List , a versão inicial do produto surgiu de uma necessidade genuína do(s) criador(es).
Coisas simples podem fornecer um valor imenso. O Slack era simplesmente uma extensão de um protocolo aberto, mas fornecia imenso valor para os usuários certos. Este é outro caso em que não houve inovação técnica necessária para criar algo extremamente valioso.
Não é apenas coincidência que o Slack nasceu de uma empresa de jogos. Isso é relevante além da arquitetura técnica. Slack não parece trabalho. É uma das razões pelas quais as pessoas adoram. A MetaLab projetou grande parte da IU inicial do Slack. Do fundador da MetaLab, Andrew Wilkinson :
Para chamar a atenção em um mercado lotado, precisávamos encontrar uma maneira de chamar a atenção das pessoas. A maioria dos softwares corporativos se parece com um terno barato de baile dos anos 70 - azuis e cinzas suaves em todos os lugares - então, começando com o logotipo, fizemos o Slack parecer como se um canhão de confete tivesse explodido. Azul elétrico, amarelo, roxo e verde por toda parte. Demos a ele o esquema de cores de um videogame, não um produto de colaboração empresarial.
Publicado também aqui .