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

Entradas de la categoría ‘desarrollo de producto’

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

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

Deja un comentario

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

8 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

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

10 comentarios

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 proporcionarle (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 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 son contrarios a que la empresa compre el producto por causas que nada tienen que ver con los beneficios que aporte a ésta.)
  • 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

“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
Seguir

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

Únete a otros 480 seguidores

%d personas les gusta esto: