[modo rollo introductorio ON]

El pasado Jueves 21 de octubre se celebró la III jornada sobre Inversión privada en Nuevas Empresas de Base Tecnológica organizada por Madri+d en la que participé para presentar mi experiencia como Business Angel. Empecé a analizar este tipo de operaciones hace cuatro años, e hicimos nuestra primera inversión hace tres años y medio (por cierto un rotundo fracaso). Aunque claramente hay muchos inversores con mucha más experiencia, el haber hecho siete inversiones directas y participar en un vehículo junto con el involucrarnos de manera muy activa con los emprendedores nos ha llevado a tener un elevado número de interacciones y por tanto de experiencias.

[modo rollo introductorio OFF]

Me pidieron que hiciera especial énfasis en el apartado de seguimiento post inversión. En este área hay muchos temas a hacer y a evitar, si os interesa puedo dedicar a ello otro post. Después de darle muchas vueltas y pensar en las funciones más importantes del inversor tras la inversión, llegué a la conclusión de que una de ellas es la de “empujar” al equipo a enfocarse en hacer las primeras ventas. Los que ya hayáis pasado por ello lo sabréis, pero para los nuevos emprendedores o nuevos inversores, el esfuerzo necesario desde tener el primer prototipo o la primera beta hasta decir vamos a cobrar por el producto es increíble. De hecho, el problema es que nunca llega y los tiempos se amplían de manera insospechada con el consecuente impacto en la posición de caja de la compañía. ¿Qué provoca este retraso?

1. El querer tener el producto perfecto que arrolle el de la competencia. En las betas, se prueba el concepto y en teoría no debería haber cambios hasta el producto final, sino bug fixes. No obstante, en muchas ocasiones se descubren mejoras que pueden hacer el producto mucho más atractivo y se toma la decisión de: “ya que tenemos que arreglar estos pocos bugs, añadamos estas mejoras para salir con más fortaleza y con un producto más completo”. Esto se acaba convirtiendo muchas veces en un ciclo ininterrumpible.
2. La infraestructura necesaria se olvida cuando no se ha pasado por este proceso antes. Hacen falta los contratos de licencia o prestación de servicios, el sistema de soporte, sistema de facturación, manuales y documentación … Es un trabajo que aparentemente no aporta valor, pero que es muy importante para empezar con una mínima seguridad jurídica. En muchas ocasiones algunos de estos pasos dependen de terceros proveedores que pueden retrasar la salida del producto aunque  el producto en sí esté perfectamente terminado.

¿Cómo se puede tratar de combatir este retraso? Del siguiente conjunto de ideas, algunas han sido testadas y otras no, y me encantaría conocer vuestra experiencia y “trucos”.

• Comenzar con una versión muy básica del producto. Este enfoque ayuda a mitigar los dos problemas anteriores. Por un lado, evita los retrasos de las mejoras y de arreglar los bugs de las mejoras, y por otro, facilita la elaboración de “la infraestructura”. Se podría considerar que los clientes pueden no encontrar suficientemente atractivo un producto si no tiene todas las funcionalidades que creemos necesarias, pero creo que el arranque con un producto básico puede ser positivo desde otros ángulos. Por un lado, una versión sencilla facilita la explicación y la adopción. Si lo unimos a una buena comunicación con el cliente, se puede preguntarle para luego priorizar qué mejoras encuentra más atractivas y trabajar primero en ellas. Por último, los usuarios percibirán un procedimiento de mejora continua que aporta valor.
  Como ejemplo, cuando Apple añadió al iPhone la posibilidad de copiar y pegar, se vendió como un gran avance, igual que sucedió en la versión 4 con la multitarea. ¿Qué fue crítico en este caso? Que las mejoras de sencillez y de interfaz de usuario del primer iPhone eran tan atractivas que la falta de algunas funcionalidades adicionales no se consideraron como un “deal breaker”.
• Ponerse una fecha límite clara y trabajar ajustando funcionalidades y tareas para alcanzarla. En lugar de decir vamos a salir cuando el producto tenga estas características, se puede establecer primero la fecha límite y luego las características objetivo y las mínimas. De esta forma, la presión es mayor y se evitan pérdidas de tiempo en las que se incurre en ocasiones cuando no hay una fecha clara. Trabajar contra reloj suele estimular mucho al ser humano. Sobre la base de ese “deadline” trabajar el calendario hacia atrás para poner fechas límite parciales.
• Anticipar el desarrollo de la infraestructura. Cuando el producto está a medio desarrollar puede parecer prematuro empezar a pensar en los contratos, licencias, papeleos, manuales etc. Pero es cuando debe hacerse o, al menos, arrancarse para evitar que sean camino crítico de cara a la salida al mercado. Esto es todavía más importante si requiere de la participación de terceros, cuyos plazos de desarrollo deben estar incluidos dentro del planning del punto anterior. Si en estas ocasiones se puede poner adicionalmente penalidades por incumplimiento de plazos, mucho mejor.

¿Cuáles son vuestras experiencias en este problema? ¿Qué trucos empleáis? ¿En qué discrepáis respecto de lo que he planteado? Me interesan mucho vuestros comentarios.

This entry was posted on Monday, October 25th, 2010 at 10:43 and is filed under Empresas, gestion, startup. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.