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

Posts from the ‘estrategia de producto’ category

Una gestión ágil de producto no debe significar que no tengamos un plan. Debemos aplicar un plan que sea flexible para acomodar cambios en las asunciones subyacentes y mantenga un equilibrio entre el largo y el corto plazo. Eso se consigue con el enfoque conocido como Cebolla de la Planificación.

Agile y planificación de producto no son incompatibles. La planificación multicapa o “Cebolla de la Planificación” (por motivos obvios, ver figura)  ayuda a los equipos de producto a elegir el nivel adecuado de detalle dependiendo del alcance temporal en el que están planificando. Estos niveles son:

  • Visión
  • Roadmap
  • Release
  • Iteración
  • Diario

Cebolla de planificación

Visión

En lo más alto del modelo tenemos el nivel de la Visión. Como sabemos, la visión define el futuro del producto a largo plazo (que según el producto de que se trate puede ser un período típicamente de entre uno y varios años): qué problemas va a resolver y para quién los va a resolver. La visión debe expresar y ayudarnos a entender el valor que nuestro producto aporta a los clientes y cómo podría diferenciarse de otras soluciones que intentan resolver los mismos problemas.

Una forma de conseguirlo es elaborar de forma colaborativa con los implicados en la organización un lienzo de visión de producto o un artefacto similar que podamos contrastar con el mercado.

Aunque la visión debe tener una vocación de estabilidad y de referencia a largo plazo esto no quiere decir que no tenga que revisarse periódicamente (sobre todo en mercados muy dinámicos) digamos en plazos de 6 meses a un año, para adaptarla a las nuevas condiciones de clientes, competidores, tecnologías, entorno, etc.

Roadmap

El roadmap es uno de los artefactos principales de la estrategia de producto y define cómo se van a alcanzar los objetivos plasmados en la visión a lo largo del tiempo (próximos meses-años). El roadmap despliega y expande la visión en una sucesión de versiones de producto (o, como veremos a continuación, de backlogs de release).

Especialmente el roadmap interno (dirigido a departamentos y stakeholders de nuestra empresa) suele ser muy detallado -incluyendo calendarios, proyectos, tecnologías- y constituye una potente herramienta de planificación y desarrollo. El roadmap no habla (sólo) de features, sino principalmente de mercados, aplicaciones, personas, problemas, escenarios, valor, capacidades y diferenciadores clave y objetivos de negocio.

Por el contrario, el roadmap externo va dirigido al mercado, es menos detallado y constituye esencialmente una herramienta de comunicación y marketing. En cualquier caso, tanto los roadmaps internos como los externos transmiten una información de prioridades y de disponibilidad.

El roadmap debe centrarse en temas

Desde el punto de vista de planificación de producto, es útil que cada release gire alrededor de un tema que define un objetivo de negocio, una persona o un problema de cliente.

¿Y por qué es importante? Porque sólo enfocándonos en un tema vamos a poder resolverlo al 100%. De lo contrario nuestro producto siempre va a quedarse resolviendo el 40% del problema de mucha gente pero no va a ser excelente para nadie. Y, como sabemos, la gente no tiene “medios problemas”, sino problemas enteros

Las técnicas de integración y despliegue continuos típicas de los productos digitales nos permiten ir liberando un flujo continuo de funciones y características. Pero que algo se “pueda hacer” no quiere decir que sea lo mejor que “debamos hacer”. Enfocar una release en todas las funciones y características que satisfacen un objetivo de negocio, una persona o un problema de cliente tienen ventajas no sólo a la hora de implementar una solución más integrada y consistente, sino a la hora de comunicarla y venderla. Empaquetando nuestras entregas alrededor de temas estamos insuflando a nuestro producto una vocación de propósito y foco muy valiosa.

El roadmap no debe ser muy detallado en la descripción de cada release (especialmente las más alejadas en el tiempo del momento actual) y específicamente en cuanto a la UX, funciones y características que cada una debe poseer. Todo eso se irá concretando -incluyendo las necesarias actividades de descubrimiento y validación de producto– cuando se vaya acercando el momento de entregar cada una de ellas. Lo que sí es importante es que explicite cualquier precedencia y dependencia entre funciones y características del producto en sus diferentes releases.

