James Smith

Esta semana converso com James Smith de BugSnag, onde eles fazem monitoramento de erros de aplicação. Conversamos sobre quebrar computadores quando criança, usar código aberto como uma forma de obter tração inicial, marketing para desenvolvedores, o papel dos dados na tomada de decisões e muito mais. Esperamos que você goste!

Josh Pigford: Vamos começar porque gosto de conhecer a história completa, onde os fundadores estiveram, como chegaram até aqui, então vamos começar por aí. Você trabalhou em muitas empresas diferentes e projetos de código aberto ao longo dos anos e mais recentemente, antes do Bug Snag, você foi o CTO na Heyzap.

Então estou curioso, como você começou com computadores e tecnologia?

James: Sim, com certeza, bem, isso é voltar bem longe. É uma boa pergunta.

Acho que meu pai me deu, eu me lembro, um Natal, meus pais me deram um computador. Acho que era um IBM SX25 486 SX25 e basicamente eles o pegaram para nós com alguns jogos. Acho que tínhamos Lemmings lá e um jogo chamado Micro Machines se você já jogou.

Josh: Clássicos.

James: Lá atrás quando eu era criança. São jogos clássicos, e isso me introduziu aos computadores em primeiro lugar, e então eu quebrei, desmontei e montei de novo e descobri essa coisa chamada BASIC naquela época e pensei, espera, eu posso fazer esse computador fazer coisas, para o horror do meu pai. E tenho certeza de que você ouve essa história com muitos fundadores no início, como você começou a construir coisas.

Bem, você começa a construir coisas quebrando coisas primeiro.

Josh: Com certeza.

James: Então peguei esse computador, quebrei, irritei meu irmão porque ele queria apenas jogar Micro Machines nesse computador. E depois, lembro, tive muita sorte por ser de Londres e tínhamos internet a cabo muito cedo. E tivemos internet acho que em '96, o que é uma eternidade atrás agora.

Josh: Uau, sim.

James: E então naquela época lembro, acho que a razão principal pela qual comecei a construir produtos em vez de apenas quebrar coisas e desmontar foi porque meu amigo e eu costumávamos jogar esse jogo, Duke Nukem 3-D se você já jogou antes.

Josh: Veio grátis no seu computador ou algo assim? Ou era alguma versão grátis ou você tinha…

James: Eu tinha a versão Shareware, que era como o primeiro pacote ou o que fosse.

Josh: Sim, sim, certo.

James: Joguei aquilo até a morte, era um jogo ótimo.

Mas sim, descobrimos que você podia, naquela época estávamos jogando via modem, o que realmente me envelhece agora acho. Você tinha que ligar para o computador de outra pessoa em vez de ir via TCP/IP pela internet como é agora. Você tinha que ligar para a linha telefônica de outra pessoa e então os modems conversariam um com o outro.

O jogador IPX, acho que é chamado assim no Duke Nukem e pensei, isso é ruim, queremos estar na internet e jogar esse tipo de coisa. Então encontramos essa ferramenta que passa o material IPX via TCP/IP e aí pensei, por que ninguém sabe disso?

Então fizemos um pequeno site, era tipo, ei, se você quer jogar Duke Nukem na internet em vez de ter que ligar para o modem do seu amigo aqui está como você usa. E muitas pessoas, isso era apenas uma ferramenta que outra pessoa construiu, era uma ferramenta gratuita, e muitas pessoas vieram para este site e disseram, uau, isso é loucura, as pessoas gostam disso. E então pensei, não seria legal se você pudesse ter um ranking? Não seria legal se você pudesse ter uma classificação de quem está ganhando mais jogos de Duke Nukem e eu não sabia como fazer isso, eu apenas sabia HTML naquela época, um pouco de BASIC, e pensei não seria legal se eu pudesse fazer essa página da web atualizar dinamicamente?

E novamente, tenho certeza de que você ouve isso de muitos fundadores com quem conversa, mas foi meio que o que me fez começar a construir produto. Pensei, quero ser capaz de atualizar o que estava neste site dinamicamente baseado no que as pessoas estão inserindo. É simples, acho que era em Perl naquela época. E pensei, oh, certo, não foi tão difícil. E uma vez que você ultrapassa esse penhasco, tenho certeza que você tem a mesma reação. Uma vez que você ultrapassa o penhasco de, uau, posso controlar isso, posso mudar isso, isso é algo que construí, desbloqueia em sua mente, bem, provavelmente posso construir muitas coisas agora. Isso abre as possibilidades.

Josh: Há um efeito de bola de neve aí.

James: Exatamente, sim, é positivo, é emocionante. Então pegamos essa experiência e continuamos construindo desde então, e sim, você mencionou Heyzap, que é, você provavelmente adivinhou pelo meu sotaque que não sou, minha empresa está na Baía, mas não sou da Baía.

Heyzap é a empresa que me levou a San Francisco, antes disso fiz um curso de Matemática e Ciência da Computação em uma faculdade chamada Bath University no Reino Unido na costa oeste da Inglaterra. Que é onde conheci meu cofundador na verdade para Bug Zap. E depois fiz esse caminho padrão de entrar em finanças e trabalhei para Bloomberg em Londres construindo plataformas de negociação.

