Crecimiento de productos tecnológicos

Archive for ‘febrero, 2011’

En muchas ocasiones, el “ingrediente secreto” de una innovación de éxito está en identificar riesgos, priorizarlos y encontrar maneras creativas de eliminarlos.

Muchos directivos tienen (¿tenemos?) cableada en la cabeza la típica relación entre rentabilidad y riesgo de los activos financieros –a mayor riesgo, mayor rentabilidad– y la utilizan para medir nuevos negocios, productos y empresas. Desde ese punto de vista, que liga de manera estática ambas variables, el mayor riesgo es el precio a pagar por una mayor rentabilidad. Y, tal como prescriben las herramientas de análisis financiero al uso, aquellos nuevos proyectos cuya rentabilidad es inferior a la de otros proyectos con un nivel de riesgo equivalente sencillamente se quedan sin recursos para acometerlos.

Pero en realidad, como hemos dicho otras veces en este blog, la innovación se caracteriza por una serie de riesgos (tecnológicos, de mercado,  etc.) y las técnicas de reducción de la incertidumbre y de aprendizaje organizacional son imprescindibles en su eliminación y/o gestión. Por eso se agradecen artículos como “Beating the Odds When You Launch a New Venture”, de C. Gilbert y M. Eyring, que explican cómo la innovación de éxito no se basa en buscar la alta rentabilidad asociada a un riesgo elevado, sino en identificar rápidamente y eliminar sistemáticamente riesgos en el orden correcto y usando el nivel de recursos y los métodos más adecuados.

En el razonamiento de los autores resulta central la idea de que el valor y el riesgo de un nuevo producto o empresa están relacionados inversamente. Cuando reducimos el riesgo estamos aumentando el valor de la empresa. Pero es vital el orden en que abordamos estos riesgos, porque no todos son iguales. Por ejemplo, alguien interesado en lanzar un nuevo sitio web de comercio electrónico puede ir gestionando los riesgos a medida que se le van presentando -y probablemente el primero sería el diseño del sitio web. Sin embargo, a menos que primero confirme la demanda de los clientes éstos no van a comprar (por muy interactivo que sea el sitio) y si no responde a la pregunta del mix de producto es posible que se abastezca de productos que no va a poder vender.

Resolver rápidamente los riesgos más importantes acelera la curva de valor de la iniciativa o proyecto de que se trate. Gilbert y Eyring distinguen entre tres tipos de riesgos:

  • Riesgos fatales (deal-killer) son aquellos que si no se resuelven pueden dar al traste con toda la operación y habitualmente toman la forma de asunciones no justificadas o no contrastadas sobre las que se basa el negocio. Por ejemplo, ¿existe demanda para mi producto?
  • Riesgos que dependen de las decisiones tomadas (path-dependent) son aquellos que aparecen cuando el tomar la decisión o el camino equivocado (p.ej., la tecnología a aplicar, el mercado a abordar) podría significar la pérdida de grandes cantidades de tiempo y/o dinero.
  • Riesgos operativos que pueden resolverse sin gastar mucho tiempo ni dinero. Puesto que probablemente no vamos a tener dinero para resolverlos todos, aquí la clave está en cuáles y en qué orden se resuelven. La respuesta está en seleccionar aquéllos en los que el ratio de riesgo eliminado (o el consecuente aumento de valor) frente al coste del experimento necesario para eliminarlo –una especie de ROI del experimento– es más favorable.

Para hacer más predecible y eficiente la creación y gestión de nuevos productos y mercados es imprescindible identificar y priorizar sus riesgos y a continuación concebir y ejecutar experimentos que los resuelvan sistemáticamente. En cuanto a los tipos de experimentos más útiles, los autores distinguen dos:

  • Experimentos enfocados: se utilizan para eliminar un riesgo específico, habitualmente de tipo fatal o dependiente de las decisiones.
  • Experimentos integrados: están diseñados para comprobar cómo diversos elementos (el modelo de negocio, el producto, el mercado) funcionan conjuntamente. En esencia, implican lanzar el negocio –o una parte de él– en un ámbito restringido, p.ej., pilotos, prototipos, mercados de prueba.