El roadmap debe revisarse y actualizarse con mayor frecuencia que la misión (y obviamente, siempre cuando ésta ha sido modificada). Períodos entre dos y seis meses (incluso menores) son habituales.

Release

En este nivel el objetivo es especificar las funciones y características que poseerá cada release definida en el roadmap. El backlog de release es un artefacto táctico que lista los trabajos necesarios para cumplir el plan estratégico de producto y su audiencia la constituyen principalmente los equipos de proyecto y desarrollo.

Al contrario que en el roadmap, que no debería entrar en excesivo detalle sobre funciones y características, el backlog de release se compone de épicas e historias de usuario, diagramas de flujo, bocetos de diseño y mockups de experiencia de usuario.

En general, el backlog de release se deriva del roadmap. Pero la influencia contraria también es posible: el feedback sobre la release que recibimos de los clientes puede servir para reajustar el roadmap. En conclusión, roadmap y backlog deben estar sincronizados.

El backlog de release se debe actualizar con cada actualización del roadmap y con cada liberación de release.

El problema con el ”backlog de producto”

A veces se usa un artefacto que está a caballo entre el roadmap y el backlog de release, llamado “backlog de producto”, y que puede recoger un backlog que abarca varias releases. Este concepto está heredado del mundo de los proyectos de desarrollo a medida, donde no existe una estrategia de producto con diferentes releases. A mi modo de ver éste es un artefacto confuso porque mezcla el enfoque multirelease del roadmap con la concreción del backlog y hace que la idea de propósito de cada release de producto se diluya y se pierda en una mezcla sin orden ni concierto de funciones y características. En muchas ocasiones, ese backlog de producto no es más que un aluvión de desarrollos, impuestos por diversos stakeholders, pero sin una integridad y consistencia. Personalmente prefiero enfocar el backlog de producto en la próxima release. Esto crea un backlog conciso, con un propósito y un significado claros, y más fácil de gestionar.

De modo que si lo más cercano a la planificación que tienes es un backlog de producto siento decirte que no tienes un roadmap (y probablemente, tampoco una estrategia de producto).

Iteración/Sprint

En una filosofía de desarrollo ágil, en el nivel de iteración el equipo selecciona los elementos individuales del backlog que comprende el siguiente ciclo y crean un plan para entregar cada historia.

Si la metodología que se sigue es  en concreto Scrum (donde las iteraciones se conocen como sprints) probablemente se reconozca este nivel como la sesión de planificación del sprint. En cualquier caso, incluso los equipos que no aplican una metodología Scrum tienden a realizar una forma de planificación de nivel de iteración al seleccionar y planificar sus próximos trabajos en pequeños lotes.

La planificación de iteración se realiza al principio de cada ciclo, en períodos típicamente de entre dos y seis semanas.

Diario

En este nivel de planificación el equipo evalúa el status al principio del día actual y colabora para elaborar un plan para avanzar hasta el siguiente día.

Muchos equipos consiguen esto mediante un “standup” diario, una reunión en la que discuten:

  • El progreso conseguido en el día anterior
  • El progreso que esperan conseguir en el día actual
  • Los obstáculos que pueden impedir dicho progreso y qué se puede hacer para contrarrestarlos.

Si bien este ritual matutino comienza con lo que se ha conseguido en el día anterior, los equipos más eficaces reconocen que el standup es una reunión de planificación, no de status. Por lo tanto, debería centrarse en crear un plan para avanzar al nivel diario.


En conjunto, estos niveles de planificación proporcionan el compromiso entre flexibilidad y detalle necesario para gestionar productos en este mundo Agile.

El post “Niveles de planificación de producto en Agile” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Product Management de productos tecnológicos y Product Marketing de productos tecnológicos te pueden ayudar.]

Deja un comentario

La construcción ágil de productos necesita un “cerebro” que le dé una dirección y un propósito. La planificación de producto puede contribuir a ello, pero en escenarios ágiles la planificación tradicional (fija, predictiva) no sirve. Es necesaria una planificación más ágil, que incorpore componentes de flexibilidad, aprendizaje y adaptación.