E tenho muito respeito por essa empresa, aprendi muito lá, também tinha uma atitude bastante empreendedora naquela empresa, mas ainda estava trabalhando em finanças, e finanças é, sem desrespeitar ninguém que trabalha em finanças, mas não era para mim, era uma indústria bastante deprimente para se trabalhar.

Um par de velhos amigos meus entraram no programa Y Combinator. Isso foi em, acho, inverno de 2008, dezembro de 2008, e estavam construindo, na época, acho que era um widget incorporável para jogar jogos flash em qualquer site. A ideia era, e isso realmente data essa empresa também agora, porque flash é completamente inexistente nos dias de hoje.

Josh: Claro.

James: Mas a ideia era que se você fosse uma publicação como New York Times ou em algum lugar onde tivesse conteúdo e quisesse aumentar o engajamento, então a ideia era que você pudesse incorporar um widget de jogos flash na parte inferior da sua página para aumentar o tempo no site, e então vim, entrei na empresa como primeiro funcionário saído da, apenas formado da classe Y Combinator, e acabei transformando em uma empresa de tamanho decente, mudei o foco cerca de duas ou três vezes, como startups tendem a fazer, mas sim, foi o que realmente me deu o gosto pela vida startup.

Sempre fui construtor, sempre construí coisas na minha vida, mas pensei, bem na verdade e quanto a construir coisas para um bem maior? E quanto a construir coisas para melhorar a sociedade ou construir coisas para ganhar dinheiro também.

Josh: Com certeza, com certeza.

James: Em um nível fundamental, então sim, foi isso que me trouxe para cá.

Josh: Então como você, então Heyzap, foi, então você mencionou a coisa de jogos flash. Se eu me lembro bem, costumava fazer um monte de design, trabalhos de consultoria, fui para a faculdade para design, e tenho 87% de certeza que quase aceitei um trabalho na Heyzap fazendo design de interface, então…

James: Sabe de quê? Vou ter que procurar em minha caixa de entrada de email agora. Que mundo pequeno, isso é loucura.

Josh: Isso seria 2000 e, oh não sei, 9 ou 10 ou algo assim? Talvez um pouco mais recente que isso.

James: Heyzap bem cedo então. Isso é loucura.

Josh: Sim. Então sim, que mundo pequeno.

Então voltando aos primeiros dias em que você estava quebrando seus computadores. Seus pais apoiavam o fato de você desmontar as coisas e montar de novo e descobrir como as coisas funcionam, ou eles ficavam meio chateados com isso, ou…

James: Sim, meus, acho que eles eram, eu não diria apoiadores. Acho que tolerante é provavelmente uma palavra melhor.

Lembro que meu pai ficou muito estressado em um ponto. Alguns anos depois eu tinha isso, quando tínhamos uma conexão de internet permanente porque não sei se você se lembra naquela época, com discagem, se você tivesse apenas uma linha telefônica...

Josh: Era tudo.

James: Era tudo, sim, você tinha que alternar a internet ligada e desligada, então novamente, tive a sorte de ter, com o serviço telefônico que tínhamos, eles dariam uma segunda linha de graça.

Então meu pai disse, oh ótimo, agora posso fazer telefonemas sem ter que ouvir ruídos de modem no telefone, e então pegamos essa segunda linha e lembro que acho que estava rodando um serviço web PHP e pensei, gostaria de poder hospedar isso eu mesmo. Não quero, sou criança, não tenho dinheiro para hospedagem, mas tenho algumas peças antigas de computadores então peguei uma placa-mãe muito antiga, alguns componentes antigos, instalei acho que Debian Red Hat nela e configurei Apache lá e estava hospedando um servidor web de uma caixa de sapato, literalmente uma caixa de sapato em um armário, e era tipo um armário Ikea ou algo assim. Acho que abri um buraco na parte de trás do armário para passar os cabos. E meu pai viu isso e ficou tipo, ele veio basicamente e fez um teste de saúde e segurança. Ele disse, olha, apoio você construindo essas coisas e entendo o que você está fazendo aqui mas em primeiro lugar, você está rodando um computador quente de uma caixa de sapato, exatamente.

E em segundo lugar, venha conversar comigo se você vai abrir um buraco na parte de trás do meu móvel. E pensei, isso vai ser legal, vou fazer isso acontecer, vou construir essa coisa.

Então não, foi desafiador em alguns pontos.

Josh: Claro.

James: E acho que se eu estivesse na posição dele provavelmente ficaria um pouco irritado com esse tipo de coisa.

Josh: Claro.

James: Mas ele foi tolerante.

Josh: Você estava em construir outras coisas ou era sempre tecnologia, baseado em eletrônicos?

James: Sim, acho, novamente isso é provavelmente como uma mentalidade de pessoa de produto, mas sempre gostei de construir coisas em geral. Lembro que antes de entrar em computadores, montei um pequeno sistema, pequenos modems de servidor, acho que tinha um kit de eletrônicos que peguei desse lugar chamado Maplin Electronics, que é meio como um Radio Shack.

Josh: Sim.

James: No Reino Unido.

E eu tinha um kit Servo e um monte de fios e tudo esse tipo de coisa, e fiz um pequeno sistema para abrir e fechar minhas cortinas no meu quarto. E era como, máquina de Rube Goldberg com um nível de conexões e fios e cabos, e sim, acho que gosto da tangibilidade de construir coisas. Gosto do fato de que, acho que na escola eu estava, você já viu aqueles robôs de toner que você pode programar para ir para a esquerda e para a direita e seguir em frente e esse tipo de coisa, eles desenham padrões.

