¿Qué hace que un outcome sea bueno?

Descripción

Ya sabes que un outcome es un cambio medible en el comportamiento de alguien que le importa al negocio, y en la lección 5 aceptaste que reconocerlo es también trabajo tuyo. Falta un paso: no toda frase que suena a outcome lo es de verdad. "Mejorar la experiencia del usuario" tiene la forma de una meta importante, pero no dice nada que se pueda auditar seis semanas después. Esta lección te da un criterio concreto —tres preguntas, no una intuición— para separar un buen outcome de uno vago, disfrazado, o simplemente inútil como guía de trabajo.

Un buen outcome tiene que pasar tres pruebas al mismo tiempo: nombra una métrica concreta (no "la experiencia", sino checkout conversion); declara una dirección y una magnitud de cambio (no "mejorar", sino "subir de 22% a 26%"); y se conecta con un valor real para el usuario o el negocio, no solo con una actividad interna del equipo. Si a una propuesta le falta cualquiera de las tres, todavía no es un outcome accionable — es, en el mejor de los casos, una buena intención esperando que alguien la convierta en algo medible.

Conexión con el módulo. En la lección 3 definiste qué es un outcome en general; aquí afinas la puntería para reconocer los buenos entre los que parecen serlo. Esto importa especialmente después de la lección 4: el equipo de Mercado no falló por falta de intención — probablemente varios de los 10 ítems de output puro tenían, en algún documento, una frase que sonaba a outcome ("mejorar la conversión con recomendaciones"). El problema es que esa frase nunca pasó las tres pruebas de esta lección, y por eso nadie pudo auditarla después. La lección 7 sigue este hilo: incluso un buen outcome, bien definido, necesita además un mecanismo declarado que explique por qué el feature debería moverlo.

Una analogía: el termómetro y las pastillas contadas

Imagina un médico que, al final de cada visita, reporta con orgullo: "le di tres pastillas al paciente". Es un dato real y verificable —contó las pastillas, las administró—, pero no contesta la pregunta que de verdad importa: ¿bajó la fiebre? Otro médico, en cambio, usa el termómetro: mide la temperatura antes de la pastilla, la mide después, y reporta "la fiebre bajó de 39° a 37.2°". Los dos médicos hicieron el mismo trabajo real de administrar las pastillas. La diferencia está en qué decidieron medir: uno midió su propia actividad (pastillas dadas), el otro midió la condición real del paciente (la fiebre).

Un buen outcome es el termómetro, no las pastillas contadas. Y aquí está el matiz que esta lección agrega: no cualquier número sirve de termómetro. Si el médico midiera, en cambio, "cuántas veces pidió agua el paciente" —un número real, medible, con un antes y un después—, seguiría sin estar midiendo lo que importa: pedir agua no está confiablemente conectado con la fiebre. Un buen outcome necesita las tres cosas a la vez: un número (no una impresión), que se mueva en una dirección declarada (no "mejoró", sino "bajó de 39 a 37.2"), y que ese número esté genuinamente conectado con la condición que de verdad te importa (la fiebre, no cuántas veces pidió agua). Las tres preguntas de esta lección son, literalmente, cómo elegir el termómetro correcto antes de tratar al paciente.

Ejemplo trabajado: el checklist de tres preguntas, ejecutado

Vamos a construir isGoodOutcome, un checker que aplica las tres pruebas —métrica nombrada, dirección declarada, conexión con valor real— a un conjunto de propuestas típicas de una reunión de planeación de Mercado, algunas buenas y algunas vagas.

// isGoodOutcome(): un outcome candidato necesita las tres cosas: una metrica
// nombrada, una direccion/magnitud de cambio, y una conexion con valor real
// para el usuario o el negocio (no solo actividad del equipo).
function isGoodOutcome(candidate) {
  const reasons = [];
  if (!candidate.hasMetric) reasons.push('no nombra una metrica');
  if (!candidate.isDirectional) reasons.push('no dice una direccion o magnitud de cambio');
  if (!candidate.tiedToValue) reasons.push('no se conecta con valor para el usuario o el negocio');
  return { statement: candidate.statement, good: reasons.length === 0, reasons };
}

