James Smith

Esta semana hablo con James Smith de BugSnag, donde realizan monitoreo de errores de aplicaciones. Hablamos sobre romper computadoras de niño, usar código abierto como una forma de obtener tracción inicial, marketing para desarrolladores, el papel de los datos en la toma de decisiones y mucho más. ¡Espero que te guste!

Josh Pigford: Saltemos adentro, me gusta obtener la historia completa, dónde han estado los fundadores, cómo llegaron a donde están ahora, así que supongo que comenzaremos desde allí. Entonces has tenido tu mano en muchas empresas diferentes y proyectos de código abierto a lo largo de los años y luego, más recientemente, antes de BugSnag eras el CTO en Heyzap.

Entonces supongo que me intriga, ¿cómo entraste en computadoras y tecnología para empezar?

James: Sí, claro, bueno, eso se remonta muy atrás. Es una buena pregunta.

Entonces creo que mi papá me consiguió, recuerdo, una Navidad, mis padres me compraron una computadora. Creo que era una computadora IBM SX25 486 SX25 y básicamente la consiguieron para nosotros con un par de juegos. Creo que teníamos Lemmings y un juego llamado Micro Machines si alguna vez has jugado ese.

Josh: Clásicos.

James: Hace mucho cuando era niño. Son juegos clásicos, y eso me metió en las computadoras en primer lugar, y luego la rompí, la desarmé y la volví a armar y descubrí esta cosa llamada BASIC en esos días y pensé, espera, puedo hacer que esta computadora haga cosas, para horror de mi papá. Y estoy seguro de que escuchas esta historia con muchos fundadores al principio, cómo llegaste a construir cosas.

Bueno, comienzas a construir cosas rompiendo cosas primero.

Josh: Claro.

James: Entonces obtuve esta computadora, la rompí, molestaba a mi hermano porque solo quería jugar Micro Machines en esta computadora. Y luego, recuerdo, fui bastante afortunado en que soy de Londres y teníamos cable de internet muy temprano. Y así teníamos internet creo que en 1996, lo cual es una locura de hace tanto tiempo.

Josh: Vaya, sí.

James: Y así en ese momento recuerdo, creo que la razón principal por la que comencé a construir productos en lugar de simplemente romper cosas y desarmarlas fue que mi amigo y yo solíamos jugar este juego, Duke Nukem 3-D si alguna vez has jugado ese juego.

Josh: ¿Vino gratis en tu computadora o algo así? ¿O fue alguna versión gratuita o tenías...?

James: Tenía la versión Shareware, había algo así como el primer paquete o lo que fuera.

Josh: Sí, sí, claro.

James: Jugué eso hasta el cansancio, fue un gran juego.

Pero sí, descubrimos que podías, en aquellos días estábamos jugando vía módem lo cual realmente me envejece supongo ahora. Tenías que marcar la computadora de alguien más en lugar de pasar por TCP/IP a través de internet como es ahora. Tenías que marcar la línea telefónica de otra persona y luego los módems hablaban entre sí.

El reproductor IPX, creo que se llama en Duke Nukem y pensamos, esto apesta, queremos estar en internet y jugar este tipo de cosas. Así que encontramos una herramienta que canaliza las cosas de IPX vía TCP/IP y luego pensamos, ¿por qué nadie sabe sobre esto?

Así que hicimos un pequeño sitio web, era como, oye, si quieres jugar Duke Nukem por internet en lugar de tener que marcar el módem de tu amigo, aquí te mostramos cómo usarlo. Y así mucha gente, esto era solo una herramienta que alguien más construyó, era una herramienta gratuita, y así mucha gente vino a este sitio web y pensó, vaya, esto es loco, a la gente le encanta. Y luego pensé, ¿no sería genial si pudieras tener una tabla de clasificación? ¿No sería genial si pudieras tener un ranking de quién está ganando la mayoría de los juegos de Duke Nukem? y no sabía cómo hacerlo, solo sabía HTML en aquellos días, un poco de BASIC, y pensé, ¿no sería genial si pudiera hacer que esta página web se actualice dinámicamente?

Y de nuevo, estoy seguro de que escuchas esto de muchos de los fundadores con los que hablas, pero eso es lo que me metió en la construcción de productos. Pensé, quiero poder actualizar lo que hay en este sitio web dinámicamente basado en lo que las personas están ingresando. Es simple, creo que era en Perl en aquellos días. Y pensé, oh, okay, eso no fue tan difícil. Y luego una vez que pasas ese precipicio, estoy seguro de que tienes esa misma reacción. Una vez que pasas el precipicio de, vaya, puedo controlar esto, puedo cambiar esto, esto es algo que he construido, se desbloquea en tu mente, bueno, probablemente pueda construir muchas cosas ahora. Esto abre las puertas.

Josh: Hay un efecto bola de nieve allí.

James: Exactamente, sí, es positivo, es emocionante. Así que tomamos esa experiencia y seguimos construyendo desde entonces, y sí, mencionaste Heyzap que es, probablemente adivinaste por mi acento que no soy de, mi empresa se basa en el área de la Bahía, pero no soy del área de la Bahía.

Heyzap es la empresa que me llevó a San Francisco, así que antes de eso hice una licenciatura en Matemáticas e Informática en una universidad llamada Bath University en el Reino Unido en la costa oeste de Inglaterra. Que es donde conocí a mi cofundador en realidad para BugSnag. Y luego después de eso hice este camino predeterminado de entrar en finanzas, y trabajé para Bloomberg en Londres construyendo plataformas de trading.