Josh: Sim, sim, sim.

James: Então esqueci o que eles são chamados agora, mas tínhamos um desses na escola e acho que quando você vê as ações que você está dizendo a uma máquina ou sistema para fazer tem impactos tangíveis, isso meio que desperta aquele bichinho. Então sim, sempre estive envolvido com a construção de coisas.

Josh: Você sempre foi empreendedor, como obviamente há o lado da construção, mas meio que, não realmente o lado de vendas, mas querendo ganhar dinheiro com coisas, ou sempre foi produto em primeiro lugar?

James: Definitivamente produto em primeiro lugar, acho que o lado empreendedor das coisas eu acabei caindo.

Acho que por ser o primeiro funcionário da Heyzap, mesmo sendo CTO dessa empresa e executando o time de engenharia, eu ia em conferências e ia em eventos, então por padrão acabei vendendo o produto. E em particular em Bug Snag, o cliente de Bug Snag sou eu. São colaboradores técnicos individuais ou líderes técnicos. E estive em ambas as funções.

Se você tem um produto que construiu e ama e construiu por uma razão particular para resolver um problema particular, e seu cliente é basicamente a mesma persona que você, fica muito mais fácil, sai muito mais naturalmente.

Mas sim, quando começamos Bug Snag, Simon e eu nos financiamos nos primeiros, acho, nove meses da empresa. Então acho que os dois dissemos que tínhamos nove meses de economia na conta bancária, e acho que na verdade calculei errado. Acho que só tinha seis meses de economia na conta bancária, e aluguel em São Francisco não é barato.

Josh: Não, não é algo que você possa acidentalmente estar como, ah, eu subestimei isso em três meses.

James: Exatamente, mas... vou te dizer, isso meio que moldou o negócio para nós. Sou um construtor, gosto de produtos e produto em primeiro lugar, mas se você vai aos seus clientes e diz o que você gostaria, eles vão dar uma resposta diferente se você diz quanto você pagaria, e então enquadrar, quer dizer, este é seu negócio, você sabe disso muito bem, mas enquadrar em torno do quanto você pagaria foi uma experiência tão capacitadora para Simon e eu porque tínhamos dinheiro diminuindo. Nós, acho que acabamos atingindo lucratividade quando estávamos financiando com cerca de um mês de sobra em economia.

E então foi empreendedorismo forçado. Acho que realmente depende de como você define comportamento empreendedor, mas a maioria dos empreendedores que conheço e respeito são pessoas de produto primeiro e pessoas comerciais em segundo lugar. Você tem que ter ambas, obviamente, mas sim, tipo, caí nela desse jeito.

Josh: Sim, sim. Então vamos, acho, como Bug Snag surgiu? Na minha cabeça, por que outro rastreador de erro de aplicação, certo? Qual foi o impulso para…

James: Exatamente.

Então nós, Simon e eu estávamos basicamente frustrados. Então Simon é meu cofundador, nos conhecemos na faculdade. Na verdade o contratei para dirigir meu time de mobile na Heyzap, o trouxe para os EUA para dirigir um dos meus times na Heyzap e estávamos em um pub um dia falando sobre construir software em geral. E eu tinha estado escrevendo software na Bloomberg em Finanças e depois também fiz um pouco de software embarcado durante a faculdade e depois dirigindo Heyzap como uma startup, vi o mesmo conjunto de problemas em todas essas diferentes indústrias e Simon disse que viu a mesma coisa.

Então saindo da faculdade, Simon era um consultor de software, e então ele iria resolver problemas em grandes empresas como Votify que é uma grande empresa de telecomunicações ou indústria de Defesa do Reino Unido e coisas assim. Ele voaria, resolveria seus problemas e sairia. E muitas vezes ele dizia, por que você não sabia que isso era um problema? Como demorou tanto para descobrir que isso estava quebrado?

Estávamos em um pub um dia recontando essas histórias e percebemos que toda empresa que tem software está ferrada quando está quebrada, e sendo eu um cara de produto, pensei, acho que ninguém está resolvendo isso direito. E historicamente, se você olhar para trás para quando começamos a empresa cerca de quatro anos atrás, havia praticamente um jogador no jogo na época, que era um produto que costumava ser chamado Hop Toad e agora é chamado Air Break.

Tenho que ser respeitoso com a indústria. Eles foram os pioneiros, mas foram a primeira tentativa nisso. Eles eram tipo, vamos tentar isso. Acho que eram esses caras e uma empresa chamada Exceptional, eles acabaram se fundindo.

Josh: Que Exceptional era basicamente a encarnação anterior dos caras na Intercom.

James: Isso é certo. Sim, os fundadores da Intercom originalmente construíram Exceptional, isso é correto. Então eles o venderam para os caras do Air Break e eles se fundiram e ambos estavam resolvendo o mesmo problema. Basicamente estavam dizendo, hey, em vez de apenas cavar em arquivos de log ou a versão 0.1 do monitoramento de erro que é quando um erro acontece, envie um e-mail para si mesmo, por que não apenas colocamos em um banco de dados e mostramos em um painel, então essa foi a fase um deste espaço.