“Nosotros somos ágiles. No planificamos.” ¿Os suena esta excusa? Vamos a hablar de algunas consecuencias indeseables de esta absurda interpretación en el campo de la planificación de producto y de cómo evitarlas.

Importante: en este post nos vamos a referir al uso de Agile en el desarrollo de productos para un mercado, no proyectos de desarrollo a medida de un cliente (donde se suele denominar “producto” al resultado del proyecto).

Agile necesita un cerebro

En muchos equipos Agile hay una gran frustración. Tienen la sensación de que lo único que hacen es entregar funciones y características a toda velocidad y sin orden ni concierto, sin que los responsables de producto tengan claro hacia dónde van o qué quieren conseguir realmente. Unas características que al final no añaden valor al cliente. Estos equipos han desplegado un “Agile sin cerebro”.

Agile necesita cerebroAgile proporciona un método optimizado e iterativo de implementar, pero seguimos alimentándolo con productos que están destinados al fracaso porque no han pasado por las fases críticas de eliminación de riesgos del proceso: comprobar la deseabilidad de los clientes y la viabilidad del negocio. Como dicen los americanos, hay una diferencia entre “build the features right” y “build the right features”.

Agile es una manera de construir, pero no nos va a servir para averiguar qué construir y cómo capturar valor de nuestras iniciativas de innovación. Nos da velocidad y cumplimiento pero si lo que le suministramos son malas ideas vamos a conseguir peores resultados… con la máxima velocidad y eficacia.  Por poner una analogía, si queremos cocinar un pato laqueado estilo Pekín, más vale que utilicemos  una buena receta con sus ingredientes y proceso en lugar de algo como «cada diez minutos abre la cazuela y pruébalo. Si está soso, añade sal. Si no sabe a nada, añade más comida».

Uno de los problemas de Agile es que -si no se refuerzan los mecanismos que animan a los equipos a considerar si las características que están incluyendo son las más adecuadas- esos comportamientos perversos van a proliferar. Por eso en Agile es importante, al igual que en el personaje del Espantapájaros del Mago de Oz, darle un cerebro.

Un cerebro para Agile

¿Y cómo podemos darle un cerebro a Agile? Hay varias herramientas para este objetivo:

  • Feedback de los clientes: tenemos que priorizarlo y operacionalizarlo, de modo que no sea un trámite. La esencia de Agile no es entregar lo más rápidamente posible desarrollos sin errores, sino aportar valor al cliente. Las revisiones del sprint no deben servir sólo para comprobar si se han implementado los elementos del backlog comprometidos, sino si estos son valiosos. No cambiemos velocidad por resultados.
  • Diseño de producto (y de modelo de negocio): Agile nos puede hacer olvidar que la experiencia del usuario debe tener sentido para ese usuario en cada release. Si renunciamos a descubrir y validar con antelación lo que se va a implementar podemos acabar con un producto fiable y bien construido pero que carezca de un significado, un valor y una interacción coherente. Es necesario combinar Agile con un diseño holístico y deliberado, enfocado en conseguir la mejor experiencia de cliente.
  • Planificación: Agile no es contrario a la planificación. Agile necesita planificación, pero de otro tipo. A este punto dedicaremos éste y el siguiente post.

Agile y planificación

La estrategia de producto ha podido ser una “baja colateral” en la transición a métodos ágiles. Muchos responsables de Agile se apegan a la noción errónea de que la idea de esta filosofía es mantenerse flexibles y que no hay que preocuparse o atarse a una dirección a largo plazo.

Siguiendo esta “no planificación” y respondiendo a las demandas instantáneas de cualquier stakeholder se pueden crear productos momentáneamente valiosos para alguien. Y se puede seguir así durante cierto tiempo, hasta que nos damos cuenta de que en realidad hemos ido “como pollos sin cabeza” y que alrededor del producto ha crecido toda una organización y esta falta de planificación ha provocado impactos que se extienden a varios grupos.

Los equipos ágiles necesitan un enfoque disciplinado para la planificación. Las organizaciones que invierten en una planificación adecuada tienen una mejor comprensión de los objetivos a largo plazo para el producto, y estrategias más realistas para alcanzar esos objetivos. Pero en escenarios cambiantes eso no se consigue con una planificación “tradicional”.

El problema con la planificación tradicional