const candidates = [
  { statement: 'Mejorar la experiencia de checkout', hasMetric: false, isDirectional: false, tiedToValue: true },
  { statement: 'Subir checkout conversion de 22% a 26% este trimestre', hasMetric: true, isDirectional: true, tiedToValue: true },
  { statement: 'Lanzar el nuevo dashboard de vendedores', hasMetric: false, isDirectional: false, tiedToValue: false },
  { statement: 'Subir el rating promedio de la app de 3.8 a 4.3', hasMetric: true, isDirectional: true, tiedToValue: true },
  { statement: 'Que el equipo se sienta mas productivo', hasMetric: false, isDirectional: false, tiedToValue: false },
];

console.log('=== ¿Es un buen outcome? ===\n');
candidates.forEach((c) => {
  const r = isGoodOutcome(c);
  console.log('"' + r.statement + '"');
  console.log('  veredicto: ' + (r.good ? 'BUEN OUTCOME' : 'NO -- ' + r.reasons.join('; ')));
  console.log('');
});

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

=== ¿Es un buen outcome? ===

"Mejorar la experiencia de checkout"
  veredicto: NO -- no nombra una metrica; no dice una direccion o magnitud de cambio

"Subir checkout conversion de 22% a 26% este trimestre"
  veredicto: BUEN OUTCOME

"Lanzar el nuevo dashboard de vendedores"
  veredicto: NO -- no nombra una metrica; no dice una direccion o magnitud de cambio; no se conecta con valor para el usuario o el negocio

"Subir el rating promedio de la app de 3.8 a 4.3"
  veredicto: BUEN OUTCOME

"Que el equipo se sienta mas productivo"
  veredicto: NO -- no nombra una metrica; no dice una direccion o magnitud de cambio; no se conecta con valor para el usuario o el negocio

Tres de las cinco propuestas fallan, y vale la pena mirar por qué fallan cada una, porque son tres formas distintas de fallar. "Mejorar la experiencia de checkout" le falta la métrica y la dirección — es una intención genuina, pero nadie podría decir, seis semanas después, si se cumplió o no; no hay nada que comparar. "Lanzar el nuevo dashboard de vendedores" falla las tres pruebas a la vez, y por una razón que ya conoces de la lección 2: es, literalmente, un output ("lanzar X") disfrazado con el tono de una meta — no dice qué debería cambiar como consecuencia de lanzarlo. "Que el equipo se sienta más productivo" tiene, en apariencia, algo parecido a una métrica ("productividad"), pero falla la prueba más importante: no está conectada con valor para el usuario o el negocio — es una condición interna del equipo, y aunque fuera cierta, no le dice nada a Mercado sobre si el checkout convierte mejor o si el GMV sube.

Las dos que sí pasan —"subir checkout conversion de 22% a 26%" y "subir el rating de 3.8 a 4.3"— comparten una estructura que vale la pena memorizar: [verbo de dirección] + [métrica nombrada] + [valor de partida] + [valor objetivo]. Esa estructura, por sí sola, obliga a que las tres pruebas se cumplan: no puedes escribir un objetivo así sin nombrar una métrica, sin declarar una dirección, y —si elegiste una métrica que de verdad refleja el negocio, como checkout conversion en vez de, digamos, "número de reuniones de diseño hechas"— sin conectarla con valor real.

La trampa más común: el output disfrazado de meta

Vale la pena detenerse en el caso del dashboard, porque es exactamente el patrón que produjo diez de los doce ítems de output puro en el trimestre de Mercado (lección 4). Una propuesta como "lanzar el dashboard de vendedores" se siente como un objetivo — tiene la forma gramatical de una meta ("vamos a lograr X")—, y por eso pasa desapercibida en una reunión de planeación sin que nadie la cuestione. Pero fíjate en la prueba simple: si reemplazas el verbo por "enviar" o "construir" y la frase sigue significando exactamente lo mismo ("construir el dashboard de vendedores"), es un output con ropa de outcome. Un buen outcome, en cambio, no se puede reformular como un output sin perder información: "subir checkout conversion a 26%" no es lo mismo que "construir algo" — no dice qué construir, solo dice qué tiene que pasar. Esa asimetría es la prueba más rápida que puedes aplicar en cualquier reunión: si la meta se puede lograr construyendo cualquier cosa que la cumpla, es un outcome; si la meta solo se cumple construyendo esa cosa específica, es un output.

Errores comunes

