Hay una versión del discovery que se ve bastante seguido en equipos de producto y que en realidad no es discovery. Es un conjunto de actividades que se parecen al discovery, que usan el mismo vocabulario, que generan los mismos entregables, pero que no cambian nada en la forma en que el equipo decide qué construir.
Hacen entrevistas de usuarios. Toman notas. Arman un documento con insights. Lo comparten en Notion. Y después construyen exactamente lo que ya tenían planeado construir antes de hablar con alguien.
Eso no es discovery. Es teatro.
Para qué sirve realmente el discovery
El discovery existe para reducir la incertidumbre antes de invertir tiempo y dinero en construir algo. La pregunta que debería responder es: ¿estamos construyendo algo que alguien quiere, que resuelve un problema real y que tiene sentido para el negocio?
Si la respuesta a esa pregunta la tenés antes de hacer discovery, entonces no estás haciendo discovery, estás buscando evidencia que confirme lo que ya decidiste. Eso tiene un nombre: sesgo de confirmación. Y es uno de los patrones que más daño genera en equipos de producto porque da la sensación de que estás siendo riguroso cuando en realidad estás ignorando todo lo que no confirma tu hipótesis inicial.
Un discovery real implica que lo que encontrás puede hacerte cambiar de opinión. Si salís de cada entrevista con la misma conclusión con la que entraste, algo no está funcionando.
Las señales de que tu discovery no está funcionando
La señal más clara es que el equipo construye cosas que los usuarios no usan. No porque los usuarios sean difíciles sino porque nadie se tomó el trabajo de entender de verdad qué problema tienen y si la solución que se propone realmente lo resuelve.
Otra señal es que las entrevistas de usuarios se hacen una vez y después no se habla más del tema. El discovery no es un evento puntual al principio de un proyecto, es un proceso continuo. Los usuarios cambian, el mercado cambia, el producto cambia. Lo que era verdad hace seis meses puede no serlo hoy.
También está el caso del equipo que hace discovery pero no lo conecta con las decisiones de priorización. Tienen un montón de información sobre los usuarios pero a la hora de decidir qué construir esa información no aparece en la conversación. Las decisiones se toman por presión de stakeholders, por intuición del CEO o por lo que hizo la competencia. El discovery queda como un ejercicio paralelo que no influye en nada.
Qué hace que el discovery sea real
Un discovery que funciona parte de preguntas genuinas, no de respuestas que querés confirmar. Antes de hablar con usuarios necesitás tener claro qué es lo que no sabés y necesitás saber para tomar una buena decisión.
Las entrevistas tienen que estar diseñadas para aprender, no para vender. Eso significa hacer preguntas abiertas, escuchar sin interrumpir, explorar lo que el usuario dice aunque no sea lo que esperabas escuchar y estar dispuesto a salir de la conversación con una perspectiva completamente diferente a la que tenías al entrar.
Y lo más importante: la evidencia que generás tiene que entrar al proceso de decisión. Si hacés discovery y después priorizás como si no lo hubieras hecho, es mejor no hacerlo y ahorrarse el tiempo.
Tres preguntas para evaluar lo que estás por construir
Cuando estás en la etapa de validar una idea o hipótesis, hay tres preguntas que vale la pena hacerse antes de avanzar. La primera es si lo que estás construyendo entrega valor real para el usuario, algo perceptible y concreto. La segunda es si estás resolviendo un problema real, uno que los usuarios efectivamente tienen y que vale la pena resolver. La tercera es si lo que estás construyendo contribuye al modelo de negocio y está alineado con los objetivos del momento.
Si las tres respuestas son positivas, avanzás. Si alguna es negativa, vale la pena volver atrás antes de invertir semanas de desarrollo en algo que no va a funcionar.
No hay certezas en esto. Tenés información incompleta, muchas incertidumbres y la posibilidad de equivocarte. Pero un buen proceso de discovery reduce las chances de equivocarte en lo costoso y te da más espacio para aprender rápido cuando te equivocás en lo pequeño.
Si querés evaluar cómo estás manejando el discovery en tu rol actual, en ProductPrepa podés hacer una autoevaluación gratuita que te da una lectura de tus habilidades como PM en distintas áreas, incluyendo esta. Y si querés trabajarlo con acompañamiento, los planes con mentoría están ahí para eso.