Me sigue sorprendiendo la cantidad de potenciales clientes que llegan buscando un "presupuesto para hacer un producto" sin antes haber validado nada.
Es como querer cotizar la construcción de un edificio sin tener los planos. Y en el desarrollo de productos digitales, esa ansiedad por empezar a construir casi siempre termina mal.
La urgencia por construir — y por qué sale cara
Entiendo la urgencia. Cuando tenés una idea, querés verla viva ayer. Pero antes de hablar de features, stacks o cuántas pantallas va a tener la app, hay preguntas que nos tenemos que animar a hacernos:
- ¿Quién es realmente el usuario?
- ¿Qué problema estamos resolviendo?
- ¿Ese problema duele lo suficiente como para que alguien pague por la solución?
Saltear estas preguntas es la receta para quemar meses de runway construyendo algo que nadie pidió. El error más caro en software no es el código malo — es construir lo que no se necesita.
¿Qué es el Product Discovery?
El Product Discovery es la práctica de validar tu idea antes de comprometerte con un desarrollo a escala completa. Para mí, es lo mismo que evaluar el terreno antes de construir. Necesitás entender si el suelo soporta lo que querés levantar, revisar las normativas y definir la factibilidad. Recién ahí hacés los planos, después el permiso de obra, y finalmente arrancás a construir.
En términos prácticos, el discovery es donde:
- Bajás la idea a tierra — transformás supuestos en hipótesis comprobables
- Validás al usuario — hablás con personas reales, observás comportamientos reales, identificás dolores reales
- Diseñás la experiencia — prototipás y testeás soluciones antes de escribir código de producción
- Reducís el riesgo — tomás decisiones informadas antes de invertir fuerte
Por qué saltear el discovery es el atajo más caro
Lo aprendí a fuerza de ver proyectos morir en el camino. Lo más caro en software no es desarrollar. Lo más caro es desarrollar algo que nadie necesita.
Esto es lo que típicamente pasa sin discovery:
- El equipo construye sobre supuestos — las features se priorizan por intuición, no por evidencia
- Pasan los meses — el producto toma forma, pero nadie fuera del equipo lo vio
- Llega el día del lanzamiento — y los usuarios no se comportan como nadie esperaba
- Los pivoteos se acumulan — cada uno más caro que el anterior, porque el código se construyó sobre los supuestos equivocados
Un buen discovery no solo mejora el producto. Te evita perder meses de foco y miles de dólares construyendo desde el entusiasmo en vez de construir desde el valor real.
Cómo se ve un buen proceso de discovery
Un discovery bien estructurado cubre cuatro dimensiones:
1. Validación del problema
Antes de resolver nada, confirmá que el problema existe y que importa. Esto significa entrevistas con usuarios, investigación de mercado y análisis competitivo. El objetivo no es validar tu idea — es entender el espacio del problema lo suficientemente bien como para que la solución correcta se vuelva obvia.
2. Investigación de usuarios
Mapeá quiénes son realmente tus usuarios — no quiénes imaginás que son. Creá personas basadas en evidencia. Entendé sus flujos de trabajo, sus frustraciones y las alternativas que usan actualmente. La brecha entre lo que los usuarios dicen que quieren y lo que realmente necesitan es donde nacen los grandes productos.
3. Diseño de la solución
Con un problema validado y insights reales de usuarios, ahora sí podés diseñar soluciones que tengan chances de funcionar. Acá es donde entran el prototipado, los wireframes y el testeo rápido. El objetivo es fallar rápido y barato — aprender qué funciona antes de escribir una sola línea de código de producción.
4. Evaluación de factibilidad
¿Tu equipo puede realmente construir esto? ¿Dentro del presupuesto? ¿Dentro del timeline? El discovery es donde identificás riesgos técnicos, desafíos de integración y decisiones de arquitectura que van a dar forma a todo el proyecto.
Cómo el discovery cambia la conversación
Cuando los clientes llegan a nosotros después de un discovery bien hecho, la conversación es fundamentalmente distinta. En lugar de "necesito una app con estas 47 features", escuchamos "este es el problema central, esto es lo que validamos, y esta es la versión más simple que entrega valor."
Ese cambio — de listas de features a propuestas de valor validadas — es lo que separa a los productos que funcionan de los que simplemente se lanzan.
Nuestro enfoque en BlackBox Vision
En BlackBox Vision creemos que nuestro rol no es solo diseñar arquitectura y shippear producto, sino ayudar a que la inversión de quien confía en nosotros tenga sentido.
A veces, el mejor consejo que podemos dar no es "construyamos esto", sino "validemos primero".
Lo vimos una y otra vez: los equipos que invierten en discovery lanzan más rápido, iteran con más inteligencia y construyen productos que la gente realmente usa. La inversión inicial de tiempo se paga sola muchas veces.
Si estás por arrancar un producto nuevo, resistí la tentación de saltar directo al desarrollo. Tomate el tiempo de entender el problema, validar la solución y construir desde la evidencia — no desde el entusiasmo.
