Qué NO es discovery

Descripción

Casi ningún equipo dice explícitamente "no hacemos discovery". Lo que pasa, mucho más seguido, es que un equipo cree que está haciendo discovery cuando en realidad está haciendo otra cosa que se le parece por fuera — y esa confusión es más peligrosa que no hacer nada, porque da una falsa sensación de seguridad. Esta lección cierra el módulo con las cuatro formas más comunes en que el discovery se disfraza de sí mismo sin serlo de verdad, y un criterio simple para distinguirlos.

Conexión con el módulo. Esta lección junta todo lo que viste en el módulo: de la lección 2 (construir es caro, pero preguntar la opinión de alguien también puede ser una forma vacía de "ahorrar"), de la lección 3 (una fase única no es lo mismo que un hábito continuo), y de la lección 6 (discovery real no se aísla en un equipo separado). Antes de pasar al proyecto final, esta lección te da el filtro para reconocer cuándo algo que se llama "discovery" en realidad no lo es.

Una analogía: el simulacro de incendio contra el cartel de "salida de emergencia"

Un edificio con un cartel bien puesto de "salida de emergencia" se ve preparado para una emergencia. Pero el cartel, por sí solo, no prueba nada — nadie sabe si la puerta realmente abre, si el camino está despejado, si la gente sabe qué hacer, hasta que se hace un simulacro real, con gente moviéndose por el edificio de verdad. El cartel es la apariencia de preparación; el simulacro es la preparación real, verificada.

Muchas actividades que un equipo llama "discovery" son el cartel, no el simulacro: se ven, desde afuera, como si el equipo estuviera investigando con cuidado — hay una encuesta, hubo una conversación con un usuario, se construyó un MVP "para probar"—, pero ninguna de esas cosas, al mirarlas de cerca, produjo evidencia real y verificable sobre la suposición que importa. Esta lección es el simulacro: te enseña a mirar más allá del cartel.

Ejemplo trabajado: cuatro actividades, ¿cuáles son discovery de verdad?

Imagina que un equipo de Mercado, al ser cuestionado sobre si validó recommendations antes de construir, señala estas cuatro actividades como evidencia de que "sí hicieron discovery". Vamos a chequear cada una contra tres criterios mínimos: ¿habló con usuarios reales?, ¿observó comportamiento (lo que la gente hace) en vez de solo opinión (lo que la gente dice)?, y ¿es parte de un hábito que se repite, o fue un evento único?

// isRealDiscovery: chequea actividades que un equipo llama "discovery" contra
// tres criterios minimos. No es el pickTest formal de la guia (eso es el
// modulo 4); es solo un chequeo honesto de si algo merece llamarse discovery.
function isRealDiscovery(activity) {
  const reasons = [];
  if (!activity.talkedToRealUsers) reasons.push('no hablo con usuarios reales');
  if (!activity.observedBehavior) reasons.push('solo junto opiniones, no comportamiento');
  if (!activity.repeats) reasons.push('fue un evento unico, no un habito');
  return { name: activity.name, isDiscovery: reasons.length === 0, reasons };
}

const activities = [
  { name: 'Una encuesta de satisfaccion enviada una vez al trimestre', talkedToRealUsers: true, observedBehavior: false, repeats: false },
  { name: '"Ya hable con un usuario en el pasillo la semana pasada"', talkedToRealUsers: true, observedBehavior: false, repeats: false },
  { name: 'Construir el MVP completo y ver si alguien lo usa', talkedToRealUsers: true, observedBehavior: true, repeats: false },
  { name: 'Entrevistas semanales sobre comportamiento pasado, con el equipo completo', talkedToRealUsers: true, observedBehavior: true, repeats: true },
];

console.log('=== ¿Esto es discovery de verdad? ===\n');
activities.map(isRealDiscovery).forEach((r) => {
  console.log((r.isDiscovery ? '[SI] ' : '[NO] ') + r.name);
  if (!r.isDiscovery) console.log('     falta: ' + r.reasons.join(', '));
});

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

=== ¿Esto es discovery de verdad? ===

