Presentación de la guía: de "el A/B ganó" a lanzarlo seguro, con reversa, e iterar

Por qué existe esta guía

Ya sabes decidir qué construir con criterio. Ya sabes validarlo barato antes de escribir la primera línea de producción. Y ya sabes medir el resultado real con rigor estadístico: un lift, un p-value, un intervalo de confianza que te dicen si un cambio funcionó de verdad o si fue puro ruido. Esas son tres guías completas del ecosistema de Product Engineering, y si llegaste hasta aquí, las diste por cerradas.

Pero un experimento ganador no es, todavía, un producto lanzado. Entre "el A/B dijo que variant gana" y "toda la base de usuarios está usando variant" hay una decisión que ninguna de las tres guías anteriores tomó por ti — y es una decisión con su propio riesgo, independiente de si el experimento fue válido. Puedes tener la estadística perfecta, el p-value más limpio del trimestre, y aun así lanzar mal: exponer a un millón de usuarios de golpe a un cambio que solo se probó, con cuidado, sobre unos miles. Esa distancia final —entre saber que algo funciona y lanzarlo sin romper nada en el camino— es exactamente lo que esta guía cierra.

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

De "el A/B ganó" a lanzarlo seguro, con reversa, e iterar sobre el resultado.

Vas a aprender a desacoplar deploy de release con feature flags —el código puede estar en producción sin que ningún usuario lo vea todavía—, a diseñar un rollout gradual —canary 1% → 10% → 50% → 100%, cada etapa exponiendo a más gente solo después de que la anterior se sostuvo—, a monitorear el lanzamiento en vivo vigilando los guardrails mientras sube el porcentaje, a tomar la decisión de rollback cuando algo se rompe —revertir rápido vs. arreglar hacia adelante—, a escribir un postmortem blameless que investiga el sistema y no busca culpables, a cerrar el loop ship → measure → learn iterando sobre lo que aprendiste, y a aplicar todo eso a la capa moderna de enviar modelos de IA de forma segura con shadow mode. Al terminar, puedes tomar cualquier cambio validado y medido, y llevarlo a producción completa sin que el radio de impacto de un error te sorprenda.

El caso que nos acompaña: lanzar las recomendaciones de Mercado

Toda la guía usa el mismo caso que las tres guías anteriores del ecosistema: Mercado, el marketplace. La guía de métricas cerró el experimento de recommendations —el carrusel de productos recomendados en la página de producto— con un resultado que parece, a primera lectura, una victoria sin matices:

// Donde nos dejo la guia de metricas: el resultado del A/B test de recommendations.
// GANO en la metrica primaria, con significancia estadistica real. PERO rompio
// un guardrail que nadie puede ignorar solo porque el primario gano.
const experimentResult = {
  feature: 'recommendations',
  primaryMetric: { name: 'checkoutConversion', lift: 0.1875, pValue: 0.0114, significant: true },
  secondaryMetric: { name: 'retentionD30', control: 0.246, variant: 0.308 },
  guardrail: { name: 'p95Latency', before: 650, after: 910, ceiling: 800, broken: true },
};

console.log('=== El resultado que esta guia recibe de product-metrics ===\n');
console.log('checkoutConversion: lift +' + (experimentResult.primaryMetric.lift * 100) + '%, p=' +
  experimentResult.primaryMetric.pValue + ', significativo=' + experimentResult.primaryMetric.significant);
console.log('retentionD30: control ' + (experimentResult.secondaryMetric.control * 100) + '% vs variant ' +
  (experimentResult.secondaryMetric.variant * 100) + '%');
console.log('guardrail p95Latency: ' + experimentResult.guardrail.before + 'ms -> ' + experimentResult.guardrail.after +
  'ms (techo ' + experimentResult.guardrail.ceiling + 'ms) -- ROTO=' + experimentResult.guardrail.broken);

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

=== El resultado que esta guia recibe de product-metrics ===

checkoutConversion: lift +18.75%, p=0.0114, significativo=true
retentionD30: control 24.6% vs variant 30.8%
guardrail p95Latency: 650ms -> 910ms (techo 800ms) -- ROTO=true