Para entender mejor las ventajas de la planificación ágil, recordemos cómo funciona la planificación tradicional. Ésta sigue una serie de ciclos fijos y es esencialmente predictiva. Por ejemplo, en una sesión de planificación a principios de año se pueden fijar los objetivos para ese año, una estrategia y un plan detallado para alcanzarlos. Y, habitualmente, este plan tiene el mismo nivel de detalle para todos los períodos del año.

Pero -a pesar de las mejores intenciones y la confianza en esos planes- tarde o temprano la realidad golpea. Circunstancias imprevistas tales como las demandas de los clientes, los movimientos competitivos o desarrollos en el mercado global van a hacer que algunas partes de esos planes sean inalcanzables o incluso irrelevantes.

Pero, en lugar de intentar reconciliar el plan con esa nueva realidad, el equipo redobla sus esfuerzos para alcanzar sus aspiraciones anteriores. Finalmente esto da como resultado que el equipo tiene permanentes dificultades para alcanzar las expectativas de un plan inalcanzable y la organización está permanentemente decepcionada con su incapacidad para conseguirlo. En muchos casos, ésta es la realidad de la planificación tradicional.

¿Qué es la planificación ágil?

Una de las características de los enfoques de planificación ágil es que el equipo puede planificar con diferentes niveles de detalle dependiendo del alcance temporal para el cual están planificando. Por ejemplo, puede planificar sus objetivos para el año a alto nivel, su estrategia para alcanzar esos objetivos durante los próximos meses con un poco más de detalle y los pasos necesarios para implementar esa estrategia durante las próximas semanas con el máximo detalle. Este enfoque evita la necesidad de predecir en detalle el futuro lejano (con los riesgos que apareja) y proporciona al equipo claridad en cuanto a sus responsabilidades en el corto plazo, a la vez que les ayuda a entender cómo esa responsabilidad contribuye a los objetivos a largo plazo.

Pero la principal característica de los planes ágiles es que a medida que avanzamos en el tiempo, es posible que el equipo adapte y reelabore sus planes basándose en lo que ha ido aprendiendo durante el período. Los planes ágiles no son sólo planes para ejecutar sino también planes para aprender. Por tanto, Agile no significa que no tengamos un plan. Significa que tenemos un plan que es suficientemente flexible como para acomodar cambios valiosos e importantes en las asunciones subyacentes a dicho plan.

En lugar de operar al nivel de funcionalidad o característica, la planificación ágil necesita funcionar al nivel de visión o temática: establecer objetivos basados en áreas de mercado, necesidades de clientes o temas funcionales, y no en entregables funcionales o características definidos específicamente. Esto proporciona al negocio una base para saber hacia dónde ir pero mantiene la flexibilidad para cambiar el plan, bien en cuanto al entregable específico dentro del tema o bien cambiando el propio objetivo temático.

¿Y cómo alcanzamos ese equilibrio entre planificación a corto y largo plazo? Muchos equipos ágiles utilizan un enfoque de planificación multicapa, también conocido como la “Cebolla de la Planificación”, y que describiremos en el siguiente post.

El post “Planificación de producto y Agile: ¿son incompatibles?” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Product Management de productos tecnológicos y Product Marketing de productos tecnológicos te pueden ayudar.]

Deja un comentario

La estrategia de producto no sólo debe considerar los aspectos de funcionalidad y características de cada producto individual, sino su evolución desde un producto mínimo hasta una solución completa que pueda conquistar el mercado y la gestión estratégica de una cartera de productos propios y un ecosistema de productos externos que ayude a alcanzar los objetivos de la empresa.

Seguimos definiendo los componentes de una estrategia de producto, en este post centrándonos en los aspectos más relacionados con el propio producto.

Conceptualiza tu producto

Obviamente el componente principal de una estrategia de producto va a ser el propio producto, y éste se definirá teniendo en cuenta los diferentes segmentos y problemas de clientes que hemos identificado anteriormente. En muchos casos estas diferencias entre segmentos nos llevarán a definir diferentes productos o diversas versiones o releases de un producto que formarán parte de una estrategia de desarrollo y del roadmap.

Estrategia de productoIgual que los componentes relacionados con el mercado, esta parte está a caballo entre la estrategia de producto y de marketing. A efectos de definición de estrategias el producto se caracteriza por:

