Conversis Consulting – Marketing orientado a resultados para mercados tecnológicos

Posts from the ‘desarrollo de producto’ category

Dos de las características principales de los productos para un mercado son sus costes de desarrollo y de replicación, que impactan en la rentabilidad de su negocio. Pero esas características no son las únicas que separan a los negocios basados en producto de los basados en desarrollos a medida.

En la anterior entrada hablamos sobre modelos de negocio basados en producto y destacamos la condición de que para que un producto sea tal debe ser repetible e ir enfocado a un mercado de clientes.

En esta entrada seguimos analizando los negocios basados en producto y nos centramos en dos aspectos clave: la influencia que tienen los costes de desarrollo y replicación del propio producto en dicho negocio y las diferencias entre los modelos basados en productos y en desarrollos a medida.

Costes de desarrollo frente a costes de replicación de producto

Dos de los parámetros que marcan absolutamente un modelo de negocio basado en producto son sus costes de desarrollo (lo que en su día definimos como crear la “unidad 0”) y de replicación (crear las siguientes unidades), y es llamativa la enorme diversidad que se da entre unos sectores y otros.

Por ejemplo, si estás acostumbrado a trabajar en el sector del software -donde los costes de replicación son muy bajos- te sorprenderá comprobar hasta qué punto los costes de desarrollo y replicación en otras industrias como farmacia o automoción son diferentes y cómo condicionan su potencial rentabilidad.

Costes Desarrollo vs. Costes Replicación Producto

En este cuadro se presentan cifras orientativas de estos costes para tres tipos de producto:

  • En los costes de desarrollo recogemos las actividades de investigación, definición, diseño, construcción, pruebas, certificación administrativa (muy importantes en productos relacionados con la salud)… de una versión replicable y comercializable del producto.
  • En replicación incluimos los costes incrementales de fabricación y entrega de una unidad adicional de producto. (No se incluyen costes de comercialización ni soporte.)

Por ejemplo, los fármacos suelen tener unos costes de desarrollo altísimos debido a las dificultades de descubrir la molécula de su principio activo y a los riesgos en las actividades de pruebas clínicas y de aprobación administrativa por las autoridades sanitarias, pero sus costes de replicación son bajos (se da la paradoja de que muchas veces el coste del envase es muy superior al de los componentes).

Por el contrario, en el caso de un automóvil los costes de desarrollo no son tan altos, pero los de replicación son comparativamente muy superiores debido al peso de los materiales directos y el proceso de fabricación.

Finalmente, el software (y otros contenidos digitales) se caracterizan por su mínimo coste de replicación, que en su versión más elemental consiste en copiar el contenido en un servidor accesible desde Internet para que los clientes se lo descarguen desde ahí (otras variantes, como la prestación en modo servicio, son más complejas y caras).

Estos dos parámetros, tan característicos de cada producto, influyen sobre su modelo de negocio: corrientes de ingresos y costes, estrategias comerciales… Por ejemplo, para un producto que no cuesta prácticamente nada replicar es posible utilizar un marketing basado en la prueba gratuita generalizada y en modelos fremium, estrategias que resultarían mucho más difíciles cuando el coste de cada unidad es alto. Este es el caso de ciertos productos farmacéuticos y del software. Asimismo, en productos de bajo coste de replicación y costes de desarrollo no muy altos el potencial de rentabilidad es muy elevado.

Los negocios basados en productos y proyectos son muy diferentes

Este análisis de los costes de desarrollo y replicación nos da pie a discutir cuáles son las diferencias entre los modelos de negocio basados en proyectos de desarrollo a medida y en productos para un mercado, que se resumen en la siguiente tabla:

Modelos de Negocio Producto vs. Proyecto

Esta comparación resalta varias diferencias sustanciales entre los negocios basados en desarrollos a medida y producto, especialmente en los siguientes elementos del modelo:

  • Los clientes y sus problemas/necesidades. En el caso de un desarrollo a medida el cliente es conocido y resulta accesible y podemos (no sin dificultades) entender su necesidad o problema. A partir de ahí desarrollamos la solución, sea mediante procesos lineales o iterativos.
    Por el contrario, en un producto para un mercado los clientes son desconocidos y generalmente heterogéneos e inaccesibles. El gran reto es entender cómo los clientes se segmentan en distintos grupos de necesidades, convertirlas en requisitos y decidir cuáles se van a resolver mediante el producto. Y a partir de ahí, por supuesto, diseñar y construir la solución. Un producto nunca va a ser capaz de resolver el 100% de las necesidades de todos los clientes que podrían integrar su mercado porque sería poco usable y muy caro. Por eso tenemos que decidir en qué segmentos y personas de clientes vamos a enfocarnos y -para ellos, sí- a intentar resolver el 100% de su problema. En resumen, en el caso del producto se da mucha más incertidumbre en cuanto a los clientes y sus problemas.
  • Fórmula del beneficio. Las corrientes de ingresos y costes son diferentes: un desarrollo a medida es esencialmente una iniciativa singular, que atiende a los requisitos particulares de un cliente concreto en un momento dado. Para el proveedor representa un proyecto generalmente intensivo en recursos especializados y caros. De modo que -para que el proyecto sea rentable- el precio a cobrar al cliente debe compensar con creces esos costes. Y aunque siempre hay componentes comunes que se pueden repetir a través de varios proyectos, en muchas condiciones los derechos de propiedad intelectual sobre los desarrollos -que suelen corresponder al cliente- impiden su replicación (legal) por parte del proveedor.
    Los productos para un mercado son todo lo contrario: ningún cliente nos va a pagar los costes completos de desarrollo y éste va a requerir una inversión sustancial, con lo que los productos sólo son rentables con la repetición. Y debe constituir un modelo de negocio escalable, para que, a medida que aceleramos el negocio y aumentamos los volúmenes, la rentabilidad no sólo no se deteriore sino que mejore.
    Pero también hay una influencia mutua entre las rentabilidades de estos dos negocios cuando compiten en un mismo mercado: especialmente cuando en un mercado hay proveedores vendiendo productos estándar, los precios tienden a bajar y la rentabilidad de las soluciones desarrolladas a medida se reduce.

