El problema que describes no es el problema que tienes
Q1 2026Todo proyecto empieza con un problema declarado. "Necesitamos más pipeline." "Necesitamos automatizar el onboarding." "El equipo no da abasto." El problema declarado es real en el sentido de que alguien con jerarquía lo cree, se le asignó presupuesto y ya hubo una reunión al respecto. Casi nunca es el problema.
Lo aprendí por el camino lento, a lo largo de catorce años de llamadas de discovery empresarial. Una plataforma de viajes me pidió una vez capacidad: más manos para trabajar una cola de onboarding que nunca se vaciaba. Tres horas de trabajo manual por propiedad, cuatro a seis meses para que un nuevo empleado rindiera. El problema declarado era el volumen. El problema real era que el proceso entero vivía en la cabeza de la gente. Cada onboarding era un acto de traducción de conocimiento tribal a teclas, y por eso era lento, por eso producía errores, y por eso los nuevos tardaban medio año en importar. Contratar contra ese problema lo habría empeorado. Más gente, más traducción, más varianza.
La brecha entre el problema declarado y el real no es una falla de honestidad. Es una falla de punto de vista. La persona que describe el problema describe cómo se ve desde su silla, y su silla está dentro del sistema que lo produjo. Un VP de Ventas ve deals muriendo en la etapa tres y dice "tenemos un problema de cierre". Siéntate en las revisiones de pipeline durante dos semanas y descubres que los deals estaban muertos desde la calificación; la etapa tres es solo donde se firma el certificado de defunción. El problema de cierre es un problema de calificación con disfraz.
Hay señales confiables. Cuando la misma decisión se toma de tres maneras distintas según quién esté en la sala, el problema está aguas arriba de lo que cualquiera describe. Cuando un arreglo se intentó dos veces y falló dos veces, el arreglo apuntaba a un síntoma. Cuando la descripción del problema incluye una solución ("necesitamos un nuevo CRM"), alguien ya se saltó el diagnóstico, y la pregunta interesante es qué fue lo que saltó.
La disciplina que funciona es aburrida y ligeramente invasiva. Leer los deals que murieron, en el original, no en el resumen. Sentarse en las revisiones y no decir nada durante las primeras tres. Seguir una unidad de trabajo, un deal, un onboarding, un ticket, a través de cada handoff, y anotar dónde espera. Preguntarle a la gente dos niveles más abajo qué hace realmente cuando el proceso documentado le falla, porque le falla a diario, y sus soluciones improvisadas son el mapa más fiel del sistema que vas a encontrar.
Conservo una regla de mis años en finanzas, cuando el trabajo era redactar prospectos de emisión: no puedes describirle una empresa a inversionistas hasta poder explicar cómo gana dinero y dónde podría romperse, por escrito, bajo responsabilidad legal. El discovery merece el mismo estándar. Si no puedo escribir el enunciado del problema de forma que el cliente lo lea y diga "eso es incómodo y es correcto", no terminé de diagnosticar, y cualquier cosa que prescriba es una adivinanza con factura.
El problema declarado sigue importando. Te dice dónde duele, y el dolor es información. Pero tratar el problema declarado es la forma en que las empresas terminan con un CRM nuevo configurado para automatizar un proceso roto, un plan de contratación que escala una fuga, o una herramienta de IA atornillada a un flujo que nadie puede definir. La frase más cara del mundo empresarial es "así que compramos algo para eso".
Parte del supuesto de que la descripción es un síntoma. Respétala, examínala, y después ve a buscar la enfermedad. Los clientes que más obtienen de mí son los que están dispuestos a escuchar que el problema para el que hicieron presupuesto no es el que estamos por resolver.