Aceptar una métrica solo porque es fácil de conseguir. Qué pasa: se elige medir "visitas a la página del dashboard" porque el dato ya existe en el panel de analítica, sin preguntarse si esa métrica de verdad refleja el valor que se busca (¿los vendedores actúan con lo que ven, o solo entran y salen?). Por qué pasa: la disponibilidad del dato pesa más, en el momento de decidir, que su relevancia real. Cómo detectarlo: puedes reportar la métrica con facilidad, pero cuando alguien pregunta "¿y eso qué efecto tiene en el GMV o en la retención de vendedores?", no hay una respuesta clara — falla la tercera prueba, tiedToValue, aunque pase las otras dos. Cómo corregirlo: antes de fijar una métrica, traza (aunque sea en una frase) la conexión hacia el resultado que de verdad importa. Si no puedes trazarla, sigue buscando una métrica mejor, aunque sea más difícil de conseguir.

Declarar la dirección sin la magnitud ("mejorar" no es suficiente). Qué pasa: la propuesta dice "vamos a mejorar checkout conversion" — nombra una métrica real, pero sin decir cuánto ni en qué plazo, así que cualquier movimiento, por mínimo que sea, se puede reportar como éxito. Por qué pasa: poner un número concreto se siente arriesgado — ¿y si no se llega? Cómo detectarlo: al final del trimestre, un movimiento de 0.1 puntos (que en la lección 3 viste que es ruido) se celebra igual que uno de 3 puntos, porque la meta original nunca especificó cuánto contaba como éxito. Cómo corregirlo: siempre incluye un valor de partida y un objetivo, aunque sea una estimación ("de 22% a algo por encima de 24%"). Sin esa magnitud, no hay forma de distinguir un logro real de ruido — el mismo problema que resolvió el noiseThreshold de la lección 3.

Confundir "medible" con "conectado al negocio". Qué pasa: se elige una métrica perfectamente medible y con dirección clara —por ejemplo, "número de comentarios en las reseñas de producto"— sin verificar que mover esa métrica le importe genuinamente a Mercado como negocio. Por qué pasa: las primeras dos pruebas (métrica, dirección) son las más fáciles de cumplir en el papel, y a veces eso basta para que la propuesta se sienta completa. Cómo detectarlo: pasa hasMetric e isDirectional, pero al preguntar "¿por qué esto y no otra métrica?", la respuesta es vaga ("porque suena bien tener más reseñas") en vez de trazar una conexión con GMV, retención o algún resultado de negocio real. Cómo corregirlo: la tercera prueba (tiedToValue) es la que más disciplina exige, y por eso es la que más se salta. Insiste siempre en completar la frase "...y esto le importa al negocio porque..." antes de aceptar una métrica como el outcome de una apuesta.

Ejercicios

Ejercicio 1 — Audita tres propuestas nuevas. Aplica las tres pruebas de isGoodOutcome (sin correr el código, razonando cada una) a estas tres propuestas para el próximo trimestre de Mercado:

• (a) "Reducir el tiempo de carga de la página de producto."
• (b) "Bajar el abandono de carrito de 68% a 55% en los próximos dos meses."
• (c) "Aumentar el número de pull requests mergeados por semana."

Ver solución

• (a) NO es un buen outcome. Nombra una métrica de forma implícita (tiempo de carga) pero le falta la magnitud/dirección exacta (¿reducir cuánto, en cuánto tiempo?) y, sobre todo, no traza la conexión con valor: un tiempo de carga más rápido podría subir la conversión, pero la propuesta no lo dice explícitamente — se queda a medio camino entre una métrica técnica y un outcome de negocio.
• (b) BUEN OUTCOME. Nombra la métrica (abandono de carrito), declara la dirección y la magnitud (68% a 55%) y el plazo (dos meses), y se conecta directamente con valor de negocio: menos abandono significa, casi por definición, más compras completadas y más GMV.
• (c) NO es un buen outcome — es una métrica de actividad del equipo, no de valor externo. Falla la tercera prueba con claridad: más pull requests mergeados no le dice nada a Mercado sobre si algo mejoró para un usuario o para el negocio; de hecho, optimizar por este número podría incluso incentivar PRs pequeños y triviales sin ninguna relación con outcomes reales — el error clásico de medir actividad en vez de resultado, la misma trampa de la lección 4 aplicada a un número distinto.