[NO] Una encuesta de satisfaccion enviada una vez al trimestre
     falta: solo junto opiniones, no comportamiento, fue un evento unico, no un habito
[NO] "Ya hable con un usuario en el pasillo la semana pasada"
     falta: solo junto opiniones, no comportamiento, fue un evento unico, no un habito
[NO] Construir el MVP completo y ver si alguien lo usa
     falta: fue un evento unico, no un habito
[SI] Entrevistas semanales sobre comportamiento pasado, con el equipo completo

De las cuatro actividades que el equipo señaló como "discovery", solo una pasa los tres criterios. Vale la pena mirar por qué fallan las otras tres, porque cada una representa un anti-patrón distinto:

• La encuesta trimestral falla en dos criterios: mide opinión ("¿qué tan satisfecho estás?"), no comportamiento, y ocurre una vez al trimestre, no como hábito. Es el ejemplo más claro de confundir discovery con pedir opiniones — un cartel de salida de emergencia sin simulacro detrás.
• "Ya hablé con un usuario en el pasillo" falla en los mismos dos criterios, aunque suene más informal y espontáneo que una encuesta. Una sola conversación casual, sin estructura, sin preguntar por comportamiento pasado concreto, no es distinta en sustancia de la encuesta — solo se siente más orgánica. Es el ejemplo de "ya hablé con un usuario" como si eso fuera, por sí solo, discovery.
• Construir el MVP completo y ver si alguien lo usa es el caso más interesante: sí habla con usuarios reales, y sí observa comportamiento real (uso real, no una opinión sobre uso hipotético) — pasa dos de los tres criterios. Lo que falla es que es un evento único, no un hábito — y, más importante todavía, es exactamente el error que la lección 2 de este módulo advirtió: usar el método más caro de la lista (construir) para conseguir una señal que un fake door, mucho más barato, hubiera dado en una fracción del tiempo y del costo. Construir el MVP "para probar" sigue siendo construir — con todo su costo — disfrazado de discovery.
• Entrevistas semanales sobre comportamiento pasado, con el equipo completo es la única que pasa los tres criterios: habla con usuarios reales, sobre lo que hicieron (no lo que opinan o harían), como hábito recurrente, con el equipo involucrado — no aislado en un rol separado, como advirtió la lección 6.

Por qué "construir el MVP como test" es un caso especial de este error

Vale la pena detenerse en el tercer caso, porque es el más tentador de los cuatro — se siente como discovery legítimo, porque de hecho produce comportamiento real observado, no solo opinión. El problema no es la calidad de la evidencia que produce; es su costo. Si la misma pregunta —¿la gente se interesa en esto?— se puede contestar con un fake door (mostrar la opción, medir cuántos hacen clic, sin construir nada detrás) a una fracción del costo, entonces construir el MVP completo para conseguir esa misma señal es exactamente el error de la lección 2: usar el método más caro de la lista cuando uno mucho más barato hubiera bastado. El fake door no es "menos discovery" que el MVP — para muchas preguntas, es una mejor herramienta de discovery, precisamente porque cuesta menos por la misma señal. El módulo 5 de esta guía entra en detalle en los niveles de fidelidad de un prototipo, incluido el fake door; por ahora, basta con reconocer la trampa: que algo funcione como señal no significa que sea la forma más barata de conseguir esa señal.

Errores comunes

Tratar discovery como una fase única al inicio y después ignorarlo. Qué pasa: el equipo hace una ronda de investigación al arrancar un proyecto grande, la documenta, y no vuelve a tocarla durante el resto del proyecto — el patrón de big-bang research que viste en la lección 3, ahora nombrado explícitamente como uno de los cuatro anti-patrones de esta lección. Por qué pasa: una fase de investigación con principio y fin definidos se siente "completa" y "cerrada" de una forma en que un hábito continuo nunca se siente. Cómo detectarlo: usa isRealDiscovery() — si repeats es false, no importa qué tan buena haya sido la investigación en su momento, hoy ya no cuenta como discovery vigente. Cómo corregirlo: vuelve al patrón continuousDiscovery de la lección 3 y a la disciplina de calendario que describe.

