¿Cómo industrializar el Product Discovery?

El Product Discovery es un conjunto de actividades que consiste en identificar las necesidades de los usuarios o las oportunidades de mercado, definir hipótesis sobre la necesidad y luego sobre la solución, y finalmente probarlas, antes del desarrollo.

Proceso de Product Discovery

Para saber más descarga el libro Las Organizaciones Orientadas a Producto

Por ejemplo, en el caso de un producto de sitio de citas dedicado a los deportistas:

• Hipótesis de necesidad 1: practicar un deporte es un criterio importante en las relaciones amistosas o amorosas.
• Hipótesis de necesidad 2: las soluciones existentes en el mercado son insuficientes para este caso de uso específico.
• Hipótesis de necesidad 3: los deportistas son especialmente aficionados a las soluciones digitales.
• Hipótesis de solución 1: los deportes practicados deben destacarse en los perfiles personales de cada usuario.
• Hipótesis de solución 2: el MVP puede centrarse en el running, ya que es el deporte más comúnmente practicado.
• etc...

Por lo general, hay que comenzar definiendo un caso de uso, una idea expresada en forma de necesidad del usuario. A veces, la idea se centra directamente en una solución, en cuyo caso es importante preguntarse "por qué este Producto tiene sentido": ¿cuál es la necesidad que subyace a la solución propuesta? ¿Y está esa necesidad validada / confirmada por hechos?

Para materializar este caso de uso, y siempre con el objetivo de industrializar el enfoque de Discovery, te sugerimos crear un canvas para cumplimentarlo. Al igual que un Lean Canvas, este resumen evolucionará a lo largo de tu proceso de diseño, y será progresivamente enriquecido y modificado para llegar al resultado final. También es una herramienta de comunicación muy interesante internamente para saber en qué temas está trabajando cada uno y para tener rápidamente una visión sintética de los proyectos a medio plazo de la empresa.

Canvas asociado al caso de uso

El canvas que proponemos se compone de varias partes, pero no dudes en ajustar esta ficha según tus necesidades y las especificidades de tu Producto y tu organización.

• Público objetivo: en general, es la o las personas relacionadas con el caso de uso, o los criterios discriminantes que permiten identificar a los usuarios afectados por este caso de uso.
• Problemas encontrados: se trata de la descripción del problema del usuario. Si careces de datos, inicialmente puedes completar esta parte poniéndote en el lugar del usuario final; pero en este caso, ten en cuenta que sólo es una hipótesis, es indispensable desafiarla y completarla lo antes posible después de haber encontrado a tus verdaderos usuarios.
• Feedback de los usuarios: verbatims (cualitativos) o métricas (cuantitativas) que justifican y prueban el problema del usuario.
• Hipótesis a probar: una lista de las principales suposiciones que has hecho al llenar el canvas. Esta lista definirá las tareas a realizar para el proceso de Discovery. Tendrás que priorizarlas, eligiendo primero las más arriesgadas (aquellas que pueden hacer que tu idea se desmorone si resultan ser falsas).
• Valor esperado: para la empresa y para el cliente. Complétala lo más objetivamente posible, esto permitirá priorizar los temas unos frente a otros, y descartar rápidamente los temas de bajo valor añadido.
• Ventaja competitiva: ¿Por qué es TU PRODUCTO y sólo él el que puede resolver este problema del usuario? Si no tienes una, no es necesariamente un problema (pero sería un bonus interesante).
• Adherencias y dependencias: respecto de otros proyectos internos que pueden afectar a este caso de uso, o equipos que están trabajando en temas similares.

• Competencia: ¿quiénes son tus principales competidores para esta necesidad del usuario?
• Esfuerzo de desmitificación: el esfuerzo realizado para desmitificar este tema (tiempo asignado, recursos asignados...).

Ahora que tienes un caso de uso formalizado, el siguiente paso consiste en validar o invalidar cada una de las hipótesis establecidas. La primera acción (y a menudo la más importante) consiste en verificar que los usuarios se ajustan a la idea que tienes de ellos, y que la necesidad que consideras probada lo está realmente.

