Factores del éxito de una startup y Lean Startup

Factores del éxito de una startup

Nuestro objetivo a más corto plazo estaba claro, conseguir inversión en menos de 6 meses. Probablemente, era un objetivo erróneo y debíamos pensar en un objetivo más de negocio, como validar determinadas hipótesis o conseguir algunos hitos, pero tampoco íbamos tan desencaminados, ya que en el campus de Seedrocket habíamos aprendido lo que necesitábamos demostrar para conseguir inversión: Demostrar que teníamos un buen equipo, que el mercado era lo suficientemente amplio, que era el momento adecuado para lanzar ese proyecto y que teníamos indicios de tracción. Si conseguíamos demostrar todo esto probablemente conseguiríamos inversión, nos demostraríamos a nosotros mismos que valía la pena intentar esta aventura… y podríamos pagarnos un sueldo.

Este post forma parte de la serie que nos va a llevar a conocer toda la historia de Nautal, desde su creación a su venta y más allá. Si queréis ver los capítulos que nos van a conducir en este camino, mira el índice la de historia de Nautal.

• Equipo: Creo que el equipo era bueno y sobre todo estaba muy compensado
  • Roger era un experto en el sector, había trabajado en todos los frentes; ha vendido barcos, ha alquilado barcos, y ha sido contramaestre de un puerto. Esto se demostró muy útil, porque entendía todos los puntos de vista de la gente involucrada en el sector y, además, transmitía esa pasión que convencía a indecisos de colaborar con una startup.
  • EduR era un desarrollador que había estado en Deloitte. Su perfil es curioso, una mente brillante en un corazón inquieto; había hecho de todo: derecho, matemáticas, filosofía… y había aprendido a programar y trabajó en el departamento de ERP de Deloitte.
  • EduL era un director de producto que acumulaba más de 8 años de experiencia en usabilidad web. Esto en 2013, por lo que en 2005 ya había comenzado en algo que por aquél entonces era mucho menos común que ahora.
  • Y por mi parte, había llegado a ser gerente de Deloitte, lo cual presupone un nivel de aprendizaje y dedicación y había, junto con los dos anteriores socios, creado un proyecto previo, que aunque no había salido bien, había permitido aprender mucho.
• Mercado: En el mundo desarrollado hay más de 30 millones de barcos totalmente infrautilizados.
  • Haciendo el cuento del chino (típico sistema que genera sarpullidos entre los inversores y que se basa en decir que si sólo vendiera al 1% de los chinos el proyecto sería muy exitoso) sobre un 10% de los 30 millones de barcos, aplicando 100 días de alquiler al año (estándar para las empresas de chárter) a 350 euros el día nos daba un mercado objetivo de más de 100 mil millones de euros de GMV al año.
  • Con los números un poco más elaborados obtenidos del Business Plan que describí en la anterior entrada del blog, nos daba un mercado objetivo conseguible de 6.000 millones de euros al año, que podía crecer a más de 15 mil si el P2P de establecía.
• Timing: El consumo colaborativo estaban comenzando a triunfar, y el sector del chárter de barcos era obvio que iría detrás de los apartamentos y los coches, por lo que ¡era el momento!
  • AirBnB había nacido en 2008 y en 2013-2014 ya tenía cientos de miles de estancias, millones de usuarios, y estaba facturando cientos de millones de USD al año… y ¡ya había alcanzado la categoría de unicornio en solamente 5 años!
• Tracción: como los factores anteriores ya los teníamos, nos centramos en demostrar tracción, lo que significa comenzar a tener ventas y que estas crezcan a buen ritmo. Como sólo disponíamos de 6 meses, sabíamos que debíamos correr mucho, y más teniendo en cuenta que el proyecto se inició en mayo y que el sector del chárter es altamente estacional, por lo que sólo teníamos unas cuantas semanas para prepararnos para el verano en el que teníamos que demostrar las ventas.

Nuestros primeros pasos

Como teníamos muy poco tiempo para demostrar las ventas, el ritmo fue muy fuerte y la priorización muy clara.

El 2 de mayo constituíamos Sal a Navegar y comenzábamos a trabajar en el proyecto y los primeros días de junio ya teníamos la web en producción bajo el dominio www.salanavegar.com

La mayoría de gente (incluso del mundillo) se sorprendía de un periodo de desarrollo tan corto. Para lograrlo, nos apoyamos en los que habíamos aprendido de Favoralia y planificamos hacer el desarrollo más sencillo posible que nos permitiera hacer las primeras ventas.

Básicamente necesitábamos:

• Una página donde los clientes vieran los listados de barcos
• Una página donde ver un barco en concreto
• Un formulario de contacto
• Una página de back office desde donde dar de alta un armador (propietario de barco)
• Una página de back office donde dar de alta un barco

A partir de ahí todo el proceso lo llevábamos de forma manual, creamos una campaña de AdWords para que la gente que buscara alquilar un barco encontrara nuestra web, atendíamos las peticiones mediante teléfono y emails y verificábamos el cobro y hacíamos las transferencias manuales desde la web del banco. Al principio un fundador debe ser un hombre orquesta, haciendo un poco de todo, y debe hacerlo razonablemente bien.

¡El día 8 de junio teníamos nuestra primera venta!