Propuesta de valor

La concepción del producto debe estar dirigida por su foco en la creación de valor para sus clientes. La propuesta de valor es la promesa diferencial a nuestros clientes que nos va a guiar en el desarrollo de producto. Es una expresión clara y global de por qué un cliente debería hacer negocios con nosotros y de cómo su vida mejoraría después de comprar nuestro producto, hecha desde una perspectiva del cliente. La propuesta de valor recoge elementos como el concepto de producto o los resultados que éste aporta y sirve de base para el posicionamiento durante la fase de comercialización. Y debe explicitarse no sólo para los usuarios del producto sino, como veremos, también para sus compradores (cuando estos no coinciden).

Precio

Sin duda el precio es uno de los componentes más importantes de nuestra oferta, y no sólo porque define las corrientes de ingresos de nuestro negocio. Un precio adecuado puede ayudarnos a penetrar en el mercado (o a “descremarlo”, según otra estrategia) y transmite señales sobre el valor del propio producto que los clientes pueden utilizar como heurístico para tomar sus decisiones de compra. En productos digitales, por ejemplo, el uso de modelos freemium se ha adoptado cada vez más como eficaz táctica de pricing y marketing.

Pero a un nivel estratégico el producto es más que una propuesta de valor y un precio. A mi modo de ver existen otros factores que, considerados desde el principio, contribuyen enormemente al éxito del producto en el mercado. A ellos dedicamos los siguientes apartados.

Diferenciación

Un aspecto primordial en la estrategia de nuestro producto es la cómo se diferencia de sus rivales: productos competidores, sustitutivos y alternativos. Y un error frecuente consiste en asumir que esta diferenciación proviene exclusivamente de sus funcionalidades y características, cuando en realidad lo hace del valor que aporta en todas sus dimensiones. En productos también “menos es más” y un exceso de funciones puede producir una disminución de valor en términos de dificultad de uso, complejidad o incompatibilidad.

En este campo, una estrategia más radical consiste en buscar maneras de diferenciarse de la categoría de productos en su conjunto en lugar de respecto a competidores específicos dentro de la categoría, dando lugar a propuestas de valor y posicionamientos disruptivos.

Adoptabilidad

Otro aspecto clave en nuestra estrategia de producto (especialmente si éste es innovador) es conseguir que nuestro producto se difunda y sea adoptado por el mercado. Es importante hacer que nuestro producto sea “adoptable por diseño” para los diferentes segmentos, maximizando sus beneficios y minimizando las “pérdidas” o costes de toda índole que ocasiona. Para ello hay que trabajar aspectos como su ventaja relativa, su compatibilidad, sus complejidad, la posibilidad de probarlo y la posibilidad de observar su uso y beneficios.

Comprabilidad

En productos de compra compleja los que compran el producto y los que lo usan no son las mismas personas. Por eso es importante tener también en cuenta a los compradores en el diseño del producto, para asegurarnos de que éste les ayuda a alcanzar sus objetivos de negocio y resultados deseados y resulta fácil de comprar. Hacer que el producto sea “comprable por diseño” implica proporcionar propuestas de valor y experiencias de compra optimizadas para sus compradores.

Crecimiento incorporado

Algunos productos incorporan, de forma más o menos natural, palancas para el crecimiento. Tal es el caso de los productos con efectos de red (cuyo valor para los usuarios aumenta cuanto mayor es el número de estos, p.ej., redes sociales) o la viralidad (donde el uso del producto por un usuario atrae nuevos usuarios, p.ej., herramientas de colaboración). Es útil fomentar estos drivers desde la propia conceptualización y diseño del producto para incorporar en éste un motor interno de crecimiento. El crecimiento impulsado por el producto («Product-Led Growth») es una valiosa estrategia para hacer del propio producto el principal canal de adquisición, retención y monetización de clientes.

Desarrolla y entrega tu producto

Definir una estrategia de desarrollo del producto para cada segmento (o grupo de segmentos) es también una de los componentes principales de la estrategia de producto. Esta parte de la estrategia tendrá un enorme peso en la definición del roadmap, con sus sucesivas versiones del producto. Habitualmente esta estrategia suele seguir un enfoque por pasos:

