¿Ha escuchado hablar de Product Discovery?
Para entenderlo, es necesario verlo en relación con Product Delivery. Cuando desarrollamos productos de software, en realidad hacemos dos cosas: Decidir qué construir (Product Discovery) y construirlo (Product Delivery).
En el lado del Product Delivery, una vez que hemos decidido qué construir, buscamos entregar valor lo más rápido posible. Evaluamos nuestras prácticas de delivery en función de la velocidad de nuestros ciclos de release, la calidad del código y qué tan rápido logramos poner valor en manos de los usuarios.
Esto tiene sentido porque las empresas necesitan reducir su time-to-market para mantenerse competitivas.
Pero ¿Cuál es el objetivo en el lado del Product Discovery? ¿Cómo sabemos que estamos haciendo un buen trabajo?
La historia del desarrollo de software está llena de éxitos, pero también de muchos fracasos: productos que tardaron años en salir al mercado y que finalmente no eran algo que las personas quisieran, generando pérdidas millonarias.
A partir de estas experiencias, se empieza a poner énfasis en construir cosas que realmente las personas quieren. En los años 2000 aparece el Manifiesto Ágil, impulsando la idea de crear software que evoluciona y se adapta al cambio.
“Nadie quiere pasar años, creando un producto que nadie quiere” – Ash Maurya, autor de Running Lean
Nuevas metodologías y marcos de trabajo, como Lean, Design Thinking, Lean UX o Customer Journey, entre otros, están orientados a responder preguntas como: ¿Los clientes quieren nuestras soluciones?, ¿Estamos resolviendo los verdaderos problemas de nuestros clientes? Luego, para la entrega de ese valor, entran en juego otras herramientas como Scrum o XP.
Entregar todo lo que los clientes quieren no siempre es suficiente… o rentable
Las ideas abundan. Pueden venir de stakeholders, clientes, del equipo, de la competencia o de partners. Pero según estudios como el de Harvard Business Review, hasta el 70% de esas ideas no generan el impacto esperado en el negocio.
Bajo esta premisa, por ejemplo, si nos enfrentamos a un trabajo de al menos 12 features al año + otros gastos en los que incurre la empresa para el desarrollo de software podríamos enfrentar costos de aproximadamente $7,500 mensuales ($90,000 anuales)
Si solo una parte de esas funcionalidades genera resultados relevantes, el desperdicio puede ser considerable. Aun cuando el negocio logre compensarlo con las iniciativas que sí funcionan, sigue existiendo una oportunidad clara de mejorar el retorno de inversión.
¿Qué pasaría si pudiéramos identificar lo antes posible las funcionalidades que SÍ generan el retorno esperado?
Muchas personas se hicieron la misma pregunta, lo que impulsó la evolución de la forma de hacer Product Discovery. Entonces, ya no es suficiente solucionar problemas, sino que además se debe generar soluciones que las personas realmente quieran o por las que esten dispuestas a pagar. Se trata de identificar soluciones que permitan aprovechar oportunidades
El empresario Henry Ford decía “Si hubiera preguntado a la gente lo que querían, me habrían pedido un caballo más rápido”
Históricamente las empresas que lograron aplicar este enfoque, resolviendo problemas realmente relevantes, encontraron oportunidades que les permitieron trascender.
Einstein decía a sus alumnos que si él tuviera una hora para resolver un problema, usaría 55 minutos en analizar el problema para llegar a un diagnóstico certero, y una vez conociendo las causas, tardaría 5 minutos en encontrar una solución. En el mundo del software, nos obsesionamos con las características (features) cuando en realidad conviene enfocarnos en los resultados que buscamos generar tanto para los clientes como para el negocio.
Product Discovery en la práctica
El propósito del Product Discovery es aprender rápido, en una industria en la que aprender, y aprender rápidamente es la cosa más importante para reducir el riesgo de construir soluciones incorrectas o de invertir demasiado pronto en ideas que todavía no han sido validadas.
Las herramientas como Design Thinking, Lean, Agile, OKRs ayudan a responder preguntas más temprano durante el proceso para encontrar ese producto que nos permita alcanzar una oportunidad en el mercado entregando valor real para el cliente y para la organización.
¿Cómo sabemos si el Product Discovery está funcionando?
En muchos contextos Product Delivery se mide por la velocidad de entrega y valor generado, ¿cómo evaluamos el Product Discovery? La respuesta está en enfocarnos en aprendizajes validados más que en outputs. Una buena práctica de discovery no produce “features listas”, sino evidencia concreta que reduce la incertidumbre antes de invertir en desarrollo.
El éxito se mide mediante métricas de aprendizaje y riesgo:
-
Número de hipótesis validadas/invalidadas: ¿Cuántas ideas descartamos temprano gracias a experimentos con usuarios reales?
-
Tiempo de validación: ¿En cuántos días/semanas confirmamos si una solución tiene tracción real?
-
Señales de valor temprano: ¿Los usuarios muestran disposición a pagar, recomendar o usar activamente?
-
Reducción de desperdicio: Siguiendo el 70/30 de Harvard, cada hipótesis invalidada temprano salva decenas de miles de dólares [HBR].
Ejemplo práctico: Una empresa SaaS prueba 10 funcionalidades con prototipos. Solo 3 muestran intención de uso. Invierten $90K en lo validado, evitando $63K en desperdicio.
Discovery y Delivery: Dos caras de la misma moneda
El Product Discovery no reemplaza al Delivery, sino que lo complementa. En enfoques como Dual Track Agile, ambos corren en paralelo: mientras Delivery construye lo validado, Discovery sigue explorando nuevas oportunidades.
Esto genera un ciclo continuo de aprendizaje y entrega:
Discovery → Valida → Delivery → Mide → Nuevo Discovery
Anti-patrones comunes a evitar:
-
Confundir “hablar con clientes” con validación real
-
Medir éxito por cantidad de features, no por impacto
-
Hacer discovery secuencial (esperar que termine para empezar delivery)
Una forma conceptual de entender el Product Discovery
Como modelo simplificado, podemos pensar el Product Discovery así:
Éxito = (Aprendizajes Rápidos) × (Valor Validado) / Riesgo Residual
No se trata de una fórmula matemática formal, sino de una representación pedagógica. La idea central es que, en muchos contextos, mientras más rápido aprende un equipo, más valor valida y más riesgo reduce, mejores decisiones puede tomar sobre qué construir y qué no.
“No queremos el producto equivocado rápido. Queremos el correcto, continuamente.” – Marty Cagan
Referencias
- Running Lean by Ash Maurya
- Harvard Business Review - Digital Transformation Is Not About Technology
- How do you know that your product works? - Henrik Kniberg
- Inspired: How to Create Tech Products Customers Love by Marty Cagan
- Dual Track Agile by Jeff Patton
- Product Discovery that Works by Giscard Fenix