¿Qué es un outcome?

Descripción

Ya tienes la mitad de la ecuación: un output es algo que tu equipo produjo y controla por completo. Esta lección define la otra mitad, la que de verdad decide si ese esfuerzo valió la pena. Un outcome es un cambio medible en el comportamiento de alguien, o en una métrica del negocio, que ocurre como consecuencia de lo que enviaste. No es "lo bien hecho que quedó el código" ni "lo mucho que le gustó al equipo el diseño": es un número que se movió, comparado contra un número anterior, y que sigue moviéndose más allá de lo que el ruido normal explicaría.

La definición corta que vas a usar el resto de la guía, tomada casi literal de Josh Seiden, el autor que popularizó el término: un outcome es un cambio en el comportamiento humano que impulsa un resultado de negocio. Fíjate en las tres piezas de esa frase, porque las tres son obligatorias: (1) hay un cambio — un antes y un después, no una foto fija; (2) el cambio es de comportamiento humano — alguien hace algo distinto a lo que hacía; (3) ese cambio impulsa un resultado de negocio — no es un cambio cualquiera, es uno que le importa a Mercado como empresa. Si falta cualquiera de las tres piezas, no tienes un outcome todavía; tienes, en el mejor de los casos, un output con una historia bonita alrededor.

Conexión con el módulo. En la lección 2 viste que un output —"enviamos el carrusel de recomendaciones"— no carga, por definición, ningún dato sobre resultado. Esta lección le da nombre y forma a ese dato que faltaba: el outcome. Con las dos definiciones completas, la lección 4 va a cruzarlas sobre los 12 envíos de Mercado y contar, por primera vez con números reales, cuántos de esos envíos produjeron un outcome de verdad y cuántos se quedaron en output puro. Y la lección 7 va a usar esta misma idea —un cambio con un antes y un después— para empezar a preguntarse por qué un feature debería mover una métrica, no solo si la movió.

Una analogía: los invitados que se fueron satisfechos

Volvamos a la cena. Ya viste que "serví cinco platos" es un output: describe tu esfuerzo, no dice nada del resultado. El outcome de esa misma cena es otra frase, muy distinta en su naturaleza: "los invitados se fueron satisfechos, y tres de ellos ya preguntaron cuándo es la próxima".

Fíjate en las diferencias, porque son exactamente las tres piezas de la definición formal. Primero, hay un cambio: antes de la cena, esos invitados no tenían ninguna opinión formada sobre volver a tu casa; después, tres de ellos activamente quieren volver. Segundo, es un cambio de comportamiento: no es que "se sintieron bien" en abstracto —eso es difícil de verificar—, es que hicieron algo: preguntaron por la próxima fecha. Tercero, ese cambio te importa como anfitrión: es la señal que de verdad querías cuando organizaste la cena; nadie organiza una cena para poder decir "serví cinco platos", la organiza para que la gente la pase bien y quiera volver.

Y aquí está el matiz que hace útil la analogía: si le preguntas a un invitado "¿la pasaste bien?" y te dice "sí, estuvo lindo" por cortesía, eso no es todavía un outcome confiable — es una opinión, fácil de inflar, difícil de verificar. Pero si tres personas, sin que se los pidieras, preguntan espontáneamente cuándo es la próxima cena, eso es un cambio de comportamiento genuino, algo que hicieron, no algo que dijeron por quedar bien. La distinción entre "una opinión declarada" y "un comportamiento real" es, casi exactamente, la distinción entre una métrica de vanidad y un outcome de verdad — un tema que la guía de métricas retoma a fondo; aquí basta con que la sientas.

Ejemplo trabajado: ¿el número se movió, o es solo ruido?

Un outcome no es cualquier cambio de número: cualquier métrica de negocio tiene variación natural de un día para otro, de una semana para otra, sin que nadie haya hecho nada. Para que un cambio cuente como outcome, tiene que moverse más allá de ese ruido normal. Vamos a modelar esa idea con una función outcomeDelta, y a correrla sobre dos de los envíos de Mercado: uno que se sospecha que sí movió el checkout, y uno que se sospecha que no.