Ejercicio 2 — Repara la propuesta vaga. Toma "Mejorar la experiencia de checkout" (la primera del ejemplo trabajado, que falló dos de las tres pruebas) y reescríbela para que pase las tres. Usa una métrica real del vocabulario de esta guía (checkout conversion, GMV, abandono de carrito).

Ver solución

Una reescritura válida: "Subir checkout conversion de 22.4% a 25% en el próximo trimestre, reduciendo el número de pasos del flujo de pago". Verifica las tres pruebas: nombra la métrica (checkout conversion), declara dirección y magnitud (22.4% → 25%, en un plazo definido), y se conecta con valor real (checkout conversion está directamente ligado al GMV, la métrica que de verdad le importa a Mercado). Nota que la reescritura, además, empieza a insinuar un mecanismo ("reduciendo el número de pasos") — eso es, adelantado, exactamente el tema de la lección 7: un buen outcome dice qué debería cambiar; el mecanismo explica por qué debería cambiar.

Ejercicio 3 — La prueba de la sustitución. Usa la prueba que se explicó en "La trampa más común": si una meta se puede reformular como "construir/enviar X" sin perder significado, es un output disfrazado. Aplica esta prueba a "Aumentar la retención de vendedores activos a 30 días" y a "Lanzar notificaciones push para vendedores". ¿Cuál pasa la prueba de sustitución (es un outcome genuino) y cuál no?

Ver solución

"Aumentar la retención de vendedores activos a 30 días" pasa la prueba — no se puede reformular como "construir X" sin perder información, porque no dice qué construir: se podría lograr con notificaciones push, con un mejor dashboard, con incentivos de precio, con onboarding mejorado, con varias cosas a la vez. Es, genuinamente, un outcome: describe un resultado, deja abierto el camino.

"Lanzar notificaciones push para vendedores" NO pasa la prueba — es, literal, un output: la frase ya especifica qué construir, no qué debería cambiar como consecuencia. Se puede reformular exactamente como "construir notificaciones push para vendedores" sin perder ni un ápice de significado — de hecho, son la misma frase con otro verbo. Para convertirla en un outcome, habría que preguntarse primero para qué se quieren esas notificaciones (¿para subir la retención? ¿para que reaccionen más rápido a los pedidos?), y declarar esa métrica como el objetivo — las notificaciones pasarían entonces a ser, correctamente, el output que se construye para perseguir ese outcome, no el outcome en sí.

Resumen y siguiente paso

En esta lección aprendiste el checklist de tres pruebas para reconocer un buen outcome: nombra una métrica concreta, declara una dirección y una magnitud de cambio, y se conecta con valor real para el usuario o el negocio. Con el termómetro y las pastillas contadas viste por qué elegir qué medir importa tanto como medir algo — no cualquier número sirve de termómetro—. Y con isGoodOutcome ejecutado sobre cinco propuestas típicas de Mercado, viste tres formas distintas de fallar: sin métrica ni dirección, disfrazada de output, o desconectada de valor real. Aprendiste también la prueba de sustitución: si una meta se puede reformular como "construir X" sin perder significado, todavía es un output, no un outcome.

Antes de avanzar deberías poder: aplicar las tres pruebas a cualquier propuesta de outcome que te encuentres; reconocer un output disfrazado de meta con la prueba de sustitución; y reescribir una propuesta vaga como un outcome concreto y accionable.

La lección 7, la última antes del proyecto, cierra el módulo con la pregunta que quedó pendiente: aun con un buen outcome bien definido, ¿cómo sabes que el feature que estás construyendo de verdad va a moverlo? Vas a ver que declarar la métrica correcta no basta — hace falta, además, un mecanismo explícito que conecte el feature con el cambio de comportamiento que se busca.

Recursos

• Amplitude, "What Makes a Good vs Bad North Star Metric" — amplitude.com/blog/good-bad-north-star-metric. Un desarrollo extenso de cómo distinguir una métrica que refleja valor real de una que solo mide actividad — la misma pregunta de esta lección, aplicada a la métrica que guía a todo un producto. En inglés.
• Josh Seiden, "Outcomes Over Output" — outcomesoveroutput.com. Vuelve sobre la definición formal de outcome con ejemplos de metas bien y mal formuladas. En inglés.