Agile, Diseño, Customer Development, Lean Startup… ¿es todo lo mismo?
Las nuevas filosofías de desarrollo de productos y negocios tienen muchos puntos en común pero también algunas contradicciones. En realidad, cada una de ellas representa una visión parcial de un nuevo proceso de innovación que está emergiendo y cuyas piezas todavía tienen que acabar que encajar.
Una de las primeras cosas que vienen a la cabeza cuando uno intenta profundizar y aplicar las diversas filosofías de la “nueva innovación” (Agile, Diseño, Customer Development, Lean Startup…) es una curiosa sensación de déjà vu. Cuando se ha familiarizado con las iteraciones y los experimentos de Customer Development (o de Diseño, o de Agile) y empieza a estudiar los otros enfoques es difícil evitar un pensamiento de “todo esto me suena mucho” y “una vez que dominas una, las dominas todas”.
Pero ¿realmente esto es así? ¿Cuánto hay de similar y de diferente en estas filosofías? Vamos a estudiarlo para el caso de empresas orientadas a producto (repetible, para un mercado, no proyectos a medida de un cliente).

Si no son lo mismo al menos lo parecen…
La realidad es que por diversas razones (entre ellas la contemporaneidad) todas ellas comparten muchas ideas. Esencialmente, son filosofías que tratan de enfrentarse a los retos del desarrollo de nuevos productos y negocios en escenarios de gran riesgo y velocidad, que se han desarrollado prácticamente a la vez –a partir de finales del pasado siglo– y que se han “interfertilizado” mutuamente (por no decir que en ocasiones se han copiado sin demasiados miramientos). Y aunque cada una de ellas posee un lenguaje propio, en conjunto presentan muchas coincidencias y temas recurrentes:
- Foco en el cliente
- Experimentación (Producto Mínimo Viable, prototipos…)
- Feedback
- Aprendizaje
- Iteración (sprints, ciclos…)
- Coordinación y comunicación (interna y externa)
- Equipos multidisciplinares
- …
En realidad, estas filosofías ofrecen puntos de vista diferentes y parciales de lo que esencialmente es un mismo proceso: el que tiene por objetivo desarrollar un nuevo producto/empresa. Pero ahora ya no se trata de un proceso que siga un modelo lineal, por fases o en cascada, como los que han venido utilizándose con cierto éxito en el desarrollo de innovaciones incrementales.
Este nuevo modelo que va emergiendo es más adecuado para el desarrollo de productos y negocios verdaderamente nuevos – situaciones donde ni los clientes, ni sus necesidades, ni las soluciones que podrían cubrirlas ni las tecnologías que se aplicarían son totalmente conocidas o están en evolución– y es mucho más flexible y centrado en el mercado.
Agile, Diseño, Customer Development, Lean Startup son diferentes…
La realidad es que estas filosofías son diferentes (incluso complementarias) en cuanto a sus objetivos y alcance. A fin de distinguir entre unos enfoques y otros, si tuviéramos que resumir cada uno de ellos en un slogan o un par de frases el resultado podría ser el siguiente:
- Customer Development – Sal fuera de la oficina y pon a prueba iterativamente las hipótesis de tu negocio. Después, constrúyelo y escala.
- Diseño (y Design Thinking) – Crea productos (y negocios) que los clientes deseen a través de la empatía y el prototipado.
- Agile – Entrega rápidamente valor a los clientes mediante una construcción iterativa e incremental que incorpora continuamente el feedback del mercado.
- Lean Startup – Integra y aplica las filosofías anteriores en un contexto de emprendimiento: aplica ciclos rápidos de Construir-Medir-Aprender para que tu empresa sea flexible y rápida y use sus recursos de la manera más eficiente.
Dejando a un lado Lean Startup, que es una filosofía de empresa y hasta cierto punto engloba los demás enfoques, los otros representan perspectivas diferentes (y en ocasiones solapadas) del desarrollo de nuevos productos y negocios pero ninguno aporta una solución completa a todo el proceso de desarrollo. Por ejemplo:
- Customer Development representa eminentemente una óptica de (modelo de) negocio. Es imprescindible validar la Propuesta de Valor y las otras hipótesis del modelo de negocio, pero en paralelo necesitamos saber cómo “poblar” esa propuesta y definir, diseñar y construir el producto. Los propios promotores del Customer Development aclaran que es necesario complementarlo con un proceso de “Product Development”. En particular Steve Blank y Eric Ries proponen que ese desarrollo de producto consista básicamente en una Ingeniería Ágil pero desde mi punto de vista eso no es suficiente.
- El Diseño, especialmente el Diseño UX, recoge –como no podía ser de otra manera– la visión del diseñador y se centra en encontrar la solución para el problema/necesidad del mercado. Pero en general no entra en las actividades de definición del modelo de negocio ni de evaluación de la oportunidad de mercado y tampoco en la construcción del producto real.
- Agile, por su parte, representa la visión del ingeniero y se enfoca en la construcción/implementación de la solución. Pero tampoco entra en las actividades de definición del modelo de negocio ni de evaluación de la oportunidad de mercado y trata de evitar las de investigación de clientes y diseño.
… e incluso contradictorias
Pero además, lo que es innegable para alguien que haya estudiado con un mínimo espíritu crítico estas filosofías (algo no habitual entre muchos de sus apóstoles) es que entre ellas hay algunas diferencias y contradicciones muy relevantes:
- ¿Diseño holístico o construcción incremental? Como hemos visto por aquí, el “agilismo” aboga por minimizar el diseño inicial y dejar que la experiencia de usuario vaya emergiendo a través de las sucesivas iteraciones, pero la realidad es que esas iteraciones no convergen necesariamente hacia una experiencia deseable. Cuando ambas filosofías pasaron al primer plano a principios de la década pasada muchos pensaban que eran irreconciliables. Actualmente se dedican muchos esfuerzos a conseguir un Agile UX.
- ¿Prototipo, Producto Mínimo Viable o Minimal Marketable Product? ¿El MVP es uno, producto, mínimo y viable… o no es ninguna de las cuatro cosas? ¿Debemos iterar sobre versiones parciales del producto (en fase de construcción) o mucho antes, sobre artefactos desechables?
- ¿Foco en el producto o en el modelo de negocio? ¿Es verdad, como dicen algunos, que tu producto es tu modelo de negocio? ¿O sin un producto que implemente y vehicule la propuesta de valor tu modelo de negocio es un papel mojado?
Todos estos enfoques son las piezas de un puzzle que conforma un nuevo proceso de desarrollo de productos y negocios. La buena noticia es que muchos creemos que este proceso nos va a ayudar a innovar de manera más flexible y con mayores probabilidades de éxito. La mala noticia es que las piezas todavía no encajan muy bien… pero seguro que entre todos lo vamos a conseguir.
El post “Agile, Diseño, Customer Development, Lean Startup… ¿es todo lo mismo?” se publicó primero en “Marketing & Innovación”.
[Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]