Acho que eles abriram o caminho para a base de monitoramento de erro pró-ativo de serviço, mas o que aconteceu é que em Heyzap acabamos construindo um produto mobile e o monitoramento de erro mobile era terrível e o primeiro incursão para mim no monitoramento de erro como um cara de produto estava escrevendo o agente escrevendo o SDK que enviava erros de aplicativos Android para Air Break.

Então eu realmente fiz uma biblioteca OpenSource que enviava para a API do Air Break, e cheguei ao ponto onde pensei, isso foi fácil. Essa foi a parte fácil, detectar e enviar esses erros. Mas os erros são apresentados de forma errada, eles são agrupados incorretamente, o alerta não está lá. Você não pode dizer qual era o impacto do usuário. Então, na verdade, inicialmente construímos este negócio porque estávamos coçando uma coceira. Não havia nada que estava ativamente resolvendo o problema da forma como pensávamos que deveria ser resolvido.

Havia um casal de empresas na mesma época que surgiram ao redor do momento em que estávamos construindo Bug Snag, Century sendo a principal. E sim, desde então nós apenas...

Lembro do dia um quando nos propusemos a construir o roteiro para Bug Snag, tínhamos um roteiro de dois anos que escrevemos e quatro anos depois, fizemos tudo isso, mas acho que nosso roteiro agora é ainda mais longo do que isso.

Quanto mais você vai nisto, mais você percebe que os problemas...

Josh: São muito maiores.

James: Exatamente. Há o básico de tenho um pequeno aplicativo PHP ou Ruby ou o que for, e só quero saber quando cada queda acontece, essa é a parte fácil. Mas o que estamos descobrindo é que quando você entra em empresas maiores como Air BnB ou Pandora, esse tipo de empresas, os problemas são muito diferentes em escala.

Eu sempre digo isso às pessoas, é muito fácil saber que você tem erros, é muito difícil realmente consertá-los e fazer algo a respeito. E então o espaço do problema mudou, em vez de dizer aqui está uma lista de todos os erros que temos, que é o problema fácil, é agora como você se concentra nos erros que importam e como você proativamente entrega correções para os clientes mais afetados ou bugs mais afetados.

Então sim, é interessante como resolver o mesmo problema, até mesmo dentro do reino do monitoramento de erro, os problemas mudam dentro desse espaço.

Josh: E quer dizer, acho que é o caso, sinto como os últimos, não sei, cinco talvez até dez anos da web e apenas construindo software... as ferramentas são tão, a barreira de entrada é tão baixa que por muito tempo, todos estiveram apenas construindo coisas tão rápido quanto podiam, mas então o que acontece é, você percebe que apenas ter os dados em si, bem, pode ser útil, na maioria das vezes você não pode fazer nada com isso, certo?

É da mesma forma conosco com Bare Metrics, é como podemos dizer números o dia todo, mas e daí? O que você vai fazer com isso? E essa é a parte difícil.

James: Você acertou. Você sabe o que, na verdade? Isso me lembra, então Simon e eu, nossa primeira compra como empresa, como um negócio incorporado foi comprar um quadro branco no Craig's list para que pudéssemos escrever ideias e coisas no nosso quarto/escritório que tínhamos. E escrevemos, acho que quatro coisas naquele quadro branco, e a primeira da lista era respostas em vez de dados, e isso é exatamente, acho que há muitas ferramentas por aí que vão te dar dados, mas isso não é útil se você está tentando resolver problemas e priorizar.

Então, literalmente, um dos nossos princípios fundadores foi respostas em vez de dados. Podemos entregar você um passo adiante ou dez passos adiante do que apenas um arquivo de log ou uma lista de problemas.

Sim, é verdade, qualquer um em software está resolvendo o mesmo problema agora com isso.

Josh: Com certeza. Então o que, obviamente você pessoal decidiu construir este rastreador de erro de aplicação mas ajudando as pessoas a fazer mais sentido disso. Que papel anterior a Bug Snag, eu sei que você estava bem envolvido em fazer coisas OpenSource...

James: Sim.

Josh: Então que papel toda aquela coisa OpenSource anterior desempenhou no sucesso de Bug Snag?

James: Essa é uma ótima pergunta. Acho que a biblioteca de construção OpenSource, isso é o que eu costumava fazer na terra OpenSource e ainda faço esses dias é construir bibliotecas.

E a ideia era que, ei resolvi este problema, este problema não é um problema único para mim, vou limpá-lo, extrair, e compartilhar com todos. E então uma parte legal de Bug Snag é nosso SDK, são nossas bibliotecas que detectam esses travamentos e os relatam e então quando nos propusemos a construir Bug Snag muitas ferramentas no espaço que fazem monitoramento de erro, especialmente no lado mobile que é uma das nossas maiores áreas de crescimento no momento, não compartilham o código-fonte da sua solução de monitoramento de erro.

Um casal por aí, há CrashtheLinks e Aptelligent, ambos têm SDKs de monitoramento de erro de código fechado e nem sequer me ocorreu fazer isso quando construímos o negócio. Para mim, esse não é o molho secreto, isso não é o que estamos vendendo aos nossos clientes, estamos vendendo a experiência de encontrar e consertar mais rápido. Não estamos vendendo um SDK, e então sim, ao ter essa experiência em OpenSource e construindo bibliotecas, acho que isso me ensinou duas coisas.