Fíjate en la tensión que este número deja sobre la mesa: recommendations gana en conversión (+18.75%, estadísticamente significativo), gana en retención (30.8% contra 24.6%) — y al mismo tiempo rompe el guardrail de latencia que la propia guía de métricas definió como línea que no se debía cruzar. p95 pasó de 650ms a 910ms, muy por encima del techo de 800ms. Ningún equipo serio discute ya si recommendations "funciona" — la estadística contestó eso—. Lo que queda abierto, y es exactamente donde arranca esta guía, es una pregunta distinta: ¿cómo lanzas un ganador que rompe un guardrail sin exponer a toda tu base de usuarios a esa regresión de golpe?

Una analogía: el piloto que aprobó el examen, antes del primer vuelo con pasajeros

Un piloto que acaba de aprobar su examen de vuelo —simulador perfecto, instructor satisfecho, la licencia en la mano— no sube esa misma tarde a un avión con 300 pasajeros y despega directo a un vuelo transatlántico. Antes hay vuelos de instrucción supervisados, después rutas cortas con un copiloto experimentado al lado, después rutas más largas, y solo con todo ese historial acumulado llega, eventualmente, al vuelo largo sin supervisión. El examen aprobado —el "gana el A/B"— es una condición necesaria. No es, por sí sola, el permiso para exponer a 300 personas de una sola vez a un piloto que nunca voló en producción.

Esta guía es exactamente esa escalera entre el examen aprobado y el vuelo completo: cómo se sube de a poco, qué se vigila en cada tramo, y qué se hace si algo sale mal en el camino, en vez de descubrirlo con los 300 pasajeros ya arriba.

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

Ocho módulos, todos sobre el mismo lanzamiento de recommendations con su guardrail de latencia roto, cada uno resolviendo la siguiente pieza de la cadena entre "ganó el experimento" y "está lanzado, monitoreado, y aprendiendo de sí mismo":

#	Módulo	De qué se trata
1	De experimento a lanzamiento (estás aquí)	Por qué enviar es su propio riesgo: "ganó el A/B" no es "préndelo para todos"; el lanzamiento como decisión con reversa, no como interruptor; el radio de impacto de un error.
2	Feature flags	Desacoplar deploy de release: el código vive en producción, apagado, hasta que decides encenderlo. Kill switches. isEnabled ejecutado.
3	Rollout gradual	Canary 1% → 10% → 50% → 100%, con criterios explícitos para avanzar de una etapa a la siguiente. rolloutPlan ejecutado.
4	Monitorear el lanzamiento	Vigilar los guardrails durante la subida, no solo al final; cuándo frenar antes de escalar más.
5	Rollback e incident response	Revertir rápido vs. arreglar hacia adelante; el runbook; severidad de incidentes. rollbackDecision ejecutado.
6	Postmortems e iteración	El postmortem blameless (sin culpar personas) y el loop ship → measure → learn sobre el resultado real.
7	Enviar IA de forma segura	Migrar modelos con shadow mode y canary; privacidad práctica al lanzar. shadowCompare ejecutado.
8	Proyecto: lanzar recomendaciones de Mercado	El capstone: flag, rollout, monitoreo, rollback/postmortem, y migración con shadow mode, todo sobre el caso real de esta guía. Cierra el ecosistema completo.

Fíjate en la progresión: este módulo 1 instala el porqué — el marco mental de que lanzar es arriesgar, y que ese riesgo se puede contener — antes de tocar una sola herramienta concreta. Los módulos 2 y 3 son el cómo técnico de exponer gradualmente (flags, rollout). El módulo 4 es vigilar mientras subes. Los módulos 5 y 6 son qué hacer cuando algo sale mal, y cómo aprender de eso sin buscar culpables. El módulo 7 aplica todo el marco a la capa moderna de IA. El módulo 8 junta las siete piezas sobre recommendations.

El mapa de este módulo

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