// outcomeDelta(): compara una metrica antes/despues de un envio y dice si
// realmente se movio, mas alla del ruido normal de un dato de negocio.
function outcomeDelta({ metric, before, after, noiseThreshold }) {
  const deltaAbs = +(after - before).toFixed(2);
  const moved = Math.abs(deltaAbs) > noiseThreshold;
  return { metric, before, after, deltaAbs, moved };
}

const savedPaymentMethods = outcomeDelta({
  metric: 'checkout conversion',
  before: 22.4,
  after: 24.1,
  noiseThreshold: 1,
});

const recommendationsCarousel = outcomeDelta({
  metric: 'checkout conversion',
  before: 22.4,
  after: 22.5,
  noiseThreshold: 1,
});

function printOutcome(name, r) {
  console.log(
    name + ' -- ' + r.metric + ': ' + r.before + '% -> ' + r.after + '% (delta ' +
    (r.deltaAbs >= 0 ? '+' : '') + r.deltaAbs + ' pts) => ' +
    (r.moved ? 'OUTCOME (se movio)' : 'sin outcome (ruido)')
  );
}

printOutcome('Saved payment methods', savedPaymentMethods);
printOutcome('Product recommendations carousel', recommendationsCarousel);

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

Saved payment methods -- checkout conversion: 22.4% -> 24.1% (delta +1.7 pts) => OUTCOME (se movio)
Product recommendations carousel -- checkout conversion: 22.4% -> 22.5% (delta +0.1 pts) => sin outcome (ruido)

Las dos features se enviaron. Las dos son, sin dudarlo, outputs. Pero al mirar la misma métrica —checkout conversion, el porcentaje de visitas que terminan en una compra— con un antes y un después, el resultado se separa con claridad. Saved payment methods movió la conversión 1.7 puntos porcentuales, por encima del umbral de ruido que definimos (1 punto): eso es un outcome. Product recommendations carousel apenas movió 0.1 puntos, dentro del rango que cualquier semana normal produce sin que nadie haya cambiado nada: eso, con esta evidencia, no es un outcome — es indistinguible de no haber hecho nada.

Fíjate en el parámetro noiseThreshold: no es un detalle decorativo, es la pieza que evita el error más común de esta lección — confundir cualquier movimiento con una señal real. Ninguna métrica de negocio es una línea perfectamente plana cuando no pasa nada; sube y baja un poco todos los días por razones que no tienen que ver con tu feature (el día de la semana, una promoción de otro equipo, el clima). El umbral es la forma honesta de decir "necesito que el cambio sea más grande que ese vaivén normal antes de llamarlo outcome". (Cómo se elige ese umbral con rigor estadístico —significancia, intervalos de confianza— es exactamente el terreno de product-metrics-and-experimentation-guide; aquí, el punto es que el umbral existe y que sin él, cualquier ruido se puede disfrazar de éxito.)

Qué hace que algo sea, de verdad, un outcome

Repasa las tres piezas de la definición con el ejemplo de Saved payment methods, porque las tres están presentes y por eso es un outcome legítimo:

1. Hay un cambio real     ->  22.4% pasó a 24.1%, y no es ruido (supera el umbral).
2. Es comportamiento      ->  mas gente, de hecho, termino de pagar (no una opinion).
3. Le importa al negocio  ->  checkout conversion esta directamente ligado al GMV.

Y compáralo con una frase que suena a outcome pero no lo es: "el equipo quedó muy conforme con el nuevo checkout". Ahí no hay una métrica, no hay un antes y un después, y el "comportamiento" que cambió es el del equipo, no el de un usuario ni el del negocio. Le falta, como mínimo, la pieza 2 y la pieza 3. Esa confusión —una frase que tiene la forma de un logro pero no las tres piezas— es tan común que le vamos a dedicar la lección 6 completa: cómo distinguir un buen outcome de uno vago o disfrazado.

Una aclaración importante antes de seguir: esta lección te enseña a reconocer que un cambio superó el ruido, con un umbral simple para que la idea sea tangible. No te enseña a decidir con rigor estadístico si esa diferencia es significativa —eso exige pruebas de hipótesis, tamaños de muestra, intervalos de confianza, y es exactamente lo que cubre product-metrics-and-experimentation-guide. Aquí el objetivo es más modesto y más urgente: que salgas de la costumbre de mirar solo si algo se envió, y empieces a preguntar siempre "¿y la métrica, se movió?".

