Discovery continuo vs. big-bang research

Descripción

La lección 2 mostró que hay formas más baratas que construir para aprender. Pero cómo se organiza ese aprendizaje en el tiempo importa casi tanto como el método que se elige. Hay dos patrones opuestos, y casi todos los equipos caen naturalmente en uno de los dos sin haberlo decidido a propósito.

El primero es el big-bang research: una fase de investigación concentrada, casi siempre al principio de un proyecto grande — dos semanas de entrevistas, un informe con hallazgos, una presentación al equipo — después de la cual el equipo pasa meses construyendo sin volver a hablar con un usuario hasta el próximo gran proyecto. El segundo es el discovery continuo: contacto pequeño y frecuente con usuarios, cada semana, sin importar en qué etapa esté el proyecto — no una fase que empieza y termina, sino un hábito que no se detiene nunca. Esta lección muestra, con números, por qué el segundo patrón produce un equipo que sabe más, más seguido, con el mismo — o menor — esfuerzo total.

Conexión con el módulo. La lección 2 estableció que hay formas baratas de aprender; esta lección agrega la dimensión del tiempo: no basta con elegir un método barato una sola vez — hace falta un ritmo que mantenga al equipo informado todo el tiempo, no solo al principio. Las lecciones 6 y 7 de esta guía (módulo completo) — hablar con usuarios como hábito, y el opportunity solution tree como mapa vivo — solo funcionan si el discovery es continuo; un opportunity solution tree armado una vez y nunca actualizado es tan inútil como un mapa desactualizado.

Una analogía: el chequeo médico anual contra la sala de emergencias

Piensa en dos formas de cuidar tu salud. La primera: no vas al médico nunca, hasta que algo te duele tanto que terminas en la sala de emergencias — ahí sí, te hacen todos los estudios, te diagnostican, y actúan. La segunda: un chequeo anual de rutina, pequeño y de bajo costo, que detecta problemas cuando todavía son manejables, mucho antes de que se vuelvan una emergencia.

La sala de emergencias es cara, estresante, y llega tarde — el problema ya está avanzado cuando finalmente se atiende. El chequeo anual es barato, rutinario, y detecta las cosas a tiempo — pero solo funciona si de verdad es anual, no un chequeo único que hiciste una vez hace cinco años y nunca repetiste. El big-bang research es la sala de emergencias del discovery: se activa cuando ya hay un problema grande y visible (un lanzamiento fallido, una apuesta que no movió nada), y para entonces ya es tarde y caro. El discovery continuo es el chequeo anual — pequeño, repetido, y por eso mismo capaz de encontrar problemas cuando todavía son baratos de arreglar.

Ejemplo trabajado: el mismo trimestre, dos patrones de contacto con usuarios

Imagina un trimestre de 12 semanas en Mercado. En un patrón, el equipo dedica las primeras dos semanas a una investigación intensiva y después no vuelve a hablar con un usuario en las diez semanas restantes — el clásico big-bang research. En el otro, el equipo mantiene un ritmo de contacto cada dos semanas, sin importar en qué esté trabajando — discovery continuo.

// Compara dos patrones de contacto con usuarios a lo largo de un trimestre (12 semanas).
// 1 = hubo contacto real con usuarios esa semana, 0 = no hubo.
function longestSilence(pattern) {
  let longest = 0;
  let current = 0;
  pattern.forEach((hadContact) => {
    current = hadContact ? 0 : current + 1;
    longest = Math.max(longest, current);
  });
  return longest;
}

const bigBangResearch = [1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0];
const continuousDiscovery = [1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0];

console.log('=== Contacto con usuarios en un trimestre de 12 semanas ===\n');
[
  { name: 'big-bang research', pattern: bigBangResearch },
  { name: 'continuous discovery', pattern: continuousDiscovery },
].forEach(({ name, pattern }) => {
  const contactWeeks = pattern.filter(Boolean).length;
  const silence = longestSilence(pattern);
  console.log(name + ': ' + contactWeeks + '/12 semanas con contacto, silencio mas largo = ' + silence + ' semanas seguidas');
});

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

=== Contacto con usuarios en un trimestre de 12 semanas ===

big-bang research: 2/12 semanas con contacto, silencio mas largo = 10 semanas seguidas
continuous discovery: 6/12 semanas con contacto, silencio mas largo = 1 semanas seguidas

Fíjate en el número que de verdad importa aquí, y no es el total de semanas con contacto — es longestSilence: el big-bang research, a pesar de haber invertido dos semanas completas de investigación al inicio (más esfuerzo concentrado que cualquiera de las semanas del discovery continuo), termina el trimestre con 10 semanas seguidas sin ningún contacto real con usuarios. Cualquier cosa que haya cambiado en el comportamiento de los usuarios, cualquier suposición nueva que haya aparecido en la construcción, cualquier señal de que el rumbo está equivocado — nada de eso llega al equipo durante esas 10 semanas, porque la "fase de discovery" ya se dio por cerrada.