Y tengo mucho respeto por esa empresa, aprendí mucho allí, una actitud bastante empresarial también en esa empresa, pero seguía trabajando en finanzas, y las finanzas son, sin disrespeto a nadie que trabaje en finanzas, pero no era para mí, era una industria bastante destructiva para el alma trabajar en.

Un par de viejos amigos de la escuela acababan de entrar en el programa Y Combinator. Esto fue en, supongo, invierno de 2008, así que diciembre de 2008, y estaban construyendo, en ese momento, creo que era un widget integrable para jugar juegos flash en cualquier sitio web. La idea era, y esto también data mucho esta empresa ahora, porque flash es completamente inexistente en estos días.

Josh: Claro.

James: Pero la idea era que si eras una publicación como el New York Times o algo similar donde tenías contenido y querías aumentar el engagement, entonces la idea era que pudieras incrustar un widget de juegos flash en la parte inferior de tu página para aumentar el tiempo en el sitio, y así llegué, me uní a la empresa como el primer empleado recién salido de, acababa de graduarme de la clase binaria de Y Combinator, y luego terminé convirtiéndola en una empresa de tamaño decente, pivotamos una o dos veces o tres veces, como suelen hacer las startups, pero sí, eso fue lo que realmente me dio el gusto por la vida de startup.

Siempre he sido constructor, siempre he construido cosas en mi vida, pero pensé, ¿y qué tal construir cosas para un bien mayor? ¿Qué tal construir cosas para mejorar la sociedad o construir cosas para ganar dinero también?

Josh: Claro, claro.

James: A nivel fundamental, así que sí, eso es lo que me trajo aquí.

Josh: Entonces, ¿cómo, entonces Heyzap, era, entonces mencionaste la cosa del juego flash. Si recuerdo correctamente, solía hacer un montón de diseño, consultoría, fui a la escuela de diseño, y estoy 87% seguro de que casi tomo un trabajo en Heyzap haciendo diseño de interfaz de usuario, así que...

James: ¿Sabes qué? Voy a tener que mirar en mi bandeja de entrada ahora. Qué mundo tan pequeño, eso es loco.

Josh: Esto habría sido 2000 y, no sé, 9 o 10 o algo así, ¿quizás un poco más tarde que eso?

James: Muy, muy temprano en Heyzap entonces. Eso es loco.

Josh: Sí. Así que sí, mundo pequeño.

Entonces saltando al regreso a los primeros días donde estabas rompiendo tus computadoras. ¿Tus padres apoyaban el hecho de romper las cosas en pedazos y volverlas a armar y descubrir cómo funcionaban las cosas, o estaban algo molestos por eso, o...?

James: Sí, mis, creo que estaban, no diría que apoyaban. Creo que tolerante es probablemente una mejor palabra.

Recuerdo que mi papá se estresó mucho en un momento. Un par de años después tenía esto, cuando teníamos una conexión permanente a internet porque no sé si recuerdas en aquellos días, con marcado, si solo tenías una línea telefónica...

Josh: Eso era todo.

James: Eso era todo, sí, tenías que activar y desactivar internet, así que de nuevo, tuve la suerte de tener, con el servicio telefónico que teníamos, te daban una segunda línea gratis.

Así que mi papá dijo, oh genial, ahora puedo hacer llamadas telefónicas sin tener que escuchar ruidos de módem en el teléfono, así que obtuvimos esta segunda línea y recuerdo que creo que estaba ejecutando un servicio web PHP y pensé, me gustaría poder alojarlo yo mismo. No quiero, soy un niño, no tengo dinero para alojamiento, pero tengo algunas piezas viejas de computadoras, así que tomé una placa base muy antigua, algunos componentes antiguos, instalé creo que Debian rojo ardiente en ella y configuré Apache allí y estaba alojando un servidor web desde una caja de zapatos, literalmente una caja de zapatos en un armario, y era como un armario Ikea o algo así. Creo que corté un agujero en la parte posterior del armario para pasar los cables. Y así mi papá vio esto y pensó, fue y básicamente hizo una prueba de salud y seguridad. Dijo, te apoyo en la construcción de estas cosas y entiendo lo que estás haciendo aquí, pero primero, estás ejecutando una computadora caliente desde una caja de zapatos, exactamente.

Y en segundo lugar, ven y habla conmigo si vas a cortar un agujero en la parte posterior de mis muebles. Y solo pensé, esto será genial, haré que esto suceda, construiré esta cosa.

Así que no, fue una prueba en algunos momentos.

Josh: Claro.

James: Y creo que si estuviera en su posición probablemente estaría un poco enojado por ese tipo de cosas.

Josh: Claro.

James: Pero fue tolerante.

Josh: ¿Estabas interesado en construir otras cosas o siempre fue tecnología, basada en electrónica?

James: Sí, creo que, de nuevo, esto es probablemente como una mentalidad de persona de producto, pero siempre he estado interesado en construir cosas en general. Recuerdo que antes de meterme en computadoras, establecí un pequeño sistema, pequeños módems de servidor, creo que tenía un kit de electrónica que obtuve de este lugar llamado Maplin Electronics, que es algo así como una Radio Shack.

Josh: Sí.

James: En el Reino Unido.

Y tenía un kit Servo y un montón de cables y todo ese tipo de cosas, e hice un pequeño sistema para abrir y cerrar mis cortinas en mi dormitorio. Y era como, un nivel de máquina de Rube Goldberg de conexiones y cables y todo eso, y sí, creo que me gusta la tangibilidad de construir cosas. Me gusta el hecho de que, creo que en la escuela, ¿alguna vez has visto esos robots de tóner que puedes programar para ir a la izquierda y a la derecha y hacia adelante y ese tipo de cosas, dibujan patrones?

