Outcomes vs. outputs: medir impacto, no entregables

Un output es lo que produce el equipo; un outcome, el cambio que provoca en personas o negocio. Cómo distinguirlos, qué métricas engañan y cómo fijar metas.

info Definición Rápida

Un output es lo que el equipo produce: una función, una pantalla, un proyecto o una iniciativa. Un outcome es el cambio que ese output provoca en el comportamiento de las personas o en el resultado del negocio. La diferencia parece pequeña, pero define si un equipo rinde cuentas por lo que entregó o por lo que cambió.

¿Qué diferencia hay entre output y outcome?

Cada autor lo define con matices propios:

Teresa Torres (Product Talk, 2026): un output es algo que se construye o se produce (una función, un proyecto, una iniciativa), y un outcome es el impacto de ese output: un cambio en el comportamiento del cliente o un resultado de negocio. Cuando se le encarga a un equipo un output, termina cuando el software se publica.
Josh Seiden (autor de Outcomes Over Output), en una conversación publicada por Intercom en 2019: un outcome es un cambio en el comportamiento humano que impulsa resultados de negocio. Torres cita la misma definición.
Marty Cagan (SVPG, 2019): los equipos de funciones (“feature teams”) “son todo output” y reciben una lista priorizada de funciones y proyectos. Los equipos de producto son multifuncionales y se enfocan y se miden por outcomes, no por output.
Product School (2025): los outputs son lo que entrega el equipo de producto, y los outcomes son el cambio que esa entrega crea.

El punto en común: el equipo no debería rendir cuentas por lanzar funciones, sino por el cambio que esas funciones buscan.

¿Por qué le importa a un diseñador?

Porque el diseño es uno de los entregables más visibles. Pantallas, prototipos y flujos se pueden contar, mostrar y aprobar. Si el equipo se mide por eso, el incentivo es entregar más, no comprobar si lo entregado funciona. Un diseñador que presenta cinco pantallas terminadas puede estar haciendo bien su trabajo y aun así no haber cambiado nada.

Pensar en outcomes da al diseño una pregunta más útil. En lugar de “¿qué entregamos?”, la pregunta es “¿qué van a hacer las personas de forma distinta cuando esto exista?”. Esa pregunta lleva directamente a la investigación, a las hipótesis y a las pruebas.

¿Cómo se identifica un outcome?

Seiden propone, en la conversación con Intercom, una pregunta concreta para cualquier función: ¿qué van a hacer las personas de forma diferente como resultado de esto? Si la respuesta es “usarán la función”, eso es un output. Si la respuesta describe un cambio observable, como “buscarán menos veces antes de encontrar lo que necesitan”, eso es un outcome.

Seiden da un ejemplo con el NPS: ningún equipo puede cambiar el NPS directamente, así que la tarea pasa a ser un problema de alcance. El equipo se pregunta qué comportamientos suyos y de sus clientes sí puede cambiar, y los convierte en cambios que puede diseñar y probar.

Product Talk recomienda, además, que fijar outcomes sea una conversación en dos direcciones: el líder aporta la visión del negocio y el equipo aporta el conocimiento del cliente y de la tecnología. Ninguna de las dos partes debería imponerse. Su ejemplo: “nuestro outcome es lanzar una app para Android” es un output; al preguntar por su valor aparece el outcome de fondo, lograr que más personas se comprometan con el producto, que se puede acotar a todas las plataformas, a usuarios móviles o solo a Android.

¿Por qué las métricas de tráfico engañan?

Product Talk advierte que hay métricas que parecen outcomes, pero que solo miden adopción. Su ejemplo: aumentar el porcentaje de usuarios que vieron un informe de rendimiento. Parece un buen outcome, pero Torres lo llama métrica de tracción porque mide la adopción de una sola función, no el valor para el cliente: ver el informe no demuestra que fuera útil, y quizá algunos clientes ni lo necesitan.

Las métricas de sentimiento, como CSAT o NPS, también tienen límites. Product Talk las considera difíciles por sí solas porque no indican una dirección. Sugiere emparejarlas con una métrica de comportamiento, por ejemplo “aumentar el uso sin afectar negativamente la satisfacción”.

