Una conversación puede sonar prometedora sin aportar demasiado al equipo. Quien funda el proyecto describe una idea, la otra persona coincide en que parece útil, y ambas partes se van con la sensación de que la reunión ha ido bien. Lo que sigue siendo una incógnita es si el problema importa lo suficiente como para que alguien cambie lo que ya hace.

El proceso de customer discovery profundiza en esa incertidumbre. Ligado al trabajo de desarrollo de clientes de Steve Blank, confronta con la realidad lo que asumimos sobre los clientes, sus problemas y el negocio. El objetivo es entender en qué condiciones podría funcionar un producto antes de que el entusiasmo por la solución se convierta en un plan cerrado.

Analiza una decisión real

Una buena entrevista puede empezar explorando la última vez que alguien se topó con el problema. ¿Qué lo causó, quién intervino y cómo lo resolvieron? Pide ver la hoja de cálculo, el hilo de mensajes o cualquier otro documento relevante, siempre que sea adecuado y con su permiso. Estos detalles ayudan a diferenciar una simple molestia que se tolera de un problema en el que ya se invierte tiempo o dinero para solucionarlo.

Imaginemos un equipo que quiere crear un software para aprobar facturas de autónomos. Una entrevista reveladora podría mostrar que la carga administrativa no es para tanto, pero que la duda sobre quién puede autorizar el pago es lo que genera los retrasos. Diseñar una pantalla más rápida para introducir datos atacaría la parte más visible sin resolver el obstáculo real. Explorar el trabajo que la gente realmente necesita resolver ayuda al equipo a replantearse su propuesta.

Además, quien realiza la tarea puede no ser quien compra, quien gestiona el presupuesto o quien revisa la seguridad. El discovery tiene que llegar a esos perfiles siempre que influyan en la adopción. Que a una persona usuaria le guste la idea no garantiza que su empresa vaya a comprarla.

Pon a prueba tus hipótesis

Antes de buscar participantes, deja por escrito qué tendría que cumplirse para que la idea funcione. Podría ser la frecuencia del problema, la insatisfacción con las alternativas actuales o la disposición a cambiar un proceso establecido. Define qué datos debilitarían cada hipótesis, no solo los que la confirmarían. Si no, casi cualquier conversación se puede interpretar como una señal positiva.

Apóyate en una guía de entrevista para no perder el hilo y, al mismo tiempo, dejar espacio a respuestas inesperadas. Evita convertir cada sesión en una demo: en cuanto los participantes ven la solución propuesta, sus respuestas tienden a girar en torno a ella. Mostrar un concepto más adelante puede servir, siempre que el equipo sepa distinguir las opiniones sobre el concepto de los datos reales sobre el comportamiento actual.

El discovery no termina en las entrevistas. Una prueba piloto, una conversación de compra o la simple observación del flujo de trabajo pueden destapar limitaciones que pasaron desapercibidas al hablar. Ninguna de estas cosas da una certeza absoluta por sí sola, pero juntas justifican una decisión más clara: centrarse en este tipo de cliente, ajustar la propuesta, validar si realmente comprarían o dejar de invertir en una idea cuyo problema no se ha confirmado. El aprendizaje solo sirve de verdad cuando cambia lo que el equipo hace después.