Estas diferencias entre un negocio y otro implican un cambio de pensamiento y de filosofía de gestión que provoca que a muchas empresas les resulte difícil pasar de un modelo basado en desarrollos a medida a otro basado en producto para un mercado. En la próxima entrega hablaremos de los escollos que nosotros mismos nos ponemos al convertirnos en una empresa de producto.

El post “Modelos de negocio basados en producto: características y diferencias respecto al negocio de desarrollos a medida” 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.]

4 comentarios

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).

Customer Development, Diseño y Agile

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:

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.]

1 Comentario

Hablamos mucho de la visión de producto pero ¿qué forma debería tener? ¿Una frase, un documento, un prototipo…? En este post proponemos un formato.

Supongo que cada uno tendrá sus preferencias pero estaréis de acuerdo en que idealmente la visión de producto debería expresarse mediante un artefacto que la haga fácil de compartir, comunicar y debatir.

Y recordando lo que decíamos en un post anterior, una buena manera de enfocarnos en las soluciones (productos y servicios) que vamos a proporcionar y los tipos de clientes a los que vamos a servir en un futuro más o menos cercano es guiarnos por el valor que vamos a crear y entregar a esos clientes.

Una Visión de Producto centrada en el Valor para el Cliente

Recordando nuestras ideas sobre el valor, la visión debería reflejar estos puntos:

  • La funcionalidad y características del producto sólo son valiosas en tanto que producen una utilidad y resultados para el cliente
  • El valor del producto viene dado por sus beneficios (funcionales, económicos, emocionales) pero también por sus costes, tal y como los percibe el cliente
  • El valor del producto es contextual (depende del cliente y la aplicación) y sobre todo es relativo (se percibe frente a las alternativas existentes).

Teniendo en cuenta esos requisitos, trabajando con algunos clientes he encontrado que un formato útil para expresar la Visión de Producto es el siguiente: Lienzo de Visión de Producto El formato se compone de estos elementos:

  • Frase resumen: una breve expresión (1-2 frases) de la propuesta de valor. Puede ser útil expresarla como una analogía con un negocio conocido, p. ej., “el 7-Eleven de los seguros”.
  • Cliente: ¿Para quién es el producto? Perfil demográfico (si es persona). Perfil psicográfico (valores, estilo de vida, personalidad, actitudes…) y de comportamiento. Perfil “firmográfico” (si es empresa). Identificación de Compradores vs. Usuarios.
  • Necesidad / problema / objetivo: ¿Qué necesita el cliente? ¿Qué desea? Una manera de expresarlo es como el trabajo que desea realizar, las mejoras que desea obtener y los inconvenientes y dificultades que desea eliminar. Este apartado nos da una idea de la oportunidad para crear valor en el cliente.
  • Solución: ¿Qué es el producto? ¿Qué hace? Descripción del concepto. Experiencia de cliente. Funcionalidades y características más relevantes. Precio.
  • Valor para el cliente: ¿Para qué usar el producto? ¿Cuáles son los resultados previsibles? ¿En qué medida se cubren las necesidades? Beneficios frente a Costes (funcionales, emocionales, económicos), considerados siempre desde la perspectiva del cliente. Nuestro objetivo debería ser entregar y que el cliente percibiera ese valor.
  • Rivales: ¿Contra quién competimos (no necesariamente productos equivalentes) por ese dinero? En la mayoría de los casos va a ser el statu quo, estrategias de mitigación, soluciones parciales/provisionales. Y también productos competidores, sustitutivos y alternativos.
  • Diferenciadores: Puntos de diferenciación frente a principal/es rival/es. Cómo vamos a desbancar al statu quo. Cómo vamos a conseguir ser “10 veces mejores” que las alternativas existentes, para que el mercado adopte nuestro producto.

Como se puede ver, la mitad izquierda de la plantilla recoge información acerca del mercado, mientras que la mitad derecha recoge información desde la perspectiva del mercado. El contenido de estos apartados puede ser textual pero también incorporar bocetos, mockups, etc. El objetivo es que posea un carácter gráfico y mínimo que facilite su uso, comprensión y comunicación.

Alternativas a nuestra Visión de Producto

Existen en la literatura otros artefactos que sirven para expresar una “visión” de producto:

  • Value Proposition Canvas de Alex Osterwalder: es una complemento/extensión de su famoso Lienzo de Modelos de Negocio, que detalla dos de los elementos de éste: Segmentos de Clientes y Propuestas de Valor. Este lienzo de propuesta de valor aplica el enfoque de Jobs-To-Be-Done popularizado por Clayton Christensen y en el lado del cliente se enfoca en los trabajos que estos desean realizar y los resultados que desean obtener (aumentar las “ganancias” y mitigar los “dolores”). En el lado de la solución, el lienzo recoge el concepto del producto/servicio y los atributos de éste que contribuyen a crear esas mejoras y a reducir esas pérdidas. Aunque el planteamiento es bueno debo decir que en conjunto el lienzo me resulta un poco reiterativo y confuso y no va más allá del concepto de producto y de sus features&functions.
  • Lean Canvas de Ash Maurya: una especie de Lienzo de Modelos de Negocio parcial, complementado con elementos relacionados con el producto y optimizado para su aplicación en Lean Startup. Es útil si necesitas manejar los aspectos de modelo de negocio y de producto en un único lienzo, pero a mi modo de ver insuficiente en ambos campos: le falta la visión de la “trastienda” del modelo de negocio y su orientación al valor para el cliente es mejorable.
  • Vision Board de Roman Pichler: Roman es una referencia en el mundo del Agile Product Owner (aunque discrepo de muchas de sus ideas, en especial las que se refieren al Agile Product Manager). Su Vision Board es un buen intento de artefacto ligero y conciso, pero que llega a ser contradictorio porque mezcla los problemas y soluciones del cliente con el valor para el proveedor.

