Crecimiento de productos tecnológicos

Entradas de Antonio Matarranz

Necesitamos un nuevo Product Management (1)

por en 30 diciembre 2013

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

Si quieres ser un Product Owner excelente aprende Product Management

por en 30 noviembre 2013

El rol de Product Owner no es suficiente en empresas basadas en producto. 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.

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

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 Jefe de Producto por el de un Product Owner cuyas funciones cada vez se parecen 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 el de Product Owner 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 además 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.]

2 comentarios

Publicado el libro de Consejos de Marketing a Iniciadores

por en 16 noviembre 2013

Ya se ha publicado el tercer libro de Iniciador, en esta ocasión dedicado a los Consejos de Marketing a Emprendedores.

Un libro dedicado íntegramente al marketing en el que los propios emprendedores y expertos en este campo nos muestran que el marketing es clave en todo emprendimiento y que muchos buenos proyectos no han conseguido triunfar por obviar que tan importante como lo que vendes es cómo lo vendes.

Consejos de Marketing a Iniciadores

Como ya os conté por aquí tuve la satisfacción de contribuir con un capítulo titulado «Emprendedor: no dejes el Marketing para el final».

A partir de hoy podéis comprar la versión papel y descargar gratis la versión PDF del libro en Bubok.

¡Que os sea útil!

1 comentario

Agile: ¿necesitamos Product Managers, Product Owners o ambos? (2)

por en 3 noviembre 2013

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

Agile: ¿necesitamos Product Managers, Product Owners o ambos? (1)

por en 26 octubre 2013

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 para un mercado 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 de clientes singulares -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.]

9 comentarios

Product Management en un mundo Agile (2)

por en 13 octubre 2013

Cuando se aplica Agile a la construcción de productos el Product Manager debe velar por que el trabajo más estratégico y relacionado con el mercado se siga realizando y por que las features que se entregan, además de implementadas correctamente, son las correctas para que el producto tenga éxito.

Como vimos en la primera parte de este post, la aplicación de metodologías Agile en el departamento de Ingeniería exige que los Product Managers interactúen con sus equipos de desarrollo y sus clientes más a menudo y con una mayor intensidad. En esta segunda parte seguimos hablando de la gestión de producto en un mundo Agile.

Expandiendo los límites de Agile

Como hemos dicho varias veces por aquí, Agile puede ser muy beneficioso (soy un convencido) pero no es la panacea ni una solución completa para gestionar toda la vida de un producto como un negocio. En empresas orientadas a productos para un mercado el Product Manager debe compensar algunas de las carencias que Agile sufre debido a su alcance y a sus orígenes en el campo de proyectos a medida. Pero además (y esto es más frecuente de lo que sería deseable) el Jefe de Producto debe contrarrestar algunos efectos laterales que una “implementación de manual” de Agile puede provocar. Aunque ya hablamos de este tema en otro post, resumimos aquí los principales problemas a evitar:

Product Manager strategic vision

  • Escaso conocimiento y caracterización del mercado y los clientes. A diferencia de los proyectos a medida de un cliente, el problema que debe resolver un producto no es conocido a priori. Antes que nada es necesario construir un mapa que muestre quiénes son los clientes y cuáles son sus problemas/necesidades. Además hay que conseguir que los clientes que participan en las validaciones de los sprints sean realmente representativos del mercado.
  • Insuficiente conceptualización y diseño inicial del producto. La urgencia por implementar y validar tiende a minimizar las actividades de definición y diseño. Y conjugar un diseño holístico con una implementación incremental puede resultar muy complicado. Por otra parte, la iteración y la validación con los clientes debe empezar durante esas actividades iniciales, y no postergarse hasta la construcción del producto. El diseño ágil de experiencias de usuario ayuda a combinar estos dos mundos.
  • Excesivo foco en el corto plazo en detrimento de los aspectos más estratégicos (visión, roadmap, arquitectura, portfolio de productos). El ritmo de entregas puede relegar el enfoque más estratégico a un segundo plano. Resulta difícil ser estratégico cuando se está sometido a las demandas constantes del corto plazo.

En definitiva, el Product Manager debe velar por que las actividades de la gestión de producto más estratégicas y relacionadas con el mercado se realicen.

¿Pero los buenos Product Managers no han sido siempre ágiles?