Josh: Sí, sí, sí.

James: Así que olvido cómo se llaman ahora, pero teníamos uno de esos en la escuela y creo que cuando ves las acciones que le dices a una máquina o a un sistema que haga, tengan impactos tangibles, algo así enciende esa pasión. Así que sí, siempre me ha gustado construir cosas.

Josh: ¿Siempre has sido emprendedor, obviamente está el lado de la construcción pero más o menos, no realmente el lado de las ventas, pero queriendo ganar dinero con cosas, ¿o siempre ha sido primero el producto?

James: Definitivamente primero el producto, creo que el lado emprendedor de las cosas fue algo en lo que caí.

Creo que por ser el primer empleado en Heyzap, aunque fui CTO de esa empresa y estaba dirigiendo el equipo de ingeniería, iba a conferencias e iba a eventos, así que por defecto terminé vendiendo el producto. Y en Bugsnag en particular, el cliente de Bugsnag soy yo. Sus colaboradores técnicos individuales o líderes técnicos. Y he estado en ambos roles.

Si tienes un producto que has construido y amas y lo construiste por una razón particular para resolver un problema particular, y tu cliente es básicamente la misma persona que tú, se vuelve mucho más fácil, es mucho más natural.

Pero sí, quiero decir, cuando comenzamos Bugsnag, Simon y yo nos financiamos solos durante los primeros, creo, nueve meses de la empresa. Así que creo que ambos dijimos que teníamos nueve meses de ahorros en la cuenta bancaria, y creo que en realidad hice un cálculo erróneo. Creo que solo tenía seis meses de ahorros en la cuenta bancaria, y el alquiler de San Francisco no es barato.

Josh: No, eso no es algo en lo que puedas equivocarte accidentalmente como, oh, subestimé eso en tres meses.

James: Exactamente, pero fue... Te diré qué, marcó el rumbo del negocio para nosotros. Soy un constructor, me gustan los productos y primero los productos, pero si vas a tus clientes y dices qué te gustaría, te darán una respuesta diferente si dices qué pagarías, y entonces enmarcar, quiero decir, este es tu negocio, lo sabes muy bien, pero enmarcar alrededor de qué pagarías fue una experiencia tan empoderadora para Simon y para mí porque teníamos dinero que se estaba agotando. Nosotros, creo que terminamos llegando a la rentabilidad cuando nos financiábamos a nosotros mismos con aproximadamente un mes de ahorros de sobra.

Y así, fue emprendimiento forzado. Creo que, realmente depende de cómo definas el comportamiento empresarial, pero la mayoría de los empresarios que conozco y que respeto son primero personas de productos y segundo personas comerciales. Tienes que tener ambos, obviamente, pero sí, simplemente caí de esa manera.

Josh: Sí, sí. Así que déjame, supongo que, ¿cómo surgió Bugsnag? En mi cabeza, ¿por qué otro rastreador de errores de aplicaciones, verdad? ¿Cuál fue el impulso para...?

James: Exactamente.

Así que Simon y yo estábamos básicamente frustrados. Simon es mi cofundador, nos conocimos en la universidad. En realidad lo contraté para dirigir mi equipo móvil en Heyzap, lo traje a los Estados Unidos para dirigir uno de mis equipos en Heyzap y estábamos sentados en un pub un día hablando sobre la construcción de software en general. Y había estado escribiendo software en Bloomberg en Finanzas y luego también hice un poco de software integrado durante la universidad y luego dirigiendo Heyzap como una startup, vi el mismo conjunto de problemas en todas estas industrias diferentes y Simon dijo que vio lo mismo.

Así que después de la universidad, Simon era consultor de software, así que iría y resolvería problemas en grandes empresas como Votify, que es una gran empresa de telecomunicaciones, o en la industria de defensa del Reino Unido y cosas así. Entraría volando, resolvería sus problemas y saldría volando. Y muchas veces él estaría como, ¿por qué no sabías que esto era un problema? ¿Cómo tardaste tanto en darte cuenta de que esto estaba roto?

Estábamos en un pub un día contando estas historias y nos dimos cuenta de que todas las empresas que tienen software están jodidas cuando se rompe, y siendo yo una persona de productos, dije, no creo que nadie esté resolviendo esto correctamente. Y, históricamente, si miras hacia atrás a cuando comenzamos la empresa hace aproximadamente cuatro años, prácticamente había un solo jugador en el juego en ese momento, que era un producto que solía llamarse Hop Toad y ahora se llama Airbrake.

Tengo que ser respetuoso con la industria. Fueron los pioneros pero fue el primer intento de esto. Fueron como, déjemos intentar esto. Creo que fueron esos chicos y una empresa llamada Exceptional, terminaron fusionándose juntos.

Josh: El cual Exceptional era básicamente la encarnación anterior de los chicos de Intercom.

James: Así es. Sí, los fundadores de Intercom originalmente construyeron Exceptional, eso es correcto. Así que la vendieron a los chicos de Airbrake y se fusionaron juntos y ambos estaban resolviendo el mismo problema. Básicamente estaban diciendo, oye, en lugar de simplemente escarbar en archivos de registro o la versión 0.1 de monitoreo de errores que es que cuando ocurre un error, te envíes un correo electrónico a ti mismo, ¿por qué no simplemente lo ponemos en una base de datos y lo mostramos en un panel? así que esa fue la fase uno de este espacio.