Todos ellos son artefactos bastante aceptables y en su momento me sirvieron de inspiración (aunque ninguno me acabe de convencer plenamente). Por su parte creo que nuestra Visión de Producto

  1. Incorpora esos aspectos mínimos que deben guiar la estrategia, el roadmap y el desarrollo del producto
  2. Añade diversos elementos expresamente relacionados con el valor para el cliente (p.ej.: explicita beneficios y costes, resalta diferenciadores) que son críticos para el éxito de la propuesta.

Finamente, seguro que habréis notado el paralelismo de nuestra plantilla con la clásica expresión de posicionamiento de Geoffrey Moore en “Chrossing the Chasm”:

Para <segmento clientes>
que tienen <problema / objetivo / necesidad>
<Nombre producto> es un <categoría de producto>
que aporta <razón única para comprar / beneficios clave>.
A diferencia de <alternativa principal>
proporciona <diferenciación>.

Esta coincidencia no es necesariamente mala (ni casual). Lo que si debemos tener claro es que el objetivo y el uso de ambos artefactos son diferente. La Visión está orientada a futuro y expresa dónde querríamos estar dentro de unos (pocos) años en términos de Producto-Mercado; el Posicionamiento está orientado al presente y expresa qué lugar queremos que nuestro producto ocupe en la mente de nuestros clientes.

¡Espero que os sea útil!

El post “Vision de Producto: una propuesta de formato” se publicó primero en “Marketing & Innovación”.

[Una buena función de "product management" es imprescindible para gestionar cada producto como un negocio. Descubra en este taller práctico cómo implementar una gestión de productos realmente enfocada en el mercado.]

7 comentarios

FeditLa Federación Española de Centros Tecnológicos (Fedit) me ha invitado a impartir un taller sobre”Desarrollo Ágil de Negocios y Productos Tecnológicos” el próximo 29 de abril en su sede de Madrid.

Los contenidos están basados en la nueva versión de mi taller sobre Agile Product Development (ver introducción y agenda en la presentación adjunta).

En está página tenéis más información sobre contenidos e inscripción. El taller está abierto a todo el mundo (con un precio especial a los Centros asociados) y como en otras ocasiones Fedit me autoriza a ofreceros un descuento del 20% en la inscripción. Para conseguirlo basta con que dirijáis un email a comunicacion@fedit.com, explicando que sois lectores de este blog.

Nos vemos el día 29 en Madrid…!

 

El post “Taller sobre Desarrollo Ágil de Negocios y Productos Tecnológicos en Fedit” se publicó primero en “Marketing & Innovación”.

1 Comentario

En gestión de productos hablamos con frecuencia de la “visión” como algo que debe enmarcar nuestro roadmap y guiar el desarrollo de producto a largo plazo, y con frecuencia achacamos el fracaso de una marca al hecho de que “carece de una visión clara”. Pero ¿para qué sirve y cómo se construye una visión de producto?

Intuitivamente todos tenemos una idea de la visión como algo que describe las soluciones (productos y servicios) que vamos a proporcionar y los tipos de clientes a los que vamos a servir en un futuro más o menos cercano. Dependiendo de la industria, la visión puede cubrir típicamente entre 2 y 5 años aunque en algunos sectores (pensemos en farmacia) la visión puede abarcar plazos mucho más largos.

Ciertamente, la visión no busca describir los productos que estamos vendiendo hoy, aunque es a través de una sucesión de productos y versiones “actuales” como aspiramos a alcanzar esa visión. Y siempre deberíamos tener una visión hacia el futuro: si nos acomodamos en nuestros productos y mercados presentes podemos ser presa fácil de rivales más innovadores. Así pues, la visión debe actualizarse periódicamente. Iterando sobre la Visión de Producto

 

La Visión debe validarse y ser estable, pero tiene que poder evolucionar

Asumiendo que estamos utilizando un proceso de desarrollo de nuevos productos más o menos flexible y centrado en el mercado, una expresión estable de la visión sólo puede ser el resultado de las actividades de descubrimiento y validación del producto. Previamente, durante las actividades de búsqueda y evaluación preliminar de la oportunidad de mercado, es útil manejar borradores provisionales de la visión de producto (con su expresión de clientes, problemas, soluciones, etc.) pero que no constituyen visiones validadas.

Con posterioridad, si la evaluación de la oportunidad culmina en un “Go!” y acometemos el proceso propiamente dicho de desarrollo del producto, sin duda que las asunciones recogidas en la visión se convertirán en las primeras hipótesis a comprobar.

Mediante un proceso iterativo de análisis y experimentación en el mercado (aplicando entrevistas, observaciones, contraste de mockups…) podemos ir eliminando incertidumbres y refinando los componentes de nuestro modelo de negocio y nuestra visión. El objetivo de esta actividad, que consiste en descubrir un producto que valga la pena construir y comprobar el Encaje Problema/Solución, equivale a alcanzar una visión de producto validada.

A partir de ahí entramos en una fase de validación del producto y de comprobación del Encaje Producto/Mercado durante la cual la visión debe gozar de una cierta estabilidad y vocación de permanencia (o al menos, toda la que nos permiten estos enfoques en lo que cualquier asunción está sujeta a refutación).