Número um, me ajudou a entender o valor de fazer isso, certo? Então as pessoas podem ver por trás da cortina quando você constrói coisas na terra OpenSource. Por exemplo, em nossa biblioteca Android que detecta travamentos em aplicativos Android, acho que era eu provavelmente não posso dizer o nome da empresa, um de nossos grandes clientes no lado mobile de consumo, eles avaliaram todos os concorrentes e disseram, ei nós fomos com você porque você tem todas essas bibliotecas opensource porque queremos contribuir para elas e queremos ver o que você está construindo sob o capô.

Para mim isso foi apenas um padrão, é assim que eu opero. E foi realmente, muito capacitador ver que nossos clientes pensavam a mesma coisa. Acho que a segunda coisa é que não há códigos de trapaça, não há cortes de fonte quando você está trabalhando no OpenSource. Você está trabalhando aberto, e então você tem que pensar, essa biblioteca parece apropriada para a comunidade que estou construindo.

Você pode ter um conjunto de princípios norteadores para bibliotecas de monitoramento de erro, mas a que você constrói para Ruby provavelmente tem que se sentir um pouco diferente da que você construiu para Android, provavelmente tem que se sentir um pouco diferente da que você construiu para Python. E se você construir do jeito OpenSource e compartilhar todo esse código e essa interface com seus clientes, você não pode se esconder.

A comunidade Python é um bom exemplo aqui, então há este conceito de ser pythônico que as pessoas se orgulham na comunidade Python. Eu concordo com isso também, é meu background. Eu vim da comunidade Python há um tempo. Isso é se seu código está escrito de forma pythônica, desenvolvedores de software têm mais probabilidade de ter respeito pela sua biblioteca e portanto adotá-la em sua base de código.

Então sim, acho que essas são meio que as principais coisas que tirei do meu background de open source. Também acho que construir bibliotecas para mim e construir SDKs é muito parecido com construir um produto. Você está construindo, é uma experiência do usuário. Uma biblioteca é apenas um conjunto de interfaces de usuário, apenas acontece que são funções e classes em vez de interfaces visuais. Então acho que isso me deu um respeito saudável por construir produtos também.

Josh: Você sente que o trabalho anterior de open source ajuda você a obter clientes iniciais ou é meio irrelevante?

James: Depende, então tenho tendência a trabalhar em qualquer linguagem em que estou trabalhando no momento, então tive dois grandes projetos de open source, um ou dois plug-ins JavaScript que são muito datados esses dias mas baseado em query e uma grande biblioteca Android que construí que foi HDP Cline em Android.

E a coisa é que para Bug Snag, porque somos multiplataforma, apoiamos monitoramento de erro em praticamente qualquer plataforma, mobile, desktop, navegador, o que quer que você esteja usando. Ter expertise na terra Android significava que eu era capaz de falar um pouco em conferências Android, mas era só isso, realmente. Não me deu nenhuma credibilidade em nenhuma das outras plataformas.

Mas eu lembro, acho que quando fomos à Air BnB pela primeira vez para mostrar o produto, eles são um dos nossos clientes, um dos caras lá foi como, ah, eu costumava usar sua biblioteca http, e é meio engraçado porque quando você escreve software opensource sinto que você está apenas fazendo isso atrás do teclado e sim, você pode ter muitas estrelas no GetHub, ou pessoas garfando seu produto no GetHub, mas conhecer alguém na vida real que usou seu produto antes é uma experiência totalmente diferente, é meio que emocionante.

Sim, acho que nessa situação isso me deu um pouco mais de credibilidade. Mas não para nenhuma das outras plataformas, gostaria que tivesse.

Josh: Entendi. Então obviamente há uma abundância de ferramentas para desenvolvedores, só em geral, só monitoramento de erro ou qualquer coisa assim, mas há basicamente um número infinito de ferramentas à disposição de um desenvolvedor, então como desenvolvedor você mesmo, como você impede de ficar sobrecarregado pelas ferramentas à sua disposição, e também não se distrair, como, essa ferramenta aleatória vai resolver todos os meus problemas.

Como você se mantém focado em usar apenas as ferramentas que realmente fazem uma grande diferença?

James: Essa é uma pergunta muito boa. Falo muito sobre isso com meu time. Não sei se isso vem com a idade, porque estou programando há muito tempo e a seleção de ferramentas faz parte do meu trabalho há muito tempo, mas fiquei muito, muito pragmático nos últimos tempos. Acho que, antigamente, a forma como aprendi a construir software em primeiro lugar era tentando todas as últimas e melhores novidades de software e construindo toneladas de projetos paralelos e brincando com isso.

Literalmente, ontem mesmo, estava brincando com uma ferramenta chamada Roll Up, que é um sistema de agrupamento JavaScript que está meio que competindo com Web Pack no momento. E apenas em um pequeno projeto paralelo que estava explorando, mas quando se trata de construir e escolher ferramentas para trabalho, para Bug Snag, para o dia a dia, muito me inclino para ser pragmático, então honestamente esses dias eu não tenho muita influência na seleção de ferramentas. Normalmente é meu cofundador ou os times de engenharia. Mas se alguém me pedisse conselho sobre isso, eu diria, qual é a ferramenta mais popular ou a ferramenta que é estável, mas com tendência de crescimento.

Então quando escolhemos um framework JavaScript para nosso painel, não era como, vamos escolher o mais legal novo framework JavaScript. Era como, qual é o mais bem suportado, há grandes empresas usando? A qualidade da cadeia de ferramentas, é de alta qualidade? Todas essas coisas.

