Presentación de la guía: valida la apuesta antes de construirla

Por qué existe esta guía

La guía anterior, product-thinking-for-engineers, te enseñó a pensar como alguien que decide qué construir: distinguiste outputs de outcomes, trazaste la cadena de valor, priorizaste con RICE, dimensionaste oportunidades, recortaste al MVP correcto, y —en su último módulo— aprendiste a tratar cada decisión de producto como una apuesta sostenida por un montón de suposiciones, algunas de las cuales, si son falsas, hunden la apuesta entera. Esa guía terminó con un ejercicio muy concreto: tomó la apuesta recommendations del backlog de Mercado y encontró, con un pipeline que corriste en Node, cuál de sus suposiciones era la más peligrosa.

Esta guía empieza exactamente donde esa terminó. No vas a volver a encontrar la suposición riesgosa —eso ya está hecho—. Vas a aprender a validarla: a conseguir evidencia real, barata, antes de que el equipo gaste semanas de ingeniería construyendo algo que podría estar apostando sobre una creencia falsa.

La promesa de esta guía, resumida en una frase, es esta:

Validar la apuesta con usuarios antes de construirla.

"Construirla para saber si funciona" es la respuesta más natural para cualquier ingeniero — es lo que sabes hacer, es lo que se siente como progreso real, y produce algo tangible que se puede demostrar en un demo. Pero construir para aprender es, casi siempre, la forma más lenta y más cara de conseguir la misma información. Esta guía te enseña el camino más barato: el descubrimiento de producto (discovery). No como una fase burocrática antes de la "construcción de verdad", sino como un hábito continuo que le compra al equipo evidencia real —a una fracción del costo— antes de comprometer semanas de trabajo.

El caso que nos acompaña: la apuesta de recomendaciones de Mercado, sin probar

Esta es, literal, la forma en que la guía anterior dejó las cosas. No hay lógica nueva en el siguiente bloque — es una foto del estado actual de la apuesta, tal como quedó al cierre de product-thinking-for-engineers:

// Estado en el que la guia anterior (product-thinking-for-engineers, modulo 6)
// dejo la apuesta "recommendations" de Mercado. No hay logica nueva aqui --
// es, literal, el resultado de esa guia, solo mostrado de nuevo.
const recommendationsBet = {
  assumption: 'Los usuarios van a comprar mas si ven recomendaciones personalizadas',
  risk: 0.6,
  impact: 5,
  tested: false,
  confidenceCeiling: 0.3,
};

console.log('=== La apuesta "recommendations" de Mercado, donde la dejamos ===\n');
console.log('Suposicion mas riesgosa: "' + recommendationsBet.assumption + '"');
console.log('score = risk(' + recommendationsBet.risk + ') x impact(' + recommendationsBet.impact + ') = ' + (recommendationsBet.risk * recommendationsBet.impact));
console.log('tested: ' + recommendationsBet.tested);
console.log('confidence de RICE topado en: ' + recommendationsBet.confidenceCeiling);
console.log('\nEsta guia existe para mover "tested" a true -- con evidencia barata, no adivinando.');

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

=== La apuesta "recommendations" de Mercado, donde la dejamos ===

Suposicion mas riesgosa: "Los usuarios van a comprar mas si ven recomendaciones personalizadas"
score = risk(0.6) x impact(5) = 3
tested: false
confidence de RICE topado en: 0.3

Esta guia existe para mover "tested" a true -- con evidencia barata, no adivinando.

Fíjate en el número que importa: confidenceCeiling: 0.3. En el módulo de RICE de la guía anterior, el confidence es uno de los cuatro factores que determinan cuánto se prioriza una apuesta — y mientras la suposición más riesgosa siga sin probarse, ese número está artificialmente topado bajo, sin importar cuánto entusiasmo tenga el equipo. La única forma honesta de destaparlo es conseguir evidencia real sobre si "los usuarios compran más al ver recomendaciones" es cierto. Esa es, en una frase, la tarea completa de esta guía: subir ese 0.3 con evidencia, no con optimismo.

Una analogía: probar el agua con el pie

Antes de tirarte de clavado a una alberca que no conoces, metes el pie. No porque seas cobarde — porque es la forma más barata de conseguir la información que necesitas ("¿está fría? ¿tiene la profundidad que pensaba?") sin pagar el costo completo de tirarte y descubrirlo de la peor manera. Meter el pie te cuesta dos segundos. Tirarte de clavado y descubrir que el agua estaba helada, o que la alberca era más baja de lo que pensabas, te puede costar mucho más que dos segundos.

Construir la funcionalidad completa para saber si a los usuarios les gusta es el equivalente de tirarte de clavado sin haber probado el agua. Puede salir bien. Pero cuando sale mal, el costo no es "dos segundos de agua fría" — es semanas de ingeniería, atención de producto y oportunidad de haber construido otra cosa. El descubrimiento es, literal, la versión de "meter el pie" aplicada a apuestas de producto: una forma barata y rápida de sentir la temperatura del agua antes de comprometerte con el clavado completo. El resto de esta guía es, en el fondo, aprender distintas formas de meter el pie — cada vez con más precisión — antes de decidir si vale la pena tirarse.

El mapa de los 8 módulos de la guía

Esta guía tiene ocho módulos. Cada uno te da una pieza del proceso completo de validar una apuesta con usuarios, siempre sobre el mismo caso — la apuesta recommendations de Mercado:

#	Módulo	De qué se trata
1	Por qué discovery (estás aquí)	Por qué descubrir antes de construir: construir es la forma más cara de aprender, y el discovery continuo compra evidencia barata.
2	Hablar con usuarios	Entrevistas que no mienten: preguntar por comportamiento pasado, no por intenciones futuras (el Mom Test).
3	El opportunity solution tree	Mapear el espacio del problema — outcome, opportunities, solutions, experiments — antes de saltar a una solución.
4	Suposición e hipótesis	Convertir una suposición en una hipótesis falsable y diseñar el test más barato que la puede refutar.
5	Prototipado y fidelidad	Prototipar al nivel justo: paper, clickable, wizard-of-oz, fake door — según qué necesitas aprender.
6	Evitar el sesgo	Los sesgos que arruinan el discovery: confirmación, preguntas líderes, la brecha say-do.
7	Sintetizar y decidir	Agrupar hallazgos, contar señales, decidir seguir, pivotar o matar la apuesta.
8	Proyecto: valida recommendations	El capstone: el pipeline completo de discovery, corrido de punta a punta sobre la apuesta de Mercado.

Fíjate en la progresión: este módulo 1 instala por qué vale la pena hacer todo esto — el argumento de costo que justifica el resto de la guía. Los módulos 2 y 3 te dan las herramientas para entender al usuario y mapear el problema. El módulo 4 convierte lo que aprendiste en un test diseñado con rigor. El módulo 5 te da los niveles de prototipo para correr ese test sin construir de más. El módulo 6 te protege de engañarte a ti mismo mientras interpretas lo que encontraste. El módulo 7 cierra el ciclo con una decisión. Y el módulo 8 corre todo, de punta a punta, sobre recommendations.

El mapa de este módulo

Dentro del módulo 1, ocho lecciones construyen el argumento de a poco:

Lección   Pregunta que contesta
────────  ──────────────────────────────────────────────────────
L1        (esta) ¿Dónde nos dejó la guía anterior, y qué promete esta?
L2        ¿Por qué construir es la forma más cara de aprender?
L3        ¿Qué diferencia hay entre discovery continuo y una fase de research?
L4        ¿Cuánto cuesta, en concreto, construir lo equivocado?
L5        ¿Qué compra exactamente el descubrimiento, si no construye nada?
L6        ¿El discovery frena al equipo, o corre junto a la entrega?
L7        ¿Qué NO es discovery, aunque se le parezca?
L8        Proyecto: compara el costo de dos caminos y decide qué descubrir esta semana

La lección 2 establece la tesis central con una comparación general de costos: leer datos existentes, hablar con usuarios, prototipar o construir — y por qué construir queda, sistemáticamente, hasta el final de esa lista. La lección 3 nombra el error de proceso más común: tratar el discovery como una fase única al inicio del proyecto (big-bang research) en vez de como un hábito semanal (discovery continuo). La lección 4 le pone número exacto al costo de construir sin validar, usando el propio risk=0.6 que la guía anterior calculó para recommendations. La lección 5 es el corazón del módulo: ejecuta el modelo timeToEvidence() que compara, con datos, cuánto cuesta y cuándo llega la evidencia por el camino de "construir y ver" contra el camino de "descubrir barato". La lección 6 responde la objeción más común contra el discovery — "esto nos hace más lentos" — mostrando que discovery y delivery corren en paralelo, no en secuencia. La lección 7 cierra con las formas en que un equipo puede creer que está haciendo discovery sin estarlo de verdad. Y la lección 8, el mini-proyecto, te pone a decidir, con el modelo ejecutado, qué descubrir esta semana sobre recommendations.

La frontera: qué NO entra en este módulo (ni en esta guía, todavía)

Esta guía tiene hermanas en el ecosistema de Product Engineering, y este módulo en particular tiene una frontera clara con la guía que la precede:

