Grandes productos: Discovery vs. Delivery
La mayoría de nosotros trabajamos en problemas bastante difíciles y normalmente se necesitan sistemas bastante complejos para resolverlos.
Muchos equipos se enfrentan a dos grandes desafíos:
En primer lugar, deben descubrir cómo debe ser la solución para el cliente (Discovery). Esto significa tanto averiguar si realmente hay clientes que necesitan esta solución (demanda), como encontrar una solución que funcione tanto para los clientes como para la propia empresa. Aún más difícil es encontrar una única solución que funcione para muchos clientes y no solo para algunos específicos. Para lograrlo, debemos aprender rápidamente.
En segundo lugar, hay que asegurarse de entregar una implementación robusta y escalable en cuyo valor puedan confiar nuestros clientes (Delivery). El equipo debe tener confianza en el Release. Aunque probablemente nunca se pueda confiar al 100% en algo, tampoco se debería tener que rezar para que todo salga bien cuando se lanza algo.
Por tanto, hay que aprender rápidamente y a la vez tener confianza en los releases.
¿Puede funcionar?
Es comprensible que mucha gente piense que estos dos objetivos diferentes son contradictorios. Debemos intentar lanzar algo rápidamente para poder descubrir qué funciona y qué no. Sin embargo, tampoco queremos lanzar algo que aún no está maduro y arriesgarnos a dañar a nuestros clientes y nuestra marca.
He hablado con muchos equipos de producto y a menudo me han cuestionado porque en un momento insto a un equipo a lanzar de manera más agresiva y recopilar feedback de los clientes, y al mismo tiempo les exijo que no hagan compromisos en cuanto a software confiable, de alto rendimiento y seguro.
El Minimum Viable Product
Para muchos equipos, el concepto de un Minimum Viable Product (MVP) no es sencillo, porque por un lado están motivados para ofrecer algo al cliente rápidamente y obtener feedback, pero por otro lado rápidamente sienten que el llamado "producto" podría ser una vergüenza – ¿y cómo podría uno lanzar algo así al público?
Aprendizaje rápido y releases sólidos
Me gustaría explicar cómo los buenos equipos pueden lograr conciliar ambos objetivos: aprendizaje rápido y releases sólidos.
Básicamente, creo que a la mayoría de los equipos les resulta más fácil el segundo objetivo – es decir, entregar software de calidad – que probar cosas rápidamente y obtener nuevos conocimientos. Continuous Delivery, es decir, la entrega continua, es un buen método que he podido observar en los equipos que han comprendido la importancia de muchos cambios pequeños e incrementales en un sistema complejo.
¿Qué es realmente un producto?
Parte de la razón de esta confusión es el hecho de que a menudo simplemente no se sabe con exactitud qué significa cuando se habla de "producto", "calidad del producto", "live in production", etc. Siempre intento utilizar el término "producto" para un producto que está en un estado en el que realmente es comercializable. Es escalable y ofrece cierto rendimiento. Tiene una sólida suite de pruebas de regresión. Está diseñado para recopilar los análisis necesarios. Según sea necesario, ha sido internacionalizado o localizado. Es fácil de mantener. Cumple con la promesa de marca. Y lo más importante es que el equipo puede lanzar el producto con la conciencia tranquila.
Eso no es fácil y consume la mayor parte del tiempo de desarrollo. Por eso nos esforzamos en no desperdiciar todos esos esfuerzos.
Realizar este trabajo cuando el product manager ni siquiera está seguro de si los clientes quieren o necesitan la solución es una receta infalible para el desperdicio.
El Product Discovery
El propósito del Product Discovery es, por tanto, recopilar evidencias de que todos los esfuerzos de los desarrolladores para crear software de alta calidad no serán en vano.
Por eso existen tantas técnicas diferentes para el Product Discovery. Tenemos técnicas para comprender mejor a nuestros usuarios y clientes y para validar ideas de producto de forma cualitativa y cuantitativa. Y la mayoría de estas técnicas ni siquiera requieren el tiempo de los desarrolladores (esto es importante, ya que sabemos cuánto tiempo y esfuerzo cuesta producir buena calidad).
Un Product Discovery efectivo tiene mucho que ver con obtener acceso al cliente, y no simplemente implementar nuestros experimentos para nuevos productos lo más rápido posible.
Si eres una startup muy joven sin clientes, esto no es realmente un tema relevante (y quizás sea demasiado pronto para software con calidad de producción).
Sin embargo, la mayoría de nosotros tenemos clientes reales e ingresos reales, por lo que debemos pensar en ello. Ya he escrito sobre las técnicas más importantes para experimentar rápida y responsablemente con el Product Discovery en empresas establecidas.
Muchas de estas técnicas consisten en convencer a algunos de nuestros clientes o clientes potenciales para que prueben nuestras nuevas ideas de producto (de cualquier manera). Un programa de desarrollo de clientes es especialmente adecuado para ello, ya que estas personas se han ofrecido voluntariamente como conejillos de indias. Podemos hablar con ellos o simplemente observarlos mientras prueban nuestras ideas de producto, o dejarles probar nuestros prototipos durante un tiempo y ver qué resulta.
Conclusión: Discovery vs. Delivery
Si realmente quieres descubrir grandes productos, es extremadamente importante probar tus ideas de forma temprana y frecuente con usuarios y clientes reales. Si quieres entregar grandes productos, deberías utilizar las mejores prácticas de desarrollo e intentar no pasar por alto las preocupaciones de los ingenieros.
Cuando queremos avanzar rápidamente y descubrir nuevas ideas, usamos métodos de Discovery e involucramos a los clientes. Una vez que hemos descubierto qué solución debemos desarrollar, dejamos que los desarrolladores creen software con calidad de producción, ya que así pueden entregarlo con plena convicción.
Este texto proviene del blog de Marty Cagan y fue traducido al alemán por nosotros.