Então sim, tudo isso leva ao pragmatismo desses dias, mas acho que é assim que se faz. Acho que se você brincar com a borda afiada em projetos paralelos, mas depois se ater à abordagem pragmática para produção, se isso fizer sentido. Acho que você pode acabar com o melhor dos dois mundos, e acho que isso é verdade para bibliotecas, bem como ferramentas e serviços que você está usando.

Quer dizer, uma das coisas que meu cofundador e eu conversamos o tempo todo é como escolhemos software? E muitas vezes é por reputação. Boca a boca, não acho que seja um modelo de negócio sustentável de bilhão de dólares, mas sabe de uma coisa? Consegue ótimos clientes e eu escolho software pelo que as pessoas falam no Twitter ou em grupos do Slack que participo. Então isso para mim é outro aspecto.

Pragmatismo mais prova social, eu diria.

Josh: Sim, acho que é fácil, especialmente quando você está nos primeiros dias de construção de uma empresa, ou se você é, digamos, um empresário iniciante ou algo assim. A sensação ou a suposição de que a próxima ferramenta vai de alguma forma resolver algum grande problema para você, quando na maioria das vezes, as ferramentas em si apenas otimizam algum hábito ou fluxo de trabalho dado, certo? Elas raramente realmente mudam as coisas de uma forma grande.

Como se você não fosse já …

James: Exatamente, exatamente, sim. É, até me lembro quando fizemos muito trabalho, usamos muito Elasticsearch no Bug Snag, e o Elasticsearch lançou uma nova versão e fomos como, "Olhem para o changelog, isso vai realmente mudar fundamentalmente a forma como construímos as coisas". Não mudou.

Josh: Certo.

James: É o mesmo, é o mesmo pedaço de software. Faz as mesmas coisas. Você constrói o valor em cima das ferramentas, acho que é a máxima. As ferramentas são a camada de cola, sim, você pode reduzir o atrito como você diz, e pode se livrar de algumas tarefas repetitivas, mas sim, acho que você constrói valor em cima das ferramentas.

Josh: Bem, e presumo que com vocês, se alguém chega e não tem feito nenhum tipo de rastreamento de erros ou não tem nada em vigor para melhorar consistentemente seu produto, provavelmente não vai ser um cliente muito bem-sucedido porque isso não é algo que eles estivessem fazendo desde o início.

James: Sim, é, sabe de uma coisa, na verdade, quando começamos este negócio, nem conversávamos com pessoas que não tivessem usado algum tipo de monitoramento de erros antes.

Josh: Sim,

James: Mas na maioria das vezes é isso, é aí que estamos construindo muito valor para o negócio. Então se você é um app muito pequeno, uma loja muito pequena que tem alguns erros sendo lançados aqui e ali, então Bug Snag é ótimo, mas o quanto melhor é do que algum tipo de monitoramento de erro básico, ou se enviar um email toda vez que um crash acontece.

É melhor, mas vai fornecer muito mais valor?

O que acontece é que esses dias, especialmente no lado do cliente em mobile no monitoramento de browser e monitoramento de JavaScript, é que as pessoas sabem que têm um ponto de dor, mas não sabem como resolvê-lo. Na verdade, acho que conversei com outro fundador recentemente sobre isso.

Quando você primeiro constrói um negócio que está resolvendo um problema muito específico, você assume que seu mercado vai ser pessoas que entendem o problema. E depois que você ganha um pouco de maturidade, acontece que, pelo menos no nosso negócio, o negócio maior, o negócio de bilhão de dólares está em pessoas que sabem que há uma dor, mas não entendem que monitoramento de erro por exemplo é a maneira de resolvê-lo, e então acabamos conversando com muitas pessoas, especialmente em conferências ou eventos ou encontros e esse tipo de coisa, que são como, ouvimos reclamações de nossos clientes de que o app está quebrado e simplesmente não sabemos como.

E seria muito fácil para mim pensar que todo mundo constrói software da mesma forma que eu construo software e que você entende que monitoramento de erro é uma parte essencial do seu negócio, e parte essencial do seu stack, mas na realidade, acho que provavelmente 90% dos times de software por aí sabem que há um ponto de dor, mas realmente querem ajuda em entender qual é a melhor forma de resolver isso.

Então isso foi um entendimento realmente transformador para mim nos últimos anos, é que assumir que todo mundo sabe que precisa de uma ferramenta como essa provavelmente nos teria levado a um negócio de 50 milhões, mas na verdade o problema maior é ei, meu negócio está quebrado e não sei por quê. E não sei como resolver isso.

Josh: Então como você aborda isso da perspectiva de ajudar as pessoas a saber como corrigir o problema que elas não sabem … que não conseguem identificar, não sabem como verbalizar o que é, elas apenas sabem, ei há esse problema maior. Mas como você chega e diz, sim, esse rastreamento de erro ou logging ou expondo o problema que seus clientes estão tendo … como você os educa de que essa é a solução?

James: Sim, boa pergunta. Então realmente é em torno de dor. Acho que depende de quem estamos falando na organização, mas realmente, eles sabem que a dor existe, certo? Na pior das hipóteses, você vai estar recebendo tweets ou emails raivosos de seus clientes dizendo que isso está quebrado. Então isso nunca, como um time de software ou um time de produto, isso nunca é um bom sentimento, ouvir clientes reclamando.

