Crecimiento de productos tecnológicos

Archive for ‘marzo, 2020’

Una empresa puede descubrir múltiples problemas de mercado por resolver. Investigar a los clientes para entender la importancia que dan a cada problema y el grado de satisfacción con las soluciones actuales nos ayuda a priorizar el desarrollo de producto.

Una de las etapas principales en el desarrollo de nuevos productos (o de nuevas características, o en la renovación de productos existentes) es la definición de dicho producto.  La definición de producto es un proceso iterativo que empieza con el descubrimiento de necesidades de los clientes, continúa con la construcción de personas de compradores y usuarios y sus “viajes” y escenarios de compra y uso, y termina con la elaboración de un conjunto de requisitos (problemas de mercado) priorizados. Como vemos, en esta fase nos mantenemos esencialmente inmersos en el espacio del problema, sin pasar todavía a la formulación y validación de una solución.

Como resultado de esas actividades previas de descubrimiento de clientes con suerte nos vamos a encontrar con un conjunto de expresiones de problema (en los términos usados por los propios clientes o transcritas a alguno de los formatos estructurados más habituales), en el mejor de los casos deduplicados y agrupados por temas en forma de mapas de afinidad o diagramas en árbol multinivel.

Y el siguiente paso es priorizar esos problemas a resolver con nuestro producto ¿Por qué es importante priorizar los problemas? Hay varias razones:

  • Porque lo más seguro es que no vayamos a tener recursos y dinero para resolverlos todos.
  • Porque aunque no fuera así, probablemente resolviéndolos todos llegaríamos a un “producto Franskenstein”, complejo y no centrado en ninguna persona en particular y que no satisface completamente a nadie, lo que lastra la satisfacción de los clientes y la adopción del producto.
  • Porque lo que nos interesa no es desarrollar y lanzar ciegamente un producto, sino continuar con un proceso de descubrimiento en el que -una vez elegidos los problemas de mercado a resolver- diseñemos una solución que habrá que validar con los clientes mediante prototipos y otros artefactos (antes de empezar a construir el producto real). Y para ello lo más útil es definir un producto “mínimo” que haga más fácil, rápido y económico ese proceso. Porque necesitamos empezar a recibir feedback del mercado cuanto antes y de la forma más barata posible.

Y es que esencialmente la estrategia (incluyendo la de producto) no consiste sólo en decidir lo que se va a hacer sino (y más importante) en decidir lo que NO se va a hacer.

Para la priorización de problemas de mercado podemos aplicar varios enfoques, que vamos a describir en éste y el siguiente post:

  • El marco Importancia-Satisfacción
  • El modelo de Kano
  • El análisis Rentabilidad-Inversión.

El marco Importancia – Satisfacción

Importancia Satisfacción

Este enfoque consiste en representar los problemas en un plano con dos ejes:

  • Importancia del problema: es una medida de cuán importante es un cierto problema, necesidad o beneficio para un cliente determinado. Por ejemplo, para una persona la necesidad de compartir fácilmente contenidos con sus amigos puede ser muy importante y menos importante la necesidad de privacidad. La importancia es un concepto específico del espacio del problema, independiente de cualquier tipo de solución.
  • Satisfacción con las soluciones actuales: es una medida de cuán satisfecho está un cliente con las soluciones actualmente disponibles para un problema determinado. Expresa en qué grado las soluciones actuales satisfacen los problemas de los clientes y nos ayuda a identificar necesidades “infraservidas” (y “sobreservidas”) con bajo nivel de satisfacción.

Es importante que tanto la importancia como la satisfacción sean evaluadas explícitamente por los clientes cuya opinión hemos recabado en nuestra investigación, y no sean “impresiones” del equipo investigador. De este modo nos aseguramos de capturar la forma en que los clientes perciben y expresan sus problemas y necesidades. Luego, la importancia y la satisfacción de cada problema se evalúan como un score calculado promediando sobre el conjunto de clientes.

Según sus scores agregados, los problemas pueden caer en uno de cuatro cuadrantes:

  • Alta Importancia, baja Satisfacción: este es un caso claro, representa la oportunidad de innovar resolviendo un problema que es importante pero que no está adecuadamente cubierto. La recomendación en este cuadrante es invertir.
  • Baja Importancia, alta Satisfación: este también es un caso claro, pero en sentido contrario. No hay mucha oportunidad en resolver un problema poco importante que además está adecuadamente cubierto con las soluciones actuales. La recomendación aquí es evitar.
  • Alta Importancia, alta Satisfacción: este es un escenario dudoso. Podemos encontrarnos ante un mercado interesante pero muy competitivo, donde resulte difícil hacerse un hueco. Sin embargo, la importancia del problema y la oportunidad de mercado pueden justificar invertir en desarrollar soluciones innovadoras.
  • Baja Importancia, baja satisfacción: finalmente, otro escenario dudoso. La baja satisfacción con las soluciones actuales puede abrir una oportunidad, pero la baja importancia del problema puede hacer que no valga la pena.

Podemos utilizar el marco Importancia – Satisfacción para obtener una medida del valor para el cliente creado por una cierta solución a un cierto problema:

Valor para el Cliente = Importancia x Satisfacción (área del rectángulo)

Análogamente, la oportunidad de creación de valor de un producto que incrementara el nivel de satisfacción de una necesidad desde un valor Satis0 hasta otro Satis1 (manteniendo constante la importancia en su valor Impor0) sería:

Oportunidad de Creación de Valor = Impor0 x (Satis1 – Satis0) (incremento de área)

El marco Importancia – Satisfacción nos permite evaluar diferentes oportunidades de creación de valor y centrarnos en las más prometedoras.

En el próximo post revisaremos otros dos enfoques para la priorización de problemas de mercado: el modelo de Kano y el análisis Rentabilidad-Inversión.

El post “Definiendo tu producto: eligiendo problemas que valga la pena resolver (1)” se publicó primero en “Marketing & Innovación”.

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

Deja un comentario

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