El discovery continuo, con menos esfuerzo concentrado (ninguna semana dedicada por completo a investigación), nunca deja pasar más de una semana sin una señal fresca. No es que el equipo de discovery continuo "sepa más" en un sentido absoluto al final del trimestre — es que nunca está más de una semana desactualizado, mientras que el equipo de big-bang research pasa la mayor parte del trimestre operando con información de hace dos meses o más.

Por qué el big-bang research "se olvida" de discovery, sin que nadie lo decida

Nadie decide explícitamente "vamos a dejar de hablar con usuarios después de la semana 2". Lo que pasa, en la práctica, es más sutil: la fase de investigación produce un informe, el informe se presenta, el equipo pasa a "modo construcción", y ahí el calendario se llena de sprints, revisiones de código y deploys — ninguno de los cuales tiene, por defecto, un espacio reservado para hablar con un usuario. El discovery no se cancela; simplemente deja de tener un lugar en la agenda, y una vez que eso pasa, hace falta un esfuerzo activo para retomarlo — esfuerzo que compite contra el ritmo de entrega que ya está en marcha. El discovery continuo evita este problema resolviéndolo al revés: en vez de tratar el contacto con usuarios como algo que hay que "encontrar tiempo para hacer", lo trata como un bloque fijo en el calendario, con la misma prioridad que una reunión de planeación — chico, recurrente, y por eso mismo difícil de cancelar por accidente.

Errores comunes

Confundir "hicimos research alguna vez" con "hacemos discovery". Qué pasa: un equipo señala una fase de investigación que hizo hace seis meses como evidencia de que "conoce a sus usuarios", y usa esa investigación vieja para justificar decisiones nuevas. Por qué pasa: la investigación pasada sí fue real y sí costó esfuerzo real — se siente injusto tratarla como si no contara. Cómo detectarlo: cuando alguien pregunta "¿cómo sabemos esto?", la respuesta siempre apunta a la misma investigación, sin importar cuánto tiempo haya pasado desde entonces. Cómo corregirlo: pregúntate cuántas semanas de silencio (como en el ejemplo de hoy) pasaron desde esa investigación. Los usuarios, el producto y el mercado cambian; información de hace seis meses no es automáticamente falsa, pero tampoco es automáticamente vigente.

Programar discovery "cuando haya tiempo". Qué pasa: el equipo está de acuerdo, en principio, en que hablar con usuarios seguido es valioso — pero nunca le reserva un espacio fijo en el calendario, así que compite cada semana contra deadlines de entrega más urgentes, y casi siempre pierde. Por qué pasa: el discovery no tiene, por sí solo, la urgencia visible de un sprint con fecha de entrega — es fácil posponerlo "una semana más" indefinidamente. Cómo detectarlo: si le preguntas al equipo cuándo fue la última conversación real con un usuario, la respuesta es vaga ("hace un tiempo") en vez de una fecha concreta y reciente. Cómo corregirlo: trata el contacto con usuarios como un bloque fijo y recurrente en el calendario del equipo — no como algo que se hace "cuando sobra tiempo". Ese es, literal, el patrón continuousDiscovery del ejemplo de hoy: pequeño y regular, no grande y ocasional.

Pensar que discovery continuo significa "discovery todo el tiempo, sobre todo". Qué pasa: al escuchar "discovery continuo", alguien entiende que hay que investigar cada suposición de cada apuesta, todo el tiempo, sin parar — y el equipo se agota tratando de sostener ese ritmo. Por qué pasa: "continuo" suena a "constante y exhaustivo", cuando en realidad describe la cadencia (nunca dejar pasar mucho tiempo sin contacto), no el volumen de trabajo por semana. Cómo detectarlo: el equipo reporta sentirse abrumado por el discovery, con sesiones largas y exhaustivas cada semana. Cómo corregirlo: mira de nuevo el ejemplo trabajado — el patrón continuousDiscovery de hoy tiene menos esfuerzo concentrado que el bigBangResearch (ninguna semana de investigación intensiva de tiempo completo), y aun así cierra casi todos los huecos de silencio. Discovery continuo es pequeño y frecuente, no grande y constante.

Ejercicios

Ejercicio 1 — Calcula un tercer patrón. Sin ejecutar Node, imagina un patrón de 12 semanas donde el equipo habla con usuarios las semanas 1, 5 y 9 ([1,0,0,0,1,0,0,0,1,0,0,0]). Calcula cuántas semanas tuvieron contacto y cuál es el longestSilence. Compáralo con los dos patrones del ejemplo trabajado.