Então no lado mais visceral das coisas, quando seus clientes reclamam você se sente mal sobre as coisas, então há essa dor já embutida, mas o que estamos vendo mais frequentemente é na verdade saídas tangíveis dessa dor, então isso, começamos essa conversa falando sobre como nunca foi fácil construir software esses dias e os clientes têm uma escolha esses dias, então o que acontece é quando você está avaliando produtos …

Um de nossos clientes, não posso dizer o nome porque eles ficarão furiosos se eu disser, mas quando começaram a usar Bug Snag, começaram a usar o produto porque tinham uma classificação de uma estrela na loja de apps, a loja de apps do iTunes, e foram como, isso apesta, isso é embaraçoso, as pessoas acham que somos um produto ruim, e então essa era a razão tangível para colocar monitoramento de erro em vigor era que estavam sendo classificados publicamente sobre a qualidade do seu software.

Isso está se tornando cada vez mais prevalente esses dias com todas essas ferramentas diferentes como Product Hunt ou Stack Shed que permitem você comparar produtos maçã com maçã e se as pessoas estão dizendo bem essa está falhando ou essa é lenta você não vai com esse produto.

Então em vez de apenas ter esse fator de boca a boca há quase como uma saída tangível de que seu produto é ruim, essa é a classificação de qualidade do seu produto, e isso, podemos educar sobre como você pode sair de ruim para bom e esse é nosso trabalho, ajudando as pessoas a verem que há um caminho para resolver isso, mas na verdade o ponto de dor é apenas, já está na mente dos times de produto.

Josh: Então qual foi uma parte chave do sucesso para Bug Snag. Houve alguma coisa que realmente mudou o crescimento para vocês? Ou duas coisas, três coisas?

James: Sim, quer dizer, uma coisa que acho que o foco é importante. Acho que sempre nos focamos na experiência do produto, certo? Acho que seria muito fácil continuar adicionando novas plataformas que suportamos ou adicionar pular quando nossos clientes dizem construir esse recurso, mas acho que ter uma experiência de produto holística de ponta a ponta tem sido a coisa que nos mantém com uma taxa de crescimento constante.

Em termos de pontos de inflexão, construímos, acho que foi cerca de 18 meses atrás. Mudamos a forma como modelamos nossos dados para permitir que as pessoas filtrem e se concentrem em quais erros importam mais, então construímos esse novo painel inteiro. Chamamos de painel 2 internamente.

Construímos esse novo painel inteiro que permite você destacar melhor os piores problemas, e acho que esse tem sido o maior ponto de inflexão para nós porque como disse anteriormente, o problema de entender quais erros estão acontecendo em seu aplicativo Ruby on Rails de baixo volume é que acho que fazemos um trabalho bem legal disso, mas quando você entra no espaço do problema de sou uma aplicação do lado do cliente ou aplicação de consumidor e estou recebendo dezenas de milhões de relatórios de crash por dia ou centenas de milhões de relatórios de crash por dia, isso se torna mais um problema de sinal para ruído do que um problema de apenas ter uma lista de erros.

Então construímos esse novo painel e acho que foi cerca de um ano atrás que começamos a ter essa boa palavra de boca no espaço de consumidor. Isso foi aproximadamente na época em que o Air BnB começou a nos usar, Pandora começou a nos usar e todo mundo foi como, sim, legal, monitoramento de erro é uma coisa, mas quando tenho um cem milhões de erros por dia e tenho cem desenvolvedores trabalhando nesse problema, como posso realmente resolver esses problemas?

Então fizemos essa grande mudança de painel e acho que isso teve um impacto bastante grande no negócio. Nos permitiu não apenas resolver problemas para colaboradores individuais e pequenos times de dev, mas também subir no mercado para times de dev maiores.

Josh: Então houve um tempo, no inverso disso, então você teve esse bom crescimento e houve algumas coisas que foram esses pontos de inflexão para você, mas houve um tempo que você pensou que Bug Snag não ia conseguir?

James: Acho que a coisa interessante sobre startups é no negócio SaaS, quando você é um negócio SaaS gerador de receita, e isso é o material que você fala o tempo todo e falamos o tempo todo como fundadores, é que sinto que sempre poderíamos conseguir. Sempre há uma maneira de continuar como um negócio. Acho que estabelecemos altas expectativas para nós mesmos como uma empresa, e às vezes estamos como, não estamos atingindo essas expectativas, ou queremos crescer mais rápido do que estamos crescendo agora, e então a boa notícia sobre ser um negócio SaaS gerador de receita é que acho que sempre estivemos em um estado financeiro saudável, mas a questão é mais como podemos acelerar o negócio sem queimar nosso dinheiro.

Isso é, encontrar esse ponto doce de crescimento, certo? Encontrar esse ponto doce de aceleração, acho que é a parte difícil. E vou te dizer qual é a coisa mais difícil, as pessoas sempre me perguntam e tenho certeza que perguntam para você o mesmo. Quais são as coisas mais difíceis no negócio?

Sempre disse contratação e precificação, e contratação sendo no início da empresa especialmente sendo fundadores britânicos na Bay Area, não tínhamos uma rede de onde contratar, e então encontrar pessoas para se juntar ao time foi muito difícil.