Creo que allanaron el camino para la base de monitoreo de errores proactivos de servicio, pero lo que sucedió es que en Heyzap terminamos construyendo un producto móvil y el monitoreo de errores móviles fue terrible y el primer incursión para mí en el monitoreo de errores como persona de productos fue escribir el agente escribiendo el SDK que enviaba errores de aplicaciones Android a Airbrake.

Así que en realidad hice una biblioteca OpenSource que se enviaba a la API de Airbrake, y llegué al punto en que dije, eso fue fácil. Esa fue la parte fácil, detectar y enviar estos errores. Pero los errores se presentan de la manera incorrecta, están agrupados incorrectamente, la alerta no está allí. No puedes saber cuál fue el impacto del usuario. Entonces, en realidad, inicialmente construimos este negocio porque estábamos rascándonos una picazón. No había nada que estuviera resolviendo activamente el problema de la manera en que creíamos que debería resolverse.

Hubo un par de empresas al mismo tiempo que surgieron alrededor del momento en que estábamos construyendo Bugsnag, Sentry siendo la principal. Y sí, desde entonces simplemente hemos estado...

Recuerdo el primer día cuando nos propusimos construir la hoja de ruta para Bugsnag, teníamos una hoja de ruta de dos años que escribimos y cuatro años después, hemos hecho todo eso, pero creo que nuestra hoja de ruta es ahora aún más larga que eso.

Cuanto más profundas te adentres, más te das cuenta de que los problemas...

Josh: Son mucho mayores.

James: Exactamente. Están los conceptos básicos de tengo una pequeña aplicación de PHP o Ruby o lo que sea, y solo quiero saber cuándo sucede cada falla, esa es la parte fácil. Pero lo que estamos encontrando es que cuando entras en empresas más grandes como Airbnb o Pandora, este tipo de empresas, los problemas son muy diferentes en escala.

Siempre le digo esto a la gente, es muy fácil saber que tienes errores, es muy difícil en realidad arreglarlos y hacer algo al respecto. Y entonces el espacio del problema ha cambiado, en lugar de decir aquí hay una lista de todos los errores que tenemos, que es el problema fácil, ahora es cómo te enfocas en los errores que importan y cómo entregas proactivamente correcciones a los clientes más ampliamente afectados o errores ampliamente afectados.

Así que sí, es interesante cómo resolver el mismo problema, incluso dentro del ámbito del monitoreo de errores, los problemas cambian dentro de ese espacio.

Josh: Y quiero decir, creo que ese es el caso, me parece que en el pasado, no sé, hace cinco, quizás incluso diez años de la web y simplemente construir software... las herramientas son tan, la barrera de entrada es tan baja que durante mucho tiempo, todos simplemente han estado construyendo cosas lo más rápido que pueden, pero lo que sucede es que te das cuenta de que solo tener los datos en sí mismo es, bueno, puede ser útil, en su mayoría no puedes hacer nada con eso, ¿verdad?

Así es con nosotros con Baremetrics, es como que podemos decirte números todo el día, pero ¿y qué? ¿Qué vas a hacer con eso? Y esa es la parte difícil.

James: Lo has clavado. ¿Sabes qué, en realidad? Esto me recuerda, así que Simon y yo, nuestra primera compra como empresa, como un negocio incorporado fue comprar una pizarra en Craig's list para poder escribir ideas y cosas en nuestro dormitorio/oficina que teníamos. Y escribimos, creo que cuatro cosas en esa pizarra, y la primera en la lista fue respuestas en lugar de datos, y esto es exactamente, creo que hay muchas herramientas que te darán datos, pero eso no es útil si estás tratando de resolver problemas y priorizar.

Entonces, literalmente, uno de nuestros principios fundacionales fue respuestas en lugar de datos. ¿Podemos entregarte un paso más o diez pasos más que solo un archivo de registro o una lista de problemas?

Sí, es verdad, cualquiera en software está resolviendo el mismo problema en este momento con eso.

Josh: Por supuesto. Entonces, ¿obviamente ustedes han decidido construir este rastreador de errores de aplicaciones pero ayudando a las personas a entenderlo mejor? ¿Qué rol antes de Bugsnag, sé que estuviste bastante involucrado en hacer cosas de OpenSource...?

James: Sí.

Josh: ¿Entonces qué papel jugaron todas las cosas OpenSource anteriores en el éxito de Bugsnag?

James: Esa es una gran pregunta. Creo que la biblioteca de construcción OpenSource es, eso es lo que solía hacer en el mundo OpenSource y todavía lo hago estos días es construir bibliotecas.

Y la idea era que, oye, he resuelto este problema, este problema no es un problema que sea único para mí, voy a limpiarlo, extraerlo, y compartirlo con todos los demás. Y así, una parte genial de Bugsnag es nuestro SDK, son nuestras bibliotecas que detectan estos fallos y los reportan y así cuando nos propusimos construir Bugsnag muchas herramientas en el espacio que hace monitoreo de errores, especialmente en el lado móvil que es una de nuestras mayores áreas de crecimiento en este momento, no comparten el código fuente de su solución de monitoreo de errores.

Un par de ellos por ahí, hay CrashTheLines y Apteligent, ambos tienen SDK de monitoreo de errores de código cerrado y ni siquiera me pasó por la cabeza hacer eso cuando construimos el negocio. Para mí, ese no es el secreto especial, eso no es lo que estamos vendiendo a nuestros clientes, estamos vendiendo la experiencia de encontrar y arreglar más rápido. No estamos vendiendo un SDK, y así sí, al tener esta experiencia en OpenSource y construir bibliotecas, creo que me enseñó dos cosas.

