Product Discovery

¿Conoces esta situación? En tu empresa están entusiasmados con una idea de producto específica y tú, como gerente de producto, debes definir este producto. Te dicen que los desarrolladores terminarán su proyecto actual en cuatro semanas. Eso significa que puedes tomarte todo el tiempo que necesites, siempre que estés listo en cuatro semanas…

Dices que no hay problema (después de todo, a veces solo tienes unos pocos días, así que cuatro semanas suenan soñado). Incluso vas a usar todos los métodos geniales de los que siempre hablo. Empezarás con la evaluación de oportunidades para entender el problema a resolver. Luego realizarás entrevistas con usuarios reales y crearás una lista preliminar de requisitos. Al inicio de la segunda semana deberías poder trabajar ya con un diseñador de interacción en un prototipo. En la tercera semana podrás hacer pruebas con este prototipo y en la cuarta semana elaborarás los detalles de los casos de uso y revisarás el prototipo y las especificaciones con los desarrolladores.

La realidad del Product Discovery

Suena genial, pero lo que realmente ocurre normalmente no es tan genial: durante las conversaciones iniciales con los clientes, resulta que estos no están tan entusiasmados con el producto como lo estaba la dirección, y/o tienes dificultades para diseñar un prototipo con el que los clientes se manejen bien, y/o los clientes no encuentran realmente atractivas las ideas implementadas en el prototipo. Ahora el tiempo se ha acabado y los desarrolladores están listos. En los próximos tres a seis meses se desarrollará el mismo producto inútil y aburrido que ya se vio como prototipo. Cuando el producto se entrega, la dirección estará justificadamente decepcionada con el resultado.

¿Cuál es el problema?

El problema no está en la fiabilidad del software. Los desarrolladores no tienen la culpa, al fin y al cabo solo construyeron lo que les pediste. Todos saben que es tu error como gerente de producto.

No sirve de nada hablar con los usuarios, desarrollar prototipos y probarlos junto con los usuarios, si no implementas lo que aprendes en el proceso.

La idea de ver los requisitos y el diseño como una fase secuencial, predecible y planificada en el proceso de desarrollo de producto está tan arraigada en nuestra industria que a menudo es muy difícil para las organizaciones de producto abandonar este hábito.

Pero deben hacerlo. En las organizaciones de producto hay que entender que inventar nuevos productos es fundamentalmente un proceso creativo. Es más un arte que una ciencia. Por eso prefiero llamar a esta fase “Product Discovery” en lugar de “requisitos y diseño”.

El término "Product Discovery" subraya dos puntos especialmente importantes:

• Primero, hay que averiguar si realmente hay clientes ahí fuera que quieren este producto. Eso significa que hay que definir el mercado y hacer que los clientes confirmen la oportunidad del producto.

• Segundo, hay que encontrar una solución a este problema que sea utilizable, útil y factible. Y eso significa que hay que diseñar el producto y luego validarlo conjuntamente con los clientes y el equipo de desarrollo.

Product Discovery en la industria farmacéutica

La industria farmacéutica es un ejemplo extremo. Encontrar un mercado no es especialmente difícil: siempre hay suficientes problemas que vale la pena resolver (por ejemplo, salvar vidas, prolongar vidas o mejorar la calidad de vida). Encontrar la solución es la parte difícil. Cuando las empresas farmacéuticas comienzan con la “fase de Discovery”, son plenamente conscientes de que no hay garantía de encontrar una solución ni de cuánto durará el proceso. En esta industria hay que saber convivir con esta incertidumbre (y el riesgo se refleja en los precios de los productos).

Razones de las dificultades con el Product Discovery

Y aunque todos sabemos que es difícil y que la mayoría de los lanzamientos de software son fracasos porque no cumplen los objetivos deseados, en el desarrollo de software seguimos insistiendo en planificar la fase de Discovery como si fuera la construcción de un edificio.

Especialmente la dirección tiene dificultades con el concepto de Product Discovery. Y creo que hay dos razones para ello:

• Primero, el proceso de Discovery no es predecible. La dirección teme que se trabaje durante meses en algo y no salga nada de ello. Si simplemente se empieza y se desarrolla algo, al menos se puede afirmar que se ha entregado algo. Esa es probablemente la misma razón por la que tantos directivos no se llevan bien con Scrum, porque quieren saber exactamente cuántos Sprints de 30 días se necesitarán hasta terminar.

• Segundo, en una organización de producto de software, los desarrolladores siempre se consideran un recurso escaso. La idea de que un equipo de desarrolladores esté sentado sin hacer nada más que jugar al futbolín vuelve loca a la dirección.

Irónicamente, es exactamente esta lógica la que lleva a que los desarrolladores se desperdicien como recurso.

Casi todas las empresas utilizan el proceso de Discovery descrito anteriormente. En lugar de dedicar varias semanas a un prototipo, hacen que todo el equipo de desarrollo complete ciclos de lanzamiento completos para desarrollar el software, que luego pasa por control de calidad y se implementa en sistemas de producción. Esa es la razón por la que tantas empresas necesitan tres o más lanzamientos y uno o dos años antes de obtener algo útil y utilizable. Utilizan la organización de desarrollo para construir un prototipo muy, muy costoso, y convierten a sus clientes en sujetos de prueba involuntarios.

Esa es también la razón por la que tantas startups no tienen éxito. Simplemente no tienen el capital necesario para esperar dos años antes de poder despegar. Así que toman a sus desarrolladores, los dejan dar lo mejor de sí y esperan a ver qué pasa.

Conclusión

Tanto a las startups como a las grandes empresas les aconsejo concentrar sus fuerzas en este proceso de Discovery mucho más rápido. Una vez que encuentren una solución que funcione (que sea utilizable, útil y factible), todo gira en torno al trabajo de desarrollo. Hasta ese punto, aún no necesitan tantos desarrolladores. Los desarrolladores que tienen pueden y deben participar activamente en el proceso de Discovery. Hasta cierto punto, los desarrolladores también pueden preparar la infraestructura durante el proceso de Discovery.

Puedes ayudar a tu dirección a entender el proceso de Product Discovery. Si señalas consistentemente que es tu deber asegurar que los desarrolladores también creen algo útil y utilizable, y participas en los esfuerzos por encontrar una solución prometedora, podrás dirigir la atención de la dirección hacia esta fase extremadamente importante en el proceso de desarrollo de producto.

Este texto proviene del blog de Marty Cagan y fue traducido al español. 

Crear grandes productos

=> Discovery vs Delivery en productos.

Diseñar una estrategia de producto

Descubre cómo se diferencia tu estrategia empresarial vs. estrategia de producto.