Aunque en esta etapa el protagonismo lo tienen otros artefactos (requisitos, prototipos, backlogs… e incluso un “Lienzo de Producto”) más enfocados en el avance del desarrollo, la visión siempre está presente como guía y referencia para el proceso. Además de la misión obvia de indicarnos hacia dónde tenemos que ir y qué tenemos que desarrollar, en estos tiempos “ágiles” la visión cumple dos objetivos muy importantes:

  • Transmite un sentido de propósito y de intención que debe inmunizarnos ligeramente contra las veleidades de “pivotar” a la mínima dificultad. Hemos visto muchas empresas que aplican de una manera tan extrema los principios lean que a fuerza de pivotar acaban pareciendo pollos sin cabeza. La visión nos insufla un sesgo hacia la perseverancia que puede ser muy útil.
  • Además de indicarnos lo que deberíamos desarrollar la visión nos marca lo que NO debemos desarrollar: en principio, toda funcionalidad, característica, atributo… que nos aleje del camino para alcanzar dicha visión. Estos nos protege de solicitudes oportunistas de muchos stakeholders (inversores, directivos, vendedores…) que en el mejor de los casos tienen sólo una panorámica parcial del mercado.

Finalmente, a un nivel más estratégico, una  visión validada sirve de base para definir una estrategia de producto (que dibuja el camino para alcanzar dicha visión) y un roadmap interno en la que se definen las sucesivas versiones del producto para ir acercándonos a ella.

La Visión debe enfocarse en el Valor para el Cliente

Se pueden aplicar muchos enfoques para definir la visión, pero si asumimos que el objetivo de todo producto es resolver un problema de mercado, yo optaría por un enfoque basado en el valor para el cliente. En otras ocasiones hemos definido este valor como “la utilidad percibida del conjunto de beneficios que recibe un cliente a cambio del coste total de una oferta, teniendo en consideración otras ofertas y precios competitivos”.

Por lo tanto la visión debería tener en cuenta específicamente aspectos como los beneficios y costes de toda índole (funcionales/ emocionales/ económicos y explícitos/ ocultos) de nuestra oferta y los diferenciadores frente a las principales alternativas que ofrece el mercado. Sin embargo, como veremos, la mayoría de artefactos existentes para expresar la visión no van más allá del plano de la experiencia de usuario y las features&functions del producto.

¿Qué forma debería tener esta visión basada en el valor? En un próximo post haremos una propuesta de plantilla de Visión de Producto que intente recoger estas ideas.

El post “Vision de Producto: para qué sirve y cómo se construye” se publicó primero en “Marketing & Innovación”.

[Una buena función de "product management" es imprescindible para gestionar cada producto como un negocio. Descubra en este taller práctico cómo implementar una gestión de productos realmente enfocada en el mercado.]

4 comentarios

Desarrolla productos que los clientes quieran comprar aplicando Agile, Lean y Design Thinking

Estoy actualizando los talleres Conversis relacionados con gestión y desarrollo de productos, para incorporar las últimas ideas que he ido desarrollando en el blog. Creo que la formación disponible en España sobre el “nuevo desarrollo y gestión de productos” tiene algunas carencias:

  • Suele centrarse exclusivamente en alguna de las filosofías actuales (Agile, Lean…) pero carece de una perspectiva integradora.
  • Generalmente es poco práctica, centrándose en aspectos de validación pero sin bajar al terreno de la construcción de productos y negocios.
  • Aunque se vende como gestión de producto muchas veces en realidad se trata de gestión de proyecto.

Agile Product DevelopmentEsas son algunas de las carencias que aspiro a solucionar con esta renovada oferta y el primer paso es un nuevo taller sobre Agile (/ Lean / Design-oriented…) Product Development.

El objetivo del taller es presentar un proceso completo para el desarrollo de nuevos productos basado en el valor para el cliente, analizar dónde encajan cada una de esas nuevas metodologías y herramientas y cuándo es mejor usar unas y otras, y aprender a combinarlas de una manera integrada para construir productos que los clientes quieran comprar.

Éste es el temario:

1. Introducción: necesitamos desarrollar productos de una manera más flexible y enfocada en el mercado.

    • El nuevo desarrollo de producto. Diferencias con los enfoques tradicionales.

2. Cómo descubrir y evaluar oportunidades de mercado.

    • Productos y modelos de negocio.
    • Exploración de oportunidades, análisis y cuantificación.
    • Segmentación y targeting.
    • Tamaño y evolución del mercado.

3. Cómo entender lo que necesitan los clientes.

    • Investigación de mercados tradicional y no convencional: entrevistas, etnografía, lead users, experimentación en el mercado.
    • Conceptualizando las necesidades y problemas de los clientes: enfoque Jobs To Be Done.
    • Comprensión profunda de los clientes: customer insights.
    • Definiendo el espacio del problema a resolver: elicitación de requisitos, Voice of Customer.

4. Cómo diseñar y validar modelos de negocio.

    • Modelos de negocio y propuestas de valor.
    • Customer Development y Productos Mínimos Viables. Iteraciones y pivotes.
    • Validación de la oferta: Encaje Problema-Solución y Encaje Producto-Mercado.

5. Cómo definir y diseñar productos/servicios.

    • Diseño centrado en las personas. Design Thinking.
    • Arquetipos de cliente: personas de usuario y de comprador.
    • Cómo hacer que mi producto sea más deseable, útil, usable y comprable.
    • Cómo construir y gestionar experiencias de clientes.

6. Cómo implementar nuevos productos mejor y más rápidamente teniendo en cuenta al cliente.

    • Ingeniería Ágil: principios, valores y técnicas.
    • Priorizando las características del producto a implementar.
    • Conjugando un diseño integral con una implementación incremental. Diseño Lean/Agile.

7. Emprendimiento basado en hipótesis: Lean Startup.

Este es el temario que vamos a cubrir en un taller organizado por Feuga y que tendrá lugar en su sede de Santiago de Compostela el próximo 24 de marzo. En esta página tenéis más información (justificación, objetivos, audiencia…) y la posibilidad de registraros.

Si estáis ese día en Santiago espero veros por allí. Y si queréis organizar algo alrededor de estos temas en vuestra empresa no dejéis de contactarnos.

