La brecha say-do

Descripción

Hasta ahora, este módulo asumió que si haces las preguntas correctas —de comportamiento pasado, sin líder, sin vender tu solución— vas a obtener la verdad. Esta lección introduce una complicación incómoda: incluso con la entrevista perfecta, lo que la gente dice sigue sin ser lo que la gente hace. No por mala fe — la memoria falla, la gente se sobreestima a sí misma, y las circunstancias del momento de decidir de verdad son distintas de las circunstancias de recordar o imaginar una decisión. A esta distancia entre la palabra y la acción se le llama la brecha say-do (say-do gap), y es la razón por la que el descubrimiento nunca se detiene en la entrevista: el comportamiento observado siempre pesa más que la opinión declarada.

Conexión con el módulo. Esta lección construye sayDoGap(), el segundo modelo central del módulo (junto con classifyQuestion), que compara lo que un grupo de usuarios dijo que haría con lo que de verdad hizo frente a una situación real. No resuelve la brecha —eso requiere métodos que van más allá de la entrevista, como el fake door del módulo 5— pero te da la herramienta para medirla y para nunca confundir una entrevista exitosa con una validación completa.

Una analogía cotidiana: todos juran que van a ir al gimnasio en enero

Cada primero de enero, los gimnasios se llenan de gente que jura, con total sinceridad, que este año sí va a ir tres veces por semana. No están mintiendo cuando lo dicen — en ese momento, con la motivación del año nuevo fresca, lo creen de verdad. Para marzo, la mayoría dejó de ir. La brecha no está entre lo que dijeron y una mentira consciente; está entre la intención genuina del momento de decir algo y el comportamiento real cuando llega el momento de actuar, semanas después, con el cansancio del día, el clima frío, y cien otras prioridades compitiendo por la misma hora.

Un comprador de Mercado que dice en una entrevista "sí, definitivamente compraría más si viera recomendaciones" está en la misma posición que la persona que jura ir al gimnasio en enero: la intención es real en el momento de decirla, pero el comportamiento futuro depende de factores —el ánimo de ese día, cuánta prisa tiene, si confía en la recomendación específica que ve— que la entrevista, por sí sola, no puede capturar.

Ejemplo trabajado: sayDoGap() sobre ocho usuarios de Mercado

Imagina que, además de las entrevistas, el equipo de Mercado le mostró a un grupo de usuarios un prototipo temprano de recomendaciones (el tipo de prueba que vas a diseñar a fondo en el módulo 5) y registró dos datos por persona: lo que dijo en la entrevista previa (said, si afirmó que compraría más viendo recomendaciones) y lo que hizo frente al prototipo real (did, si de verdad interactuó/compró).

// L6: el modelo say-do. Cada usuario dijo si compraria mas viendo recomendaciones (said)
// y despues, frente a un prototipo real (M5), si de verdad hizo clic/compro (did).
function sayDoGap(users) {
  const saidYes = users.filter((u) => u.said === 'yes');
  const saidYesButDidNot = saidYes.filter((u) => u.did === 'no');
  const gapPercent = saidYes.length === 0 ? 0 : +((saidYesButDidNot.length / saidYes.length) * 100).toFixed(1);
  const saidNoButDid = users.filter((u) => u.said === 'no' && u.did === 'yes');

  return {
    total: users.length,
    saidYes: saidYes.length,
    saidYesButDidNot: saidYesButDidNot.length,
    gapPercent,
    saidNoButDid: saidNoButDid.length,
  };
}

const mercadoUsers = [
  { id: 'u1', said: 'yes', did: 'yes' },
  { id: 'u2', said: 'yes', did: 'no' },
  { id: 'u3', said: 'yes', did: 'no' },
  { id: 'u4', said: 'no', did: 'no' },
  { id: 'u5', said: 'yes', did: 'yes' },
  { id: 'u6', said: 'yes', did: 'no' },
  { id: 'u7', said: 'no', did: 'yes' },
  { id: 'u8', said: 'yes', did: 'no' },
];