• Encontrar la apuesta, priorizarla, encontrar su suposición más riesgosa ya se hizo — es product-thinking-for-engineers-guide, el prerequisito de esta guía. Aquí se asume que ya tienes la apuesta (recommendations) y su suposición riesgosa (risk=0.6, impact=5); el trabajo de esta guía es validarla.
• Cómo entrevistar sin que la gente te mienta es el módulo 2 de esta misma guía. Aquí, en el módulo 1, vas a hablar de entrevistas y tests como conceptos, pero no vas a aprender la técnica todavía.
• El opportunity solution tree —mapear el problema completo antes de elegir una solución— es el módulo 3.
• Diseñar el test más barato que puede refutar una hipótesis, con un algoritmo que compara candidatos es el módulo 4. Este módulo 1 compara dos caminos generales (construir vs descubrir); el módulo 4 te da la herramienta para elegir entre muchos tests candidatos con rigor.
• Medir con estadística rigurosa —significancia, tamaño de muestra, A/B testing— es product-metrics-and-experimentation-guide. El discovery de esta guía es cualitativo y cuantitativo barato; el rigor estadístico completo es esa guía hermana.
• Construir la funcionalidad de verdad, una vez validada es el ecosistema Fullstack.

Dentro de este módulo 1 específicamente: vas a aprender el argumento de por qué vale la pena descubrir antes de construir, con el costo puesto en números. No vas a aprender todavía cómo ejecutar una entrevista, un fake door o un prototipo — eso empieza en el módulo 2.

Errores comunes

Pensar que "ya conocemos la suposición riesgosa" es lo mismo que "ya la validamos". Qué pasa: un equipo que hizo bien su tarea de product-thinking —encontró recommendations, calculó risk=0.6, impact=5, identificó la suposición correcta— se siente como si ya hubiera terminado el trabajo difícil, y pasa directo a construir. Por qué pasa: nombrar el riesgo se siente como haberlo resuelto; es un progreso real, pero parcial. Cómo detectarlo: en la reunión de planeación, la conversación sobre recommendations se centra en el diseño técnico del motor, sin ninguna mención de cómo se va a probar la suposición antes de construirlo. Cómo corregirlo: recuerda el estado exacto que viste en el ejemplo de hoy — tested: false, confidence: 0.3 — y trata ese estado como una tarea pendiente, no como un dato de fondo. Esta guía entera es esa tarea.

Asumir que "descubrir" significa "encuestar" o "preguntar qué opinan". Qué pasa: el equipo llama "discovery" a mandar una encuesta rápida preguntando si a los usuarios "les gustaría" ver recomendaciones, y trata la respuesta como evidencia suficiente. Por qué pasa: preguntar la opinión de alguien es fácil, rápido, y se siente como "hablar con usuarios" — el nombre correcto de la actividad, aunque el contenido esté vacío. Cómo detectarlo: la "evidencia" del equipo consiste enteramente en lo que la gente dijo que haría, nunca en lo que hizo. Cómo corregirlo: este error tiene nombre propio y una lección dedicada — la lección 7 de este módulo, y en profundidad el módulo 6 de la guía (la brecha say-do). Por ahora, basta con sospechar de cualquier "validación" que consista solo en preguntar qué opina la gente.

Tratar esta guía como una repetición de product-thinking-for-engineers. Qué pasa: alguien que ya hizo la guía anterior espera volver a ver RICE, MVP, o cómo encontrar la suposición riesgosa, y se desorienta cuando esta guía no repite ese contenido. Por qué pasa: las dos guías comparten el mismo caso (Mercado) y hablan de las mismas apuestas, lo que puede sentirse como territorio repetido. Cómo detectarlo: la pregunta "¿esto no lo vimos ya?" aparece seguido durante las primeras lecciones. Cómo corregirlo: la frontera de arriba es la respuesta permanente — esta guía asume el trabajo de la anterior como punto de partida y avanza desde ahí; no lo repite, lo continúa.

Ejercicios

Ejercicio 1 — Ubica el punto de partida. Sin volver a leer la guía anterior, responde de memoria: ¿cuál es la suposición más riesgosa de recommendations, cuál es su risk y su impact, y en qué número quedó topado el confidence de RICE mientras siga sin probarse?

Ver solución

La suposición más riesgosa es "los usuarios van a comprar más si ven recomendaciones personalizadas", con risk=0.6 e impact=5 (score=3.0, la más alta de las cuatro suposiciones que sostienen la apuesta). Mientras siga tested: false, el confidence de RICE queda topado en 0.3. Estos son, literal, los mismos cuatro números que abrieron esta lección — y son el punto de partida fijo de toda la guía: cada módulo que sigue trabaja para mover ese tested de false a true, con evidencia real.

Ejercicio 2 — Ubica el módulo correcto. El equipo de Mercado, mientras trabaja en recommendations, tiene tres preguntas nuevas. Para cada una, di qué módulo de esta guía (1 a 8) la resuelve:

• (a) "¿Cómo le pregunto a un usuario sobre su última compra sin que me diga lo que cree que quiero oír?"
• (b) "Tenemos tres tests candidatos para la suposición riesgosa — ¿cuál es el más barato que de verdad la puede refutar?"
• (c) "Ya corrimos los tests y tenemos diez notas de entrevistas — ¿cómo decidimos si esto es suficiente para seguir adelante?"

Ver solución

• (a) Módulo 2 — Hablar con usuarios. Es, literal, su definición: entrevistas que preguntan por comportamiento pasado, no por intenciones futuras, para evitar que la respuesta sea lo que el usuario cree que quieres escuchar.
• (b) Módulo 4 — Suposición e hipótesis. El test más barato que puede refutar una suposición, elegido entre varios candidatos, es exactamente el pickTest que enseña ese módulo.
• (c) Módulo 7 — Sintetizar y decidir. Agrupar notas de entrevistas, contar señales y decidir si alcanza para seguir, pivotar o matar la apuesta es el cierre del ciclo de discovery, y es el tema de ese módulo.

Ejercicio 3 — Explica la promesa con tus palabras. En dos o tres frases, y usando el caso de recommendations, explica qué significa "validar la apuesta con usuarios antes de construirla" — sin usar la palabra "discovery" ni "validar" en tu explicación.

Ver solución

Una respuesta razonable: "Antes de que el equipo pase semanas construyendo el motor completo de recomendaciones, hay una forma barata de averiguar si la idea central —que la gente compra más cuando ve productos sugeridos— es cierta. Consiste en conseguir evidencia real, con usuarios de verdad, gastando días en vez de meses, para saber si vale la pena construir la versión completa antes de comprometer ese tiempo." El punto del ejercicio no es memorizar el vocabulario técnico —eso viene con el resto de la guía—, sino confirmar que entiendes la idea de fondo sin necesitar las palabras exactas: gastar poco para saber temprano, en vez de gastar mucho para saber tarde.

Resumen y siguiente paso

En esta lección conectaste esta guía con la que la precede: la apuesta recommendations de Mercado quedó con su suposición más riesgosa nombrada (risk=0.6, impact=5) pero sin probar, y el confidence de RICE topado en 0.3 hasta que eso cambie. Conociste la promesa de esta guía —validar la apuesta con usuarios antes de construirla— y el mapa completo de sus ocho módulos, todos construidos alrededor de ese mismo caso. Y viste la analogía que va a acompañar el módulo entero: descubrir es probar el agua con el pie antes de tirarte de clavado.

Antes de avanzar deberías poder: recitar el estado exacto de la apuesta recommendations (suposición, risk, impact, confidence); ubicar, a grandes rasgos, qué módulo de esta guía resuelve qué tipo de pregunta; y explicar, con tus propias palabras, por qué "construir para saber" no es lo mismo que "descubrir para saber".

La lección 2 entra de lleno en el argumento central del módulo: ¿por qué construir es, en general, la forma más cara de aprender? Ahí vas a ver la primera comparación de costos —ejecutada, con números reales— entre las distintas formas que tiene un equipo de conseguir información antes de comprometerse a construir algo.

Recursos

• Teresa Torres, Continuous Discovery Habits — producttalk.org/continuous-discovery-habits. El libro que más influye en el vocabulario de esta guía: un hábito estructurado y sostenible de contacto semanal con usuarios. En inglés.
• Marty Cagan (Silicon Valley Product Group), "Discovery vs. Delivery" — svpg.com/discovery-vs-delivery. Por qué descubrir rápido con usuarios reales y construir con calidad no son objetivos en conflicto, sino dos tipos de trabajo que se necesitan mutuamente. En inglés.
• Melissa Perri, "The Build Trap" — melissaperri.com/blog/2014/08/05/the-build-trap. El artículo que nombra el patrón que esta guía existe para evitar: construir sin parar, sin la pausa de averiguar primero si vale la pena. En inglés.
• Jeff Patton, "Dual Track Development" — jpattonassociates.com/dual-track-development. La fuente original de la idea que vas a ver a fondo en la lección 6: discovery y delivery como dos tracks paralelos del mismo equipo, no dos fases separadas. En inglés.