Errores comunes

Confundir un output vestido de métrica con un outcome real. Qué pasa: alguien dice "la página tuvo mucho impacto" o "lanzamos la página y le fue muy bien", pero al pedir el número, lo que hay es una opinión o, en el mejor caso, una métrica de actividad que no estaba ahí antes porque la página tampoco estaba ahí antes —así que "tuvo tráfico" no es comparable con nada—. Por qué pasa: una frase con forma de logro se siente como un logro, aunque no tenga un antes y un después reales detrás. Cómo detectarlo: pregúntate "¿comparado con qué?" — si no hay una línea base previa al envío, no puedes calcular un deltaAbs, y sin delta no hay outcome, solo una medición aislada. Cómo corregirlo: todo outcome necesita una comparación explícita: la métrica antes del envío, la métrica después, y el delta entre las dos. Si no puedes completar esas tres casillas, todavía no tienes un outcome — tienes, como mucho, una promesa pendiente de comprobar.

Llamar outcome a cualquier movimiento, sin mirar el ruido. Qué pasa: la métrica sube un poquito la semana después del lanzamiento, y el equipo lo celebra como si la feature lo hubiera causado, sin preguntarse si ese mismo vaivén ocurre normalmente sin ninguna razón. Por qué pasa: cualquier subida se siente como una confirmación, y nadie quiere ser quien apague el entusiasmo. Cómo detectarlo: lo viste ejecutado — recommendationsCarousel subió 0.1 puntos, un movimiento real, y aun así el modelo lo marcó sin outcome (ruido), porque no superó el umbral. Cómo corregirlo: exige siempre un umbral, aunque sea uno simple como el de este ejemplo. "Subió" no es suficiente; "subió más de lo que sube normalmente sin hacer nada" sí lo es.

Medir la métrica equivocada para la pregunta que en realidad te importa. Qué pasa: se declara un outcome sobre una métrica fácil de mover pero que no está conectada con el valor real —por ejemplo, "subieron las visitas a la página del carrito"— sin verificar que esa métrica se relacione con lo que de verdad le importa al negocio (el GMV, en el caso de Mercado). Por qué pasa: algunas métricas son más fáciles de mover que otras, y es tentador reportar la que sí subió, aunque no sea la que importa. Cómo detectarlo: la métrica que reportas cambió, pero cuando alguien pregunta "¿y eso qué efecto tuvo en el GMV?", nadie tiene una respuesta clara. Cómo corregirlo: antes de declarar victoria, verifica que la métrica que elegiste esté genuinamente conectada con el resultado de negocio que le importa a Mercado — la relación entre "qué mides" y "qué te importa" es, precisamente, el criterio central de la lección 6.

Ejercicios

Ejercicio 1 — Completa las tres piezas. Para la afirmación "el dashboard de vendedores está muy pulido visualmente, el equipo de diseño está orgulloso", identifica cuál de las tres piezas de la definición de outcome (cambio con antes/después, comportamiento humano, resultado de negocio) están presentes y cuáles faltan.

Ver solución

Ninguna de las tres piezas está presente. No hay un cambio con antes y después (no se compara nada, es una foto fija de cómo se ve hoy). No hay comportamiento humano que haya cambiado (el orgullo del equipo de diseño es una opinión interna, no algo que un vendedor haya hecho distinto). Y no hay conexión declarada con un resultado de negocio (¿el dashboard pulido llevó a que los vendedores actualicen más su inventario? ¿A que vendan más? No se dice). Es una frase perfectamente válida sobre la calidad del trabajo, pero no es, de ninguna forma, un outcome. Para convertirla en uno, haría falta algo como: "desde el rediseño, el 25% más de vendedores actualiza su inventario semanalmente" — ahí sí hay las tres piezas.

Ejercicio 2 — Calcula el veredicto. Usa outcomeDelta mentalmente (o cópiala y córrela) para este caso: la métrica seller retention (retención de vendedores activos) estaba en 68% antes del lanzamiento del dashboard de analítica, y 69.2% después. El equipo definió noiseThreshold: 1.5 para esta métrica en particular (porque históricamente varía bastante mes a mes). ¿Cuál es el veredicto?