El post “Nuevo Taller: Agile Product Development” se publicó primero en “Marketing & Innovación“.

1 Comentario

El nuevo Product Manager debe basarse en un foco obsesivo en el cliente, en gestionar el producto como un negocio, en la experimentación y la iteración para ir aprendiendo en el mercado y en equipos multidisciplinares integrados.

En la primera parte de este post hablamos de cómo estos nuevos tiempos dominados por el poder de los clientes y la volatilidad reclaman una nueva gestión de producto. En esta segunda parte vamos a ver cómo este movimiento implica cambios en las filosofías, los procesos y los artefactos del Product Management.Agile Lean Product Management

Filosofía y principios del nuevo Product Management

A mi modo de ver, estos son los pilares filosóficos de la nueva gestión de producto.

  • Foco obsesivo en el cliente. El “enfoque hacia el cliente” debe dejar de ser una frase vacía. Las necesidades, problemas y objetivos de los clientes y el valor que les podemos aportar deben ser la “medida de todas las cosas” en la gestión de producto. La colaboración con el mercado y el valioso feedback que podemos obtener de él deben ser constantes a lo largo de todo el proceso de desarrollo  y en todo el ciclo de vida del producto.
  • Gestionar el producto como un negocio. Si quiere aspirar a ser el “CEO del producto” el Product Manager debe convertirse en un experto en su modelo de negocio. No es sólo que para que un producto tenga éxito debe estar sustentado por un modelo de negocio rentable y escalable. El mayor potencial de disrupción en cualquier sector no está en productos más o menos nuevos, sino en modelos de negocio innovadores que revolucionan las industrias.
  • Experimentación e iteración. La nueva gestión de productos debe estar más basada en datos y evidencias de mercado y menos en opiniones y convenciones. Y para conseguirlo debemos identificar lo que no sabemos sobre nuestro negocio, expresarlo como hipótesis y validarlo (o refutarlo) mediante la experimentación en el mercado. Las nuevas tecnologías han permitido multiplicar la fiabilidad y la velocidad y reducir el coste de estos experimentos.  Y mediante iteraciones sucesivas este proceso nos permite ir avanzando en el descubrimiento y validación de nuestro producto.
  • Equipos multidisciplinares e integrados. Hay que romper los silos organizativos y construir equipos multifuncionales que permitan integrar conocimientos y puntos de vista y favorezcan la mejora y el aprendizaje continuos. Como se decía en este artículo pionero, el desarrollo (y la gestión) de productos no debe funcionar como un equipo de relevos que se van pasando el testigo sino como una melé de rugby que avanza de manera solidaria. Estos equipos priman la interacción y la adaptación frente a los procesos predefinidos y fomentan el uso de unos artefactos sencillos que favorecen la transparencia y la colaboración.

Procesos, tácticas y artefactos del nuevo Product Management

Vamos a pasar revista a algunas de las actividades clave de la gestión de producto y a analizar cuáles serían sus procesos, tácticas y artefactos.

Búsqueda y evaluación de oportunidades de mercado

La búsqueda de oportunidades de negocio trata de identificar problemas y necesidades de mercado que valga la pena resolver. Pero la evaluación de oportunidades no consiste en un business case estático, construido sobre unas previsiones financieras a largo plazo totalmente irreales (cuando no ilusorias). Debemos realizar una evaluación ligera y dinámica, basada inicialmente en un bosquejo preliminar del modelo de negocio y en unas simulaciones financieras básicas, que nos ayuden a identificar los riesgos más importantes y a decidir si vale la pena lanzar el proceso descubrimiento y validación de producto. El concepto de Plan Máximo Inviable  (propuesto aquí) puede resultar útil.

Desarrollo de nuevos productos y negocios

El desarrollo de nuevas ofertas y negocios es un proceso iterativo, guiado por la evidencia del mercado y el feedback de los clientes y protagonizado por un equipo multidisciplinar. Personal de Product Management, Diseño de Experiencias y Tecnología/Ingeniería colaboran con diferentes grados de involucración en las iteraciones del proceso, cuyo objetivo último es validar un producto que valga la pena escalar y un proceso comercial replicable (Encaje Producto-Mercado).

Comercialización

En general Product Management no se ocupa de implementar programas y actividades de go-to-market: esa es la función del equipo de Marketing/Ventas (o de Growth Hacking, según la terminología al uso).

Pero lo que sí es responsabilidad del Product Manager es proporcionar a Marketing/Ventas todo el contexto de producto necesario para que estos puedan crear sus programas y campañas, habilitarles con el conocimiento de producto necesario para que puedan desarrollar sus tareas y colaborar con ellos en actividades específicas relacionadas con el producto. (Cuando la función de gestión de producto se reparte entre varios puestos, ésta es la misión específica del Product Marketing Manager).

Product Management debe aportar los siguientes resultados:

  • Segmentos outbound de mercado, personas de comprador con sus necesidades, objetivos y escenarios de compra.
  • Estrategia y procesos comerciales escalables y alineados con los procesos de compra, para crear una “máquina de fabricar clientes”.
  • Posicionamientos y arquitectura de mensajes para los diferentes segmentos y personas, centrados en los problemas de mercado y en el valor para el cliente.
  • Herramientas de marketing y ventas que den soporte a esos procesos comerciales y ayuden a crear la experiencia de compra deseada: argumentarios, comparativas respecto a la competencia, presentaciones y demostraciones de producto, referencias…

Estrategia de producto

La transición a filosofías más ágiles e iterativas no debe ser la excusa para carecer de una estrategia de producto que se alinee con la estrategia de la empresa y sea sinérgica con los restantes productos de la cartera. Pero obviamente esta estrategia no debe traducirse en un plan para ejecutar de manera inflexible, sino en un plan para aprender y descubrir nuevos mercados.

