Este artículo pertenece a la serie “Startupea”. Espero que sea de ayuda a esos locos a los que les gusta crear cosas de la nada. Si eres uno de ellos, sígueme en Twitter.
¿Se aprende más de los casos de éxito o de los fracasos?
Cuando vemos en la prensa casos de startups de éxito lo que normalmente nos muestran son los aciertos que les han hecho llegar a donde están. Pero para mí, sus fallos son tanto o más importantes en cuanto a ofrecer información útil. Cuéntame un acierto, y podré o no replicarlo. Cuéntame un fallo y podré evitarlo casi con seguridad.
Todos cometemos fallos. Errar es humano. Me gustaría contaros los principales errores que he cometido yo en Erasmusu.com desde su creación en 2008. Con suerte puede que evite que caigas en la misma piedra.
Algunas son cagadas monumentales, otras eran trampas casi imposibles de evitar. La mayoría las hemos logrado subsanar con el tiempo (ahora nos va bastante bien), otras al ser defectos de base, nos acompañarán mientras dure Erasmusu. Pero recuerda que así es como se aprenden las cosas, en las trincheras, dando guerra.
1. Lanzar la web con todo el contenido privado
Lo primero que hicimos cuando lanzamos Erasmusu en marzo de 2009 fue darle una puñalada a nuestro SEO.
Por aquel entonces, nuestro referente en cuanto a «hacer bien las cosas en esto de las redes sociales» era Tuenti. Y como a Tuenti le había ido genial con su sistema de invitaciones y con toda la web privada excepto la portada, así que salimos nosotros.
Pero el tema es que Tuenti es un red social, que como Facebook, se centra en tu red de contactos. Y sin embargo en Erasmusu, la clave es el contenido de calidad en torno a los destinos Erasmus.
Así que lo que conseguimos saliendo con toda nuestra base de datos de ciudades y universidades no accesible por buscadores fue un suicidio en cuanto al SEO se refiere. Todos los textos creados en los foros, experiencias, etc. por los usuarios eran invisibles para Google. Gallifante al canto.
Además, el problema cuando no te sobran los recursos de desarrollo y el tiempo para programar / diseñar, es que dar el salto de un sistema privado a otro público con las friendly URLs bien creadas, etc. no es trivial. Así que la broma nos salió cara.
2. Sacar demasiadas features en tu lanzamiento
Esta es casi imposible de evitar. Puedes leer esto miles de veces en diferentes artículos, que si es tu primer proyecto, caerás irremisiblemente en este error casi con seguridad. Nosotros pensábamos que salíamos con lo justo, y sin embargo, en retrospectiva, salimos con demasiadas cosas.
«¿Es necesario esta feature? – ¡Claro! ¡Lo tiene Tuenti y les va genial! ¡Es IMPORTANTE que lo tengamos!». Y así con infinidad de características que se cayeron de Erasmusu en iteraciones posteriores porque resultó que realmente nadie las necesitaba. Menudas risas me pego leyendo correos del verano de 2008 en el que estaba diseñando el UX del primer Erasmusu. Todo me parecía importantísimo.
La estrategia de toda startup nueva debería ser definir muy bien cual es el Minimum viable product, y una vez definido, darle algún que otro tijeretazo más. La idea es evitar crear algo que al final resulta que nadie quiere.
«The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.»
¡Ojo! Un MVP no es un producto incompleto. Haz que sea elegante y usable. Que su usabilidad y estética sean brutales. Pero no le añadas absolutamente nada más que lo imprescindible.
De esta forma:
- Gastarás menos tiempo en desarrollo.
- Empezarás a recibir feedback cuanto antes.
- Los usuarios serán los que marquen la futura evolución de tu producto. De forma real, según sus necesidades. Y no según hipótesis tuyas. No hay nada más real que la realidad.
- Te centrarás en lo realmente importante. Y como consecuencia, tu producto será de lejos, mucho más usable.
- Si tu producto no lo quiere nadie, te enterarás pronto.
- No arrastrarás secciones inservibles durante futuras iteraciones. Esas que no quieres borrar por molestarte el tiempo que invertiste en desarrollarlas.
- Podrás ver cuál es el impacto real en tus objetivos de cada nueva feature que vayas creando, por el mero hecho de ir probándolas según vaya tocando.
3. Intentar generar dinero mediante afiliación
Solo un chalado fuera de serie como David Bonilla (Otogami) puede intentar generar ingresos mediante afiliación y salirle bien la jugada. Para el resto de los mortales es un suicidio casi seguro.
No, en serio, será posible, sobre todo si lo que ofreces es una especie de marketplace al estilo de Otogami o apps como HotelTonight, ReallyLateBooking o ElTenedor, en las que todo está orientado a la reserva / venta. Es decir, como dice Carlos Sánchez: «Para ganar pasta en afiliación DEBES tener un proyecto orientado al 100% a una categoría de producto».
Pero si tienes un portal web, blog, red social, etc. como nosotros, y no estás orientado a un producto o marketplace de productos concretos es realmente complicado. Para ganar dinero por afiliación, dinero de verdad, tu nivel de tráfico debe ser brutal. Y aún así, podrías rentabilizar ese tráfico mucho mejor por otros medios como venta directa de un producto o servicio propio.
En Erasmusu hemos probado la afiliación desde muchos ángulos, como los widgets de búsqueda de vuelos de Minube, cursos y masters para estudiantes, plataformas como Zanox, etc. Y no nos ha compensado en ninguno de los casos.
Además, desde mi punto de vista, si tienes un portal con capacidad de mover tráfico hacia una marca o producto, no es tu responsabilidad que luego ese tráfico que envías se convierta en una venta. Hay mil factores totalmente ajenos a ti: podría ser que el producto no guste a tus usuarios, que la landing de pago no sea lo suficientemente atractiva, que no sea la época adecuada, etc.
Para el dueño del producto afiliado siempre será un win-win, venderá o no venderá, pero recibirá tráfico en cualquier caso. Pero para ti lo más seguro es que sea un fail-fail.
4. Trabajar en un equipo a distancia
En Erasmusu somos cuatro socios. Dos gallegos y dos murcianos. Hemos trabajado siempre a distancia, en ocaciones en parejas, pero nunca los cuatro juntos bajo el techo de una misma oficina. Este ha sido sin duda, uno de los mayores lastres que hemos tenido.
En nuestros inicios estábamos orgullosos de tener un equipo, que aún en la distancia, funcionaba bastante bien, usando Gtalk, Skype, Google Docs, etc. Pero con el tiempo, y sobre todo viendo como trabajábamos cuando nos juntábamos los cuatro en algunas raras ocasiones para hacer un push especial, nos dimos cuenta de que no hay nada, nada, comparado a trabajar en un equipo bajo el mismo techo.
Trabajar a distancia hará que gastes irremisiblemente cientos de horas chateando en Gtalk, escribiendo emails mastodónticos para explicar tus puntos de vista, malinterpretes el tono de otros miembros del equipo, etc.
Y no tendrás ninguna de las pequeñas grandes cosas que se experimentan trabajando codo con codo con otras personas: las ideas rápidas en un papel, los subidones de adrenalina cuando subes una nueva release, la camaradería y las risas, la motivación que se transmite de unos a otros, el placer de tirar a Emilio por un precipicio en el New Super Mario Bros con la Wii de la ofi, etc.
La comunicación en una startup es crucial. Trabajar a distancia es un error que no deberías permitirte.
5. No vender algo desde el día uno
«Primero vamos a generar tráfico y luego ya veremos. Cuando estemos petados a visitas habrá miles de formas de ganar dinero, por ejemplo con venta de camisetas o bla, bla, bla. ¡Estará chupado!».
Ese, básicamente, era nuestro modelo de negocio en 2009. Es decir, básicamente humo.
Después de cuatro años de sufrimiento, en los que me ha costado sangre y sudor llegar a un modelo de negocio viable en Erasmusu, tengo dos cosas claras:
- No volveré a fundar una de red social en mi vida.
- No volveré a emprender en ningún proyecto que no venda algo desde el día uno. Me refiero a si es con ánimo de lucro, emprender por ejemplo en una ONG quizás es diferente. Aunque bien pensado, incluso en este caso puedes vender un «Salva la vida de este niño con tu ayuda». Desde el día uno.
Crea algo y ponlo a la venta. Pero embarcarte en una quimera en la que primero tienes que generar tráfico para luego vender algo que no tienes muy claro qué es es casi sinónimo de fracaso. Nosotros nos hemos librado, pero por poco.
Si cuentas con inversión desde el día uno y quieres hacer una apuesta en plan: «primero crecer y fidelizar y luego vender», igual puedes optar por no vender nada de inicio. Pero es bastante arriesgado. No solo eso, el feedback que recibes haciendo ventas reales con clientes reales es realmente útil a la hora de elegir la dirección del proyecto.
6. No dejar bien claro dónde empieza y acaba el área de trabajo de cada socio
Y relacionado con esto, no tener clara una jerarquía en el equipo.
Sí, sé que con lo de la jerarquía me vais a meter caña los amantes de las startups cool americanas. En el mundo de la piruleta existen empresas que funcionan como Github sin managers, deadlines, work hours ni meetings. Y me encanta leer que funcionan sin jerarquía. Pero mi realidad personal es que nosotros nos sentíamos super modernos en lo de «no hay nadie por encima de nadie», pero no es que nos haya salido redondo el tema precisamente.
La mayoría de las tensiones internas que hemos sufrido en Erasmusu han venido por discusiones de cómo hacer las cosas y si hacer o no algo en concreto. Y los puntos de choque siempre han sido las áreas en las que dos miembros del equipo pensaban tener la última palabra. Por ejemplo, la línea divisoria entre el UX y el UI no siempre es tan clara. Y si un socio hace UX y otro UI y ninguno de los dos está jerárquicamente por encima del otro, puede darse un bloqueo en las discusiones.
Dos personas pueden añadir tantos argumentos como quieran a una discusión, pero puede darse el caso de que simplemente tienen un punto de vista opuesto. Eso es un bloqueo típico.
Esto no ocurre en empresas ya establecidas, con sus jefes de proyecto, de diseño, de desarrollo, etc. Si trabajas en un sitio así, a tu jefe podrás discutirle una, dos o hasta tres veces algo. Pero en caso de que no haya consenso entre tú y otro del equipo, o entre tú y tu jefe, él tomará finalmente la decisión y no habrá bloqueo posible. Eso sí, será su responsabilidad saber delegar siempre en la medida de lo posible y no abusar de su posición.
Pero en Erasmusu, las discusiones de socios al entrar en áreas que otro consideraba su competencia han hecho que más de una vez llegara la sangre al río, con interminables chats fuera de tono, emails al rojo vivo, etc. Eso ha jodido bastante al equipo en algunas épocas y nos ha hecho malgastar valiosísimas horas.
Y todo esto es algo que realmente se podría haber evitado. El problema fue que desde el inicio no se definió bien una jerarquía en el equipo que nos sacara de posibles bloqueos. Al estar todos al mismo nivel en cuanto a tomar decisiones, cada uno al 25%, no había «jefes de proyecto» reales que tuvieran la última palabra en caso de bloqueo en una discusión.
Yo he sido el project manager de Erasmusu en cuanto a su planificación en el tiempo, especificación de las tareas a realizar, coordinación del equipo y desarrollo del modelo de negocio. Pero nunca he tenido la última palabra para para poder sacar a dos socios de un bloqueo o a mi mismo. ¡Y menudas trifulcas se han montado!
7. Intentar previsiones de datos sin ningún tipo de experimento real previo
«España tiene 47 millones de habitantes. Si el 1% de ellos son médicos (470.000) y yo le logro vender al 1% de ellos al mes mi producto (4.700) que vale 2€ entonces voy a ganar 9.400€ al mes».
Permitidme que me parta el culo ante algo así. El ejemplo en concreto es con datos inventados, pero esa forma de extrapolar futuros ingresos es algo que he visto en varios planes de negocio circulando por ahí. Y no solo eso. Nosotros cometimos el mismo error.
Extrapolar tus futuros ingresos con datos demográficos es un fail de proporciones cósmicas. Lo que acabarás haciendo en tu hoja de excel es cambiar los ratios y demás variables hasta que salga un número que tenga sentido con lo que quieres pedir a los inversores. O al menos eso es lo que nos pasó a nosotros. Pero eso no se corresponde absolutamente con nada probado en el mundo real.
Esta sería una forma bastante más fiable de hacer una estimación:
- Pon a la venta tu MVP que comentaba antes. Lo más básico posible pero que sea vendible.
- Dale movimiento, genera tráfico creando contenido y cuidando tu lista de correo.
- Ahora puedes hacer predicciones de forma más fiable. Si estás ganando 200€ y recibes 1000 visitas al mes, puedes extrapolar, con un margen de error bastante menor que con el humo anterior, que si recibes el doble de visitas recibirás algo así como el doble de ingresos al mes. Suena lógico, ¿no?
Bonus: Algunas cagadas épicas del equipo de Erasmusu
Como algunos de vosotros me estáis preguntando detalles más concretos por email y el artículo está teniendo bastante aceptación en Twitter me he animado a añadir algunos momentos rollo «La he liao parda» y detalles algo más técnicos y concretos. Para que os echéis unas risas y veáis que como dice mi padre: «en tos laos cuecen habas«.
- En una competición de proyectos en la que participábamos junto con nuestra competencia, de tanto monitorizar cómo iban en el ránking, me confundí a la hora de enviarle a nuestros usuarios el link para que nos votaran y le dí el de la competencia en lugar del nuestro. Les llovieron bastantes votos hasta que nos dimos cuenta. Aún tengo pesadillas con esto. Menos mal que no ganaron al final (ni ellos ni nosotros).
- Una vez, por error, alguien la cagó en una consulta de SQL y le pusimos el mismo nombre a todas las ciudades del sistema. Creo que podías hacer un «Erasmus Murcia, Polonia» sin problemas.
- Cuando aún éramos poco más que una idea en papel y un montón de sketches de UX salió nuestra competencia online (en un .com). Una «gran» ocurrencia fue la de registrar los dominios .net, .org y otros que no habían registrado ellos. ¿Para que los queríamos? Para nada. Simplemente por ser malotes. Ni que decir tiene que esto fue jugar sucio y poco ético. Cuando la competencia se enteró, se cabrearon mogollón (teníamos comunicación con ellos). No nos quedó más que agachar cabeza, pedir perdón y devolvérselos. Menuda vergüenza.
- En una de la versiones anteriores de Erasmusu, creo que en el segundo rediseño, en la sección «Editar Perfil» el botón de «Darme de baja» era el que estaba más abajo haciendo scroll. La gente lo confundía con el de «Guardar» y se daban de baja de Erasmusu. Esta fue si que fue realmente épica.
- Una vez, al cambiar la web a «En mantenimiento», se les quedaba a los usuarios esta página en la caché y la única forma de poder entrar en Erasmusu era haciendo CTRL+F5. Nos llovieron incidencias en el email de contacto durante semanas.
Añadiré alguna otra más adelante si me refrescan la memoria Emi, Adri o Iván 🙂
Conclusión
Espero que alguno de los errores que cometí en mi startup te sean de ayuda a ti para poder evitarlos y que te hayas echado unas risas con las tiras cómicas de xkcd. Dale caña a tus proyectos y sígueme en Twitter si te gustan estos temas.
Por cierto, me arrepiento del título que le he dado al artículo. Parezco un gurú startupero 😛 No más títulos vende humo para los próximos posts.
¿Y tú? ¿Qué errores cometiste? ¿Te han pasado cosas parecidas? ¿No estás de acuerdo con algo de lo que digo? Deja un comentario y nos lo cuentas 🙂