Lección   Pregunta que contesta
────────  ──────────────────────────────────────────────────────────
L1        (esta) ¿Dónde nos dejó product-metrics, y qué falta resolver?
L2        ¿Por qué "ganó el A/B" no es lo mismo que "está listo para todos"?
L3        ¿Por qué lanzar es una decisión de riesgo, y no un interruptor?
L4        ¿Cómo se mide el radio de impacto de un error, en números?
L5        ¿Por qué "deployado" y "lanzado" son dos momentos distintos?
L6        ¿Qué tienen en común todos los lanzamientos cuidadosos?
L7        ¿Cómo se lanza, en concreto, un ganador que rompe un guardrail?
L8        Proyecto: decide el enfoque de lanzamiento de recommendations

La lección 2 nombra el error central que este módulo entero existe para prevenir: tratar la significancia estadística como si fuera, por sí sola, luz verde para exponer al 100% de los usuarios. La lección 3 reformula el lanzamiento como una decisión de riesgo con dos ejes —qué tan grave si sale mal, qué tan fácil es volver atrás— en vez de un botón de encendido. La lección 4 pone número al radio de impacto: cuántas personas reales quedan expuestas a una regresión conocida, según qué fracción de la base recibe el cambio primero, ejecutado en Node sobre el caso de Mercado. La lección 5 separa dos momentos que el lenguaje cotidiano confunde —el código está en producción; eso no significa que los usuarios ya lo vean—, sin enseñar todavía el mecanismo técnico (eso es el módulo 2). La lección 6 sintetiza qué comparten todos los lanzamientos cuidadosos, sin importar la herramienta específica. Y la lección 7 cierra el módulo aplicando todo el marco al caso concreto que arrastra esta guía: cómo se piensa el lanzamiento de un ganador que rompe un guardrail, antes de que el módulo 2 te dé la primera herramienta técnica para ejecutarlo.

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

Esta guía tiene hermanas en el ecosistema de Product Engineering, y una hermana en el ecosistema Fullstack. Saber la frontera de entrada te ahorra confusión más adelante:

• Decidir qué construir, priorizar, dimensionar el roadmap es product-thinking-for-engineers-guide. Aquí se asume que ya se decidió construir recommendations.
• Validar la apuesta barato con usuarios antes de construir (fake door, prototipos) es product-discovery-and-prototyping-guide. Aquí el motor ya está construido y ya se corrió el experimento.
• Diseñar y correr el A/B test, calcular su significancia estadística es product-metrics-and-experimentation-guide. Aquí se usa el resultado —significativo, con guardrail roto— sin recalcular la estadística.
• La infraestructura de deploy (pipeline CI/CD, build de producción, deploy atómico a nivel infraestructura) es fullstack-performance-and-deployment-guide, en el ecosistema Fullstack. Esa guía cubre cómo el código llega a los servidores; esta guía cubre el rollout de producto de una feature ya deployada: qué porcentaje de usuarios la ve, qué guardrails se vigilan, cuándo se revierte a nivel feature. Vas a ver "rollback" en las dos guías, en capas distintas.
• Ética y gobernanza de IA a fondo queda fuera; el módulo 7 toca lo práctico —migrar un modelo con shadow mode, privacidad de datos al lanzar— que un ingeniero de producto necesita, no un curso completo de ética de IA.

Dentro de este módulo 1 específicamente: vas a instalar el marco mental del lanzamiento como riesgo. No vas a ver todavía cómo se implementa un feature flag (módulo 2), ni cómo se diseña la rampa exacta de un rollout (módulo 3), ni cómo se vigila un dashboard en vivo (módulo 4), ni cómo se decide un rollback (módulo 5). Este módulo contesta por qué esas herramientas existen, antes de que las uses.

Errores comunes

Tratar el resultado de esta guía como una continuación más de la estadística de product-metrics. Qué pasa: alguien llega a esta guía esperando más fórmulas de significancia, más cálculos de p-value, y se sorprende cuando la primera lección habla de radio de impacto y no de estadística. Por qué pasa: "el experimento ganó" se siente como el final de la historia, y cuesta ver que lanzar tiene un riesgo propio, independiente de si la estadística fue correcta. Cómo detectarlo: la pregunta que alguien hace es "¿pero no era que ya sabíamos que funciona?" — sí, y ese "ya sabíamos que funciona" es exactamente el punto de partida de esta guía, no su conclusión. Cómo corregirlo: la guía de métricas contestó si el efecto es real; esta guía contesta cómo exponer a la gente a ese efecto real sin que el camino hacia el 100% sea, en sí mismo, un riesgo nuevo.