Los grandes emprendedores no asumen riesgos: los gestionan. Determinar cuáles de las asunciones clave son correctas -y cuáles no- y hacer rápidamente los ajustes pertinentes marcan a menudo la diferencia entre el éxito y el fracaso.

Y tú ¿ya has identificado tu incertidumbre más importante?

12 comentarios

Desde hace unos años todo es Agile: la creación de software, el desarrollo de productos, las organizaciones… En este post explicamos los orígenes de esta filosofía, los beneficios que aporta y algunas de sus limitaciones.

Desde hace más de diez años las filosofías Agile están revolucionando el desarrollo de software. Por poner como ejemplo a alguien habitual en este blog, Steve Blank y Eric Ries han incorporado el Desarrollo Ágil como una de las bases de su Startup Stack (junto a Customer Development y Business Model Generation). Tal ha llegado a ser el predicamento de esta filosofía que en los últimos tiempos hay quien intenta convencernos de que Agile no solo es la panacea para el desarrollo de productos de cualquier tipo y en cualquier mercado, sino que todo aquel que no se haya convertido a Agile no es más que un “dinosaurio de las cascadas” o -lo que casi es peor- un “cowboy metido a programador”.

Por aportar un poco de contexto y abrir el debate sobre el papel de Agile en el desarrollo de productos vamos a repasar los orígenes y principios básicos de este movimiento (desde la perspectiva de alguien que -aunque hace mucho tiempo que dejó de programar- sí que dedicó los primeros años de su carrera a la Ingeniería del Software).

Lo primero que hay que decir es que lo que ahora se conoce como Agile surgió a partir de los años ochenta del pasado siglo (e incluso antes) en forma de metodologías “ligeras” de desarrollo software, como respuesta a las limitaciones de las metodologías “pesadas” tipo Waterfall (Cascada). Dichas metodologías pesadas se habían definido inicialmente para el desarrollo de proyectos de software a medida como una adaptación de los métodos al uso en los sectores de la fabricación y la construcción. Estos son entornos intensivos en el uso de materiales y maquinaria específica y donde los costes de hacer cambios cuando el proyecto está avanzado son prohibitivos, lo que exige una exhaustiva definición inicial de requisitos y un diseño cerrado. Las metodologías de desarrollo software tipo cascada asumen que hay un cliente que sabe cuál es su problema (por eso contrata el desarrollo) y se basan en unas fases secuenciales sin solapamientos y un diseño inicial estable e invariable (BDUF, Big Design Up Front).

Sin embargo el desarrollo de programas, por su propia naturaleza, no se ajusta muy bien a dichas condiciones: la complejidad de los problemas que se suelen resolver mediante software, la indefinición de los requisitos del cliente, la importancia de la interacción entre el producto final y sus usuarios, el continuo cambio tecnológico, etc. hacían imposible que aspectos como la solución dada al problema del cliente, los requisitos, el diseño e incluso la arquitectura del programa pudieran mantenerse constantes durante el desarrollo. Y el modelo en cascada no está preparado para encajar bien esos cambios.

Por otra parte la tecnología del software posee algunas características particulares que abrieron la posibilidad de otro tipo de metodologías; entre estas peculiaridades podemos citar la facilidad para “componentizar”/modularizar el desarrollo, crear prototipos o automatizar las pruebas y los (comparativamente) bajos costes de realizar cambios que aporta su naturaleza “inmaterial”. A partir de los pasados años ochenta empiezan a aparecer una serie de nuevos modelos para el desarrollo de software a medida, tales como el Desarrollo Rápido de Aplicaciones, el Espiral o el Proceso Unificado y -más tarde- metodologías como XP (Extreme Programming) o FDD (Feature Driven Development). Estas metodologías se basan en un desarrollo iterativo e incremental en el que los requisitos y las soluciones van evolucionando gracias a la comunicación con los usuarios y la colaboración entre equipos multidisciplinares autoorganizados, todo con el objetivo de mejorar la calidad del software y la capacidad de respuesta ante cambios en los requisitos del cliente y el entorno.

En la segunda parte de este post hablaremos del Agile Manifesto y de los beneficios y limitaciones de estos enfoques.

Este post en Marketing & Innovación.

9 comentarios