A pesar de que algunos Jefes de Producto sufren dificultades en la transición a Agile, gente como Saeed Khan sostiene en tono jocoso que los buenos Product Managers siempre han sido ágiles. (O, al menos, lo han sido desde mucho antes que se redactaran los principios del Agile Manifesto.) Desde siempre -y forzados por las circunstancias del puesto y las demandas del mercado- a los Jefes de Producto competentes no les ha quedado más remedio que dar prioridad a

  • Individuos e interacciones, antes que procesos y herramientas. Después de todo ¿los buenos Jefes de Producto no están siempre en contacto directo con su mercado y con los otros departamentos de la empresa?
  • Productos que funcionen, antes que documentación exhaustiva. Y es que ¿quién puede estar más interesado en que un producto funcione, sino la persona encargada de su éxito en el mercado?
  • Colaborar con los clientes, antes que negociar contratos. Y es que la principal prioridad de alguien que se define como el “mensajero del mercado” es interactuar y obtener insights de los clientes mediante entrevistas, visitas, encuestas, revisiones de producto, programas beta, etc.
  • Responder ante cambios, antes que seguir un plan. Los mercados (necesidades de clientes, ofertas competitivas…) cambian y el buen Product Manager reajusta las prioridades a la vista de las nuevas evidencias y datos.

El de Product Manager siempre ha sido uno de los puestos más “ágiles“ de una organización (no le ha quedado más remedio) aunque en general hay que admitir que muchos Jefes de Producto -y no sólo ellos- se beneficiarían de una mayor agilización de sus actividades. Hablaremos de ello en un próximo post.

Implementar las features correctas, antes que implementar features correctamente

Agile exige más a los Product Managers (según algunos expertos, hasta un 30-50% más de dedicación). Una de las grandes controversias en empresas de producto que adoptan alguna forma de Agile es si el rol de Product Manager debe ser desempeñado por la misma persona que el de Product Owner, o si deben ser personas diferentes pero con una estrecha colaboración entre ambas. Si se opta por la primera opción, esa persona debe conjugar los focos -eminentemente externo e interno, respectivamente- de una y otra función. (En empresas de proyectos a medida no hay lugar a este conflicto porque esencialmente no se necesitan Product Managers.)

En cualquier caso, ese tiempo dedicado a los equipos internos puede significar menos tiempo fuera de la oficina, en el mercado. Pero no se puede llegar a entender un mercado si no se sale del despacho. Y ese es el principal dilema del Product Manager en unas empresas de producto cada vez más Agile.

Agile ayuda a entregar de unas features & functions implementadas rápida y correctamente. Pero es responsabilidad del Product Manager garantizar que esas features & functions, además, son las correctas desde una perspectiva de mercado.

En otro post analizaremos que procesos y artefactos debe aplicar un Product Management más Agile/Lean.

El post “Product Management en un mundo Agile (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.]

2 comentarios

Product Management en un mundo Agile (1)

por en 6 octubre 2013

Las empresas de producto están adoptando masivamente metodologías Agile. Eso presenta para los Product Managers nuevas oportunidades -pero también dificultades- y redefine muchos de los procesos y artefactos de la gestión de producto.

[NOTA: Este post trata del impacto sobre los Jefes de Producto de la adopción de filosofías Agile en el departamento de Ingeniería, no de cómo hacer un Product Management más Agile/Lean, que será objeto de otra entrada.]

Agile, por su iteración, su cadencia y la involucración de los clientes impone nuevas exigencias a los Product Managers. En este blog hemos hablado repetidamente de ambos temas (ver aquí y aquí). Veamos ahora cómo se influyen mutuamente.

Incluso con Agile, las empresas de producto necesitan Product Managers

Como hemos dicho por aqui repetidamente, las empresas de producto necesitan Product Managers, y las que aplican Agile no son una excepción. En realidad, deberíamos decir que necesitan de alguien que desempeñe la función de Product Management: alguien que sea el “CEO del producto” (aunque esa función, dependiendo del tipo de empresa, pueda ser desempeñada por uno o varios Product Manager… o el propio CEO). Porque nada bueno cabe esperar si esa responsabilidad, en vez de a una persona, se la damos a un comité.

Esencialmente, Agile no cambia el alcance de las responsabilidades del Product Manager (debe seguir gestionando su producto como un negocio y ser el “mensajero del mercado”) pero la manera de desempeñarlas debe adaptarse a un entorno -en lo que a construcción del producto se refiere- caracterizado por una cadencia más rápida, un enfoque más iterativo y flexible y una interacción más intensa con el mercado y el equipo de proyecto.