Para ello, probablemente tendrás que combinar investigación cualitativa y cuantitativa. Conocer a los usuarios, incluso sumergirte en su entorno; examinar los comentarios de los usuarios, o analizar los datos que dispongas.

Tendrás que basarte en este material para profundizar en la necesidad del usuario, y así actualizar tus personae (o personas) y tus Jobs to Be Done, según el enfoque que prefieras.

Si, en esta etapa, tus investigaciones muestran que las hipótesis relacionadas con el problema son falsas, es preferible detenerse ahí (o bien modificar y probar de nuevo tus hipótesis). En caso contrario, después de haber validado (y probablemente profundizado considerablemente) la necesidad del usuario, es hora de centrarse en las Soluciones. Organiza una lluvia de ideas invitando a tantos perfiles diferentes como sea posible: expertos del mercado, personal de ventas, Product Managers, desarrolladores. Si ya tenías algunas soluciones en mente desde el principio, haz el esfuerzo de dejarlas a un lado para empezar desde cero; esto te permitirá reflexionar de una forma más libre, aunque es probable que después de haber trabajado en la necesidad, la solución inicial ya no se ajuste completamente o resulte por no satisfacerla por completo.

Para leer el capítulo completo descarga el libro Las Organizaciones Orientadas a Producto

Las soluciones propuestas pueden redactarse en forma de Épica. No todas estas épicas serán desarrolladas al final: en una lógica de MVP, tendrás que priorizar las ideas que te permitan probar la mayor cantidad de hipótesis y aportar el mayor valor, mientras que sean realizables en un tiempo reducido.

Después de haber priorizado una idea que responde a la necesidad del usuario, ambiciosa pero factible, y que se basa en las fortalezas de tu empresa o tu organización, te recomendamos que te tomes un poco de tiempo para reflexionar sobre el modelo económico de este Producto o esta funcionalidad.

El último paso consiste en probar esta idea de solución con los usuarios. Construye un prototipo, si es posible interactivo, y haz que tus usuarios lo prueben. Si los resultados son excelentes, felicidades, es muy probable que el Producto tenga buenos resultados. Si son promedio o regulares, toma en consideración los diferentes comentarios de los usuarios y revisa tu copia: refina la solución y, si es necesario, profundiza nuevamente la necesidad para ver si no te has perdido algo.

Si las pruebas del prototipo son malas, o si no logras ganar la adhesión después de varios intentos, déjalo y pasa a otra idea. Archiva el prototipo, que quizás pueda ser útil más tarde (si el mercado se desarrolla o las necesidades del usuario evolucionan).

Ejemplo de kanban para el proceso de Product Discovery
(un caso de uso puede dar lugar a varias épicas / soluciones distintas para probar)

También puedes dividir este tablero en 2 partes distintas, una para los casos de uso (y que se detiene en la etapa de lluvia de ideas de las soluciones), y la otra para las épicas (e incluye todas las fases hasta el desarrollo).

Los ejemplos son numerosos en las diferentes tiendas de aplicaciones, en las columnas de revistas tecnológicas o en StartupGraveyard: demasiados Productos resultan ser soluciones a problemas que no existen (recuerda las Google Glass), o que apuntan a los usuarios equivocados, o que nunca encuentran su modelo económico. Por supuesto, ninguna metodología, por sofisticada que sea, te protegerá al 100% contra el fracaso; pero muchos problemas a menudo pueden anticiparse y resolverse en unas pocas semanas de trabajo bien estructurado.

¿Quién se encarga del proceso de Discovery?

En general, la mayoría de las empresas practican Product Discovery, hasta cierto punto. La dificultad radica en industrializar este enfoque a nivel empresarial. Aplicar las metodologías descritas anteriormente está al alcance de cualquier organización; lograr hacerlo sistemáticamente, apropiadamente, al nivel correcto, y en todos los temas de Producto, es una tarea más compleja.

Dependiendo del nivel de madurez de tu organización, te proponemos varias opciones.

Un trío de Product Designer, Product Manager y Product Owner

Si tu organización aún funciona separando el rol de Product Manager (enfocado en la visión del Producto, la hoja de ruta a medio-largo plazo y el diseño) y Product Owner / Associate PM (enfocado en la entrega y la gestión del backlog), en este caso estos 3 roles deben estar involucrados en el Discovery, en diversos grados.