Isso muda um pouco esses dias e isso é, especialmente quando estou crescendo meu time executivo ou meus gerentes eu sou como, como encontro pessoas que acreditam em nossa filosofia e visão como um negócio, mas então no lado da precificação acho que o mais próximo que já ficamos de ser como, uh oh isso é assustador, é quando passamos por algumas iterações de precificação, então quando começamos o negócio nos precificamos em um modelo tudo que você pode comer. Basicamente dissemos que você pode ter quantos dados, quantos relatórios de crash quiser, e basicamente cobrávamos pelo número de desenvolvedores que estavam usando o produto.

Então mudamos nosso modelo de precificação para redobrar isso em um ponto e simplesmente não se sentiu certo, e não funcionou. Não se alinhava com o valor que estávamos fornecendo. E então acho que, não sei, isso parece ser a coisa número um que vem à tona quando estou falando com outros fundadores é que precificação você nunca acerta, e sinto que isso é uma coisa libertadora de entender. Acho que se eu, como desenvolvedor de software, sempre sinto que há uma resposta certa para um problema e então você pode refatorar algo tão bem que seja a resposta perfeita, mas quando se trata de precificação, li um bom artigo, e esse é seu negócio também então você pode falar sobre isso.

Sinto que é muito libertador quando você entende que você nunca vai acertar o modelo de precificação perfeito, e é uma experiência iterativa em vez de uma experiência de essa é a resposta certa.

Mas sim, acho que para voltar à sua pergunta aí, eu nunca realmente pensei que não íamos conseguir, às vezes senti que tínhamos tomado decisões que desaceleraram o crescimento do negócio e especialmente em torno de precificação. Essa é uma das áreas principais.

Josh: É uma das coisas, como é uma parte necessária disso, certo? Porque se você não tentasse, você não saberia que não funcionou e se você não sabe então você potencialmente perdeu algo que poderia ter sido uma coisa ótima, certo?

James: Certo, mas é aterrorizante porque precificação é tal uma, ainda hoje, precificação é tal uma âncora essencial para seu negócio que, eu quero mudar as coisas, e …

Josh: Bem e isso faz as pessoas ficarem realmente emocionais … sim, desculpe vá em frente.

James: Exatamente, exatamente, e você se lembra de Zen Desk na verdade alguns anos atrás, eles fizeram uma mudança de precificação e não garantiram as pessoas e isso foi esse grande alvoroço em torno disso, foi meio louco.

Josh: Sim. Então terminando as coisas aqui, o que o futuro reserva para Bug Snag, então vocês têm alguns milhares de clientes agora? Três ou quatro?

James: Sim, estamos chegando perto de quatro mil organizações pagantes usando o produto agora.

Josh: Então qual é a aparência do produto para os próximos quatro mil clientes?

James: Essa é uma boa pergunta. Acho que a forma como configuramos as coisas agora é que fizemos um trabalho muito, muito bom em informar engenheiros e gerentes de engenharia sobre o que está quebrado, quais são os piores problemas e como corrigi-los. Esse é o núcleo do nosso negócio e acho que o que ouvimos cada vez mais de nossos clientes é ajude-nos a entender tendências e padrões, ajude meu CTO a entender o estado do negócio. Ou expandindo para outras áreas da equipe de produto. Um dos exemplos aqui é que tínhamos este cliente que tinha um programa piloto em que estava trabalhando, e acho que era um negócio de sete dígitos pelo qual estava trabalhando e seu painel quebrou durante este programa piloto, e o engenheiro de vendas e o vendedor não sabiam que o painel tinha quebrado e depois perderam a venda.

Então, mesmo um engenheiro de vendas ou um representante de vendas na empresa, se você é um negócio de software, todos na empresa se importam se o software está funcionando ou não. Mas a visualização que estamos apresentando agora em nossos painéis, que é aqui está a lista de erros e aqui estão os piores erros e aqui está como corrigi-los, não é necessariamente a visualização correta para mostrar ao seu time de vendas, ou seus representantes de suporte ao cliente ou até seu CEO ou seu CTO.

Então, pegando esses dados principais que estamos coletando e destacando e exibindo de maneiras mais apropriadas para o resto da organização do produto. Então, isso é quase um problema de camadas. Acho que não são os problemas muito difíceis em torno da coleta de dados e detecção de falhas e os problemas subjacentes, acho que fizemos um bom trabalho em resolver, mas tornando esses dados mais acessíveis ao resto da sua organização.

Se você é um negócio construído em torno de software, então todos devem se importar se está funcionando ou não e se você está entregando uma alta qualidade.

Então é para lá que estamos indo.

Josh: Você sente que está apenas começando? Você vem fazendo isso há alguns anos, mas ao mesmo tempo, os problemas, você ainda tem um problema realmente grande para resolver, certo?

James: Sim, digo isso o tempo todo, sinto que isso não é algo em que você diz, é um problema resolvido agora, consertamos.

Josh: Certo.

James: Toda vez que você vai mais fundo descobre cada vez mais problemas e acho que o objetivo central, a coisa central que estamos tentando resolver é que toda vez que você vai mais fundo percebemos como podemos fazer melhor, e como podemos oferecer uma experiência ainda melhor para nossos clientes e então isso é o mais emocionante, é isso que me tira da cama pela manhã. É que há tantos problemas para resolver, e sim, me pergunto se isso é verdade para todos os negócios, mas certamente é verdade para o nosso negócio.

Josh: Eis aí, James Smith do BugSnag.