La plasmación de la estrategia de producto lo constituye un nuevo tipo de roadmap de producto, más ágil y centrado en el mercado. Frente a los roadmaps tradicionales, constituidos por  listas de funcionalidades y especificaciones técnicas y que reflejan los objetivos de stakeholders internos, el nuevo roadmap debe basarse en una lista de los problemas de mercado y objetivos de cliente que aspiramos a resolver. Pero considerados no como un compromiso ineludible o un plan inexorable, sino como un backlog priorizado de oportunidades de mercado que vayan alimentando y constituyan el input de nuestro proceso de descubrimiento y validación.

Medida y control

Si queremos gestionar el producto como un negocio es imprescindible disponer de una serie de métricas que nos permitan supervisar, analizar y optimizar continuamente su rendimiento en todas las dimensiones relevantes para garantizar el éxito del producto.

No basta con limitarnos a unas métricas de funnel (como por ejemplo, las famosas “Métricas para Piratas”, tan aplicadas en productos digitales): en cada fase del ciclo de vida hay que definir un scorecard de producto que incorpore métricas adecuadas (accesibles, auditables, accionables) en áreas como los objetivos de negocio, el go-to-market, la habilitación de la organización o la calidad del producto.

El post “Necesitamos un nuevo Product Management (2)” 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.]

2 comentarios

La gestión de producto debe adaptarse a estos nuevos tiempos dominados por el poder de los clientes, la innovación y la volatilidad. Las filosofías basadas en el descubrimiento de mercados, la agilidad, el diseño de experiencias y la validación de clientes y productos pueden contribuir a renovar el Product Management.

El Product Management no tiene últimamente muy buena prensa. De un tiempo a esta parte muchos gurús vienen desacreditando la (“antigua”) actividad de gestión de productos:

Combinando Agile, Design Thinking, Customer Development, LeanLlevamos 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.

Por centrar el debate, dejemos claras un par de cosas:

  • La gestión de producto tradicional (y no olvidemos que esta función empezó a definirse hace menos de 80 años) ha estado influida -igual que otras funciones de la empresa- por filosofías basadas en la planificación rígida, en organizaciones jerárquicas, en procesos secuenciales, en burocracia… Este enfoque ha podido resultar eficaz en épocas de cambio lento y de innovación limitada, cuando las empresas controlaban sus mercados, pero no lo es en esta era en que las nuevas tecnologías aparecen cada día, habilitando modelos de negocio radicalmente nuevos y en que unos clientes cada vez más conectados e informados están al mando. Necesitamos adaptar el Product Management a esta nueva era.
  • La gestión de producto se puede mejorar. Si la ingeniería de software se ha podido beneficiar de las metodologías iterativas y evolutivas o del prototipado rápido (sin que por ello tengamos de cambiar de nombre a esta actividad) el Product Management puede adoptar principios de Agile o Design Thinking para hacerse más flexible y adaptarse a esta era cambios e incertidumbre. Pero no pensemos que el nuevo Product Management equivale a Customer Development o que el nuevo Product Manager es el Product Owner. Como hemos visto, ninguna de estas metodologías/roles abarca todo el espectro de funciones  que exige la gestión de producto.

En realidad, la función/rol de Product Management nunca ha sido más importante que ahora, especialmente en productos tecnológicos. Más que nunca, las empresas seguirán necesitando personas que se responsabilicen  de hacer productos que la gente quiera comprar y del éxito de esos productos en el mercado, con toda la extensión y profundidad de actividades que requiere esa función (recordemos que la gestión de productos es mucho más que el desarrollo de nuevos productos).

Bien sea un Jefe de Producto experimentado o bien el propio CEO quien desempeñe esa función necesitamos una persona (y no un comité) que se responsabilice de gestionar el producto como un negocio.  Por eso los rumores sobre la muerte del Product Management han sido enormemente exagerados, como lo demuestra el hecho de que incluso las empresas tecnológicas más avanzadas siguen contratando Product Managers expertos.

Pero eso requiere que el Product Management se adapte a la extrema volatilidad y velocidad de los mercados, clientes y tecnologías actuales.

Necesitamos un Product Management más Agile / Lean / ….. (escribe tu buzzword favorita)

Hacer un Product Management más moderno significa incorporar de manera crítica lo mejor de las nuevas filosofías de una forma no dogmática y sin caer en prescripciones “religiosas” ni en liturgias innecesarias… a la vez que se preserva lo que sigue funcionando.

Creo que es estéril definir si el nuevo Product Management debe estar más basado en Agile o en Design Thinking, Customer Development, o Generación de Modelos de Negocio (no me gusta participar en guerras de religión). Como hemos visto por aquí, todas estas filosofías tienen muchos puntos en común -aunque también algunas contradicciones, que se van superando paulatinamente. Pero lo más importante es que en conjunto renuevan y aportan una nueva dimensión a la gestión de producto.

Este nuevo enfoque para el Product Management se debe caracterizar por un intenso foco en el mercado y en las experiencias del cliente, una máxima flexibilidad y adaptación y una mínima burocracia, que se aplican en todo el ciclo de vida del producto.

El Product Manager debe ser el experto en el mercado y la voz más autorizada en el equipo. No se conforma con recibir de una manera reactiva los requisitos que le envían todos los interesados (clientes, vendedores, desarrolladores, directivos) sino que de una manera activa genera customer insights e información de mercado. Para ello aplica un conjunto ecléctico de técnicas para entender lo que el mercado necesita y cómo crear valor para los clientes (y no limitarse a escuchar lo que algunos usuarios dicen que quieren).

El Product Manager destila esos inputs para descubrir problemas y necesidades que vale la pena resolver (en términos de su importancia, urgencia y extensión) y mantiene una lista priorizada de problemas abiertos y de la oportunidad de mercado asociada con cada uno. Para cada oportunidad de mercado prioritaria el Jefe de Producto elabora y valida una visión del producto que sirva para alinear a todo el equipo y mantenerlo enfocado en los segmentos de mercado, personas (de comprador y usuario) y problema a resolver.