Antes que nada, pregúntate si no sería mejor estructurar la organización de otra manera para permitir que los Product Managers se encarguen tanto del Discover como del Delivery en un área más reducida.

Si tal evolución es imposible, tendrás que repartir las tareas de Discovery entre los 3 perfiles considerados:

• El Product Designer generalmente se encargará de la investigación exploratoria; de llevar a cabo la mayoría de las pruebas con usuarios; de crear, probar e iterar sobre los prototipos o soportes visuales que sirven para desmitificar la idea.
• El Product Manager estará presente en la fase de exploración de la necesidad, pero tomará parte aún más activamente en la fase de exploración de las soluciones. En este modelo, también es él quien dirige esta fase de Discovery (backlog, gestión del avance de los temas en el ciclo Discovery, gestión del tiempo-presupuesto asignado...)
• El Product Owner está en este tipo de organización muy concentrado en la entrega; sin embargo, participa en la medida de lo posible en algunas actividades de exploración de la necesidad (entrevistas con usuarios, por ejemplo). En general, interviene principalmente en la fase de diseño de la solución para hacer la conexión entre el equipo de Producto y ayudar a identificar las dificultades potenciales, estimar la complejidad del tema y aportar sus ideas de diseño.

Un binomio de Product Designer y Product Manager

Si tu organización sigue las reglas de una buena organización de Producto, los equipos son pequeños, autónomos y obsesionados con el ROI (del usuario y de la empresa). Un (buen) Product Manager puede, por lo tanto, llevar a cabo simultáneamente las actividades de Product Discovery y Product Delivery, especialmente si está respaldado por un Product Designer en la dimensión Discovery.

En estas organizaciones más maduras, a veces es el Product Designer quien dirige la fase de Discovery, siendo el Product Manager un contribuyente entre otros (al igual que un perfil técnico, como un arquitecto o un ingeniero de producto líder). Para obtener más detalles sobre cómo organizar las actividades de diseño de productos en una organización de productos, te referimos al Volumen 4 de la Product Academy.

¿Cómo articular el Discovery y el Delivery?

Aquí hemos observado dos lógicas posibles. Ambas pueden dar buenos resultados.

Un doble ciclo tipo "Scrum"

Muchas organizaciones establecen una doble lógica de sprint, con un proceso de Product Discovery y Delivery operando en paralelo. 

Estos 2 ciclos deben estar interconectados y ser participativos, para evitar caer en un ciclo en V disfrazado. Lo que significa que el ciclo de Product Discovery debe ser lo más corto posible (la idea es desmitificar un tema en un mínimo de tiempo) y todo el equipo debe estar lo más involucrado posible en esta fase (no se trata de una fase de encuadre en modo proyecto cuyo resultado descubriría el equipo a posteriori).

Ejemplo de proceso de Product Discovery en modo sprint

A este esquema se le puede añadir un tercer ciclo: el del proceso Growth (ver el Volumen 2 de la Product Academy para más información), que busca experimentar a alta frecuencia para mejorar poco a poco el Producto. Este proceso puede ser llevado a cabo por el equipo y su Product Owner, en el marco del ciclo de delivery; pero también se puede crear un tercer ciclo de experimentaciones de alta frecuencia, aún más rápido que el ciclo Scrum y llevado por un Growth Marketer o un equipo Growth dedicado.

Ejemplo de procesos Discovery, Delivery y Growth entrelazados

Un modelo de "respiración"

Algunas organizaciones adoptan tiempos de pausa a intervalos regulares para alternar ciclos enfocados en el Delivery y períodos más propicios para el Discovery.

Esto puede consistir en alternar, por ejemplo, un ciclo de 2 semanas (de desarrollo) y luego una semana (dedicada al Discovery). Durante este período, los equipos de desarrollo priorizan refactorizaciones, PoCs o la reducción de la deuda técnica (pero su ancho de banda se ve afectado por su participación en las actividades de Discovery). En otros casos, la organización se toma un mes entero cada 3 meses para reflexionar sobre los objetivos del siguiente período y permitir que los equipos exploren nuevos temas.