Product manager en empresa ágil

Cadencia, iteración, interacción

En Agile, los Jefes de Producto interactúan con sus equipos de desarrollo y sus clientes más a menudo -y con una mayor intensidad- que con las metodologías más lineales: participan en reuniones de releases y sprints, incorporan antes a los clientes para las revisiones de producto y reelaboran el backlog para adaptarlo a cambios en las necesidades del mercado. En algunas situaciones el Product Manager debe asumir también las funciones del Product Owner.

Los documentos tradicionales de la gestión de productos (Requisitos de Mercado, Especificaciones de Producto…) se desagregan y se sustituyen por otros artefactos más sencillos, relevantes y adaptados al ciclo de Agile: visión, roadmaps, prototipos, épicas, historias de usuario, backlogs actualizados…  De hecho, tal vez la responsabilidad principal del Jefe de Producto para con el equipo técnico sea aportar prototipos e historias de usuario útiles y usables sobre las que los ingenieros puedan construir. Estos nuevos artefactos contienen los ingredientes esenciales de nuestros antiguos documentos (y algunos más), pero transformados para ofrecer una mayor claridad, adaptabilidad y alineamiento con el equipo.

Cuando la construcción del producto se hace ágil se requiere del Jefe de Producto una mayor involucración en actividades internas, de nivel táctico y contenido técnico. Un criterio enormemente importante del trabajo del Product Manager en entornos Agile es no dejarse absorber por su foco táctico y orientado al proyecto de construcción del producto.

La mayor parte del trabajo de generación de ingresos de un producto no la realiza el equipo técnico

El desarrollo de nuevos productos es un área vital en la gestión de productos, pero no la única: la comercialización y el alineamiento con el resto de productos de la empresa son también aspectos primordiales. Y ese desarrollo de nuevos productos es mucho más amplio que su construcción o implementación: hay que descubrir y analizar la oportunidad de mercado, definir el producto…  Algunos han escrito que si afirmas que usas Agile como tu proceso de gestión de producto es como si dijeras que probar los platos mientras cocinas es tu proceso para ser un chef. Agile no es un marco para Product Management.

Si bien los ingenieros podemos tener a veces una percepción diferente, la realidad es que la mayor parte del trabajo necesario para que un producto tenga éxito en el mercado se desarrolla fuera del departamento de Tecnología/Ingeniería (aunque, deseablemente, en estrecha colaboración con éste):

  • Antes de la construcción del producto: descubrimiento de problemas de mercado, análisis y cuantificación de la oportunidad de mercado, definición de segmentos (necesidades, personas, escenarios) e identificación de los más interesantes, elaboración de concepto, visión y roadmap del producto, propuesta de valor, diseños iniciales.
  • Durante la construcción: iteraciones de diseño, incorporación de los segmentos importantes del mercado en la validación del producto, empaquetamiento de la funcionalidad en productos y módulos, estrategia de precios.
  • Después de la construcción del producto: posicionamiento, elaboración de mensajes, generación de contenidos y habilitación de equipos de marketing y ventas para que puedan comercializar el producto, participación en programas, campañas y oportunidades comerciales, gestión de alianzas, supervisión y medida del éxito del producto en el mercado.
  • En paralelo con todo el proceso (especialmente en empresas con una cartera de varios productos en distintas fases de su ciclo de vida): estrategias de producto, gestión de una cartera sinérgica, previsiones financieras, comunicación y coordinación con otros involucrados internos (dirección, marketing, ventas, ingeniería).

En definitiva, Agile exige más a los Product Managers pero no constituye un proceso de gestión de producto. En la segunda parte de este post seguiremos hablando de las interacciones entre Product Management y Agile.

El post “Product Management en un mundo Agile (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.]

5 comentarios

Agile y el papel del Product Owner en empresas de producto

por en 28 septiembre 2013

La imparable adopción de filosofías Agile en el desarrollo de productos viene suscitando una cierta polémica sobre el papel del Product Owner y su intersección (en algunos casos, colisión) con el del Product Manager.

En este post introductorio no pretendo hacer una descripción detallada de la función del Product Owner (no soy un experto y podéis encontrar miles de mejores referencias), sino centrarme en algunas de sus peculiaridades en empresas orientadas a producto y en la evolución que está experimentando para adaptarse a estos entornos.

