¿Cómo y cuándo hacer Product Discovery de forma ágil?
Veamos qué significa hacer Product Discovery o Descubrimiento de Producto y cómo lo podemos aprovechar en contextos complejos de la mano de la agilidad
Para qué sirve el Product Discovery
El Descubrimiento del Producto (Product Discovery) tiene el objetivo de determinar qué es lo que se necesita construir. En resumen podríamos decir que valida que estamos todos de acuerdo con el escenario futuro que queremos alcanzar con el producto, establece objetivos, crea una imagen más clara de los problemas reales y necesidades de los usuarios y responde las preguntas claves a la hora de crear un roadmap de producto.
Así como la agilidad vino a interpelar los procesos lineales y secuenciales de construcción de productos debido a la inminente necesidad de incorporar el aprendizaje y el feedback de los usuarios para nutrir los planes y las definiciones de producto, el Product Discovery vino a cuestionar la noción de que podemos presuponer lo que nuestros clientes necesitan.
Además, esta potente herramienta te ayuda a construir productos que se vuelven vitales para los usuarios, no solo buenos productos. Un producto vital es aquel que resuelve una necesidad tan profunda y prioritaria de las personas que se ven imposibilitadas de vivir sin él. Toma por ejemplo Google. Hoy es tan vital que te sería muy costoso re-acostumbrarte a navegar en internet y encontrar la información que necesitas sin su existencia.
¿Qué se necesita para hacer Product Discovery?
Lo primero que necesitas es convencerte que todas las decisiones de diseño de un producto parten de un supuesto que tiene grandes chances de ser erróneo.
Por ejemplo, hace un tiempo un cliente nos expresó algo así acerca de un producto de su empresa: "Lo que nos lleva a ese problema serio de performance es que debemos validar la existencia de unidades disponibles en la zona antes de poder confirmar la visita técnica a su domicilio, porque de lo contrario sería un problema enorme para nuestro cliente". La siguiente pregunta fue: "¿Eso de que "sería un problema enorme" es un supuesto o una hipótesis validada?". Su respuesta fue que era un supuesto, tomando consciencia de inmediato de cuán arraigados están los supuestos en las decisiones de diseño de los productos.
Paradójicamente, cuanto más desconfías de tus decisiones de diseño de producto es cuando más cerca estás de obtener los beneficios del Product Discovery. Velo de esta forma, construir un producto de estas características es como conducir a un lugar nunca antes visitado, en un día de niebla. El conductor tiene dos opciones: confiar en su intuición (creer en sus supuestos) o seguir el GPS (hacer Product Discovery).
¿El Discovery de Productos puede no ser ágil?
Sí, claro. Las técnicas de descubrimiento de producto y la agilidad tiene algunas cuestiones en común, pero no todo. Aunque se fundamentan en una misma creencia: no podemos conocer anticipadamente lo que debemos construir.
En entornos complejos no podemos conocer anticipadamente lo que debemos construir.
Product Discovery viene a interpelar la noción de que podemos conocer los problemas de nuestros usuarios y tomar decisiones de diseño de producto sin validarlas con ellos, y la agilidad viene a interpelar la creencia de que podemos conocer anticipadamente no sólo el producto que debemos construir sino también el plan detallado para edificarlo.
Pero, sí, podrías hacer Product Discovery sin ser ágil. ¿Cómo? Asumiendo que se realiza es una fase inicial de validación de producto previo a la construcción del Product backlog, seguido de una serie de iteraciones de Product Delivery con agilidad.
- Comunicación del progreso a los Stakeholders para calmar ansiedades y despertar su involucramiento.
- Diferenciar Product Discovery de Product Delivery y comprender el valor de cada uno.
- Segmentar tu universo de consumidores o usuarios para empatizar e identificar necesidades profundas de cada uno.
- Conocer los criterios para ordenar el Product Backlog según la estrategia y fase del ciclo de vida en la que se encuentra.
Los pasos para hacer Product Discovery de forma ágil
En este caso, debes hacer lo siguiente en este orden:
- Incorporar la creencia de que los insights del product discovery no son una constante escrita en piedra y pueden cambiar, por lo tanto,
- Mitigar el riesgo con Product Discovery y amalgamar su estructura al Product Delivery.
OJO, no nos referimos a que sean dos tracks en paralelo (dual-track) sino uno solo con discovery y delivery conjugados en un mismo equipo de producto.
Dependiendo del framework que utilices, ese amalgamiento será diferente. Por ejemplo, en Scrum o Large Scale Scrum (LeSS), el Product Discovery pasa a ser una actividad que se realiza durante el refinamiento del Product Backlog. ¿Cuáles son los requisitos en el diseño del equipo que se requieren para que esto funcione? Algunos de ellos son: incrementar el tiempo de refinamiento ya que Scrum recomienda no más del 10% del tiempo del Sprint, y tener personas que pasan la mayor parte del tiempo en Product Discovery (refinamiento de Product Backlog) y otras que pasan la mayor parte del tiempo en delivery (construyendo el incremento de producto), poniendo especial cuidado en que ambos tipos de perfiles pasen parte de su tiempo en la actividad complementaria para que no se generen silos ni sub-equipos.
¿Significa que todo PBI que pasa por el refinamiento tiene que pasar por el proceso de Product Discovery?
No, definitivamente no. No siempre los beneficios que te brinda el Product Discovery valen el esfuerzo que requiere. Por eso, vamos a ponerlo en perspectiva.
Product Discovery está destinado a mitigar cuatro tipos de riesgos:
- Viabilidad de Negocio: ¿La solución propuesta por este PBI funciona para nuestro negocio?
- Factibilidad Técnica: ¿Es factible la construcción de este PBI desde el punto de vista técnico?
- Usabilidad: ¿El usuario sabrá cómo utilizar la funcionalidad propuesta por este PBI?
- Valor: ¿El usuario escogerá hacer uso de la funcionalidad propuesta por este PBI o buscará una alternativa?
Cualquier PBI que no conlleve ninguno de estos riesgos evaluando la probabilidad de ocurrencia y el nivel de impacto, no sería necesario que pase por el proceso de Product Discovery, aunque sí por el refinamiento para luego ir directo a Product Delivery.
En resumen
Destacando los 4 puntos esenciales: hacer Discovery de Producto no es garantía de agilidad. Para obtener el mayor valor de esta práctica, intégrala al proceso de delivery, teniendo especial cuidado de no hacer dual-track ni crear silos o sub-equipos. El Product Discovery se lleva adelante como parte del refinamiento del Product Backlog (en Scrum). No todos los PBIs (o unidades de trabajo) pasan por product discovery.