Yo tambien escribo
Experiencias de otro emprendedor en el mundo

Tres conceptos que muchas veces se oponen en la toma de decisiones de una start-up (O la mayor de las empresas de software). Tres palabras obligadas a entenderse. Conceptos que muchas veces ponen en liza traumas entre diferentes grupos en la organización. Simplificando hacia lo absurdo:

– Business dice: Quiero para ayer estas nuevas 20 funcionalidades. Testeadas, documentadas y a poder ser que sean compatibles con todas plataformas tecnológicas con las que nos integramos. ¿Fácil no?

– El equipo tecnológico dice: Necesito el doble de tiempo que tu me das para hacer la mitad de funcionalidades que me pides. La verdad que para ir bien deberíamos introducir nuevos componentes tecnológicos para poder estar seguros que entregamos algo con la calidad que el proyecto requiere.

Y la verdad que todos tienen tanta razón como errores en sus afirmaciones. Veamos en perspectiva.

De siempre nos han dicho que el cliente tiene la razón, quizás sea cierto. Pero también es cierto que lo que distingue un buen equipo de negocio de uno mano es su habilidad para separar el grano de la paja, la capacidad para ver más allá de una venta y la destreza para conocer el negocio del cliente para poner peso a sus prioridades. En resumen:  El cliente tendrá la razón ponderada siempre que seas capaz de medirla. Y aquí me lanzo a dar unos humildes consejos:

• Aprende todo lo que puedas de tu cliente (Con o sin él).
• Ten preparado tu roadmap de cliente en función de tu visión del mercado…
• … pero debes estar capacitado a cambiarlo profundamente en función de tus clientes (No seas orgulloso).
• Aprende a ponderar. No es más importante la feature que te requiere el último cliente que has ido a visitar, sino el que REALMENTE te dará más negocio.
• Si no eres capaz de explicar QUÉ y PARA QUÉ quiere un cliente una funcionalidad (Con más de 2 líneas de definición) no es digna de que influya en tu producto (¿Como se lo vas a explicar al equipo técnico?). Primero aprende a escuchar y entender, muchas veces el propio producto puede ofrecer una alternativa sin necesidad de nuevos desarrollos.
• Conoce el ritmo de tu cliente. ¿Para qué quieres una funcionalidad A si el cliente tiene bloqueado el presupuesto hasta el próximo año?
• La frase ¨Muchos clientes lo piden¨ debería estar prohibida. Aprende a montar matrices cliente-funcionalidad para poder actuar en consecuencia. Muchas veces te sorprenderías.
• Un buen producto debe incorporar aquello que tu comunidad quiere (Clientes, partners, open source, etc.) pero sin perder la esencia de la visión de tu empresa (Ya sabéis… aquello de Henry Ford). A mí me gusta la proporción 7 a 3.
• ! El buen producto no es el que más funcionalidades tiene! Sino el que mejor se adapta a lo que realmente demanda el mercado. No peques de visionario.
• Quien define necesidades debe entender que un error en las expectatuvas impactará en el desarrollo y la calidad de la siguiente release.

Y luego eso se traslada al equipo técnico. Del cual me siento partícipe con sus virtudes y defectos. Cuando nos llega una lista de features siempre tendemos a ponernos las manos a la cabeza (¿A qué suena?), no entender los motivos ni preocuparnos en encontrarlos. El buen ingeniero es el que es capaz de salir del huevo en el que solemos vivir la gente con alto componente  tecnológico, entendiendo el gran valor que aportan a la compañía involucrándose en su desarrollo y aportando sus habilidades para la maduración del producto.

• No incorpores algo por el simple hecho de que parece que aportará más valor a la funcionalidad. Usa los canales estándares de definición, participa activamente con el Product Manager. No hay nada peor para Business que no saber explicar el comportamiento de una pantalla cuando está el producto instalado en un cliente.
• Pierde 1 día más de lo que tenías en la cabeza a definir una funcionalidad. Minimizarás por 10 los riesgos y serás capaz de apuntar más fino a la funcionalidad deseada.
• El equipo técnico también debe conocer el mercado y el tipo de cliente para el que desarrolla. Es responsabilidad del Product Manager transmitirlo y del ingeniero asimilarlo. A veces las cosas no son como uno piensa.
• Trabajar en la definición no es perder tiempo reunidos. Si no aportas nada levántate y vete a hacer otra cosa. Pero luego no pidas explicaciones sobre un diseño.
• Usa el poder de las metodologías ágiles. No escondas tus desarrollos. Crea, testea y comparte rápido.
• Entiende la funcionalidad que desarrollas. Porque es necesaria. Eso te ayudará a definir y focalizar.
• Prioriza en el diseño la arquitectura, librerías o herramientas que tienes definidas. Tampoco te salgas del estándar de desarrollo definido sin comunicarlo antes. Un ingeniero es curioso y atrevido por naturaleza. Eso hace a veces querer probar cosas nuevas. Encuentra el momento. Sistemas te lo agradecerá (Y el proceso de upgrade también :))
• El valor del producto está en parámetros como robustez, escalabilidad y mantenimiento. Argumenta un nuevo desarrollo en base a estos parámetros, no en las tecnologías que usas.
• Normalmente las previsiones a más de 6 meses vista suelen fallar :).
• Un ingeniero debe entender que una mala planificación impacta fuertemente en el ciclo de release y en las ventas. Que por suerte o desgracia son los dos puntos que mantienen viva una empresa.

En resumen, la diferenciación que permite a empresas como Abiquo competir con otras como VMware está en la agilidad, comunicación y compromiso con el proyecto. Un sector puede pensar que la clave de una empresa está en la facturación, otra en la excelencia y la innovación en el producto. Pero la realidad nos hace aprender que en medio se encuentra el buen camino.

PD: En este post hablo del mundo Business (Sales, Business development, etc) y Desarrollo ( I+D, desarrollo, etc.) como dos equipos diferenciados. Claro queda que es una separación ficticia. El éxito de cualquier empresa de producto radica en la mezcla de ambos.