Pero antes de empezar tal vez convenga recordar un par de características de Agile que influyen en este tema (y que hemos tratado anteriormente aquí y aquí). Aunque originalmente las metodologías Agile provienen del campo de los proyectos a medida de un cliente, es en los últimos años cuando se han incorporado al desarrollo de productos repetibles para un mercado. Sin embargo, por su propia naturaleza, Agile se aplica principalmente a las actividades de construcción / implementación del producto, es decir, entra en juego cuando se ha analizado la oportunidad de mercado y se ha decidido que se va a construir “algo” (la “unidad 0” de un producto replicable).

Product Owner y gestión de proyectos

El rol o función de Product Owner proviene de Scrum, una metodología Agile de gestión de proyectos en la que el equipo colabora unido e integrando continuamente el feedback del cliente a través de un proceso iterativo dividido en sprints.

En sus orígenes, el Product Owner de Scrum era un rol táctico, orientado al proyecto e integrado en el equipo técnico que lo ejecuta. Su misión era representar al “negocio” en el proyecto y asegurar que las decisiones de implementación estaban alineadas con las necesidades del cliente y que cualquier problema o duda se resolvía lo antes posible. Para ello actúa como interfaz entre el cliente y el equipo técnico, recabando el feedback del primero al final de cada sprint y adaptándose a los cambios en sus necesidades.

El Product Owner está en contacto permanente con equipo de proyecto (jefe y desarrolladores) gestionando el backlog de la release, elaborando y priorizando historias de usuario, expandiendo especificaciones y tomando decisiones inmediatas sobre funcionalidad y prioridades. Originalmente, en escenarios de proyectos a medida, era incluso habitual que el propio Product Owner fuera un miembro de la organización cliente. En estas circunstancias el Product Owner era literalmente el dueño del “producto” (entendido éste como el resultado del proyecto).

Product Owner y construcción de productos

La gestión de productos replicables para un mercado difiere de la gestión de un proyecto para un cliente en muchos aspectos fundamentales. Empezando por el hecho de que en el escenario de producto repetible no hay un cliente predefinido, sino una mezcla de clientes más o menos heterogéneos y desconocidos (y que en el mejor de los casos podremos segmentar y representar mediante uno o varios arquetipos significativos de clientes). Por eso uno de los primeros pasos en el desarrollo de un producto es acotar el espacio de problemas de mercado y definir el problema a resolver.

Como consecuencia, resulta prácticamente imposible que el Product Owner sea una persona proveniente de la (o, mejor, una) organización cliente: tiene que tratarse de un miembro de la empresa desarrolladora, encargado de representar al mercado en las actividades de construcción del producto. Unas actividades que se enmarcan en un ciclo de vida de producto mucho más amplio y que abarca desde el análisis de la oportunidad de mercado hasta la comercialización del producto.

Aplicado al desarrollo de productos para un mercado, el rol del Product Owner es muy exigente: antes de planificar los sprints, debe escribir historias de usuario y colaborar con el equipo de testing para definir los criterios de aceptación. Durante la planificación de los sprints debe explicar al equipo de implementación las historias sobre las que van a trabajar a lo largo de las siguientes semanas. Durante el sprint (típicamente 1-4 semanas) supervisa el avance, toma decisiones sobre alternativas de implementación,  responde a preguntas, valida las historias terminadas y prepara las historias para el siguiente sprint.

Del Product Owner se espera que esté disponible para el equipo cuando aparecen dudas y que mantenga actualizado el backlog del producto, reorientando las prioridades en función del feedback de los clientes y otros afectados, unas responsabilidades que exigen una presencia casi continua en la war room. El del Product Owner es un trabajo a jornada completa.

Por poner este rol en el contexto de empresas de producto, podemos compararlo con las funciones típicas del Product Manager. En este post Rich Mironov toma el Framework de Pragmatic Marketing al que nos hemos referido otras veces y superpone las actividades del Product Owner.

Agile Product Manager - Product Owner

Así obtenemos una perspectiva de las funciones del Product Owner y de su intersección con las actividades globales de Product Management: ocupan un área a caballo entre la zona estratégica y la táctica y muy centrada en el hemisferio más “técnico” del plano. De hecho, el alcance del rol de Product Owner guarda un gran paralelismo con el del clásico Technical Product Manager, si bien algunas de las actividades que desempeñan, la cadencia con que las realizan (y, desde luego, el nombre que les dan ;- ) son muy diferentes.

Y en este contexto el nombre de Product Owner es menos afortunado: en general sigue estando más enfocado en el proyecto de construcción que en el resto de la vida del producto y la propiedad que ejerce no abarca mucho más que el backlog y las historias.