console.log('=== sayDoGap() sobre 8 usuarios de Mercado ===\n');
mercadoUsers.forEach((u) => {
  console.log('  ' + u.id + ': dijo=' + u.said.padEnd(3) + ' | hizo=' + u.did);
});

const result = sayDoGap(mercadoUsers);
console.log('\nTotal de usuarios: ' + result.total);
console.log('Dijeron que sí comprarían más: ' + result.saidYes);
console.log('De esos, NO lo hicieron cuando llegó el momento: ' + result.saidYesButDidNot);
console.log('say-do gap: ' + result.gapPercent + '%');
console.log('(dato aparte) dijeron que no y aun así lo hicieron: ' + result.saidNoButDid);

Qué esperar. Al correr el archivo con Node, la salida es exactamente esta:

=== sayDoGap() sobre 8 usuarios de Mercado ===

  u1: dijo=yes | hizo=yes
  u2: dijo=yes | hizo=no
  u3: dijo=yes | hizo=no
  u4: dijo=no  | hizo=no
  u5: dijo=yes | hizo=yes
  u6: dijo=yes | hizo=no
  u7: dijo=no  | hizo=yes
  u8: dijo=yes | hizo=no

Total de usuarios: 8
Dijeron que sí comprarían más: 6
De esos, NO lo hicieron cuando llegó el momento: 4
say-do gap: 66.7%
(dato aparte) dijeron que no y aun así lo hicieron: 1

De los ocho usuarios, seis dijeron en la entrevista que comprarían más viendo recomendaciones — un resultado que, si te detuvieras solo en la palabra, sonaría a validación fuerte: 75% de "síes". Pero frente al prototipo real, cuatro de esos seis no compraron nada — un say-do gap de 66.7%, dos tercios de quienes dijeron que sí, no lo hicieron. Ese es el número que de verdad le importa a la decisión de negocio, no el 75% de "síes" de la entrevista.

Fíjate también en el dato aparte: u7 dijo que no compraría más, y sin embargo sí lo hizo frente al prototipo. Este caso es menos común pero igual de instructivo — confirma que la palabra y la acción son dos señales genuinamente distintas, no solo que la gente "exagera para quedar bien". A veces alguien subestima su propio comportamiento futuro tanto como otros lo sobrestiman. sayDoGap() no cuenta este caso dentro del gapPercent (que mide específicamente cuántos "síes" no se cumplieron, porque es el patrón que más falsas esperanzas genera en un equipo de producto), pero vale la pena reportarlo por separado — es exactamente el tipo de detalle que la síntesis del módulo 7 va a querer capturar.

Por qué el comportamiento pesa más que la opinión

No se trata de que las entrevistas no sirvan — sirven muchísimo para entender por qué alguien haría algo, qué problema resuelve, qué lenguaje usa para describirlo. Pero para saber si realmente lo va a hacer, el comportamiento observado es una señal de mayor strength (fuerza de evidencia) que la opinión declarada, sin importar cuán bien redactada esté la pregunta que la generó:

FUERZA DE LA EVIDENCIA (de menor a mayor strength)
────────────────────────────────────────────────────────────────
opinión sobre una hipotética   →   "¿te gustaría...?" -- la más débil
opinión sobre el pasado         →   "¿qué te pareció...?" -- mejor, pero
                                     sigue siendo un recuerdo verbal
comportamiento pasado relatado →   "cuéntame la última vez que..."
                                     -- un hecho, aunque contado de palabra
comportamiento observado        →   qué hizo frente a un prototipo real
                                     (fake door, wizard-of-oz) -- la más fuerte
────────────────────────────────────────────────────────────────