Otra trampa es el output disfrazado de outcome. “Lanzar el nuevo onboarding” parece un resultado, pero sigue siendo un entregable. El outcome podría ser algo como “más personas completan su primera tarea en la primera semana”.

¿Cómo se prueba?

Un outcome es una hipótesis hasta que se comprueba. Seiden habla de formular el trabajo como una hipótesis (“creemos que si hacemos esta función, generará este outcome”) y probarla con un experimento o un MVP. Según él, la incertidumbre es normal: no hace falta tener certeza de que un cambio moverá el comportamiento, pero sí al menos una corazonada que justifique probarlo.

Para un outcome nuevo, Product Talk recomienda fijar primero una meta de aprendizaje (“aprender qué mueve esta métrica”) y después una de desempeño (“aumentar X en Y %”). Así el equipo sabe si la prueba le enseñó algo, aunque el número no se haya movido todavía.

Para la parte práctica, el Lean UX propone el mismo ciclo desde el lado del diseño: supuesto, prueba mínima, medición y decisión.

Ejemplo

Ejemplo ilustrativo: un equipo de diseño de una tienda en línea tiene como objetivo “Rediseñar el carrito”. Al revisarlo, se pregunta qué debería cambiar en el comportamiento de quienes compran. Reescribe la meta: “Que más personas completen la compra después de agregar un producto al carrito”. Como primera prueba, muestra el costo de envío en la misma pantalla del carrito, en lugar de al final, para la mitad de los usuarios. Si la tasa de compra sube, el cambio pasa a ser permanente. Si no sube, el equipo aprende que el envío no era la barrera principal y busca otra hipótesis, sin haber rediseñado todo el carrito.

Para tu equipo: toma tres entregables de la última planificación y, para cada uno, escribe qué comportamiento debería cambiar. Si no puedes escribirlo, el entregable probablemente no tiene un outcome claro.

¿Cuándo NO conviene forzar la distinción?

Cuando el entregable es obligatorio por regulación, seguridad o contrato. Un output puede ser necesario aunque no haya un outcome medible.
Cuando el outcome aún no se puede medir y no hay forma razonable de aproximarlo. Entonces conviene empezar por un indicador provisional y revisarlo.
Cuando la métrica se vuelve la meta y el producto empieza a optimizarla a costa de la experiencia.
Cuando el equipo no tiene acceso a datos de comportamiento. Sin ellos, el outcome es una suposición.

Errores comunes

Llamar outcome a un entregable con otro nombre.
Usar métricas de adopción como si fueran de valor.
Medir solo sentimiento, sin comportamiento que lo acompañe.
Fijar metas tan conservadoras que siempre se cumplen y no enseñan nada.
Olvidar la meta de aprendizaje y medir solo desempeño.
Abandonar la distinción cuando el jefe pide fechas de entrega.

Relacionado en la wiki

Para ordenar qué medir en el tiempo, lee la nota sobre métrica norte: ahí las métricas de entrada son la forma de convertir outcomes en palancas de trabajo. Los OKRs para diseño aplican la misma idea a objetivos trimestrales, y los KPIs del equipo deberían apuntar a outcomes y no solo a entregables.

Fuentes

Preguntas frecuentes

¿Qué es un output y qué es un outcome?

Un output es algo que el equipo construye o produce: una función, un proyecto o una iniciativa. Un outcome es el impacto de ese output, es decir, un cambio en el comportamiento de los clientes o un resultado de negocio.

¿Por qué las métricas de adopción no son outcomes?

Porque miden que alguien usó algo, no que le sirvió. Product Talk las llama traction metrics: indican adopción, no valor. Un outcome describe qué hace la persona de forma distinta después del cambio.

¿Cómo se convierte un objetivo de negocio en outcomes de producto?

Preguntando qué comportamiento lo haría cambiar. Josh Seiden propone preguntar qué harán las personas de forma diferente como resultado de una función, y luego formular una hipótesis y probarla.

¿Por qué importa esto para diseño?

Porque un equipo medido por pantallas entregadas tiene pocos incentivos para comprobar si lo entregado funciona. Medir outcomes obliga a diseñar con hipótesis y a aceptar cuando una solución no cambia nada.