El Product Owner ideal… y el real

En aquellas empresas que aplicaron un Agile “de manual” al desarrollo de productos (lo que en muchos casos significa la exclusión de la figura del Product Manager) pronto se descubrió que el alcance original del Product Owner era insuficiente para asegurar el éxito del producto en el mercado. Como consecuencia, los defensores de Agile han ido reclamando para el Product Owner la responsabilidad sobre un rango más amplio de funciones que van desde la visión y el roadmap de producto hasta la asignación de recursos.

Se ha pretendido evolucionar hacia un Product Owner ideal (una especie de “Súper Product Owner”) más estratégico y centrado en el negocio, aunque ello ha llevado a una cierta explosión de sus atribuciones… y a una tendencia sospechosa a solaparse con el papel tradicional del Product Manager. En general, esta definición del papel del Product Owner responde a una concepción de la gestión de producto desde la óptica del departamento de Tecnología, que inevitablemente resulta incompleta (y, en ocasiones, sesgada).

Además, en la realidad el puesto de Product Owner es habitualmente cubierto con personal del departamento de Tecnología/Ingeniería con escasos conocimientos del mercado (clientes, competidores) y de otras áreas y funciones de la empresa. Y eso limita su capacidad para realizar eficazmente las tareas de interacción externa e interna necesarias para garantizar el éxito del producto.

Algunos autores y consultores que promueven este nuevo papel del Product Owner llegan a sostener que hasta ahora no había en las empresas una única persona responsable de cada producto y que el Product Owner viene a suplir esa carencia (y si queréis saber cómo, no tenéis más que leer su libro o cursar uno de sus seminarios ;- ). Pero como ya sabemos, la realidad es que en cualquier empresa de producto razonablemente gestionada ya existe esa figura de “CEO del producto” y que atiende al nombre de Product Manager.

Por eso hace unos años se suscitó la polémica de si las empresas de producto comercial necesitaban únicamente Product Managers o Product Owners (o los dos) y si ambas funciones podían ser desempeñadas por la misma persona, aspectos estos que iremos cubriendo en próximas entradas.

El post “Agile y el papel del Product Owner en empresas de producto” 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.]

11 comentarios

Haz que tu producto sea comprable

por en 14 septiembre 2013

No basta con hacer productos más usables, hay que hacerlos más comprables. Y eso exige enfocarnos en el comprador y hacer un esfuerzo de conceptualización y diseño de producto guiado por sus necesidades y objetivos.

Decíamos en un post anterior que en productos de compra compleja compradores y usuarios no son las mismas personas y si a la hora de diseñar el producto nos enfocamos exclusivamente en la funcionalidad de los usuarios podemos dejar de lado los objetivos del comprador y no proporcionarle una razón suficientemente poderosa como para abrir la chequera.

Por eso en productos de compra compleja debemos enfocarnos explícitamente en el comprador, hacer las cosas desde su punto de vista y ponérselo fácil. Porque la “comprabilidad” no surge por azar: es fruto entre otras cosas de una concepción y diseño explícito del producto.

Como crear un producto “comprable por diseño”

Para asegurar que el producto resulta comprable son necesarios una conceptualización global y un diseño deliberado que tenga en cuenta al comprador. El diseño centrado en el usuario es importante, pero es necesario un diseño centrado además en otra persona: el comprador.

Objetivos Comprador Experiencia Usuario Características Producto

Y para hacer productos más comprables debemos proporcionar al comprador una propuesta de valor atractiva y ofrecerle (en lo que toca al producto) una excelente experiencia de compra. Pero antes tenemos que empezar por entenderlo.

Entiende a tus compradores

Captura customer insights para entender sus necesidades, objetivos y motivaciones (tanto racionales como emocionales). Modela cada tipo de comprador mediante una representación arquetípica (persona de comprador) fundamentada en evidencias de mercado, no en especulaciones de despacho. Incorpora su contexto de negocio, los resultados que quiere obtener, su previsible “viaje de comprador” y sus escenarios de compra, todo ello ligado en una historia (no sólo como datos desconectados). Dedica especial atención a la persona del “dueño del problema” pero no olvides que cada comprador es diferente y tiene su propia percepción del valor de tu producto.

Construye propuestas de valor que den a cada uno razones para comprar

En realidad un producto no tiene una única propuesta de valor sino varias, específicas de cada persona de comprador, y en general constan de dos componentes principales (definidos en relación a las alternativas disponibles en el mercado):

  • Los beneficios y resultados de toda índole que el producto aporta al comprador, diferenciados respecto a otros productos y sustentados en razones para creer.
  • A eso hay que restarle unos costes totales de adquisición y uso del producto: inversión, costes de explotación… incluyendo los riesgos que pueden impedir que el comprador obtenga los beneficios buscados. Para contrarrestar esos riesgos es aconsejable, por ejemplo, que el producto sea sencillo de usar y compatible con los usos, procesos e infraestructuras existentes.

Un diseño holístico, que parta de los objetivos de negocio, es imprescindible para definir quiénes deben usar el producto, en qué escenarios, para realizar qué tareas y qué experiencias de uso debe proporcionarles, de modo que -implementadas y orquestadas adecuadamente- en conjunto entreguen los resultados que espera el comprador.

No podemos perder de vista que las funcionalidades y experiencias de usuario deben ser el vehículo para alcanzar los resultados que busca el comprador: para ello, hay que empezar con los objetivos del comprador y seguir con las experiencias del usuario, para llegar finalmente a las features & functions del producto.

La razón para comprar no emerge de una serie de historias de usuario inconexas. Si no tenemos los objetivos del comprador como guía podríamos terminar proporcionando experiencias excelentes a usuarios innecesarios, olvidándonos de usuarios clave, o no integrando esas experiencias bajo un propósito común.

De hecho, este enfoque debe aplicarse más allá del producto “desnudo”: en el High-Tech Marketing clásico siempre se ha hablado de la necesidad de no quedarse ahí y de proporcionar al cliente soluciones o productos “completos” (que incorporan productos complementarios y servicios auxiliares para suministrar una experiencia óptima) y que satisfagan su razón para comprar.

Optimiza sus experiencias de compra

La experiencia de compra no se limita a algo que la gente de Marketing y Ventas construye a posteriori y de manera independiente del producto: aunque tiene muchos elementos off-product (mensajes, canales de marketing, contenidos, relaciones personales…) me quiero referir ahora a los componentes on-product de la experiencia de compra.

En el producto hay muchos atributos que pueden influir para que la experiencia del comprador sea favorable a nuestra opción. Para ello, por ejemplo, el producto debe ser fácil de probar antes de comprar, la adopción del producto debe ser visible y los resultados de su uso deben ser observables, los beneficios del producto deben ser fácilmente comprensibles y comunicables…

Otras características del producto deseables en relación a la experiencia de compra se han puesto de manifiesto más recientemente, como consecuencia de unas nuevas tecnologías que hacen que nuestros mercados y clientes estén cada vez más conectados. Por ejemplo, es muy valioso incorporar al producto elementos de viralidad (Hotmail es el caso clásico) y efectos de red.

Una técnica que puede ser útil a la hora de diseñar experiencias de compra e incorporar atributos de comprabilidad al producto son las “historias de comprador” (análogas a las historias de usuario que se emplean en la especificación funcional de productos).

Alguien podría pensar que estas características no son propiamente features & functions del producto porque no son las que se aplican a resolver el problema del cliente (y éste no estaría dispuesto a pagar por ellas). Sin embargo, sí lo son desde una perspectiva de comprabilidad del producto y –si queremos vender– más nos vale hacer todo lo posible por incorporarlas.

Al final, tanto las experiencias de compra como las de uso son parte de la experiencia global del cliente con nuestro producto.

Haciendo un producto más comprable: un ejemplo

Volviendo al ejemplo del producto software para Automatización de Fuerza de Ventas -SFA- que veíamos en el pasado post, vale la pena hacer un par de reflexiones:

  • La funcionalidad y experiencia ofrecidas por el SFA a Vendedores  y otros usuarios deben ser tales que garanticen los objetivos de eficacia y eficiencia comercial que persigue el Director Comercial (comprador). Por ejemplo, si los comerciales no tienen una manera fácil y permanentemente disponible de actualizar sus actividades, no va a haber posibilidad de supervisarlas.
  • El esfuerzo comercial (collateral, demos) dedicado a comunicar y demostrar la funcionalidad disponible para los usuarios es mucho menos eficaz que el que dedicamos a conectar el producto con los objetivos de negocio que los compradores quieren alcanzar. Las exhaustivas demos funcionales son inútiles si los compradores no perciben cómo el producto les va a proporcionar sus resultados deseados. Por no mencionar que muchos Vendedores, potenciales usuarios del SFA, son contrarios a que la empresa compre el producto por causas que nada tienen que ver con los beneficios que aporte a ésta (sino con su deseo de eludir un control más exhaustivo de sus actividades).
  • El mercado de herramientas SFA fue hace unos años el primer campo de batalla de la revolución que ha supuesto el SaaS (Software as a Service), con Salesforce.com como líder. Por supuesto que el SaaS ha significado antes que nada un cambio en el modelo de negocio del software. Pero no podemos olvidar que su éxito ha venido dado, en gran medida, por haber propuesto un producto mucho más comprable: una propuesta de valor atractiva (sencillez, modelo freemium, pago por uso), menores riesgos (posibilidad de probar antes de comprar, sin contratos a largo plazo ni inversiones iniciales), un proceso de compra más sencillo (se limita el papel del departamento de Informática), etc.

Como conclusión, además de que los productos sean útiles, usables, deseables… también deben ser comprables en el sentido de que deben concebirse y diseñarse explícitamente para proporcionar una poderosa razón para comprar y contribuir a una gran experiencia de compra.

Deleitar a los usuarios es importante, pero dar una razón para que los que tienen el dinero compren lo es más. Del mismo modo que en otros ámbitos se aplica la idea de diseñar productos para su “fabricabilidad”, debemos empezar a diseñarlos para su “comprabilidad”.

El post “Haz que tu producto sea comprable” 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

¡Es el comprador, estúpido!

por en 7 septiembre 2013

“Enfócate en la experiencia del usuario” parece ser el nuevo mantra. Y es una gran idea… excepto cuando el usuario no es el comprador del producto. Porque si no vendemos en primer lugar, no habrá ocasión para que el usuario se beneficie de esa gran experiencia.

Últimamente hablamos mucho de que nuestros productos tienen que ser usables y deseables…Personalmente soy un convencido y no dejo de encomiar la importancia del diseño de experiencias de usuario. Pero eso significa que a veces nos centramos en el usuario y nos olvidamos del comprador. En este post vamos a hacer un pequeño alegato sobre la importancia del comprador y a favor de que los productos sean, además, comprables.

En muchos productos, comprador y usuario son la misma persona, de modo que centrarse en los problemas y objetivos del usuario, su escenario y sus tareas, y proporcionarle una gran experiencia de uso es la clave para la decisión de compra. Por eso en mercados B2C son tan importantes aspectos como la deseabilidad y la usabilidad del producto.

Por el contrario, en mercados tecnológicos o para el cliente empresarial muchos productos son de compra compleja: diversas personas participan en el proceso de compra, en diversos roles y con diferentes niveles de involucración e influencia. Y esas personas que participan en el proceso de compra no son en general los mismos que van a terminar usando el producto (aunque en algunos casos esos compradores sean también usuarios). Si recordáis la famosa frase “la gente no quiere un taladro de un centímetro, quiere agujeros de un centímetro”, esta diferencia es más importante aún en productos de compra compleja porque la persona que necesita el agujero y la que va a usar el taladro no son la misma.

Si aspiramos a tener éxito en un mercado B2B es importante identificar un problema de negocio grave, a ser posible con un “dueño” claro, y enfocar ahí nuestro producto. Ese dueño del problema siempre va a tener un rol clave en el proceso de compra, sea como decisor final, como evaluador de negocio, etc. Y aunque en muchas categorías de producto sea típico incorporar a los usuarios finales en la compra, habitualmente se trata de un rol de validación o de una involucración “de oficio”. Quienes deciden (y firman los cheques) son los responsables de negocio que tienen un problema por resolver, y una vez tomada la decisión a un nivel ejecutivo o gerencial a los usuarios no les queda sino acatarla y empezar a usar el producto.

Importante: por supuesto que en un proceso de compra compleja puede haber otros implicados (influenciadores, prescriptores, inversores…) pero en aras de la claridad vamos a restringirnos a los dos grandes grupos mencionados.

Compradores y usuarios: un ejemplo

Por ejemplo, consideremos el caso de un producto de Automatización de Fuerza de Ventas (SFA), un tipo de software corporativo que suele formar parte de las soluciones CRM y que muchos de vosotros conoceréis como usuarios y compradores (si es que no también como vendedores, como es mi caso).

Usuarios y Compradores

