El problema que resuelve el Product Discovery
La mayoría de proyectos de software no fallan por problemas técnicos. Fallan porque empezaron a construir sin saber exactamente qué construir.
Hemos visto a empresas gastar 80.000 € en una app que nadie quiso usar. Hemos rescatado proyectos con 6 meses de desarrollo tirado porque nadie había validado los supuestos clave. Hemos tomado llamadas de CEOs desesperados que habían lanzado su producto y descubierto que el mercado no era el que creían.
El error más caro al desarrollar una app no es elegir mal la tecnología ni contratar un equipo caro. Es empezar a construir sin saber exactamente qué construir.
El Product Discovery existe para eliminar ese riesgo antes de que sea caro.
Qué es y qué no es un Product Discovery
Un Product Discovery es:
- Un proceso estructurado de 2 semanas para definir el problema, el usuario y la solución antes de invertir en desarrollo
- Una sesión de alineación entre el equipo de negocio y el técnico sobre qué construir y en qué orden
- Un ejercicio de priorización brutal: qué es imprescindible para el MVP, qué puede esperar, qué probablemente nunca debería construirse
- El punto donde emergen los riesgos técnicos que nadie había visto y los supuestos de negocio sin validar
- Al final, un documento: alcance concreto, arquitectura técnica, roadmap priorizado y precio cerrado del proyecto
Un Product Discovery NO es:
- Un análisis de requisitos funcionales al uso (eso produce documentos de 100 páginas que nadie lee)
- Una excusa para retrasar el desarrollo indefinidamente
- Algo que solo hacen las startups (las corporaciones que lo saltan pagan el precio más tarde)
- Opcional si quieres un precio cerrado honesto — es la única manera de darlo
Qué incluye el Discovery de Dribba
El servicio de Product Discovery & Strategy de Dribba dura 2 semanas y cubre:
Semana 1 — Entender el problema
- Entrevistas con stakeholders clave (CEO, CTO, Product, usuarios si es posible)
- Análisis del mercado y la competencia
- Mapeo de los flujos de usuario principales
- Identificación de los supuestos críticos a validar antes de desarrollar
- Definición de los criterios de éxito del producto
Semana 2 — Definir la solución
- Prototipo de baja fidelidad de los flujos principales
- Test con usuarios reales (mínimo 5) si hay acceso a ellos
- Definición técnica: arquitectura, integraciones, stack
- Roadmap priorizado: MVP vs. versiones futuras
- Identificación de riesgos técnicos y mitigaciones
- Estimación detallada y precio cerrado del proyecto completo
Al final de las 2 semanas, el cliente tiene en la mano suficiente información para tomar una decisión de inversión fundamentada.
Por qué el Discovery es la mejor inversión de tu proyecto
El coste del Discovery (4.500 €) es, en promedio, entre el 5 y el 10% del presupuesto de un proyecto típico de app en Barcelona. Pero su retorno es desproporcionado:
- Elimina el riesgo de construir lo equivocado: la causa número uno de proyectos fallidos
- Genera el precio cerrado del proyecto: sin Discovery, cualquier precio es una estimación que se ajustará después
- Alinea al equipo: todos empiezan el desarrollo con el mismo mapa
- Reduce el tiempo de desarrollo: el 30% del tiempo en proyectos sin Discovery se destina a entender qué había que hacer
- Es independiente: si decides no seguir con Dribba, el entregable es tuyo
¿Cuándo no tiene sentido hacer un Discovery?
El Discovery no es para todos los proyectos. Tiene menos sentido si:
- El alcance está completamente definido y documentado: si tienes un PRD exhaustivo, el Discovery se reduce a una revisión rápida
- Estás haciendo staff augmentation: si necesitas un engineer que se integre en tu equipo a ejecutar tareas definidas, no necesitas Discovery
- Es un proyecto de mantenimiento: corrección de bugs o mejoras menores no requieren Discovery
En todos los demás casos — especialmente cuando construyes algo nuevo o rediseñas algo existente — el Discovery es no negociable si quieres un precio cerrado.
Discovery vs. Design Sprint de Google
Mucha gente confunde el Product Discovery con el Design Sprint de Google Ventures. Son procesos relacionados pero distintos:
| Aspecto | Product Discovery | Design Sprint |
|---|
| Duración | 2 semanas | 5 días |
| Output principal | Alcance + precio cerrado + arquitectura | Prototipo validado con usuarios |
| Foco | Definición de qué construir | Validación de una hipótesis específica |
| Cuándo usarlo | Antes de un proyecto nuevo | Para resolver un problema concreto de producto |
En Dribba combinamos elementos de ambos según el proyecto. Para la mayoría, el Discovery de 2 semanas es el proceso adecuado.
Qué pasa al terminar el Discovery
Al final de las 2 semanas recibes:
- Documento de alcance: qué está incluido en el MVP y qué no, con justificación
- Wireframes de flujos principales: visual de baja fidelidad de la experiencia
- Documento de arquitectura técnica: stack, integraciones, decisiones técnicas
- Roadmap priorizado: MVP + versiones futuras ordenadas por impacto/esfuerzo
- Propuesta de proyecto con precio cerrado: lo que costará construir el MVP
Con este material puedes tomar una decisión de inversión informada. Si decides seguir con Dribba, los 4.500 € se descuentan del presupuesto. Si no, el entregable es tuyo. Si tu equipo está en Barcelona, podemos hacerlo presencial en nuestra oficina del barrio de Gràcia.