Asumir que un guardrail roto invalida el resultado del experimento y hay que empezar de cero. Qué pasa: al ver que p95Latency rompió su techo, alguien concluye que hay que descartar recommendations por completo y volver a discovery. Por qué pasa: "algo se rompió" suena a fracaso total, y es más simple pensar en blanco y negro que en un lanzamiento que necesita cuidado extra. Cómo detectarlo: la conversación salta directo de "el guardrail se rompió" a "cancelemos todo", sin pasar por "¿cómo lo lanzamos de forma que el guardrail roto no lastime a nadie mientras lo arreglamos?". Cómo corregirlo: un guardrail roto no cancela un ganador estadísticamente significativo — cambia cómo lo lanzas. Esa es, literalmente, la lección 7 de este módulo y el hilo de las siete lecciones de tema que siguen en esta guía.

Confundir "leí el módulo 1" con "ya sé lanzar". Qué pasa: alguien termina este módulo, entiende el marco mental, y asume que ya puede lanzar recommendations a producción sin haber tocado feature flags, rollout gradual, monitoreo ni rollback. Por qué pasa: el marco mental se siente completo porque explica por qué — pero el cómo técnico todavía no llegó. Cómo detectarlo: si te preguntan "¿y con qué herramienta apagas recommendations si algo sale mal a las 3am?", y no tienes respuesta concreta, todavía te falta el módulo 2 (feature flags) y el módulo 5 (rollback). Cómo corregirlo: este módulo te da el marco de decisión; los módulos 2 a 7 te dan las herramientas para ejecutarlo. Se necesitan los dos.

Ejercicios

Ejercicio 1 — ¿Quién contesta esta pregunta? Para cada pregunta, di qué guía del ecosistema de Product Engineering la contesta:

• (a) "¿El lift en conversión de recommendations es real, o podría ser azar?"
• (b) "¿Vale la pena construir el motor de recomendaciones completo, comparado con las otras apuestas del backlog?"
• (c) "El A/B ganó, pero rompe la latencia. ¿Cómo lo lanzo sin que el guardrail roto le pegue a toda la base de usuarios de golpe?"

Ver solución

• (a) product-metrics-and-experimentation-guide — la significancia estadística (p-value, intervalo de confianza) es su territorio.
• (b) product-thinking-for-engineers-guide — priorizar y dimensionar apuestas contra el resto del backlog.
• (c) Esta guía, shipping-and-iterating-products-guide — específicamente el módulo 1 instala el marco, y los módulos 2 a 5 dan las herramientas concretas (flags, rollout, monitoreo, rollback).

La regla para orientarte: si la pregunta es sobre si el efecto es real, es métricas. Si es sobre elegir qué construir, es pensamiento de producto. Si es sobre cómo llevar un resultado ya validado a toda la base sin romper nada en el camino, es esta guía.

Ejercicio 2 — Ubica el módulo correcto. El equipo de Mercado tiene tres preguntas nuevas sobre el lanzamiento de recommendations. Para cada una, di qué módulo de esta guía (2 al 7) la resuelve:

• (a) "¿Cómo apagamos recommendations instantáneamente, sin un nuevo deploy, si algo se pone mal a mitad de la noche?"
• (b) "Llevamos dos días en 10% de rollout y el guardrail sigue roto. ¿Seguimos subiendo o frenamos?"
• (c) "Ya decidimos revertir. ¿Cómo escribimos el reporte del incidente sin que se sienta una cacería de culpables?"

Ver solución

• (a) Módulo 2 — Feature flags. El kill switch —apagar sin re-deploy— es exactamente su definición.
• (b) Módulo 4 — Monitorear el lanzamiento. Decidir si avanzar o frenar según el estado de los guardrails durante la subida es su territorio.
• (c) Módulo 6 — Postmortems e iteración. El postmortem blameless, con timeline y factores contribuyentes en vez de nombres señalados, se enseña ahí.