La tracción tiene mucho que ver con el Product Market Fit, y lo habitual es que el primer producto que saques no lo tenga, en consecuencia, casi diría que uno de los factores que habría que añadir al TOP 4 Factores del éxito de una startup es la velocidad de iteración. Porque a mayor velocidad de iteración, mayores posibilidades de conseguir el Product-Market-Fit antes de que te quedes sin caja. Incluso en un artículo que leí proponía que en lugar de contar los meses de vida que le quedan a la startup con la caja actual, se contara las posibles iteraciones antes de quedarse si caja. El ejemplo me gustó porque ponía el foco no sólo en el tiempo, sino en la agilidad de iteración; si reducías el tiempo de probar nuevas ideas e iterar, de alguna manera estabas aumentando el runway de la compañía.

Creo que todo este proceso fue lo más ágil posible para conseguir las ventas que queríamos demostrar para conseguir inversión, pero dista mucho de la metodología lean o agile que ahora abrazamos. Si nuestro modelo de negocio era alquilar barcos de particulares, los grandes riesgos del proyecto eran: 1) saber si los propietarios particulares alquilarían sus barcos a desconocidos, y 2) saber si los clientes alquilarían barcos de particulares que no cuentan con la infraestructura y homogeneidad de producto y calidad de una empresa de chárter.

Probablemente en 1 o dos semanas podríamos haber hecho unas cuantas encuestas entre propietarios de barcos montado una landing page para validar el punto 1 y alguna landing page apoyada por un poco de SEM para validar el punto 2. 

Lean Startup

Aunque creo que el inicio fue lo suficientemente bueno, ahora lo habría planteado de otra forma.

Para pensar sobre esto, me gusta mucho la definición de startup que hizo Steve Blank: Una Startup es una organización temporal formada para buscar un modelo de negocio repetible y escalable.

El término “Buscar” implica que debes innovar, averiguar, conocer algo que no conoces.

Por lo tanto, una Startup va más de buscar que de ejecutar un plan preestablecido (aunque la ejecución sea crítica).

La idea es ir avanzando en el conocimiento de la forma más rápida y económica posible, y para ello, el sistema que yo he aprendido se basa en responder a las siguientes preguntas:

• ¿Qué gran objetivo se fija? El fijar un objetivo es importante para marcar el destino al que quieres llegar y que las acciones que vayas tomando te acerquen a ese objetivo.
• ¿Cuáles son los grandes riesgos que existen para conseguir ese objetivo? No te enamores de tu idea, sé crítico, pregunta a amigos y a expertos para que te den feedback.
• ¿Qué experimentos harás para obtener respuestas a los grandes riesgos?
• ¿Cómo se obtienen las ideas que permitirán conseguir ese objetivo? Aquí básicamente hemos usado 3 opciones: preguntar a tus usuarios (cuando es una innovación más sencilla), acompañarlos en el proceso y pensar cómo podría ser mejor (cuando es una disrupción) y mirar a la competencia.
• ¿Cómo se priorizan? Para priorizar las ideas hemos usado la metodología ICE que me pareció muy interesante y que se basa en evaluar para cada idea: 
  1. Cuál es el impacto esperado de desarrollar esa idea (puedes valorarlo en téminos de ingresos generados o gastos ahorrados), 
  2. Cuál es el grado de confianza que tienes en que ese impacto se producirá si desarrollas la idea (por ejemplo, se una idea de bombero o es algo que grandes players ya han implementado), y
  3. Cómo de fácil es desarrollar esa idea (puedes apoyarte en los desarrolladores, en nuestro caso, nuestro CTO Jaume Bosch desarrolló unas cartas donde todos los desarrolladores votaban, para cada idea, las horas que estimaban de desarrollo)
• ¿Cómo se trocean? Un proyecto demasiado largo tiene demasiados números en los que algo puede salir mal… Debes conseguir que cada iteración permita aportar un poco más de valor al cliente, y que se pueda validar. No sirve trocear un proyecto en fases que no aportan ningún valor al cliente hasta el momento final.

• ¿Cómo se validan? ¡Con métricas! 
  1. Para pequeñas innovaciones hemos usado los test A/B: Hay herramientas que te permiten hacer este test que consiste en enviar la mitad de los visitantes a la web a la versión antigua y la mitad a la versión modificada. Fijando un objetivo (por ejemplo, la tasa de conversión de la página) te permitirá saber si la nueva página convierte mejor o peor que la antigua. 
  2. Para mayores disrupciones puedes fingir tener la solución y evaluar el comportamiento de los usuarios, por ejemplo con una landing page que simule que ya está todo el desarrollo hecho, pero cuando el usuario intente hacer la acción le informes de que está en desarrollo (y ya que está ahí le pides su opinión sobre algo relativo al proyecto). Con esas intenciones de los usuarios podrás saber si hay un interés real por esa idea o no.
• ¿Qué se hace con lo que no cumple el objetivo fijado? Eliminarlo, y no es tan fácil. Piensa en una idea que creías buena, que has tardado 3 semanas en desarrollar y que no ha cumplido con los objetivos que te habías fijado, pero que tampoco empeora nada. La tentación de dejarlo es enorme, pero es muy contraproducente, porque va complicando el código y eso hará que todos los desarrollos futuros sean más lentos y den más errores. Básicamente cumple el criterio KISS (Keep It Simple, Stupid!)

Aquí un vídeo donde hablaba de estas cosas (no me tengáis en cuenta la portada…)