Este orden de fuerza —que vas a ver formalizado con más rigor en el módulo 6— explica por qué el resto de esta guía no se detiene en la entrevista: el módulo 5 diseña prototipos específicamente para observar comportamiento real, no relatado, y el módulo 4 te enseña a elegir el test más barato que puede refutar una suposición, no solo el que confirma lo que ya crees. La entrevista de este módulo es indispensable para entender el problema — pero, por sí sola, nunca es suficiente para decidir si construir algo.

Errores comunes

Una muestra de amigos que te dicen lo que quieres oír. Qué pasa: para conseguir entrevistas rápido, alguien del equipo entrevista a colegas, amigos o familiares que conocen el proyecto y quieren que salga bien — y todos "validan" la idea con entusiasmo. Por qué pasa: reclutar desconocidos reales toma tiempo y esfuerzo; reclutar a quien ya tienes cerca es gratis y rápido, y esa cercanía es precisamente lo que rompe la validez del dato — la misma dinámica de "tu mamá te quiere y no quiere lastimarte" que da nombre al Mom Test (lección 3), multiplicada por cada persona de la muestra. Cómo detectarlo: revisa quién fue entrevistado — si más de uno o dos conocen al equipo, trabajan en la misma empresa, o tienen algún interés personal en que el proyecto salga bien, la muestra está sesgada antes de hacer una sola pregunta. Cómo corregirlo: recluta usuarios reales, sin relación previa con el equipo — y cuando sea posible, complementa la entrevista con observación de comportamiento real (sayDoGap es exactamente la herramienta para hacer esa comparación honesta), no solo con más entrevistas del mismo círculo cercano.

Reportar el "say" y quedarse ahí. Qué pasa: el equipo entrevista a ocho usuarios, seis dicen que sí, y la conclusión que llega a la reunión de planeación es "75% de validación" — sin ningún intento de observar si esos seis realmente actuarían así frente a algo real. Por qué pasa: el "say" está disponible de inmediato, después de una sola sesión de entrevistas; el "do" requiere un paso adicional —un prototipo, un fake door— que toma más tiempo y esfuerzo diseñar. Cómo detectarlo: si la única evidencia detrás de un confidence alto en RICE son entrevistas donde la gente dijo que haría algo, sin ninguna observación de comportamiento real, el número está inflado. Cómo corregirlo: trata el resultado de las entrevistas como la primera mitad del trabajo, no el final — la segunda mitad, diseñar algo que mida comportamiento real (fakeDoorSignal, módulo 5), es la que de verdad puede mover el confidence de 0.3 a algo más alto, como viste en el cierre del módulo 6 de product-thinking-for-engineers-guide.

Ejercicios

Ejercicio 1 — Calcula sayDoGap sin ejecutar Node. Para este grupo de cinco usuarios, calcula manualmente gapPercent:

const users = [
  { id: 'a', said: 'yes', did: 'yes' },
  { id: 'b', said: 'yes', did: 'yes' },
  { id: 'c', said: 'yes', did: 'no' },
  { id: 'd', said: 'no', did: 'no' },
  { id: 'e', said: 'yes', did: 'no' },
];

Ver solución

saidYes = 4 (a, b, c, e). saidYesButDidNot = 2 (c, e). gapPercent = (2 / 4) * 100 = 50.0. La mitad de quienes dijeron que sí, en este grupo, sí cumplieron su palabra — un say-do gap de 50% es alto, pero menos severo que el 66.7% del ejemplo trabajado en la lección. Sigue siendo evidencia de que la palabra sola no basta para decidir.

Ejercicio 2 — Interpreta un gapPercent de 0%. Si sayDoGap() devuelve gapPercent: 0 para un grupo de usuarios, ¿significa eso que la suposición riesgosa de recommendations está totalmente validada? Explica qué sí confirma ese resultado y qué todavía no.

Ver solución