Ver solución

Este patrón tiene 3/12 semanas con contacto (menos que continuousDiscovery, que tuvo 6) y un longestSilence de 3 semanas (entre la semana 1 y la 5, y entre la 5 y la 9, ambos huecos de 3 semanas de silencio). Comparado con bigBangResearch (longestSilence = 10), este patrón trimestral es mucho mejor — nunca hay más de 3 semanas sin contacto—, pero comparado con continuousDiscovery (longestSilence = 1), sigue dejando huecos considerables. El ejercicio muestra que "continuo" no es binario: hay un espectro entre el silencio total y el contacto semanal, y cuanto más corto el longestSilence, más rápido el equipo detecta un cambio o un problema.

Ejercicio 2 — Diagnostica tu propio equipo (o uno que conozcas). Sin ejecutar Node, describe en palabras el patrón real de contacto con usuarios de un equipo que conozcas —¿se parece más a bigBangResearch o a continuousDiscovery?— y estima su longestSilence aproximado en semanas.

Ver solución

No hay una respuesta única —depende del equipo que elijas—, pero el ejercicio busca que apliques el criterio del longestSilence, no una impresión vaga de "hablamos con usuarios seguido". Muchos equipos, al hacer este ejercicio con honestidad, descubren que su longestSilence real es de varios meses, aunque tengan la sensación general de estar "conectados con el usuario" — la sensación viene de una investigación pasada memorable, no de un patrón de contacto reciente y verificable, exactamente el error nombrado arriba.

Ejercicio 3 — Diseña un patrón mínimo viable. Para un equipo con muy poco tiempo disponible (solo 2 horas por semana para discovery), diseña un patrón de 12 semanas (como los del ejemplo) que mantenga el longestSilence en 2 semanas o menos, con la menor cantidad posible de semanas de contacto.

Ver solución

Un patrón que cumple la condición con el mínimo esfuerzo: contacto cada 3 semanas — [1,0,0,1,0,0,1,0,0,1,0,0] — da 4/12 semanas con contacto y un longestSilence de 2 semanas (el máximo permitido). No hace falta contacto semanal (como continuousDiscovery, que usó 6 semanas) para mantener un longestSilence razonable — con una cadencia de cada 3 semanas, el equipo invierte la mitad del esfuerzo de continuousDiscovery y aun así nunca queda más de dos semanas a ciegas. El punto del ejercicio: el hábito de discovery se puede ajustar al presupuesto real de tiempo de un equipo, siempre que se mantenga regular — la irregularidad, no la baja frecuencia, es lo que produce los huecos largos y peligrosos del big-bang research.

Resumen y siguiente paso

En esta lección comparaste dos formas de organizar el discovery en el tiempo: el big-bang research, una fase concentrada al inicio que deja al equipo, en el ejemplo de hoy, 10 semanas seguidas sin ninguna señal fresca de usuarios reales; y el discovery continuo, un hábito pequeño y regular que nunca deja pasar más de una semana sin contacto. Viste que el patrón continuo no exige más esfuerzo total — exige regularidad, no volumen — y que la diferencia entre los dos patrones no está en cuánto se investiga, sino en cuánto tiempo pasa el equipo operando a ciegas entre una señal y la siguiente.

Antes de avanzar deberías poder: explicar la diferencia entre big-bang research y discovery continuo sin usar la palabra "fase"; calcular el longestSilence de un patrón de contacto dado; y diseñar un patrón de discovery ajustado a un presupuesto de tiempo limitado, sin sacrificar la regularidad.

La lección 4 toma el patrón bigBangResearch de hoy —la ausencia casi total de contacto con usuarios antes de construir— y le pone el costo exacto en el caso real de Mercado: ¿cuánto cuesta, en concreto, construir recommendations sin haber validado la suposición riesgosa primero?

Recursos

• Teresa Torres, "Continuous Discovery" (glosario) — producttalk.org/glossary-discovery-continuous-discovery. La definición exacta que sostiene esta lección: "weekly touch points with customers by the team building the product". En inglés.
• Teresa Torres, Continuous Discovery Habits — producttalk.org/continuous-discovery-habits. El libro completo sobre cómo instalar este hábito de forma sostenible en un equipo real, más allá de la comparación de esta lección. En inglés.
• Jeff Patton, "Dual Track Development" — jpattonassociates.com/dual-track-development. Sobre por qué el discovery, para funcionar de verdad, tiene que correr en paralelo con la entrega — no antes ni después, como una fase separada. Central en la lección 6 de este módulo. En inglés.