Constanza Gahona
10 de diciembre de 2025 - 6 minutos de lectura
La mayoría de los proyectos tecnológicos no fracasan por la tecnología. Fracasan incluso antes de empezar.
Me ha tocado ver proyectos con un potencial enorme. De verdad, muy buenos. Pero igual fracasan. Y casi siempre es por un error que es típico, y que cuesta verlo cuando el proyecto está recién partiendo:
Parten construyendo sin alinear objetivos, sin entender el problema real y sin feedback de usuarios.
Y ahí pasa lo que a nadie quiere: tiempo perdido, plata perdida, más trabajo y muchísima frustración.
Uno de mis principales aprendizajes como Head of Product en GUX es este: Los proyectos fallan al principio, no al final.
Dónde empieza el problema
En cualquier equipo que construye tecnología, da lo mismo si es una empresa grande o una startup de tres personas, hay un factor común: el tiempo manda.
Cuando los plazos mandan, es muy fácil decidir mal. No porque el equipo sea desordenado o poco estratégico, sino porque todos quieren avanzar, cumplir, mostrar progreso.
Y lo entiendo. Cuando uno le ve potencial a un proyecto, lo único que quiere es construirlo rápido para deje de ser una idea y empiece a ser una realidad. Pero construir sin parar a entender el problema tiene un costo. Y muchas veces puede ser grande.
¿Product Discovery? No tengo idea qué es
Si no trabajas en producto, seguramente nunca has escuchado este concepto. Pero no te preocupes: es muy fácil de entender.
Inventemos un ejemplo:
Frutalia, una empresa chilena que produce jugos naturales y distribuye a supermercados y cafeterías en todo el país. Operan bien, venden bien, pero tienen un dolor importante: su proceso de reposición de productos es lentísimo.
Entonces ahí llega el equipo de operaciones y propone:
“Vamos a automatizar todo el flujo: que los vendedores suban productos, que el sistema sugiera cantidades según stock, que Logística apruebe y que Bodega despache. Además, le metemos dashboards bonitos para ver quiebres de inventarios”
No se diga más. Todo clarísimo. Que empiece el proyecto.
Pero apenas empiezan a diseñar, aparecen cosas que nadie vio al principio:
- Los vendedores usan tres métodos distintos para registrar los pedidos (WhatsApp, Excel y llamadas)
- Logística en vez de aprobar, corrige. Y eso cambia todo el flujo.
- El 40% de los quiebres se produce por errores humanos, no por falta de stock.
- Y la guinda de la torta: nadie sabía que Bodega tiene un sistema propio, el cual es clave para que todo funcione.
De repente la solución “obvia” ya no era tan obvia. El equipo se da cuenta de que estaban diseñando algo bonito, dinámico, moderno.. pero desconectado de la realidad.
Eso es exactamente lo que pasa cuando se parte construyendo sin validar. Y el Product Discovery existe precisamente para evitar eso.
Es el proceso donde equipos, usuarios y negocio paran un segundo para entender el problema completo antes de invertir tiempo, plata y energía en una solución.
Es hablar con las personas que viven el proceso día a día, descubrir fricciones que nadie había levantado, alinear expectativas entre áreas y eliminar supuestos que, si no se cuestionan, pueden costar millones.
A veces se siente como ir más lento, pero en verdad es lo contrario: El Product Discovery acelera, porque te asegura avanzar por el camino correcto.
Qué se hace realmente en un Discovery
Seguro te imaginas el Discovery como un proceso eterno de muchas reuniones. Pero déjame decirte algo: en verdad es algo muchísimo más entretenido de lo que crees. Tanto para mí como para el cliente.
En GUX estos procesos duran entre 3 y 6 semanas, dependiendo del proyecto y su complejidad.
1. Alineamos la visión
Acá está el principal desafío: tenemos que convencer a los clientes del valor del proceso. A muchos les da lata comprometerse con sesiones semanales de 1,5 horas. Además, muchos equipos llegan creyendo que ya tienen la solución lista: “Queremos X, con Y funcionalidades y Z integraciones”
Pero cuando nos juntamos, se dan cuenta rápido que hay un desorden importante:
- Distintas áreas tienen versiones diferentes del problema
- Las prioridades chocan
- Salen desacuerdos que nunca se conversaron
Es un momento que incluso puede ser un poco incómodo, pero es muy necesario (y créeme que después se agradece).
2. Hablamos con usuarios reales
Acá es cuando los clientes se empiezan a sorprender. Porque una cosa es imaginar cómo funciona un proceso.. y otra muy distinta es escuchar a quienes de verdad lo viven.
Entrevistamos a usuarios reales para tener una mirada objetiva.
Y ahí empiezan a salir cosas interesantes:
- Casos borde que nunca se habían levantado
- Fricciones que no estaban documentadas
- Pasos que parecen obvios pero que no lo son
- Motivaciones que contradicen totalmente las suposiciones iniciales
Me ha pasado varias veces que, después de estas entrevistas, el cliente me dice: “Ya… esto cambia todo”. Y sí, cambia todo. La opinión del usuario es clave, en 30 minutos te aterrizan más que semanas enteras de suposiciones.
3. Priorizamos de verdad
Muchos creen que todo es indispensable para la primera versión del producto. Pero cuando empezamos a hablar de las necesidades, impacto y esfuerzo, aparece la primera gran verdad: No todo puede ir al MVP.
Acá ordenamos prioridades con lógica, datos y la realidad del negocio. Separamos lo que es “nice to have” de lo que realmente mueve la aguja. Y ese ejercicio, aunque a veces duela, evita muuuucho trabajo. He visto cómo un proyecto pasa de 25 funcionalidades a un MVP de 6. Más simple, más claro, más efectivo.
4. Entender y cuestionar el proceso
Antes de diseñar cualquier solución, necesitamos entender bien el problema. Y para eso usamos distintas herramientas que nos ayudan a ordenar la información y ver qué es lo que de verdad está pasando.
Aparecen conceptos como:
- Customer Journey
- Elevator Pitch
- Impact Mapping
- Visión Box
- Trade-Off
No siempre las usamos todas. Usamos las que el proyecto necesita, sin rellenar de más. El objetivo es simple: desarmar el proceso para entenderlo de verdad.
5. Prototipamos para validar
Cuando ya tenemos claro el problema, recién ahí pasamos a la solución. No necesitamos un diseño final ni algo bonito: solo lo mínimo para validar si vamos bien.
Acá probamos si:
- El flujo tiene sentido
- Las decisiones reflejan lo que necesita el usuario
- El negocio está alineado
- La solución funciona en escenarios reales
En el prototipo es donde hacemos todos los cambios: algo que sonaba buenísimo en palabras se cae en segundos cuando lo ves funcionando.
Y eso es lo mejor que puede pasar. Porque significa que descubrimos el error antes de gastar meses desarrollando.
6. Aterrizamos la viabilidad técnica
El Discovery no es solo entender al usuario o al negocio. También tiene una patita técnica muy importante, porque no sirve de nada diseñar algo increíble si después no se puede construir.
En esta etapa revisamos:
- La arquitectura que necesita el producto
- Los riesgos del proyecto
- Las integraciones con sistemas existentes
- Las restricciones técnicas que podrían afectar el alcance
- Cualquier decisión crítica que impacte en el desarrollo.
7. Cerramos con claridad total
Después de todas las sesiones, entrevistas, análisis y prototipos, llega mi parte favorita del proceso: cerrar con claridad.
Acá es donde todo lo trabajado agarra forma y por fin podemos responder, de forma clara, estas tres preguntas: ¿Qué vamos a construir? ¿Por qué lo vamos a construir? ¿Cómo lo vamos a construir?
El equipo ya tiene:
- Un roadmap claro y consensuado
- Prioridades ordenadas
- MVP definido con lógica y realidad
- Un prototipo validado
- Historias de Usuario
- Estimaciones aterrizadas de esfuerzo
- Un entendimiento común del problema y la solución
No es solo una entrega. Es tener certeza de que el proyecto parte desde el lugar correcto.
Construir bien empieza por entender
Después de varios Discovery, hay algo que siempre veo: Los equipos llegan con dudas o resistencia, pero terminan sorprendiéndose por todo lo que aparece cuando se analiza el problema en serio.
Aparecen casos bordes que nunca habían visto, el diseño se hace estratégico y las personas pasan de ser participantes tímidos a actores claves del proyecto.
Y ahí es cuando el proceso hace clic.
El Discovery no es un freno: es lo que permite alinear miradas, entender la visión del producto y avanzar con una claridad que no se puede lograr de otra forma.
Un proyecto no parte cuando se desarrolla, parte cuando se entiende.
Si quieres que conversemos del tuyo, escríbeme aquí
Constanza Gahona,
Head of Product – GUX