El uso de datos de mercado en lugar de opiniones y convenciones, la iteración y la colaboración en equipos multidisciplinares son la clave de todas las actividades: no sólo en desarrollo, también en la comercialización, la evolución y el control del producto.

En conjunto, este movimiento implica cambios en las filosofías, los procesos y los artefactos del Product Management, que iremos detallando en la segunda parte de este post.

El post “Necesitamos un nuevo Product Management (1)” 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.]

9 comentarios

Hacer que una misma persona desempeñe las funciones de Product Manager y Product Owner puede ser una opción válida si las circunstancias nos obligan, pero entraña un gran riesgo de fallo. Si es posible, lo mejor es dedicar recursos exclusivos para ambas funciones, que trabajen en estrecha colaboración.

Tanto el rol de Product Manager como el de Product Owner son funciones muy exigentes, que demandan una dedicación exclusiva. A eso se añaden las diferencias de foco, relación, etc. de ambos roles, que exigen perfiles muy diferentes:

  • El rol de Product Management tiene un foco más estratégico y centrado en el negocio y el mercado (éxito del producto), está más volcado hacia el exterior de la empresa y hacia los departamentos internos que deben colaborar para alcanzar ese éxito y su interacción con los clientes gira alrededor de sus necesidades presentes y futuras.
  • El rol de Product Owner tiene un foco más táctico y técnico, está más volcado hacia el interior de la empresa (equipo de implementación) y su interacción con los clientes se centra en las features a entregarles de manera inmediata.

Sin embargo, las circunstancias mandan y a veces resulta imposible cubrir ambas funciones con puestos (y personas) dedicados en exclusiva a cada una de ellas. En las empresas reales es muy habitual que un Product Manager deba asumir también el rol de Product Owner y viceversa.

Product Manager and Product Owner

¿Puede un Product Manager asumir el rol de Product Owner?

Mi opinión es que un Product Manager experimentado puede asumir también con garantías la función de Product Owner en un producto de una complejidad moderada. Sin embargo, también puede ocurrir que ese Product Manager fracase a la hora de sacar todo el partido de Agile y entre en alguno de los siguientes “modos de fallo”.

Dónde puede fallar un Product Manager que asume también funciones de Product Owner

Los problemas suelen venir cuando el Product Manager carece del tiempo, los recursos o la experiencia para desarrollar ambas funciones y acaba dando prioridad a una de ellas, que suele ser la suya original como Jefe de Producto. Como consecuencia:

  • Tiene una integración “a tiempo parcial” con el equipo técnico y nunca llega a sacar partido de la capacidad de éste para cambiar de dirección.
  • Prefiere enfocarse en los aspectos más globales -descuidando las labores del día a día del Product Owner- y acaba obligando a Ingeniería a asignar sus propios Product Owners… que tienen que adivinar lo que quiere ese Product Manager remoto.
  • Ocasiona que historias de usuario y pruebas de aceptación adolezcan de falta de detalle y actualización.

Eso se traduce en una insuficiente presencia de la voz del mercado durante la construcción del producto y, como consecuencia, en la implementación de features que no son aceptadas, reelaboraciones costosas, frustración en el equipo e incapacidad para entregar valor para el cliente.

¿Puede un Product Owner asumir el rol de Product Manager?

La realidad nos muestra que incluso un Product Owner experimentado tiene dificultades para asumir todas las funciones de Product Manager. Ello se debe a que las actividades más estratégicas y de relación con el mercado, la visión de negocio  y la coordinación con los departamentos no técnicos de la empresa no figuran entre sus habilidades y experiencia.

Dónde puede fallar un Product Owner que asume también funciones de Product Manager

Aunque los veremos con más detalle en otro post, estos son los modos de fallo más habituales:

  • Foco en entregar features, no en la estrategia de producto a largo plazo: visión, roadmap.
  • Asunción de que los clientes que participan en las revisiones de producto representan al conjunto del mercado.
  • Desconocimiento de aquellas facetas del producto que condicionan su éxito en el mercado: precios, packaging/bundling, ofertas complementarias, valor para el cliente, diferenciadores competitivos.
  • Desconexión respecto a los departamentos internos (Marketing, Ventas, Dirección…) que deben colaborar para convertir el producto en un negocio.

La consecuencia de todo ello es un equipo de desarrollo muy productivo… pero que entrega un producto que no responde a un target claro, se lanza en el momento equivocado, con un precio inadecuado, con unos departamentos de Comercial y Soporte insuficientemente habilitados y, consecuentemente, incapaz de alcanzar su mercado objetivo y de aportar el beneficio esperado.

Si es posible, separar las funciones de Product Manager y Product Owner

En empresas de producto que aplican metodologías ágiles de implementación basadas en Scrum, las figuras del Product Manager y Product Owner (cada una con su alcance y funciones) son imprescindibles. Pero para desarrollarlas con el grado de profundidad y dedicación que requieren y evitar los modos de fallo enumerados anteriormente es conveniente que cada una esté desarrollada por personas especializadas y con dedicación completa:

  • Product Manager – el “CEO del producto”, enfocado en los aspectos de negocio y en el mercado desde una perspectiva estratégica, encargado de “construir las features correctas” para crear y comercializar un producto que tenga éxito en el mercado.
  • Product Owner – integrado en el equipo de ingeniería ágil, enfocado en proporcionar funcionalidad a los clientes, encargado de “construir correctamente (y rápidamente) las features.

La ingeniería ágil puede mejorar la calidad y la flexibilidad en la construcción de nuestros productos. Y un enfoque ágil aplicado a toda la gestión de producto -y en general al conjunto de las funciones de la empresa- puede conseguir que seamos más adaptables, centrados en el mercado y rápidos. Pero eso no se consigue optando por la figura del Product Owner en lugar del Product Manager (o viceversa), sino desarrollando ambas funciones de la manera más coordinada y eficaz posible.