Ejercicio 3 — Predicción con criterio. Sin haber leído todavía la lección 4, piensa en dos formas de lanzar recommendations a Mercado: "encenderlo para el 100% de los usuarios esta misma tarde" y "encenderlo primero para el 1% de los usuarios, y revisar el guardrail antes de seguir". Dado que ya sabes que el guardrail de latencia está roto (p95 910ms, techo 800ms), ¿cuál de las dos formas te parece que contiene mejor el daño de esa regresión conocida, y por qué? No hace falta ningún cálculo todavía; hace falta el argumento.

Ver solución

"Encenderlo primero para el 1%" contiene mejor el daño. La razón, sin necesitar todavía ninguna fórmula: la regresión de latencia ya es un hecho conocido, no una posibilidad — cualquier usuario expuesto a variant va a experimentar, en algún grado, esa latencia más alta. Si expones al 100% de golpe, expones a toda la base a una regresión que ya sabes que existe, antes de haber verificado nada más en producción real. Si expones al 1% primero, sigues exponiendo gente a la misma regresión —no la eliminas—, pero limitas a cuántas personas les toca mientras decides qué hacer con el guardrail roto. El argumento no depende todavía de conocer el vocabulario formal de "radio de impacto" —que llega en la lección 4—: alcanza con notar que una de las dos opciones apuesta el 100% de la base a un problema ya conocido, y la otra apuesta solo una fracción.

Resumen y siguiente paso

En esta lección instalaste la promesa de toda la guía —de "el A/B ganó" a lanzarlo seguro, con reversa, e iterar— y conociste el caso que la acompaña: recommendations, el ganador estadísticamente significativo (+18.75% en conversión, p=0.0114) que además rompe el guardrail de latencia que la guía de métricas dejó definido (p95 910ms, techo 800ms). Viste el mapa completo de los ocho módulos de la guía y las ocho lecciones de este módulo, y trazaste la frontera con las guías hermanas: aquí no se recalcula si el efecto es real —eso ya pasó—; aquí se decide cómo exponer a la gente a ese efecto real sin que el camino hacia el 100% sea, en sí mismo, un riesgo nuevo.

Antes de avanzar deberías poder: explicar con tus propias palabras por qué "ganó el experimento" y "está listo para exponer al 100%" son dos preguntas distintas; describir, sin fórmulas todavía, por qué exponer gradualmente contiene mejor un daño conocido que exponer de golpe; y ubicar, a grandes rasgos, qué módulo de esta guía resuelve qué tipo de pregunta sobre el lanzamiento de recommendations.

La lección 2 baja al primer concepto del marco: ¿por qué "ganó el A/B" no es lo mismo que "préndelo para todos"? Vas a ver, con el propio caso de Mercado, exactamente qué información nueva aparece entre el momento en que termina el experimento y el momento en que el 100% de la base está usando la feature — y por qué esa información nueva es la que justifica toda esta guía.

Recursos

• Google SRE Workbook, Capítulo 16, "Canarying Releases" — sre.google/workbook/canarying-releases. El capítulo de referencia sobre por qué un cambio se prueba primero en una porción pequeña de producción antes de exponerlo a todos; la base conceptual de los módulos 3 y 4 de esta guía. En inglés.
• Pete Hodgson (con Martin Fowler), "Feature Toggles (aka Feature Flags)" — martinfowler.com/articles/feature-toggles.html. El artículo de referencia sobre feature flags como mecanismo para separar el despliegue del código de su exposición a usuarios; desarrollado a fondo en el módulo 2. En inglés.
• Charity Majors, "Deploys Are the WRONG Way to Change User Experience" — honeycomb.io/blog/deploys-wrong-way-change-user-experience. El argumento completo sobre por qué "deployado" y "lanzado" son dos momentos distintos, que la lección 5 de este módulo introduce. En inglés.
• LaunchDarkly, "What Is Progressive Delivery All About?" — launchdarkly.com/blog/what-is-progressive-delivery-all-about. Una introducción práctica al rollout gradual como práctica de la industria, que conecta directamente con el módulo 3 de esta guía. En inglés.