Esta organización asegura que los equipos tendrán tiempo para dedicarse al discovery, pero tiene el inconveniente de una progresión más "irregular" en comparación con el modelo anterior de Continuous Discovery.

Para saber más descarga el libro Las Organizaciones Orientadas a Producto

¿Cuánto tiempo dura el proceso de Product Discovery?

Por naturaleza, las actividades que hemos descrito anteriormente pueden ser bastante prolongadas y nunca están técnicamente "terminadas": siempre se puede profundizar un poco más en la necesidad, hacer una iteración adicional sobre un prototipo o iniciar una nueva sesión de pruebas con usuarios. Además, el Product Discovery no se detiene en la fase del problema y continúa durante el desarrollo de la solución (y las iteraciones sobre esta).

Sin embargo, un equipo de Product Discovery no puede permitirse el lujo de dedicar meses a uno o dos casos de uso. Aunque es difícil determinar de antemano el tiempo que se debe invertir en un tema dado, sugerimos que se haga un balance. Para ello, se pueden considerar 3 criterios:

• La importancia estratégica del tema: si trabajas con un modelo de objetivos del tipo OKR, tenderás a pasar más tiempo en el discovery para los temas que tengan mayor impacto en tus objetivos. En cualquier caso, un caso de uso clave para tu estrategia de producto justifica un mayor presupuesto de Discovery.
• El nivel de riesgo: este está fundamentalmente relacionado con la complejidad del tema y el nivel de certeza que tienes sobre él. Si se trata de un tema que ya has tratado en el pasado, y del que tienes muchos datos recientes "a mano", no necesitas pasar mucho tiempo en Discovery.
• El nivel de urgencia: ¿Cuándo esperas poder empezar a desarrollar el caso de uso considerado?, ¿1 mes?, ¿3?, ¿6?

Te sugerimos que definas 3 "tipologías" de casos de uso, y que dimensiones el esfuerzo en función de:

• Los casos de uso muy arriesgados y exploratorios: tenderás a invertir tiempo y energía en Product Discovery en estos proyectos.
• Los casos de uso moderadamente arriesgados, sobre los que tienes dudas: establece una fecha límite en un futuro cercano para hacer un primer balance de la fase de discovery.
• Los casos de uso urgentes o con muy poco riesgo: planifica un proceso más rápido (unas pocas semanas).

Si das cadencia a tu ciclo de Product Discovery en sprints, es conveniente asignar un cierto número de sprints de diseño a cada tipo de proyecto. A veces es difícil evaluar el nivel de riesgo de antemano, así que no dudes en planificar una primera semana de exploración para cada proyecto y luego, si es necesario, afinar el nivel de urgencia o prioridad.

De hecho, puede ser interesante llevar a cabo en paralelo temas bastante sencillos de desmitificar pero con un alto impacto y temas estratégicos a más largo plazo.

En cualquier caso, el Product Discovery no debe convertirse en un proceso de diseño detallado; la idea es desmitificar algunas hipótesis importantes, si es necesario mediante prototipos, no diseñar la solución final y completa.

Evolución del riesgo a lo largo del proceso de Product Management (inspirado en Spotify)

A este respecto, no olvides que construir la solución tú mismo es solo una opción entre muchas, y no siempre la mejor: si el tema es arriesgado, complejo, o potencialmente costoso en desarrollo, la fase de Product Discovery también puede servir para identificar posibles socios técnicos o incluso objetivos de adquisición. Si resulta que un tercero satisface perfectamente la necesidad que has identificado, o que un actor propone una solución en SaaS adecuada, la colaboración puede ser una solución económica, al menos hasta validar el apetito de tu mercado. Una herramienta NoCode también puede ser una solución para probar rápidamente y a menor costo una hipótesis de producto o mercado.

Qué hacer y qué no hacer

Si aún no lo has hecho, te animamos a contratar y/o formar Product Managers y Product Designers en tu empresa, y a realizar con ellos las actividades de Product Delivery. Tu producto solo se beneficiará de ello. Aquí te dejamos algunos elementos para ayudarte a implementar este proceso en tu organización.

Para leer el capítulo completo descarga el libro Las Organizaciones Orientadas a Producto

Foto de Mauro Gigli en Unsplash