El formato se compone de estos elementos:



Llevamos algunos años anunciando la muerte del Product Management… por lo menos tal y como se concebía hasta ahora. Pero algunos de los consultores y autores que venden estas ideas esencialmente gestionan negocios cuyo éxito se basa en gran medida en que estas predicciones lleguen a hacerse realidad. Es importante tener en cuenta posibles conflictos de interés a la hora de valorar ciertas opiniones.![El rol de Product Owner no es suficiente en empresas que comercializan productos para un mercado. Para que un Product Owner pueda colaborar eficazmente con su Product Manager (o asumir alguna de sus funciones) es imprescindible un mayor conocimiento y experiencia en aspectos de negocio. Las empresas de producto que desean tener éxito en el mercado necesitan Product Managers experimentados… y los contratan. No hay más hay que ver las ofertas de empleo que se publican en los sitios web de las propias compañías (incluso de las más punteras) o en LinkedIn. Sin embargo, en los últimos años la tendencia a la “agilización” ha llevado a algunos evangelistas de Agile a promover la sustitución del “anticuado puesto de Product Manager” por el más moderno de Product Owner. En realidad, lo que estos apóstoles promueven es extender las atribuciones del rol de Product Owner original de Scrum, elevándolo a la altura de una especie de “Súper Product Owner”, que aborde cada vez más áreas de la gestión de producto. En definitiva, lo que postulan es sustituir el rol de Product Manager por el de un Product Owner cuyas funciones cada vez se parece más a las de aquél. En este blog hemos hablado ya de las relaciones entre Product Manager y Product Owner y de por qué prescindir de uno u otro puesto es una mala idea. Y personalmente soy un firme partidario de aplicar lo que de bueno tienen los enfoques Agile/Lean/Design Thinking al Product Management… y a todas las áreas de la empresa. Creo que las empresas de producto -especialmente en mercados tecnológicos, rápidos e innovadores- se beneficiarían de una Gestión de Producto más Agile/Lean (no quiero entrar en guerras de religión con el nombre). Pero es ilusorio pensar que por ampliar el alcance del rol de Product Owner y prescindir del de Product Manager vamos a gestionar mejor nuestros productos. Y lo creo por varios motivos: • Las actividades de un Product Owner (incluso en sus versiones más avanzadas) son una parte de las necesarias para garantizar el éxito de un producto en el mercado, y que definen la responsabilidad del Product Manager. El desarrollo de nuevos productos no lo es todo: antes hay que descubrir y analizar la oportunidad de mercado y después hay que comercializar, explotar, mantener y evolucionar el producto. Contrariamente a lo que muchos ingenieros podrían pensar, el lanzamiento no es el principio del fin de un producto: es el fin del principio. Un rol que en sus versiones más básicas únicamente existe durante el proyecto de construcción del producto no puede aspirar a garantizar el éxito de éste en el mercado. • La realidad es que lo que con mayor frecuencia se encuentra en las empresas es un “Mini Product Owner”, no sólo en actividades, sino en habilidades. Aparte de que el alcance de los roles de Product Manager y Product Owner son diferentes (el Jefe de Producto es mucho más estratégico y enfocado al exterior), el tipo de profesional que desempeña este último tampoco ayuda. En la mayoría de las empresas se trata de alguien con bagaje puramente técnico y con escasa experiencia y aptitud para entender realmente un mercado, descubrir las necesidades esenciales de los clientes y colaborar con los otros departamentos de la empresa y gestionar el producto como un negocio a lo largo de todo su ciclo de vida. (Nota al margen: la formación sobre Product Owner/”Agile Product Manager” disponible en España deja bastante que desear, limitándose en muchos casos a cubrir una Gestión Ágil de PROYECTOS, en el mejor de los casos complementada con pinceladas de Lean Startup y otros enfoques de moda, pero no necesariamente con gestión de PRODUCTO). El Product Owner típico necesita más conocimientos y habilidades de negocio No podemos dar la “propiedad” de los aspectos estratégicos de un producto a alguien que carece de los conocimientos y la experiencia necesarios. Estos son algunos de ejes de gestión de producto que deberían mejorar muchos Product Owners: • Mejorar su perspectiva sobre la estrategia de producto global y las sinergias de la cartera de productos. El Product Owner típico tiende a optimizar la release, sin tener en cuenta las oportunidades de bundling y cross-selling con otros productos, y a veces pierde de vista el roadmap. • Aprender a diferenciar entre unos pocos clientes y el mercado en su conjunto. El Product Owner medio tiende a dar credibilidad y a generalizar el input de los clientes más cercanos o comunicativos y de aquellos que se avienen a probar el producto durante el desarrollo. Además, es habitual que el mercado se componga en realidad de diferentes grupos de clientes, cada uno caracterizado por unas necesidades similares - pero diferentes de un grupo a otro. Pero las técnicas de segmentación y targeting no suelen estar entre los conocimientos del Product Owner. • Entender los drivers que crean valor para el cliente para convertirlos en productos más comprables y aprender a elaborar posicionamientos, comparativas respecto a la competencia y mensajes significativos para el mercado. Las propuestas de valor que elabora el Product Owner típico en realidad consisten en enumeraciones de atributos y funcionalidades. • Entender el modelo de negocio que sustenta el producto y las herramientas para capturar el máximo valor para la empresa: packaging, pricing. El Product Owner medio tiene tendencia a añadir funcionalidades sin pensar en cómo rentabilizarlas. • Aprender a priorizar aspectos estratégicos del producto (tales como la experiencia de usuario, los drivers de compra o una arquitectura que permita evolucionarlo fácilmente y crear productos derivados) frente a funcionalidades de usuario visibles individuales. • Mejorar sus habilidades para comunicar eficazmente y aumentar su credibilidad ante los departamentos de Marketing, Ventas, Soporte, la Dirección de la empresa y, en general, todos los que tienen que contribuir a que el producto sea un éxito en el mercado. Un Product Owner que mejorara sus capacidades de gestión de producto no sólo podría colaborar más eficazmente con su Product Manager, sino que podría abrir una vía de desarrollo y evolución profesional hacia ese rol. En resumen, necesitamos una gestión de productos mucho más Agile/Lean, pero suprimir la figura del Product Manager y sustituirla por la de un (Súper) Product Owner no es la manera de conseguirlo. El post “Si quieres ser un Product Owner excelente aprende Product Management” se publicó primero en “Marketing & Innovación”. [Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]](https://conversisconsulting.com/wp-content/uploads/2013/11/product-owner-needs-product-management.jpg?w=300&h=240)