Número uno me ayudó a entender el valor de hacer eso, ¿verdad? Entonces la gente puede ver detrás de la cortina cuando construyes cosas en el mundo del código abierto. Por ejemplo, en nuestra biblioteca de Android que detecta fallos en aplicaciones de Android, creo que fue, probablemente no puedo decir el nombre de la empresa, uno de nuestros grandes clientes en el lado móvil del consumidor, evaluaron a todos los competidores y dijeron, oye, nos fuimos contigo porque tienes todas estas bibliotecas de código abierto porque queremos contribuir a ellas y queremos ver qué estás construyendo bajo el capó.

Para mí eso fue solo un valor predeterminado, así es como opero. Y fue realmente, realmente empoderante ver que nuestros clientes pensaban lo mismo. Creo que la segunda cosa es que no hay códigos de trucos, no hay cortes de fuente cuando trabajas en OpenSource. Estás trabajando al aire libre, y así tienes que pensar, ¿se siente esta biblioteca como algo apropiado para la comunidad que estoy construyendo?

Podrías tener un conjunto de principios guía para bibliotecas de monitoreo de errores, pero la que construyes para Ruby probablemente tiene que sentirse un poco diferente a la que construiste para Android, probablemente tiene que sentirse un poco diferente a la que construiste para Python. Y si construyes de la forma OpenSource y compartes todo ese código e interfaz con tus clientes, no puedes esconderte.

La comunidad de Python es un buen ejemplo aquí, así que existe este concepto de ser pythónico que la gente se enorgullece en la comunidad de Python. Estoy de acuerdo con esto también, es mi trasfondo. Vine de la comunidad de Python hace un tiempo. Eso es si tu código está escrito de una manera pythónica, los desarrolladores de software es más probable que respeten tu biblioteca y por lo tanto la adopten en su base de código.

Así que sí, creo que esas son más o menos las principales cosas que saqué de mi trasfondo de código abierto. También creo que construir bibliotecas para mí, y construir SDK es muy similar a construir un producto. Estás construyendo, es una experiencia de usuario. Una biblioteca es solo un conjunto de interfaces de usuario, simplemente sucede que son funciones y clases en lugar de interfaces visuales. Así que creo que eso me dio un respeto saludable por la construcción de productos también.

Josh: ¿Crees que el trabajo anterior de código abierto te ayuda a conseguir clientes iniciales o es más o menos irrelevante?

James: Más o menos depende, así que tiendo a trabajar en el idioma que sea en el que estoy trabajando en el momento, así que tuve dos grandes proyectos de código abierto, uno o dos complementos de JavaScript que son bastante antiguos estos días pero basados en consultas y una gran biblioteca de Android que construí que fue HDP Cline en Android.

Y lo que sucede es que para Bugsnag, porque somos multiplataforma, apoyamos el monitoreo de errores en prácticamente cualquier plataforma, móvil, navegador de escritorio, lo que sea que estés usando. Tener experiencia en Android significaba que podía hablar un poco en conferencias de Android, pero eso era todo, realmente. No me dio ninguna credibilidad en ninguna de las otras plataformas.

Pero sí recuerdo, creo que, cuando fuimos a Airbnb por primera vez para mostrarles el producto, son uno de nuestros clientes, uno de los chicos allí fue como, ah, solía usar tu biblioteca http, y es algo divertido porque cuando escribes software de código abierto me parece que simplemente lo estás haciendo detrás del teclado y sí, podrías tener muchas estrellas en GitHub, o personas bifurcando tu producto en GitHub, pero conocer a alguien en la vida real que ha usado tu producto antes es una experiencia completamente diferente, es algo emocionante.

Sí, creo que en esa situación sí me dio un poco más de credibilidad. Pero no para ninguna de las otras plataformas, me gustaría que sí.

Josh: Te entiendo. Así que obviamente hay una abundancia de herramientas para desarrolladores, simplemente en general, solo registro de errores o cualquier cosa así, pero básicamente hay un número infinito de herramientas a disposición de un desarrollador, así que como desarrollador tú mismo, ¿cómo haces para no abrumarte por las herramientas a tu disposición, y también no distraerse, como, esta herramienta aleatoria va a resolver todos mis problemas?

¿Cómo te mantienes enfocado en usar solo las herramientas que realmente marcan una gran diferencia?

James: Esa es una muy buena pregunta. Hablo mucho sobre esto con mi equipo. No sé si viene con la edad, porque he estado programando durante mucho tiempo y la selección de herramientas ha sido parte de mi trabajo durante mucho tiempo, pero he sido muy, muy pragmático en estos días. Creo que, solía ser, la forma en que aprendí a construir software en primer lugar es que intentaría todos los últimos y mejores software nuevos y construiría toneladas de proyectos secundarios y jugaría con ello.

Literalmente, hace solo ayer, estaba jugando con una herramienta llamada Roll Up que es un sistema de agrupación de JavaScript que está peleando un poco con Web Pack en este momento. Y solo en un pequeño proyecto secundario con el que estaba jugando, pero cuando se trata de construir y elegir herramientas para el trabajo, para Bug Snag, para el día a día, muy mucho inclino hacia el lado de ser pragmatista, así que honestamente estos días no tengo mucho que decir en la selección de herramientas. Normalmente es mi cofundador o los equipos de ingeniería. Pero si alguien me pide consejo sobre esto, diré, ¿cuál es la herramienta más popular o la herramienta que es estable pero con tendencia ascendente?

Entonces, cuando elegimos un marco de JavaScript para nuestro panel de control. No era como, vamos a elegir el marco de JavaScript más genial. Era como, ¿cuál está mejor soportado, hay grandes empresas usándolo? ¿La calidad de la cadena de herramientas es de alta calidad? Todo ese tipo de cosas.

Entonces sí, todo esto conduce al pragmatismo en estos días, pero creo que esa es la manera de hacerlo. Creo que si juegas con lo de vanguardia en proyectos secundarios, pero luego te atienes al enfoque pragmático para producción, si eso tiene sentido. Creo que puedes terminar con lo mejor de ambos mundos, y creo que eso es cierto tanto para bibliotecas como para herramientas y servicios que estás usando.

Quiero decir, una de las cosas sobre las que mi cofundador y yo hablamos todo el tiempo es cómo elegimos software. Y la mayoría de las veces es por reputación. El boca a boca, no creo que sea un modelo de negocio sostenible de mil millones de dólares, pero ¿sabes qué? Te consigue grandes clientes y elijo software por lo que la gente está hablando en Twitter o en grupos de Slack en los que estoy. Entonces, eso para mí es otro aspecto.

Pragmatismo más prueba social, supongo.

Josh: Sí, creo que es fácil, especialmente cuando estás en los primeros días de construir una empresa, o si eres, digamos, un emprendedor por primera vez o algo así. La sensación o la suposición de que la próxima herramienta de alguna manera va a resolver algún gran problema para ti, cuando la mayoría de las veces, las herramientas en sí simplemente optimizan algún hábito o flujo de trabajo dado, ¿verdad? Rara vez cambian las cosas de manera importante.

Como si ya no estuvieras...

James: Exactamente, exactamente, sí. Es, incluso recuerdo cuando hicimos mucho trabajo, usamos mucho elastic search en Bug Snag, y elastic search lanzó una nueva versión y dijimos, "Mira el registro de cambios, esto va a cambiar realmente de manera fundamental la forma en que construimos cosas". No lo hizo.

Josh: Correcto.

James: Es lo mismo, es el mismo software. Hace lo mismo. Construyes el valor sobre las herramientas, creo que esa es la máxima. Las herramientas son la capa de pegamento, sí, puedes reducir la fricción como dices, y puedes deshacerte de algunas de las tareas repetitivas, pero sí, creo que construyes valor sobre las herramientas.

Josh: Bueno, y asumo que en vuestro caso, si alguien llega y no ha estado haciendo ningún tipo de rastreo de errores o no tiene nada en su lugar para mejorar consistentemente su producto, probablemente no va a ser un cliente muy exitoso porque eso no es algo que hayan estado haciendo desde el principio.

James: Sí, es, ¿sabes qué? En realidad, cuando comenzamos este negocio, ni siquiera hablábamos con personas que no hubieran usado algún tipo de monitoreo de errores antes.

Josh: Sí,

James: Pero la mayoría de las veces, es ahí donde estamos construyendo mucho valor para el negocio. Entonces, si tienes una aplicación muy pequeña, una tienda muy pequeña que tiene algunos errores de aquí y de allá, entonces Bug Snag es genial, pero ¿cuánto mejor es que algún tipo de monitoreo de errores básico, o enviarte un correo electrónico cada vez que hay un bloqueo?

Es mejor pero, ¿va a proporcionar mucho más valor?

Lo que sucede es que estos días, especialmente del lado del cliente en móvil, en el monitoreo del navegador y el monitoreo de JavaScript, es que las personas saben que tienen un punto de dolor pero no saben cómo resolverlo. De hecho, creo que hablé con otro fundador recientemente sobre esto.

Cuando primero construyes un negocio que está resolviendo un problema muy específico, asumes que tu mercado va a ser personas que entiendan el problema. Y después de que ganes un poco de madurez, resulta que, al menos en nuestro negocio, el negocio más grande, el negocio de mil millones de dólares está en personas que saben que hay un dolor pero no entienden que el monitoreo de errores, por ejemplo, es la forma de resolverlo, y así terminamos hablando con mucha gente especialmente en conferencias o eventos o reuniones y ese tipo de cosas que están como, escuchamos quejas de nuestros clientes de que la aplicación está rota y simplemente no sabemos cómo.

Y sería muy fácil para mí pensar que todos construyen software de la misma manera que yo construyo software y que entiendes que el monitoreo de errores es una parte esencial de tu negocio, y una parte esencial de tu pila, pero en realidad, creo que probablemente el 90% de los equipos de software que existen saben que hay un punto de dolor pero realmente quieren ayuda para entender cuál es la mejor manera de resolver eso.

Entonces, esa ha sido una comprensión realmente transformadora para mí durante los últimos años: asumir que todos saben que necesitan una herramienta como esta probablemente nos habría llevado a un negocio de 50 millones, pero en realidad el problema más grande es oye, mis cosas están rotas y no sé por qué. Y no sé cómo resolverlo.

Josh: Entonces, ¿cómo abordas eso desde la perspectiva de ayudar a las personas a saber cómo arreglar el problema que no pueden identificar, no saben cómo verbalizar qué es, simplemente saben, hey hay este problema más grande. Pero ¿cómo vienes y dices, sí, este rastreo de errores o registro o exposición de problemas que tus clientes están teniendo... cómo los educas en que esa sea la solución?

James: Sí, buena pregunta. Entonces realmente se trata del dolor. Creo que depende de con quién estemos hablando en la organización, pero realmente, saben que el dolor existe, ¿verdad? En el peor de los casos, vas a recibir tweets o correos electrónicos enojados de tus clientes diciendo que esto está roto. Entonces, eso nunca, como equipo de software o equipo de producto, eso nunca es un buen sentimiento, escuchar a los clientes quejarse.