El post “Agile: ¿necesitamos Product Managers, Product Owners o ambos? (2)” se publicó primero en “Marketing & Innovación”.

[Una buena función de "product management" es imprescindible para gestionar cada producto como un negocio. Descubra en este taller práctico cómo implementar una gestión de productos realmente enfocada en el mercado.]

7 comentarios

Entre el Product Manager y el nuevo Product Owner de Agile existe un cierto solapamiento que hace que muchos se pregunten si son necesarios los dos. Pero en realidad el problema no es de personas o de puestos, sino de cuál es la mejor manera de desempeñar ambas funciones.

Algunas metodologías de Agile introducen un nuevo rol relacionado con la gestión de producto: el Product Owner. Su principal responsabilidad es representar al negocio ante el equipo de implementación, actuando como la voz del cliente, gestionando el backlog y priorizando historias de usuario. La función de Product Owner, originalmente muy táctica y ligada al equipo de proyecto, es una exigencia de las metodologías basadas en Scrum.

Por otra parte, en empresas orientadas a productos para un mercado (no proyectos a medida de un cliente) es imprescindible una figura que gestione el producto como un negocio a lo largo de todo su ciclo de vida, desde la concepción y construcción a su explotación comercial y ulterior retirada: ese es el rol que se suele conocer como Product Manager.

Equilibrio Product Manager Product Owner

Así definidos, los papeles de Product Manager y Product Owner son muy diferentes, aunque tienen zonas comunes. Sin embargo, en empresas de producto se está produciendo una tendencia del Product Owner a abarcar actividades más estratégicas -que tradicionalmente forman parte de la responsabilidad del Product Manager- y es habitual que surja la controversia ¿es necesario dotarse de uno u otro, de los dos… o basta con una persona para desempeñar ambas funciones?

Para poner las cosas en contexto, recordemos algo: aunque las ventajas de Agile son indudables, simplemente adoptar una metodología de implementación ágil no es la solución al desarrollo de productos. Agile ayuda a entregar algo antes y bien, pero sin un conocimiento del mercado, una visión y un diseño aquello que se entrega puede que realmente no nos ayude a vender más productos. Sin la función de Product Manager en un entorno ágil corremos el riesgo de construir el producto equivocado. Podríamos terminar deleitando al cliente que ha participado en nuestro proceso ágil, pero no siendo capaces de vender al producto a nadie más.

En realidad, aunque todas las empresas de producto necesitan Product Managers, no todas necesitan Product Owners. Antes de empezar a analizar el problema vale la pena recordar que hay varios contextos donde esta polémica no existe:

  • En empresas de producto que no aplican Agile la figura del Product Owner no es estrictamente imprescindible. Si las necesidades de gestión de producto lo requieren es habitual crear el rol de Technical Product Manager encargado de la coordinación con el equipo de Tecnología y de suministrarle el input del mercado.
  • En empresas de proyectos a medida -no de productos repetibles para un mercado- en general no se necesitan Product Managers. Si para esa gestión de proyectos se aplica alguna metodología basada en Scrum, el Product Owner sí es obligatorio.

Para el resto de casos -empresas de producto que aplican metodologías ágiles- la primera tentación es “aplicar el manual” de descripción de los roles y dar una respuesta obvia: si el Product Manager es responsable de gestionar su producto como un negocio durante todo su ciclo de vida y el Product Owner es el representante del negocio ante el equipo de implementación, entonces el Product Owner es el representante del Product Manager ante el equipo de implementación (lo cual no deja de ser una buena referencia).

Los nombres de los puestos importan menos que las funciones y las actividades

Sin embargo, esta respuesta tiene una carencia fundamental: asume que Product Manager y Product Owner son puestos o personas, cuando en realidad son roles o funciones. El “conflicto” entre Product Manager y Product Owner en empresas de producto no consiste tanto en decidir qué puestos crear como en asegurar que ambas funciones se realizan de la manera más armónica y eficaz.

Y la manera óptima de implementar y orquestar las funciones de Product Manager y Product Owner depende de muchos factores, entre ellos:

La fase en el ciclo de vida en la que se encuentra el producto. Veamos por ejemplo lo que ocurre al principio y al final del ciclo:

  • Cuando el producto está en desarrollo, la intensidad necesaria en las funciones de Product Manager y Product Owner hacen que sea conveniente cubrirlas con sendas personas con dedicación completa.
  • Cuando el producto pasa a la etapa de evolución/mantenimiento las exigencias son menores y puede ser suficiente con que una misma persona desempeñe ambas funciones.

La estructura organizativa de la empresa. Veamos un par de ejemplos extremos:

  • En la típica start-up formada por “dos amigos en un garaje” es muy habitual que uno de ellos asuma las funciones más relacionadas con el exterior (mercado, socios, inversores) y el otro las funciones más internas (ingeniería, tecnología). Eso se traduce en que el primero desempeña el papel de CEO + Product Manager + Product Owner y el segundo el de CTO + Jefe de Proyecto (Scrum Master).
  • En una empresa multiproducto con productos complejos (cuya construcción puede involucrar a varios equipos dispersos) lo habitual es que por cada producto exista un Product Manager que se ocupa de las actividades más estratégicas y de relación con el mercado, y que interactúa con varios Product Owners (uno por cada equipo de implementación).

Dependiendo del escenario, hay casos en los que un Product Manager asume la función de Product Owner, un Product Owner asume la función de Product Manager o ambas funciones son desempeñadas por diferentes personas… casos de los que hablaremos en la segunda parte de este post.

El post “Agile: ¿necesitamos Product Managers, Product Owners o ambos? (1)” 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.]

8 comentarios
Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 505 seguidores

%d personas les gusta esto: