Para qué sirve el Product Discovery
El Descubrimiento del Producto, también conocido como Product Discovery, tiene como objetivo principal determinar qué es lo que se necesita construir. En pocas palabras, valida que todos estemos de acuerdo con el escenario futuro que queremos alcanzar con el producto. Además, establece objetivos claros, crea una imagen más nítida de los problemas reales y las necesidades de los usuarios, y responde a las preguntas clave a la hora de crear un roadmap de producto.
De la misma manera que la agilidad revolucionó los procesos lineales y secuenciales de construcción de productos, el Product Discovery llegó para desafiar la idea de que podemos presuponer lo que nuestros usuarios necesitan. Este enfoque se hace imperativo debido a la necesidad inminente de incorporar el aprendizaje y el feedback de los usuarios para enriquecer los planes y las definiciones de producto.
Además, esta poderosa herramienta te permite construir productos que no solo son buenos, sino vitales para los usuarios. Un producto vital es aquel que satisface una necesidad tan profunda y prioritaria en las personas que se vuelven incapaces de vivir sin él. Se te ocurre algún ejemplo?
¿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íes de tus decisiones de diseño de producto, más cerca estarás de obtener los beneficios del Product Discovery. Imagínalo de esta manera: crear un producto de estas características es como conducir hacia un destino nunca antes visitado en un día de niebla. El conductor se enfrenta a dos opciones: confiar en su intuición (creer en sus supuestos) o seguir el GPS (realizar el 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.
Certified Scrum Product Owner (CSPO)
Lo esencial al hacer Product Discovery de forma ágil
Utiliza este mindset de trabajo:
- 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.
¿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.
Consideración importante para el equipo
Si deciden realizar Discovery, deberán 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.
Para seguir leyendo:
Retos que enfrenta el Product Owner más allá del Product Backlog
El trabajo del Product Owner en el desarrollo ágil
Dual-Track Agile en el desarrollo de productos