Producto mínimo o “umbral”

Desde hace unos años conocido como MVP (en una de sus acepciones). Se trata del mínimo conjunto de experiencias de usuario, funcionalides y características que se puede entregar a aquellos potenciales clientes más receptivos (earlyvangelists) para que estos lo compren, nos paguen y nos proporcionen feedback que nos ayude a mejorarlo. Se trata de una versión de “entrada” en el segmento, que se irá mejorando en las sucesivas releases.

Producto completo

El objetivo último del producto es llegar a proporcionar a la inmensa mayoría de los clientes en un segmento una razón persuasiva para comprar. Para ello el producto básico se debe complementar con una serie de funcionalidades, características y productos complementarios y auxiliares que implementan ese objetivo y proporcionan una experiencia total de cliente satisfactoria. A esto es a lo que se conoce como “producto completo” o “solución completa”, que se irá consiguiendo a través de las sucesivas releases del producto y está muy relacionado con la gestión del ecosistema (ver siguiente apartado).

Gestiona tu cartera y ecosistema de productos

En mercados tecnológicos e innovadores los productos tienden a evolucionar rápidamente y a proliferar en diversas líneas y segmentos. La estrategia de producto no debe considerar no sólo la evolución de los productos aislados sino la relación entre estos dentro de la cartera de productos y con productos externos con los que conjuntamente construyen propuestas de valor.

Cartera de productos

La gestión de la cartera implica gestionar diversos productos dentro de una línea de productos y a través de varias líneas de productos de modo que puedan servir a diversos segmentos de clientes, mercados verticales, rangos de precio, objetivos estratégicos y otros factores. Las decisiones sobre la cartera de productos incluyen expandir la cartera, podar la cartera, buscar sinergias entre productos, equilibrar la cartera (por ejemplo, en función de qué productos son generadores o consumidores de financiación) y mitigar la canibalización de ventas entre productos.

Ecosistema y productos complementarios

Para proporcionar una “solución completa” que seduzca a la mayoría de cada segmento tenemos que ensamblar un ecosistema de socios y aliados que complementen y mejoren nuestro producto básico. La solución completa irá evolucionando a medida que el producto es adoptado por el mercado y las necesidades de los clientes varían. El ensamblaje de las capacidades necesarias para proporcionar la solución completa exige tomar decisiones de “hacer, comprar o aliarse” y en general requiere crear y gestionar un ecosistema robusto de socios.

Después de la estrategia

La estrategia de producto no es un fin en sí mismo, sino un medio para alcanzar otros fines. El panorama después de la estrategia se resume esencialmente en dos palabras: iteración y roadmap.

Iteración

En el mundo actual, las nuevas tecnologías están cambiando las experiencias de clientes y de cualquier lugar surgen startups dispuestas a capturar el mercado. Y por otra parte nunca podemos estás seguros de que la estrategia que hemos formulado es la óptima. Por eso los equipos de producto deben estar dispuestos a iterar rápidamente su estrategia de producto en función de la respuesta de los clientes, el desarrollo del mercado y las dinámicas internas de la empresa. Porque si vamos adelante con una estrategia fija, esa estrategia va inevitablemente a fallar.

Roadmap

El roadmap es el primer paso en la ejecución de la estrategia, en el sentido que convierte ésta en un plan para entregar las sucesivas versiones del producto que nos irán acercando a alcanzar la visión. Pero es importante tener en cuenta algo: no convirtamos el roadmap en la entrega de una sucesión de funcionalidades y características inconexas. Mejor, organicemos cada una de estas versiones de producto alrededor de un tema que represente un problema de mercado, una persona de cliente o un objetivo de negocio. Así conseguiremos que estos temas se cubran de manera más valiosa y significativa.

Si no tenemos una estrategia de producto es fácil perder el foco en lo que importa a nuestros clientes y nuestra empresa. La estrategia de producto nos ayuda a enfocarnos en nuestros objetivos de negocio y nuestros clientes y a disponer un camino para ejecutar.

En los próximos posts veremos cómo realizar una planificación ágil de producto.

El post “Estrategia de producto (2)” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Product Management de productos tecnológicos y Product Marketing de productos tecnológicos te pueden ayudar.]