Entonces, en el lado más visceral de las cosas, cuando tus clientes se quejan te sientes mal al respecto, así que hay ese dolor integrado ya, pero lo que estamos viendo la mayoría de las veces es en realidad resultados tangibles de ese dolor, así que, comenzamos esta conversación hablando de cómo nunca ha sido fácil construir software estos días y los clientes tienen opciones estos días, entonces lo que sucede es cuando estás evaluando productos...

Uno de nuestros clientes, no puedo decir el nombre porque se enfadarán si lo digo, pero cuando comenzaron a usar Bug Snag, comenzaron a usar el producto porque tenían una calificación de una estrella en la tienda de aplicaciones, la tienda iTunes, y estaban como, esto apesta, esto es vergonzoso, la gente piensa que somos un producto mediocre y así esa era su razón tangible para poner en su lugar el monitoreo de errores era que estaban siendo calificados en público en cuanto a la calidad de su software.

Esto se está volviendo cada vez más prevalente estos días con todas estas diferentes herramientas como Product Hunt o Stack Shed que te permiten comparar productos manzana con manzana y si la gente está diciendo bueno, este está fallando o este es lento, no vas a ir con ese producto.

Entonces, en lugar de solo tener este factor de boca a boca, hay casi como un resultado tangible: tu producto es mediocre, esta es la calificación de calidad de tu producto, y eso, podemos educar sobre cómo puedes pasar de mediocre a bueno y ese es nuestro trabajo, ayudar a las personas a ver que hay un camino para resolver esto, pero en realidad el punto de dolor está ahí, ya está en las mentes de los equipos de producto.

Josh: Entonces, ¿cuál ha sido una parte clave del éxito de Bug Snag? ¿Ha habido algo que realmente haya cambiado el crecimiento para ustedes? ¿O dos cosas, tres cosas?

James: Sí, quiero decir, uno creo que el enfoque es importante. Creo que siempre nos hemos enfocado en la experiencia del producto, ¿verdad? Creo que sería muy fácil continuar agregando nuevas plataformas que soportamos o agregar saltar cuando nuestros clientes dicen construye esta característica, pero creo que tener una experiencia de producto holística de extremo a extremo ha sido lo que nos ha mantenido en marcha a una tasa de crecimiento constante.

En términos de puntos de inflexión, construimos, creo que fue hace unos 18 meses. Cambiamos la forma en que modelamos nuestros datos para permitir a las personas filtrar y enfocarse en qué errores son los más importantes, así que construimos todo un nuevo panel. Lo llamamos dashboard 2 internamente.

Construimos todo este nuevo panel que te permite resaltar mejor los peores problemas, y creo que ese ha sido el punto de inflexión más grande para nosotros porque como dije antes, el problema de entender qué errores están sucediendo en tu aplicación Ruby on Rails de bajo volumen es que creo que hacemos un trabajo bastante bueno en eso, pero cuando entras en el espacio del problema estoy en el lado del cliente o soy una aplicación de consumidor y estoy recibiendo decenas de millones de informes de bloqueo por día o cientos de millones de informes de bloqueo por día, se convierte más bien en un problema de señal a ruido que en un simplemente tengamos una lista de errores problema.

Entonces construimos este nuevo panel y creo que fue hace alrededor de un año que comenzamos a obtener este buen boca a boca en el espacio del consumidor. Esto fue alrededor de la época en que Air BnB comenzó a usarnos, Pandora comenzó a usarnos y todos estaban como, sí, genial, el monitoreo de errores es algo, pero cuando tengo cien millones de errores al día y tengo cien desarrolladores trabajando en este problema, ¿cómo puedo realmente resolver estos problemas?

Entonces hicimos este gran cambio de panel y creo que eso ha tenido un impacto bastante grande en el negocio. Nos ha permitido no solo resolver problemas para contribuyentes individuales y pequeños equipos de desarrollo sino también avanzar hacia el mercado más grande para equipos de desarrollo más grandes.

Josh: Entonces, ¿hubo una época, en la inversa de eso, así que has tenido este buen crecimiento y ha habido algunas cosas que han sido estos puntos de inflexión para ti, pero hubo una época en la que pensaste que Bug Snag no lo lograría?

James: Creo que lo interesante de las startups es en el negocio SaaS, cuando eres un negocio SaaS que genera ingresos, y este es el material que hablas todo el tiempo y nosotros hablamos todo el tiempo como fundadores, siento que siempre podríamos lograrlo. Siempre hay una forma de mantener el negocio en marcha. Creo que establecemos altas expectativas para nosotros mismos como compañía, y a veces estamos como, no estamos cumpliendo esas expectativas, o queremos crecer más rápido de lo que estamos creciendo ahora, y así la buena noticia de ser un negocio SaaS que genera ingresos es que creo que siempre hemos estado en un estado financiero saludable, pero la pregunta es más cómo podemos acelerar el negocio sin quemar nuestro dinero.

Este es el, encontrar ese punto dulce de crecimiento, ¿verdad? Encontrar el punto dulce de aceleración, creo, es la parte difícil. Y te diré cuál es la cosa más difícil, la gente siempre me pregunta y estoy seguro de que te hacen la misma pregunta. ¿Cuáles son las cosas más difíciles del negocio?

Siempre he dicho contratación y fijación de precios, y la contratación al principio de la compañía especialmente siendo fundadores británicos en el Área de la Bahía, no teníamos una red desde la que contratar, y así encontrar personas que se unieran al equipo fue muy difícil.

