Hace 5 años, nos embarcamos en uno de los proyectos más raros, pero a la vez, uno de los más emocionantes que nos haya tocado hacer porque nos sirvió para aprender más y mejor de nuestros clientes y ayudarles a tomar un mejor camino en sus decisiones tecnológicas. Curiosamente, surgió de quien en ese entonces no parecía ni siquiera tener perfil de cliente: una firma de venture capital muy grande de los Estados Unidos. Esta firma había liderado una ronda de inversión de una de las startups que habíamos ayudado a construir, y sabiendo que habíamos trabajado muy cerca de ellos nos plantearon una pregunta intrigante: "Ustedes han trabajado con muchas startups, ¿guardan los datos de todo lo que hacen?"

‍

En ese momento, sospeché que querían comprar algo que habíamos desarrollado para alguna startup que falló en el pasado. Pensé en las implicaciones: nuestro trabajo es 100% confidencial y teníamos firmados NDAs con nuestros clientes así que no tenía mucho sentido seguir la charla además que jamás tiraría por la borda más de 20 años de trayectoria. Así que respondí, algo desconfiado: "Sí, pero esa información no está disponible."

‍

El hombre con bastante insistencia me repregunta: "¿Conoces el concepto de 'patrones'?"

‍

Como ex docente de Diseño de Software, respondí con confianza: "Claro que sí, me dediqué a enseñar ese concepto durante 18 años."

‍

Él continuó: "Bueno, me gustaría entender si se puede encontrar en todo el código y otra información que tengan, las cosas que se repiten en las startups que tienen éxito. Si crees que es posible, hablemos en unos días…”.

‍

Quedé desconcertado y emocionado a la vez, no imaginé que esa sería su intención, pero de repente, la idea me pareció fantástica. Encontrar predictores del éxito en el comportamiento de las startups con las que trabajamos en el pasado…brillante!

‍

Después de meditarlo bastante, acepté su propuesta unos días después, pero con un twist más interesante: "Vamos a hacerlo, pero además, vamos a realizar un trabajo que consideramos aún más útil: vamos a buscar qué cosas en común tienen las startups que fracasan." Nuestra lógica: el fracaso es frecuente y abundante y el éxito, un evento atípico, o más bien: escaso. 

‍

A modo de contexto, ayudamos a startups hace 26 años. Empezamos cuando aún no se les llamaba así en Latam. Empezamos con algunos “padres” de soluciones que hay al día de hoy como Bumeran (una versión latinoamericana de Match.com) o Yahoo Encuentros (la versión vintage de Tinder) y continuamos ayudando a más empresas a crear sus productos en Argentina y en Estados Unidos principalmente. Esta experiencia de tantos años nos permitió, tanto en la ayuda a los founders en la toma de decisiones como en la particularidades que tiene hacer tecnología para una empresa que aún no lo ha logrado y que va a "virar" muchas veces hasta lograrlo (o morir). Por diferentes razones, muchas endógenas y otras no tanto, nuestro portfolio tiene algo más de 10 veces la media de éxito del mercado en la región y esto es lo que nos hizo interesantes para realizar el estudio.

‍

Para llevar adelante el análisis, juntamos a varios referentes del equipo de Digbang. Todos venimos trabajando en tecnología y escenarios de Data desde hace muchos años pero tuvimos la suerte de contar entre filas con una de nuestras líderes que tiene formación en Matemáticas. Con su ayuda, armamos un pequeño método de estudio donde analizando código, analytics y project tracking, terminamos determinando cuáles eran las variables independientes más relevantes que funcionaban como predictores a la hora de determinar el conjunto de éxito y cuales el conjunto de fracaso.

‍

Por tratarse de un estudio privado, hay una buena y una mala noticia. La mala: no podemos publicarlo. La buena: el año pasado nos autorizaron a hacer públicos algunos datos sobre lo que llamamos "predictores del fallo". Acá van algunos de los descubrimientos que nos parecieron más interesantes junto con algunas historias tragicómicas que tuvimos. La muestra que tomamos para hacer el estudio fueron 130 startups de diferentes industrias y tamaños - aproximadamente el número de compañías que habíamos ayudado a desarrollar hasta ese entonces - y que estaban lideradas tanto por fundadores técnicos como no técnicos.

‍

Primera conclusión: Los startups con más foco en tecnología que en el usuario tuvieron el triple de chances de fracasar (excluyendo los casos de DeepTech).

Un ejemplo bastante particular que refleja esta conclusión fue el de una empresa con un que nos hizo hacer un stress test para soportar 200.000 usuarios diarios a los 6 meses. La realidad, más allá de las fantasías del CTO, es que el pico máximo de la historia del startup no superó los 3000 usuarios diarios. Otro ejemplo parecido: Una muy conocida startup (con inversión de más de 20 MM) que hicimos desde 0, tomo un CTO que terminó rehaciendo el producto entero en su lenguaje favorito, le tomó un año entero usando un equipo 3 veces más grande que el que fabricó el producto y la startup cerró menos de un año más tarde.

‍

Segunda conclusión: La diferencia entre las startups exitosas y las que no lo fueron en cuanto a la cantidad de cambios realizados al prototipo (o plan) original en los siguientes 12 meses fue abismal...más de 4 veces.

Un ejemplo de esto fue el de una startup basada en Blockchain que prolongó su “etapa de MVP” por 21 meses, prácticamente fabricando el producto entero que habíamos visualizado en el Discovery, para tener un producto "imbatible" al salir. La espera no fue tan buena: a los 2 meses de salir la cantidad de cambios necesarios para adaptar "el producto ideal" a las necesidades de los primeros usuarios superó los 6 meses de trabajo y a los 10, redujeron el equipo por falta de presupuesto.

‍

Tercera conclusión: Más del 70% de los startups que fracasaron, desperdiciaron casi 20% de su código en funcionalidades que no usan (o que las usan sólo el 5% de sus usuarios)

Cuando trataba de recordar alguna anécdota relacionada con esta afirmación, me pasó algo extraño. Es un problema tan presente que no puedo enfocarme en ninguna en particular. Lo que vemos es en general dos grupos: los que se adelantan a construir cosas que nunca usan y los que quieren generalizar cada escenario que tienen, creando, sin duda, un código super elegante, mantenible y escalable, obtendrían un 10 en la universidad, pero muy poco realista para estos escenarios.

En todos estos casos, nuestro trabajo más allá de ayudar a estas empresas a pensar y construir sus productos es intentar influenciarlos para que estos sesgos no los afecten. En nuestra experiencia, ha sido más fácil influenciar positivamente a compañías donde su fundador no es técnico y a aquellas donde hay un founder técnico con buena trayectoria como CTO (donde no tiene un rol de programador en el proyecto). 

Tenemos varias teorías de por qué sucede esto pero, llevaría un artículo aún más largo que este, y nos hemos ganado algunos enemigos al mencionarlas...así que preferimos dejarlas para chalas 1:1 y que no nos prendan fuego al mencionarlas públicamente ;)

‍

Demian Schnaidman es CEO en Digbang. Conecta con Demian aquí.

‍

‍