1 comentario

La estrategia de producto es algo más que un backlog de funcionalidades y características. Y debe empezar siempre por una comprensión del mercado y sus necesidades.

El término “estrategia de producto”, igual que el papel del product manager, no tiene una definición estándar y significa cosas diferentes en diferentes empresas. Especialmente en productos tecnológicos e innovadores esta falta de definición hace que muchas empresas piensen que por el mero hecho de haber acumulado un backlog de funcionalidades y características sin orden ni concierto ya tienen una estrategia de producto. Como veremos, eso es un gran error.

La estrategia de producto describe quiénes son nuestros clientes, cómo nuestro producto encaja en el mercado y cómo va a alcanzar sus objetivos de negocio. La estrategia nos ayuda a enfocarnos en lo que vaya a tener más impacto en nuestros clientes y en el negocio.

En éste y en el próximo post describiremos los elementos de una estrategia de producto y en los dos siguientes plantearemos cómo hacer una planificación ágil de producto.

¿Qué es la estrategia de producto?

Existen varias definiciones de estrategia de producto, la mayoría agrupadas en torno a una de estas tres grandes líneas:

  • Decisiones e iniciativas relacionadas con el producto que hay que tomar para alcanzar los objetivos de la empresa.
  • Camino o “viaje” que el producto tiene que seguir para alcanzar la visión de producto.
  • Aquella parte de la estrategia de negocio que cae en el ámbito del producto.

Un aspecto clave de la estrategia de producto es que ésta debe cristalizarse en un roadmap de producto: la sucesión de versiones que iremos liberando a lo largo de los siguientes meses o años para responder las necesidades de los diferentes mercados en los que compitamos. La estrategia convierte la visión en un roadmap.

Y, como siempre, la estrategia de producto no debe ser algo estático y prescriptivo: debe ser una estrategia para aprender, sujeta a las actividades de descubrimiento y validación de producto, y que vaya adaptándose al desarrollo del mercado y a la evolución de nuestra empresa.

Visión y estrategia de producto

La visión de producto, además de ser inspiradora, debe ser ambiciosa: debe representar una situación en la que aportamos “más valor a más clientes” que lo que estamos en situación de aportar hoy.

¿Qué nos distancia hoy de la visión? Puede haber varias razones, algunas de ellas interrelacionadas. En todas ellas el producto puede ser parte de la solución:

  • Los clientes no compran nuestro producto: esto puede deberse a un insuficiente ritmo de adopción o a una alta satisfacción de los clientes con los productos competitivos y soluciones alternativas actualmente disponibles.
  • El producto no entrega suficiente valor: ésta es una situación muy común en productos basados en tecnologías innovadoras e inmaduras, que tienen que ir progresando a través de su curva de mejora de prestaciones.
  • No tenemos presencia ni capacidad para llegar al mercado: aunque éste parece un problema exclusivamente de “músculo comercial”, el propio producto puede contribuir para mejorar la situación.

La estrategia de producto debe ser el elemento que nos ayude a salvar esta brecha.

Componentes de la estrategia de producto

¿En qué consiste una estrategia de producto? Muchos expertos despachan este tema con unas vagas referencias al mercado y a las funcionalidades y características que hay que aportarle, e incluso incorporan a la propia estrategia la visión de producto o los objetivos de empresa. En los siguientes apartados tratamos de dar una visión más consistente, completa y accionable.

Elementos de contexto

En este primer apartado nos vamos a centrar en lo qué NO es estrategia de producto. Son elementos que no forman propiamente parte de la estrategia de producto, tal como la hemos definido, pero que están tan relacionados con ella que parecen inseparables (de hecho muchos expertos los presentan como componentes de la estrategia):

  • Objetivos de negocio: son las metas de empresa que la estrategia de producto debe contribuir a alcanzar.
  • Análisis competitivo: situación de los productos competidores / sustitutivos / alternativos que rivalizan con nuestro producto.

Componentes directos de la estrategia

A mi modo de ver, los elementos que directamente forman parte de la estrategia de producto son:

  1. Identifica y conceptualiza a tus clientes
  2. Define cómo penetrar y desarrollar el mercado
  3. Concibe tu producto
  4. Desarrolla y entrega tu producto
  5. Gestiona tu cartera y tu ecosistema de productos

Caracteriza a tus clientes

Esta parte de la estrategia de producto es también parte de la estrategia de marketing. Consiste en entender y modelar nuestros potenciales clientes, aceptando que el mercado no es homogéneo en este aspecto y presenta una variedad que tenemos que gestionar y aprovechar. Este objetivo se consigue a través de diversos artefactos:

Segmentos

Los segmentos son porciones del mercado que comparten determinadas características. Sirven para descubrir, analizar, discriminar y evaluar el mercado de forma “macroscópica”.

Personas (arquetipos), escenarios (de uso y compra) y viajes del cliente

Estos artefactos aportan una comprensión detallada y rica de los objetivos, motivaciones, actitudes y comportamientos de los clientes a un nivel “microscópico”.

Problemas, necesidades, trabajos, requisitos

Pueden tomar diversas formas y ser de diferentes índoles (funcionales, emocionales, económicos) y expresan las razones por las cuales los clientes comprarían nuestros productos. Como hemos visto, existen muchos enfoques para entender los problemas y necesidades del mercado. Estos problemas y necesidades son la medida del mercado y la base de la definición de escenarios donde nuestro producto puede crear valor para los clientes.

Penetra y desarrolla el mercado

Igual que en el caso anterior, esta parte está a caballo entre la estrategia de producto y de marketing. Este componente incluye:

Análisis de las oportunidades de mercado

Una vez identificados los escenarios de creación de valor tenemos que evaluarlos para entender en qué oportunidades de mercado podemos capturar más valor y priorizarlos para decidir en cuáles (y cuándo) deberíamos enfocarnos.

Segmento(s) de entrada

Se trata de decidir si inicialmente optamos por una estrategia “de amplio espectro”, abordando varios segmentos a la vez, o por el contrario optamos por una estrategia enfocada, atacando un segmento “cabeza de playa” o, a lo sumo, un número muy reducido de segmentos. Ciertamente la conveniencia de abordar varios segmentos a la vez dependerá de las posibles sinergias entre ellos y de la disponibilidad de recursos y competencias suficientes.

Expansión

Una vez “conquistados” el o los segmentos iniciales será posible expandirse a mercados adicionales y esa expansión podrá ser más o menor relacionada o adyacente a nuestros primeros segmentos. La expansión a segmentos adyacentes reduce los riesgos de estas iniciativas, al limitar la distancia a los segmentos iniciales (y, por lo tanto, las necesidades de nuevos recursos y capacidades). La clásica estrategia de “pista de bolos” es un caso típico de este enfoque. La expansión no adyacente o diversificada requiere mayores recursos y, sobre todo, la capacidad de realizar innovaciones más profundas en producto y modelo de negocio.

En el próximo post seguiremos describiendo los componentes de una estrategia de producto, en particular aquéllos relacionados con los propios productos de la empresa, considerados aisladamente y como parte de una cartera y un ecosistema más amplios.

El post “Estrategia de producto (1)” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Product Management de productos tecnológicos y Product Marketing de productos tecnológicos te pueden ayudar.]

1 comentario

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

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

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

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

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

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

Teniendo en cuenta esos requisitos, trabajando con algunos clientes he encontrado que la Visión de Producto se puede expresar mediante artefactos como los siguientes:

  • Narrativa o historia que relata cómo los clientes futuros del producto se beneficiarán del él.
  • Prototipo conceptual de alto nivel y enfocado en esa visión futura: “visiontipo”.
  • Expresión o lienzo de visión: a este formato dedicamos el siguiente apartado.

Lienzo de Visión de Producto

Lienzo de Visión de Producto El formato se compone de estos elementos:

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

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

Alternativas a nuestra Visión de Producto

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

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

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

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

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

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

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

¡Espero que os sea útil!

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

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

7 comentarios

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.

Posteriormente, cuando la visión se despliega en un roadmap que explica cómo vamos a alcanzarla a través de sucesivas versiones y empezamos con la implementación de éstas, 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.

Y si quieres saber dónde encaja la visión en una planificación ágil de producto, lee este post.

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

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

4 comentarios
A %d blogueros les gusta esto: