Qué compra el descubrimiento: evidencia barata

Descripción

La lección 4 dejó un número incómodo: construir recommendations sin validar arriesga, en promedio, 42 person-days perdidos. Esta lección responde la pregunta obvia que ese número deja abierta: ¿cuál es la alternativa, y cuánto cuesta? Aquí es donde el discovery deja de ser una idea abstracta ("hablar con usuarios es bueno") y se convierte en una comparación concreta, con los mismos números que usaste en la lección anterior.

El discovery no compra certeza absoluta —eso solo lo da, en el mejor de los casos, medir en producción durante meses—. Lo que compra es evidencia: una señal real, sobre comportamiento real, lo suficientemente fuerte como para decidir si vale la pena construir la versión completa. Y la compra a una fracción del costo y del tiempo que cuesta construir para averiguarlo.

Conexión con el módulo. Esta es la lección bisagra del módulo: reutiliza timeToEvidence() de la lección 4 sin ningún cambio —la misma función, el mismo buildAndSee— y agrega el camino alternativo, discover. El resultado de esta comparación es el argumento completo que sostiene el resto de la guía: si descubrir cuesta una fracción de construir y llega antes, entonces aprender a descubrir bien (módulos 2 a 7) es la inversión más rentable que puede hacer un equipo antes de comprometerse a construir.

Una analogía: la cata antes de comprar la caja completa

Antes de comprar una caja completa de vino para un evento, casi nadie compra a ciegas: pide una copa, la prueba, y decide. La copa no te dice absolutamente todo lo que vas a experimentar con la caja completa —una sola copa no captura cómo se siente servir doce botellas en una fiesta real—, pero te dice lo esencial: si el vino te gusta o no, mucho antes de pagar por la caja entera. Comprar la caja completa "para probarla" sería absurdo — nadie hace eso, y sin embargo es exactamente lo que un equipo hace cuando construye la funcionalidad completa para saber si a los usuarios les va a gustar.

El discovery es la copa de cata de una apuesta de producto: no reemplaza la experiencia completa de tener el producto terminado, pero da la señal esencial —¿esto funciona, o no?— a una fracción del costo, antes de comprometerte con la caja completa.

Ejemplo trabajado: dos caminos, la misma evidencia esencial

Retomamos timeToEvidence() exactamente como quedó en la lección 4, sin cambios, y agregamos el segundo camino: discover. Este es el mismo test barato que la guía anterior ya había anticipado en su módulo 6 — mostrar recomendaciones curadas a mano a 50 usuarios durante una semana, y comparar sus compras contra un grupo de control que no las ve. Nadie construye el motor automático todavía; alguien del equipo elige las recomendaciones a mano, una por una.

// timeToEvidence: la misma funcion de la leccion 4, sin cambios.
// Hoy agregamos el segundo camino -- discover -- para la comparacion completa.
function timeToEvidence(path) {
  const costPersonDays = path.steps.reduce((sum, s) => sum + s.personDays, 0);
  const calendarDaysToEvidence = path.steps.reduce((sum, s) => sum + s.calendarDays, 0);
  return { name: path.name, costPersonDays, calendarDaysToEvidence, evidence: path.evidence };
}

const buildAndSee = {
  name: 'buildAndSee',
  evidence: 'motor completo en produccion; se mide con compras reales durante semanas',
  steps: [
    { label: 'disenar el motor de recomendaciones', personDays: 5, calendarDays: 5 },
    { label: 'construir el motor basico (3 person-months)', personDays: 60, calendarDays: 60 },
    { label: 'QA y deploy a produccion', personDays: 5, calendarDays: 5 },
    { label: 'esperar volumen suficiente de compras para medir', personDays: 0, calendarDays: 14 },
  ],
};

const discover = {
  name: 'discover',
  evidence: 'curaduria manual a 50 usuarios, comparado contra un grupo de control',
  steps: [
    { label: 'elegir 50 usuarios y curar recomendaciones a mano', personDays: 2, calendarDays: 2 },
    { label: 'correr el test 1 semana y medir compras vs grupo de control', personDays: 1, calendarDays: 7 },
  ],
};

console.log('=== timeToEvidence: dos caminos hacia la misma evidencia ===\n');
[buildAndSee, discover].forEach((path) => {
  const r = timeToEvidence(path);
  console.log(r.name + ':');
  console.log('  costo: ' + r.costPersonDays + ' person-days');
  console.log('  evidencia en: ' + r.calendarDaysToEvidence + ' dias calendario');
  console.log('  evidencia: ' + r.evidence);
  console.log('');
});

const b = timeToEvidence(buildAndSee);
const d = timeToEvidence(discover);
const costSavings = Math.round((1 - d.costPersonDays / b.costPersonDays) * 100);
const timeSavings = Math.round((1 - d.calendarDaysToEvidence / b.calendarDaysToEvidence) * 100);
console.log('=== Comparacion ===');
console.log('discover cuesta ' + costSavings + '% menos que buildAndSee (' + d.costPersonDays + ' vs ' + b.costPersonDays + ' person-days)');
console.log('discover llega a evidencia ' + timeSavings + '% mas rapido que buildAndSee (' + d.calendarDaysToEvidence + ' vs ' + b.calendarDaysToEvidence + ' dias)');

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

=== timeToEvidence: dos caminos hacia la misma evidencia ===

buildAndSee:
  costo: 70 person-days
  evidencia en: 84 dias calendario
  evidencia: motor completo en produccion; se mide con compras reales durante semanas

discover:
  costo: 3 person-days
  evidencia en: 9 dias calendario
  evidencia: curaduria manual a 50 usuarios, comparado contra un grupo de control

=== Comparacion ===
discover cuesta 96% menos que buildAndSee (3 vs 70 person-days)
discover llega a evidencia 89% mas rapido que buildAndSee (9 vs 84 dias)

Lee estos dos números con calma, porque son el resultado central de todo el módulo: discover cuesta 96% menos (3 person-days contra 70) y llega a evidencia 89% más rápido (9 días contra 84). No es una mejora marginal — es una diferencia de dos órdenes de magnitud en costo, y de casi diez veces en velocidad, para llegar a una señal sobre la misma pregunta central: ¿los usuarios compran más cuando ven recomendaciones?

⚠️ Estos números son un caso pedagógico, construido con estimaciones razonables para el ejemplo de Mercado — no una medición real de ninguna empresa. Lo que importa no es que "descubrir siempre cueste exactamente 96% menos": es la magnitud del patrón, que se repite de forma consistente en la práctica real de equipos de producto, y la lógica de decisión detrás del cálculo (costo en personDays, tiempo en calendarDays), que sí es la que vas a aplicar una y otra vez en el resto de esta guía.

Por qué discover no da "la misma" evidencia, y por qué está bien que no la dé

Fíjate en la columna evidence de cada camino: buildAndSee mide "compras reales durante semanas" — el motor automático, en producción, con todo el tráfico real de Mercado. discover mide "curaduría manual a 50 usuarios, comparado contra un grupo de control" — una muestra mucho más chica, con recomendaciones elegidas a mano por una persona, no por un algoritmo. Son evidencias distintas, y sería un error pretender que son intercambiables en todo sentido: discover no te dice si el motor automático va a funcionar técnicamente, ni cómo se comporta con millones de productos, ni si escala. Lo que sí te dice, con una muestra más chica pero con un diseño que compara contra un grupo de control, es la pregunta que de verdad importa antes de construir nada: si mostrar recomendaciones personalizadas —aunque sea curadas a mano— cambia el comportamiento de compra. Esa es la suposición riesgosa completa, ni más ni menos. El discovery no reemplaza la medición completa en producción; reemplaza la necesidad de construir todo solo para conseguir la primera señal sobre si vale la pena seguir.

Errores comunes

Pedir que el discovery pruebe todo lo que va a probar el producto terminado. Qué pasa: alguien objeta que el test de discover "no prueba si el motor automático funciona técnicamente" o "no prueba si escala a millones de usuarios", y usa esa objeción para descartar el discovery por completo. Por qué pasa: es cierto que el discovery no prueba esas cosas — pero esas no son la suposición riesgosa que se está probando. La suposición riesgosa es sobre comportamiento de compra, no sobre performance de ingeniería. Cómo detectarlo: la objeción a un test de discovery apunta a una pregunta que ese test nunca prometió contestar. Cómo corregirlo: antes de diseñar o de criticar un test, vuelve a la suposición exacta que se está probando (en este caso: "los usuarios compran más si ven recomendaciones personalizadas") — el diseño detallado de esa correspondencia, entre suposición y test, es exactamente el tema del módulo 4.

Usar el ahorro de costo como excusa para no construir nunca. Qué pasa: en el sentido opuesto, un equipo se enamora tanto de lo barato que es el discovery que empieza a tratarlo como un sustituto permanente de construir, corriendo test tras test sin nunca comprometerse a construir la versión real, aunque la evidencia ya sea clara. Por qué pasa: el discovery se siente seguro y de bajo riesgo, mientras que construir siempre implica comprometer recursos reales — es tentador quedarse en la zona cómoda de "seguir probando". Cómo detectarlo: el equipo ya corrió varios tests con señales positivas consistentes sobre recommendations, y sigue posponiendo la decisión de construir el motor real. Cómo corregirlo: el discovery existe para informar la decisión de construir, no para reemplazarla indefinidamente — el módulo 7 de esta guía (sintetizar y decidir) te da el criterio explícito para saber cuándo la evidencia ya alcanza y es momento de construir.

Comparar el costo de discover contra el costo total del backlog, no contra buildAndSee. Qué pasa: alguien argumenta que "3 person-days no es nada comparado con todo lo que tiene que hacer el equipo este trimestre", minimizando el valor del ahorro porque lo compara contra la magnitud equivocada. Por qué pasa: 3 person-days, en aislado, suena a un número pequeño y fácil de descartar como "no vale la pena ni medirlo". Cómo detectarlo: la conversación sobre el costo del discovery nunca lo compara directamente contra el costo de la alternativa que reemplaza. Cómo corregirlo: la comparación correcta, como viste en el ejemplo de hoy, no es "3 días es poco" — es "3 días en vez de 70 días, para la misma pregunta". El ahorro relevante es siempre contra el camino que el discovery evita, no contra el tamaño total del trabajo del equipo.

Ejercicios

Ejercicio 1 — Recalcula con un discover más caro. Sin ejecutar Node, si el test de discover necesitara el doble de usuarios (100 en vez de 50) y eso duplicara su costo a 6 person-days mientras el tiempo se mantiene en 9 días calendario, ¿cuál sería el nuevo costSavings frente a buildAndSee (70 person-days)? ¿Sigue siendo una diferencia enorme?

Ver solución

costSavings = 1 - 6/70 = 0.914, redondeado a 91% — todavía una diferencia enorme, apenas 5 puntos porcentuales menos que el 96% original. Este ejercicio muestra algo importante: la conclusión del módulo (discovery cuesta una fracción de construir) es robusta incluso si las estimaciones específicas cambian bastante. Duplicar el costo del test de discovery casi no mueve la conclusión, porque la brecha entre 70 person-days y cualquier número de un solo dígito sigue siendo enorme en términos relativos.

Ejercicio 2 — Explica qué pregunta contesta cada camino. En una tabla de dos columnas, escribe qué pregunta contesta bien buildAndSee que discover no contesta, y qué pregunta contesta bien discover que buildAndSee tarda demasiado en contestar.

Ver solución

buildAndSee contesta bien	discover contesta bien
¿El motor automático funciona técnicamente a escala completa?	¿Los usuarios cambian su comportamiento de compra al ver recomendaciones?
¿Cómo se comporta el sistema con millones de productos reales?	¿Vale la pena, en principio, invertir en construir el motor completo?
¿Cuál es el impacto real y sostenido en producción, a largo plazo?	¿Cuál es la primera señal, barata y rápida, antes de comprometer semanas de trabajo?

El punto de la tabla: no son la misma pregunta, y por eso no compiten — discover contesta la pregunta que hay que responder primero, antes de que tenga sentido invertir en responder las preguntas que solo buildAndSee puede contestar.

Ejercicio 3 — Argumenta con los números frente a un escéptico. Un gerente dice: "Prefiero que construyan directo — así tenemos el producto real, no un experimento con 50 personas". Usando los números exactos del ejemplo de hoy, escribe una respuesta de 3-4 frases.

Ver solución

Una respuesta posible: "Entiendo el instinto, pero mira los números: construir el motor completo cuesta 70 días-persona y tarda 84 días en darnos cualquier evidencia real. El test con 50 usuarios cuesta 3 días-persona y nos da una señal clara sobre la misma pregunta central —si las recomendaciones cambian el comportamiento de compra— en solo 9 días. No estoy proponiendo quedarnos con el experimento para siempre: si la señal es buena, construimos el motor completo con mucha más confianza que si hubiéramos empezado a ciegas. Pero arriesgar 70 días completos cuando podemos conseguir la misma señal esencial por 3 no es cautela, es gastar de más." El argumento funciona porque no pide renunciar a construir — pide secuenciar correctamente cuándo construir, usando los números reales de la comparación.

Resumen y siguiente paso

En esta lección corriste la comparación central del módulo: discover —una curaduría manual con 50 usuarios contra un grupo de control— cuesta 96% menos y llega a evidencia 89% más rápido que buildAndSee —construir el motor completo—, para la misma pregunta esencial sobre la suposición riesgosa de recommendations. Viste también por qué esta comparación no significa "discovery reemplaza construir": significa que el discovery contesta primero la pregunta que hace que valga la pena, o no, pagar el costo de construir.

Antes de avanzar deberías poder: explicar, con los números exactos, cuánto más barato y más rápido es discover frente a buildAndSee; nombrar una pregunta que discover no puede contestar y que sí necesita buildAndSee; y defender, frente a un escéptico, por qué correr el test barato primero no es lo mismo que evitar construir para siempre.

La lección 6 responde la objeción que casi siempre sigue a esta comparación: "si el discovery es tan bueno, ¿por qué no lo hacemos siempre, en vez de simplemente construir directo — no nos va a atrasar?". Ahí vas a ver por qué discovery y delivery no compiten por el mismo tiempo: corren en paralelo, en dos tracks distintos del mismo equipo.

Recursos

• Teresa Torres, Continuous Discovery Habits — producttalk.org/continuous-discovery-habits. El libro que desarrolla, con mucho más detalle del que cabe en esta lección, cómo un equipo diseña y corre este tipo de pruebas baratas de forma sostenida. En inglés.
• David J. Bland y Alexander Osterwalder, resumen de Testing Business Ideas — strategyzer.com/library/testing-business-ideas-book-summary. Un catálogo de decenas de tests baratos, del mismo tipo que discover en esta lección, organizados por qué tipo de evidencia dan. En inglés.
• Marty Cagan (SVPG), colección de artículos sobre product discovery — svpg.com/insights/product-discovery-articles. Un archivo completo de casos reales donde equipos de producto consiguieron evidencia barata antes de construir, con la misma lógica de esta lección aplicada a productos reales. En inglés.