La mayor parte de la investigación de usuarios previa al lanzamiento es teatro, y lo peor es que ambas partes conocen su papel. Preguntas "¿usarías algo así", y la persona al otro lado de la llamada —que está siendo amable, que no tiene nada en juego, que está imaginando un producto que no existe— dice que sí. Tú lo anotas como validación. No lo es. Es un desconocido siendo educado sobre una hipótesis.
Antes hacía estas entrevistas religiosamente, porque todos los libros de estrategia de producto lo indican. Habla con cincuenta usuarios antes de escribir una línea de código. Encuentra el punto de dolor. Valida el problema antes de la solución. Suena disciplinado y queda bien en una pizarra. Pero el resultado real de diez llamadas de descubrimiento es diez personas diciéndote lo que creen que quieres oír, filtrado por su propio recuerdo vago de un problema en el que no habían pensado desde que empezó la llamada. Nadie te miente a propósito. Simplemente aún no tienen la información, porque esa información no existe hasta que la cosa existe.
Lo que las entrevistas no pueden producir
Lo que realmente necesitas saber antes de construir es conductual, no actitudinal: si una persona abrirá esta app una segunda vez, si pagará por ella, si se atascará en la tercera pantalla y abandonará. Nada de eso aparece en una conversación. Aparece en una repetición de sesión, un gráfico de abandono, un ticket de soporte. Un usuario puede decirte con total sinceridad que la incorporación "tiene sentido", y luego abandonarla a los cuarenta segundos, porque el autoinforme y el comportamiento son dos instrumentos distintos midiendo dos cosas distintas.
La economía solía forzar de todos modos el orden de entrevista primero. Si construir algo toma ocho semanas y tres ingenieros, no puedes permitirte descubrir que está mal después de lanzarlo, así que adelantas el riesgo a conversaciones baratas y esperas que detecten los errores costosos. Ese trato tenía sentido cuando construir era el cuello de botella. Ya no. Un prototipo funcional —autenticación real, una base de datos real, una interfaz que alguien realmente pueda usar haciendo clic— ahora es algo que construyes en una tarde con las herramientas adecuadas, las mías incluidas. Una vez que el costo de una primera versión baja tanto, la entrevista deja de ser una reducción de riesgo barata y se convierte en el paso costoso. Estás pagando con semanas de calendario para evitar una construcción que te cuesta un fin de semana.
Lo que hago en su lugar
Construye la versión real más pequeña de la idea, ponla frente a tres a cinco personas reales que tienen el problema, y observa, no preguntes. No "qué te pareció", sino dónde vaciló tu cursor, en qué hiciste clic que no hizo nada, qué intentaste hacer que el producto no admitía en absoluto. Eso último es el oro: lo que intentaron sin que se les pidiera es una señal más veraz que cualquier cosa que te hubieran dicho en una entrevista hipotética, porque es preferencia revelada en lugar de preferencia declarada.
Esto invierte el embudo de investigación tradicional, y vale la pena explicar qué cambia:
| Entrevista primero | Construcción primero | |
|---|---|---|
| Qué estás midiendo | Intención declarada ("probablemente usaría esto") | Comportamiento revelado (lo abrieron tres veces esta semana, o no) |
| Costo de equivocarse | Bajo por ciclo, pero puedes estar equivocado durante meses a lo largo de decenas de entrevistas | Un ciclo de construcción, y luego los datos te corrigen rápido |
| Mejor pregunta para hacer | "¿Qué te resulta frustrante de cómo haces esto hoy?" | "Muéstrame la última vez que intentaste hacer X aquí" |
| En qué es bueno encontrar | Si existe un problema en absoluto | Si tu solución específica funciona |
| Modo de fallo | Todos son educados, nadie es honesto, y terminas construyendo lo equivocado con total confianza | Lanzas algo tosco antes de haberte ganado la confianza, y da una mala primera impresión |
Nota que las dos filas no se anulan entre sí — responden preguntas distintas. Las entrevistas son bastante buenas para confirmar que un problema es real. Son malas para decirte si tu solución específica es correcta, porque tu solución específica todavía no existe para que nadie pueda reaccionar honestamente ante ella. Esa es la distinción que la mayoría de los consejos de "habla con los usuarios" pasa por alto: suele ser buen consejo para descubrir problemas y mal consejo para validar soluciones, y la gente lo aplica a ambos por igual.
Una fundadora que conozco hizo catorce entrevistas para una herramienta de programación de citas dirigida a salones de belleza. Trece dijeron que el problema de las dobles reservas era real y doloroso. Ella la construyó. La adopción se mantuvo plana. Resultó que las dueñas de los salones odiaban las dobles reservas en abstracto, pero ya habían construido soluciones alternativas frágiles que no querían abandonar — algo que ninguna mencionó, porque nadie piensa en describir su mecanismo de adaptación a menos que le muestres un reemplazo y observes cómo lo rechaza.
Dónde los críticos tienen razón
Esto no se cumple en todos los casos, y estaría exagerando si dijera lo contrario. Si construir es genuinamente costoso de revertir — hardware, un flujo médico regulado, cualquier cosa con una revisión de cumplimiento normativo asociada a cada cambio — entonces el cálculo de "primero entrevistar" vuelve a invertirse, porque la asimetría de costos que hace barato construir primero simplemente no aplica ahí. Un prototipo que puedes desechar en una tarde es algo muy distinto de un dispositivo para el que ya fabricaste un molde.
El otro lugar donde la investigación se justifica es en ventas empresariales con ciclos largos. Si tu comprador es un comité de compras y tu ciclo de ventas dura cuatro meses, no puedes "simplemente lanzarlo y observar" tu camino hacia un contrato firmado — necesitas saber, antes de construir, si el producto siquiera pasa una revisión de seguridad, porque un trato rechazado a los seis meses cuesta mucho más que cualquier entrevista. Y el descubrimiento puro de problemas, hecho temprano y de forma económica — sentarte con alguien mientras hace su trabajo real, no pedirle que imagine un producto futuro — está genuinamente subutilizado y es genuinamente útil. No estoy en contra de hablar con la gente. Estoy en contra de tratar una conversación hipotética y educada como evidencia, cuando una versión tosca pero real frente a la misma persona durante diez minutos te diría la verdad en su lugar.