Ver solución

deltaAbs = 69.2 - 68 = 1.2. Como Math.abs(1.2) no es mayor que 1.5, el veredicto es sin outcome (ruido), aunque el número sí subió. Este ejercicio muestra algo importante que el módulo repite a propósito: "subió" no es lo mismo que "es un outcome". El umbral de ruido no es arbitrario decorativo — cambia el veredicto final, y por eso el umbral correcto para cada métrica (más estrecho para una métrica estable, más ancho para una que varía mucho de por sí) es una decisión real, no un número que se pone por poner. Cómo elegir ese umbral con rigor es, otra vez, terreno de la guía de métricas; aquí lo que importa es que nunca declares un outcome sin haberte hecho la pregunta.

Ejercicio 3 — Diseña el "antes" que falta. El equipo de Mercado quiere declarar un outcome para "One-click reorder button" (comprar de nuevo algo que ya compraste antes, con un clic). Proponen la métrica repeat purchase rate (porcentaje de compras que son de un producto ya comprado antes). ¿Qué necesitan tener, como mínimo, ANTES de poder correr outcomeDelta sobre este caso? Lista los datos concretos que faltan.

Ver solución

Necesitan, como mínimo: (1) el valor de repeat purchase rate antes de lanzar el botón (la línea base — sin esto, no hay before posible); (2) el valor de esa misma métrica después, medido con suficiente tiempo transcurrido para que el comportamiento se estabilice (lanzar y medir al día siguiente probablemente capture solo curiosidad inicial, no un cambio de hábito real); y (3) un noiseThreshold definido antes de mirar el resultado — decidido con la variación histórica de esa métrica, no ajustado después de ver el número para que "dé outcome". Ese último punto es sutil pero importante: si eliges el umbral después de ver el resultado, puedes inconscientemente ajustarlo para que confirme lo que quieres ver. El umbral, como los targets de un outcome, se fija antes de mirar los datos.

Resumen y siguiente paso

En esta lección definiste outcome con las tres piezas que lo hacen real: un cambio con un antes y un después, un comportamiento humano que se modificó, y una conexión con un resultado que le importa al negocio. Viste, ejecutado, que "subió un poco" no es lo mismo que "es un outcome" — hace falta comparar contra un umbral de ruido, y outcomeDelta mostró la diferencia exacta entre Saved payment methods (+1.7 puntos, outcome real) y Product recommendations carousel (+0.1 puntos, indistinguible de ruido). Y con la cena, sentiste la diferencia entre una opinión declarada ("estuvo lindo") y un comportamiento real (preguntar cuándo es la próxima) — el mismo filtro que separa una métrica de vanidad de un outcome de verdad.

Antes de avanzar deberías poder: dar la definición de outcome con sus tres piezas; explicar por qué un número que sube no siempre es un outcome; y distinguir, en una frase cualquiera, si describe un output, un outcome, o ninguno de los dos.

Con las dos definiciones completas —output en la lección 2, outcome en esta—, la lección 4 hace lo que este módulo prometió desde la lección 1: cruzar las dos sobre los 12 envíos completos de Mercado y ponerle número exacto al build trap. Vas a ver cuántos de esos envíos fueron output puro, y vas a entender, con datos, por qué el GMV casi no se movió en todo el trimestre.

Recursos

• Josh Seiden, "Outcomes Over Output" — outcomesoveroutput.com. La fuente de la definición usada en esta lección: "un cambio en el comportamiento humano que impulsa un resultado de negocio". En inglés.
• Amplitude, "What Makes a Good vs Bad North Star Metric" — amplitude.com/blog/good-bad-north-star-metric. Profundiza en cómo elegir una métrica que de verdad refleje valor, no solo actividad — el puente natural hacia la lección 6 de este módulo. En inglés.
• Marty Cagan (Silicon Valley Product Group), "Outcomes Are Hard" — svpg.com/outcomes-are-hard. Por qué medir outcomes de verdad —y no solo output— exige un cambio genuino de disciplina en el equipo. En inglés.