No entres ahí: Outcomes vs Outputs - Parte 3

“Está bien, pero… ¿Esto qué outcome mueve?”

📌 Este artículo es la tercera parte de una serie. Si todavía no leíste las anteriores, te recomiendo empezar por la Parte 1 y la Parte 2.

Hola! Cuanto tiempo que no nos leemos no? Cómo estás?

Pequeño recap hasta acá: En las dos primeras entregas hablamos más de conceptos. De las diferencias entre outcomes y outputs. De cómo muchas veces confundimos actividad con impacto. Y de cómo todo se vuelve más complejo cuando hay varios equipos involucrados, porque los outcomes ya no son solo de Producto, sino que se reparten entre distintas áreas y equipos.

Todo eso es "teoría"

En esta tercera entrega, quiero enfocarme en lo práctico: consejos para quienes están en roles de Producto (o similares) y enfrentan el desafío diario de conectar las tareas con los Outcomes, los que realmente importan. ¿Cómo hacemos para que esto funcione en la realidad?

Antes de empezar y fiel a mi estilo, una yapa que complementará todo el artículo:

Aprendí hace tiempo que no le damos suficiente valor a la comunicación interna, desde ningún puesto o área. Como responsables de Producto, generalmente somos el puente entre la visión de negocio y las decisiones técnicas para llegar a ella, y si no somos claros y constantes en cómo comunicamos los Outcomes, podemos perder el foco. No es suficiente que solo nosotros entendamos el “qué” y el “por qué”, sino que todo el equipo esté alineado. Los Outcomes tienen que ser ese lenguaje común que todos hablan.

Ahora si, veamos ejemplos concretos para aplicar en tu día laboral.

1. Empezá por la pregunta más simple: “¿Esto qué outcome mueve?”

Cada vez que estás por planear un Sprint, pensar en el Roadmap del Q siguiente, o incluso escribir un ticket de requerimientos, tratá de hacerte esta pregunta. No es una pregunta mágica que disparará reflexiones reveladoras, pero sí una advertencia. Si no podés responder qué outcome se espera mover con eso que estás escribiendo o definiendo, es probable que estés priorizando un output.

Y no tiene nada de malo. Hay outputs necesarios. Hay mejoras que simplemente hay que hacer. Hay deuda técnica que resolver. Pero si lo hacés sin la conciencia de que no tiene impacto medible, entonces solo estás alimentando una ilusión de progreso. Estás avanzando, pero no sabés hacia dónde.

Una forma fácil de entrenarlo es agregar una columna en tu board de la herramienta que uses, donde cada item tenga asociado un outcome. Puede parecer tedioso al principio, pero si ves demasiadas tareas sin outcome claro, es hora de parar un poquito y revisar.

2. Usá los outcomes como brújula también en Discovery

Otra forma de incorporar esta mirada es en las etapas previas a decidir qué construir (algunos autores le llaman Product Discovery). Cuando estés haciendo entrevistas, leyendo feedback de los usuarios o mirando métricas, no busques solamente patrones de uso o sugerencias sueltas. Preguntate si eso que estás observando ayuda o no a mover alguno de los Outcomes que ya definiste como importantes.

Es fácil enamorarse de lo que los usuarios dicen, te aseguro que es dopamina directa. Y más tentador aún es enamorarse de lo que podrían llegar a querer. Pero sin un marco de Outcomes claros, cualquier idea suena como una buena idea.

Si trabajás en una empresa donde otros equipos traen propuestas todo el tiempo a la mesa —Sales, Marketing, Customer Support, etc.—, compartir tus Outcomes puede ser una forma muy simple de filtrar sin decir que NO con dureza. En vez de “esto no lo vamos a hacer”, podés decir “hoy estamos priorizando acciones que muevan este Outcome, ¿cómo pensas que esto que me propones lo impacta?”. No cierra la conversación, la encuadra.

3. Hacelos visibles (y compartilos)

Otra trampa común: tener los Outcomes anotados pero en soledad. En una hoja, en tu cabeza o guardaditos en una página de Notion que nadie lee.

Trabajar por Outcomes no es un ejercicio de Product Managers iluminados. O de stakeholders intensos con los frameworks. Necesita ser una práctica compartida. No sirve que vos tengas clarísimo por qué se hace algo si los Diseñadores están pensando en otra cosa (no es culpa de ellos), los Devs no ven el valor, o el equipo comercial está vendiendo funcionalidades que no existen todavía.

Podés anclarlos al principio de cada Sprint, en el update del lunes, o simplemente fijarlos en un canal de Slack. No es importante el formato. Lo que importa es que estén disponibles, visibles y discutidos. Eso también implica tiempo para debatirlos. Si no están presentes, vuelven los hábitos viejos. Los de hacer por hacer/entregar por entregar y más…

4. Aceptá que no todo va a mover un Outcome, y está perfecto!

No todo lo que hagas va a tener un impacto inmediato o directo. Eso no es un problema.

Hay tareas que existen por otras razones, hay cosas que simplemente hay que hacer: actualizar una integración, cumplir con una auditoría, responder rápido un bug critico. No todas esas acciones van a mover una métrica de forma directa o indirecta, pero sí podés asumirlas con conciencia de que son trabajo necesario. Calidad del Producto.

El problema, uno muy común como humanos, es cuando la excepción se convierte en la norma. Si semana a semana tu backlog está lleno de cosas que no sabés cómo afectan a tus Outcomes, si lo único que pasa es que entran más y más tickets, entonces el equipo no está haciendo Producto. Vos no estás haciendo Producto. Mover tareas de una columna a otra no es lo mismo que mover el negocio.

Trabajar con Outcomes es una práctica diaria, un marco para tomar decisiones complicadas, y una forma de hacerle frente a las urgencias sin perder de vista el propósito de la compañía y el producto. Sí, a veces vas a tener que hacer cosas que no mueven un outcome. Pero si nunca te preguntás cuál es el impacto, entonces ya no estás construyendo Producto.

Y el cambio empieza por algo simple, una pregunta el lunes a la mañana.

“¿Esto qué outcome mueve?”

Porqué mover tareas de una columna a otra no es lo mismo que mover el negocio.

Hasta la próxima