La iniciativa para proveerse de un sistema corporativo de SFA suele partir del Director Comercial (o del CEO) de la empresa y tiene por objetivo conseguir una mayor eficacia y control en el equipo comercial con el fin de vender más y mejor. En el proceso de compra suele haber además otros participantes, como por ejemplo el Director de Sistemas (en un papel de validador técnico principalmente) o algún Gerente/Jefe de Equipo de Ventas (como evaluador de negocio). De todos ellos, probablemente sólo este último perfil sería un usuario intensivo del producto y lo utilizaría para una gestión más proactiva de su equipo y su negocio y para elaborar informes periódicos y previsiones de venta.

En cuanto a los usuarios, los principales serían los propios Vendedores y el personal de apoyo administrativo a Ventas. Los vendedores utilizarán el producto para registrar sus contactos y oportunidades, programar y coordinar sus actividades, reflejar el progreso, estimar volumen, plazo y probabilidad de las operaciones, etc. Posiblemente durante la fase de evaluación de productos se involucrará a algunos vendedores para validar la funcionalidad y usabilidad del producto. En este ejemplo se da la circunstancia de que el grupo mayoritario de usuarios (vendedores) en general es reacio a la adopción de productos SFA en la empresa, por la amenaza implícita que para ellos supone una mayor visibilidad de sus actividades y una rendición de cuentas más detallada.

Si un fabricante de SFA proporciona una experiencia de uso extraordinaria a vendedores y gerentes pero no es capaz de convertir todo eso en una mayor eficacia y eficiencia en la actividad comercial, un reporting más fácil y unas previsiones de venta más fiables para los ejecutivos de la empresa cliente, es difícil que tenga éxito en el mercado. Y eso es porque los que tienen la decisión y el dinero no van a ver claro qué resultados les permitiría alcanzar el producto.

Por supuesto que la división compradores/usuarios depende del tipo de producto (y del cliente particular) e identificar el proceso particular de compra en cada caso es trabajo del equipo comercial. Por ejemplo, en la compra de otro tipo de producto (digamos, una herramienta de desarrollo de software) el Director de Sistemas podría desempeñar un papel de decisor principal o evaluador de negocio.

¿Satisfacer a compradores o a usuarios?

Entonces ¿debemos anteponer la satisfacción de los compradores a la de los usuarios? En realidad ésta es una falsa dicotomía porque ambas están conectadas.

Por supuesto que resolver las necesidades y realizar las tareas de los usuarios es vital en sí mismo, pero además porque -si el producto está bien diseñado- en conjunto todo eso contribuirá también a alcanzar los objetivos de los responsables de negocio. En cierto modo, la funcionalidad y la experiencia del usuario es un fin en sí mismo y también un medio para que los compradores de negocio alcancen sus objetivos. Y esto último es el principal argumento de venta.

Tenemos que diseñar productos que conjuguen las tareas a realizar y la experiencia a proporcionar a los usuarios con los objetivos a alcanzar y los resultados a conseguir por los compradores, y que utilicen las primeras como un vehículo para alcanzar los segundos.

Durante el proceso de compra tenemos que ayudar a los compradores a entender cómo el producto va a crear esa conexión entre experiencias de uso y resultados de negocio. Porque, seamos claros: por definición, si los que tienen el poder y el dinero en la empresa cliente no están convencidos no nos van a comprar.

Eso implica que no podemos dejar la creación de una experiencia de compra excelente como responsabilidad únicamente de la función de marketing y ventas, como si esta experiencia fuera algo que se puede añadir a posteriori, con independencia del producto. Aunque la experiencia de compra tiene muchos componentes off-product, también son muchos sus elementos on-product, como veremos en el próximo post.

Eso en lo que se refiere al proceso antes de la compra. Con posterioridad a él, es evidente que una buena experiencia de usuario -que optimice la realización de sus tareas y la consecución de los objetivos de negocio- es vital también para la satisfacción a largo plazo del cliente (y las consiguientes renovaciones, ampliaciones y ventas adicionales del producto).

En el próximo post hablaremos de cómo diseñar productos que sean comprables, lo que implica proporcionar a los compradores tanto una buena razón para comprar como una excelente experiencia de compra.

Hasta entonces, trata de hacer este pequeño ejercicio: piensa en un producto que conozcas (si es uno que estás intentando vender, mejor) y piensa en quiénes son sus compradores y sus usuarios principales y en el protagonismo de cada uno antes y después de la compra.

El post “¡Es el comprador, estúpido!” 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