"Ya hablé con un usuario" como si fuera discovery completo. Qué pasa: una sola conversación informal, sin preguntas estructuradas sobre comportamiento pasado, se cita como si fuera evidencia suficiente para tomar una decisión de producto. Por qué pasa: es una conversación real, con una persona real, y eso se siente cualitativamente distinto de "no hablar con nadie" — aunque, en términos de evidencia, aporte muy poco más que una opinión anecdótica. Cómo detectarlo: la "evidencia" citada viene de una sola persona, en una sola conversación, sin ninguna estructura ni comparación. Cómo corregirlo: el módulo 2 de esta guía enseña cómo estructurar una conversación para que de verdad cuente como evidencia; por ahora, trata una sola conversación casual como una pista a seguir, no como una respuesta.

Construir el MVP como "test" cuando un fake door costaba 100 veces menos. Qué pasa: el equipo justifica construir una primera versión funcional argumentando que "es un experimento, no el producto final" — pero paga casi el costo completo de construcción para conseguir una señal que un fake door, sin construir nada, hubiera dado por una fracción del precio. Por qué pasa: un MVP funcional se siente más "real" y más convincente que un cartel falso o un botón que no hace nada — es más fácil de justificar frente al equipo, aunque cueste mucho más. Cómo detectarlo: usa la comparación de costo de la lección 2 — si la pregunta que el MVP responde también la puede responder un fake door con una fracción del costPersonDays, construir el MVP "para probar" es el error de esta lección. Cómo corregirlo: antes de construir cualquier cosa "para ver si funciona", pregunta explícitamente: ¿hay una versión mucho más barata de esta misma pregunta que no requiera construir nada funcional? El módulo 5 de esta guía te da el catálogo completo de esas alternativas.

Confundir discovery con pedir opiniones. Qué pasa: encuestas, votaciones, o preguntas directas del tipo "¿usarías esto?" se tratan como evidencia sólida, cuando en realidad miden intención declarada, no comportamiento — la brecha say-do que el módulo 6 de esta guía va a tratar en profundidad. Por qué pasa: preguntar la opinión de alguien es la forma más rápida y menos incómoda de "hablar con usuarios" — mucho más fácil que diseñar un test que observe comportamiento real. Cómo detectarlo: usa isRealDiscovery() — si observedBehavior es false, la actividad midió lo que la gente dice, no lo que hace, y ese es exactamente el criterio que distingue una opinión de una evidencia. Cómo corregirlo: cada vez que diseñes una pregunta para un usuario, pregúntate si la respuesta describe algo que la persona ya hizo en el pasado, o algo que cree que haría en el futuro — solo la primera cuenta como evidencia fuerte, y es el corazón de lo que el módulo 2 va a enseñar a fondo.

Ejercicios

Ejercicio 1 — Clasifica una quinta actividad. Sin ejecutar Node, aplica los tres criterios de isRealDiscovery() a esta actividad: "El equipo revisa cada semana los datos de un fake door ya corriendo (un botón de 'Ver recomendaciones' que no hace nada todavía, y mide cuántos usuarios hacen clic), y ajusta el mensaje según lo que ve". ¿Es discovery de verdad?

Ver solución

Sí, cumple los tres criterios: habla con usuarios reales (indirectamente, a través de su comportamiento de clic, que es una forma legítima de "escuchar" sin conversación directa), observa comportamiento real (clics reales, no opiniones sobre si harían clic), y se repite como hábito (revisión semanal, con ajustes). Este ejercicio es útil porque muestra que "hablar con usuarios" no siempre significa una conversación — un fake door bien diseñado, revisado con regularidad, también cuenta como discovery real, porque cumple la misma función: producir evidencia de comportamiento, de forma repetida.

Ejercicio 2 — Encuentra el anti-patrón en una frase real. Un gerente de producto dice en una reunión: "No hace falta que sigamos investigando recommendations — ya validamos la idea en el kickoff del proyecto, hace dos meses". ¿Cuál de los cuatro anti-patrones de esta lección describe mejor esta frase, y qué pregunta le harías?

Ver solución