Un gapPercent: 0 confirma que todos los que dijeron que sí, efectivamente lo hicieron frente al prototipo — una señal fuerte y alentadora, mucho mejor que un 66.7%. Pero no confirma automáticamente toda la suposición riesgosa por dos razones: primero, el tamaño de la muestra importa — un 0% sobre 3 usuarios pesa mucho menos que un 0% sobre 50 (el rigor estadístico de eso es tema de product-metrics-and-experimentation-guide, no de este módulo); segundo, sayDoGap() solo mide la brecha entre quienes dijeron que sí y lo que hicieron — no dice nada sobre si el grupo entrevistado representa bien al comprador típico de Mercado, ni sobre si hubo sesgo en cómo se reclutó la muestra (el error de "amigos que te dicen lo que quieres oír" de esta misma lección podría producir un gapPercent bajo por razones equivocadas).

Ejercicio 3 — Diseña tu propio caso con sayDoGap alto y bajo. Escribe dos listas de usuarios de 4 personas cada una: una donde sayDoGap() devuelva gapPercent mayor a 50, y otra donde devuelva gapPercent igual a 0. No hace falta ejecutar Node — verifica manualmente contando saidYes y saidYesButDidNot.

Ver solución

Gap alto (gapPercent > 50): [{said:'yes',did:'no'}, {said:'yes',did:'no'}, {said:'yes',did:'yes'}, {said:'no',did:'no'}]. Aquí saidYes = 3, saidYesButDidNot = 2, gapPercent = (2/3)*100 ≈ 66.7, mayor a 50.

Gap cero (gapPercent = 0): [{said:'yes',did:'yes'}, {said:'yes',did:'yes'}, {said:'no',did:'no'}, {said:'no',did:'no'}]. Aquí saidYes = 2, saidYesButDidNot = 0, gapPercent = (0/2)*100 = 0. Cada quien que dijo que sí, efectivamente lo hizo — el caso ideal, aunque, como viste en el ejercicio 2, con una muestra de solo 4 personas todavía habría que ser cauto antes de declarar la suposición completamente validada.

Resumen y siguiente paso

Esta lección te dio la pieza que faltaba para no confundir una buena entrevista con una validación completa: la brecha say-do, la distancia entre lo que la gente dice que haría y lo que realmente hace frente a una situación real. Viste ejecutado sayDoGap() sobre ocho usuarios de Mercado, con un resultado incómodo pero honesto: 66.7% de quienes dijeron que sí, no lo hicieron cuando llegó el momento — y entendiste por qué el comportamiento observado siempre pesa más que la opinión declarada, sin importar qué tan bien redactada esté la pregunta que la generó.

Antes de avanzar deberías poder: explicar la brecha say-do con tu propio ejemplo (más allá del gimnasio); calcular gapPercent manualmente sobre un grupo pequeño de usuarios; y explicar por qué una muestra de amigos cercanos infla artificialmente el "say" sin mover el "do" real.

La lección 7 cierra el módulo con la estructura completa de una buena sesión de entrevista de punta a punta — y te muestra cómo auditar tu propio guion con classifyQuestion() antes de sentarte con un usuario real, no después.

Recursos

• Steve Portigal, Interviewing Users (2ª edición) — rosenfeldmedia.com/books/interviewing-users-second-edition. Dedica una sección a la diferencia entre lo que los participantes dicen y lo que realmente hacen, y a técnicas de investigación que buscan observar comportamiento en vez de solo recolectar opiniones. En inglés.
• Nielsen Norman Group, "User Interviews 101" — nngroup.com/articles/user-interviews. Nombra explícitamente la memoria imperfecta y el sesgo de deseabilidad social como las dos causas principales de que lo dicho en una entrevista no coincida con el comportamiento real. En inglés.
• Teresa Torres, "Why You Are Asking the Wrong Customer Interview Questions" — producttalk.org/customer-interview-questions. Explica por qué incluso las preguntas de comportamiento pasado bien hechas siguen dependiendo de una memoria reconstruida, no de una observación directa — el puente natural hacia por qué el módulo 5 diseña pruebas que observan comportamiento real. En inglés.