Eso cambia un poco estos días y eso es, especialmente cuando estoy creciendo mi equipo ejecutivo o mis gerentes, estoy como, ¿cómo encuentro personas que crean en nuestra filosofía y nuestra visión como negocio? Pero luego en el lado de la fijación de precios, creo que lo más cercano que hemos estado a estar como, uh oh esto es aterrador es cuando pasamos por un par de iteraciones de precios, así que cuando comenzamos el negocio, precios en un modelo de todo lo que puedas comer. Básicamente dijimos que puedes tener tantos datos, tantos informes de bloqueo como quieras, y básicamente cobramos por el número de desarrolladores que usaban el producto.

Entonces cambiamos nuestro modelo de precios para duplicar eso en cierto momento y simplemente no se sentía bien, y no funcionó. No se alineaba con el valor que estábamos proporcionando. Y así creo que, no sé, esto parece ser la número uno de las cosas que surgen cuando estoy hablando con otros fundadores es que los precios que nunca aciertas, y siento que eso es una cosa liberadora de entender. Creo que si yo, como desarrollador de software, siempre siento que hay una respuesta correcta a un problema y luego puedes refactorizar algo tan bien que es la respuesta perfecta, pero cuando se trata de precios, leí un buen artículo, y este es tu negocio también para que puedas hablar sobre esto.

Siento que es muy liberador cuando entiendes que nunca acertarás el modelo de precios perfecto, y es una experiencia iterativa en lugar de una experiencia de esta es la respuesta correcta.

Pero sí, creo que para volver a tu pregunta, realmente nunca pensé que no lo lograríamos, a veces sentí que habíamos tomado decisiones que ralentizaron el crecimiento del negocio y especialmente alrededor de los precios. Esa es una de esas áreas clave.

Josh: Es una de esas cosas, como es una parte necesaria de eso, ¿verdad? Porque si no lo intentas, no sabrías que no funcionó y si no lo sabes, entonces potencialmente te has perdido algo que podría haber sido algo excelente, ¿verdad?

James: Correcto, pero es aterrador porque los precios son tal, todavía hoy, los precios son tal ancla esencial para tu negocio que, quiero cambiar cosas, y...

Josh: Bueno, y hace que la gente sea realmente emocional... sí, lo siento, adelante.

James: Exactamente, exactamente y ¿recuerdas Zen Desk hace un par de años? Hicieron un cambio de precios y no dieron derecho adquirido a la gente y eso fue este enorme alboroto alrededor de eso, fue algo de locos.

Josh: Sí. Entonces, terminando aquí, ¿qué le depara el futuro a Bug Snag? ¿Así que ustedes tienen algunos miles de clientes ahora? ¿Tres o cuatro?

James: Sí, nos estamos acercando a cuatro mil organizaciones pagadoras usando el producto ahora.

Josh: Entonces, ¿cómo se ve el producto para los próximos cuatro mil clientes?

James: Esa es una buena pregunta. Creo que la forma en que tenemos las cosas configuradas ahora es que hemos hecho un trabajo realmente, realmente bueno informando a los ingenieros y gerentes de ingeniería qué está roto y cuáles son los peores problemas y cómo solucionarlos. Ese es el núcleo de nuestro negocio y creo que lo que escuchamos cada vez más de nuestros clientes es ayúdanos a entender tendencias y patrones, ayuda a mi CTO a entender el estado del negocio. O expandiendo las cosas a otras áreas del equipo de producto. Uno de los ejemplos aquí es que tuvimos este cliente que tenía un programa piloto en el que estaban trabajando, y creo que era un trato de siete cifras en el que estaban trabajando y su panel de control se rompió durante este programa piloto, y el ingeniero de ventas y el vendedor no sabían que el panel se rompió y luego perdieron la venta.

Entonces, incluso un ingeniero de ventas o un representante de ventas en la empresa, si eres un negocio de software, todos en el negocio se preocupan por si el software está funcionando o no. Pero la vista que estamos presentando ahora en nuestros paneles, que es aquí está la lista de errores y aquí están los peores errores y aquí está cómo solucionarlos, no es necesariamente la vista correcta para mostrar a tu equipo de ventas, o tus representantes de atención al cliente o incluso tu CEO o tu CTO.

Entonces, tomando esos datos básicos que hemos estado recopilando y destacando y mostrándolos de formas que son más apropiadas para el resto de la organización de producto. Entonces esto es casi un problema de capas. Creo que no los problemas muy difíciles en torno a la recopilación de datos y la detección de fallos y los problemas subyacentes creo que hemos hecho un buen trabajo resolviéndolos, pero hacer que esos datos sean más accesibles para el resto de tu organización.

Si eres un negocio que está construido alrededor del software, entonces todos deberían preocuparse por si está funcionando o no y si estás entregando una alta calidad.

Entonces, es más o menos hacia donde vamos.

Josh: ¿Sientes que acabas de empezar? Has estado haciéndolo durante algunos años pero al mismo tiempo, los problemas, todavía tienes un problema realmente grande que resolver, ¿verdad?

James: Sí, digo esto todo el tiempo, siento que esto no es algo donde dices, bueno, ya es un problema resuelto, lo arreglamos.

Josh: Correcto.

James: Cada vez que profundizas descubres más y más problemas y creo que el objetivo principal, la cosa principal que estamos intentando resolver es que cada vez que profundizamos nos damos cuenta de cómo podemos hacerlo mejor, y cómo podemos hacer que sea una experiencia aún mejor para nuestros clientes y entonces eso es lo más emocionante, eso es lo que me saca de la cama por la mañana. Es que hay tantos problemas que resolver, y entonces sí, me pregunto si esto es cierto para todos los negocios pero ciertamente es verdad para nuestro negocio.

Josh: Aquí lo tienen, James Smith de BugSnag.