Describe el primer anti-patrón: tratar el discovery como una fase única al inicio (el kickoff, hace dos meses) y darlo por completo sin revisitarlo — el patrón de big-bang research de la lección 3, ahora con dos meses de silencio acumulados. La pregunta correcta: "¿qué cambió en el comportamiento de los usuarios, o en el producto, en estos dos meses? Y la validación del kickoff, ¿midió comportamiento real o fue principalmente una conversación sobre la idea?" — la primera pregunta ataca el problema de repeats: false; la segunda, la posibilidad de que ni siquiera el kickoff haya sido discovery real, sino una versión más elaborada del anti-patrón de "pedir opiniones".

Ejercicio 3 — Diseña una actividad que pase los tres criterios. Para la apuesta sellerTools (herramientas para vendedores, mencionada en la guía anterior), diseña en 2-3 frases una actividad de discovery que pase los tres criterios de isRealDiscovery() — habla con usuarios reales, observa comportamiento, y se repite como hábito.

Ver solución

Una actividad razonable: "Cada semana, alguien del equipo observa (con permiso) a 2-3 vendedores activos mientras suben productos nuevos al catálogo con las herramientas actuales, tomando nota de en qué paso se traban o abandonan — no preguntándoles qué opinan del proceso, sino mirando qué hacen de verdad. Estas sesiones se repiten cada semana con vendedores distintos, y las notas se comparten con todo el equipo, incluidos quienes están construyendo." Esto cumple los tres criterios: usuarios reales (vendedores activos), comportamiento observado (qué hacen, no qué dicen que harían), y hábito repetido (semanal, no un evento único) — la misma estructura que la cuarta actividad del ejemplo trabajado, adaptada a una apuesta distinta.

Resumen y siguiente paso

En esta lección cerraste el módulo con un filtro concreto —isRealDiscovery()— para distinguir el discovery real de sus cuatro disfraces más comunes: la fase única que se abandona, la conversación casual que se cita como evidencia completa, el MVP construido "para probar" cuando un fake door hubiera costado 100 veces menos, y la encuesta de opiniones disfrazada de investigación. De las cuatro actividades del ejemplo trabajado, solo una —entrevistas semanales sobre comportamiento pasado, con el equipo completo— pasó los tres criterios: usuarios reales, comportamiento observado, hábito recurrente.

Antes de avanzar deberías poder: aplicar los tres criterios de isRealDiscovery() a cualquier actividad que un equipo llame "discovery"; explicar por qué construir un MVP "para probar" sigue pagando casi el costo completo de construir; y diseñar, para cualquier apuesta, una actividad de discovery que pase los tres criterios.

Con esto cierras el módulo 1. Tienes ahora el argumento completo de por qué descubrir antes de construir: construir es la forma más cara de aprender (lección 2), el discovery necesita ser un hábito continuo, no una fase (lección 3), el costo de construir lo equivocado es real y calculable (lección 4), el discovery compra la misma evidencia esencial a una fracción del costo y del tiempo (lección 5), discovery y delivery corren en paralelo sin que uno atrase al otro (lección 6), y ahora sabes reconocer cuándo algo no es discovery de verdad, aunque se le parezca. El mini-proyecto de la lección 8 junta todo esto en una sola decisión: qué descubrir esta semana sobre recommendations, y por qué.

Recursos

• Teresa Torres, Continuous Discovery Habits — producttalk.org/continuous-discovery-habits. El libro completo dedica capítulos enteros a distinguir el discovery real de sus versiones superficiales, con muchos más ejemplos que los de esta lección. En inglés.
• Marty Cagan (SVPG), "Discovery — Judgement" — svpg.com/discovery-judgement. Sobre el criterio y el juicio que hacen falta para reconocer cuándo la evidencia de discovery es suficiente y de qué tipo — el puente natural hacia el módulo 7 de esta guía. En inglés.
• Melissa Perri, "The Build Trap" — melissaperri.com/blog/2014/08/05/the-build-trap. El artículo que nombra, en el fondo, el mismo patrón que el tercer anti-patrón de esta lección: construir como reflejo, incluso cuando se disfraza de "experimento". En inglés.