El espejismo de la velocidad

Existe una trampa muy bien camuflada en el corazón del desarrollo ágil moderno: la velocidad como proxy de valor. Los equipos miden story points completados, features lanzadas, epics cerradas. Los managers de producto construyen roadmaps repletos de entregables concretos. Los stakeholders aprueban trimestres llenos de ítems que "se van a hacer". Y así, sin que nadie lo haya decidido explícitamente, la organización acaba midiendo su capacidad de producir cosas en lugar de su capacidad de generar cambios reales en el mundo.

Esta distinción tiene nombre en la literatura de producto. Hablamos de la diferencia entre output —lo que el equipo produce— y outcome —el cambio de comportamiento o condición que ese output provoca en usuarios o en el negocio. Y aunque la distinción parezca obvia enunciada así, en la práctica resulta extraordinariamente difícil de sostener.

Josh Seiden (2019) lo explica con una claridad desconcertante: las organizaciones están estructuradas para producir cosas, no para generar cambios. Sus procesos de planificación, sus métricas de seguimiento, sus dinámicas de reporting y sus conversaciones con liderazgo giran en torno a la pregunta "¿qué vas a entregar?" en lugar de "¿qué va a cambiar?". No es irresponsabilidad. Es inercia sistémica.

¿Cuántas veces hemos participado en una planificación trimestral donde la conversación central era qué funcionalidades entran y cuáles no? ¿Con qué frecuencia alguien en esa sala formuló la pregunta inversa: qué comportamiento del usuario necesitamos cambiar, y cómo sabremos que lo hemos conseguido?

Por qué la confusión persiste

Sería injusto culpar únicamente a los equipos de esta disfunción. La presión hacia el output tiene raíces profundas que merecen ser nombradas.

En primer lugar, los outputs son tangibles y los outcomes no. Una funcionalidad se puede mostrar. Se puede hacer clic sobre ella. Se puede fotografiar en una demo. Un cambio de comportamiento en el usuario, en cambio, requiere tiempo, métricas y una hipótesis previa para poder ser medido. La naturaleza intrínsecamente más observable del output lo convierte en moneda de cambio perfecta en organizaciones que necesitan justificar inversión a corto plazo.

En segundo lugar, la incertidumbre incomoda. Trabajar orientados a outcomes implica aceptar que no sabemos con certeza qué funcionalidad producirá el cambio deseado. Implica decir "esta es nuestra hipótesis" en lugar de "esto es lo que vamos a construir". Para culturas organizacionales acostumbradas a la predictibilidad como señal de competencia —algo que Amy Edmondson ha estudiado ampliamente en su investigación sobre seguridad psicológica y culturas de aprendizaje— admitir incertidumbre puede sentirse como debilidad, aunque sea exactamente lo contrario.

En tercer lugar, las estructuras de incentivos refuerzan el output. Teresa Torres (2021) señala que la mayoría de los equipos de producto son evaluados por cuánto construyen, no por cuánto aprenden o por qué resultados generan. Si un Product Manager es juzgado por la cantidad de features lanzadas en el trimestre, tiene todos los incentivos del mundo para optimizar esa métrica, aunque no conecte con ningún objetivo estratégico real.

Marty Cagan desarrolla este argumento de forma más explícita: la diferencia entre los equipos de producto que generan impacto real y los que simplemente ejecutan roadmaps está precisamente en si tienen la autonomía y la responsabilidad de perseguir outcomes o si son básicamente fábricas de features con metodología ágil de decoración.

La trampa del roadmap de funcionalidades

Uno de los síntomas más reveladores de la cultura output es el roadmap de funcionalidades. Ese documento (herramienta, o tablón, o presentación) está lleno de items concretos organizados en el tiempo: "En Q1, filtros avanzados de búsqueda. En Q2, integración con CRM. En Q3, rediseño del dashboard."

El problema no es que estos items sean incorrectos. El problema es que su presencia en el roadmap precede a la conversación sobre qué problema del usuario o del negocio están resolviendo, y qué evidencia existe de que esa solución concreta es la correcta. Como Melissa Perri argumenta, muchas organizaciones caen en lo que ella llama la "trampa de la construcción": equipos tan ocupados entregando que nunca se detienen a preguntar si lo que entregan importa.

¿Qué alternativa existe? Perri, Torres, Seiden y otros autores del ámbito convergen en una dirección: roadmaps orientados a problemas u outcomes. En lugar de comprometerse con soluciones específicas en el tiempo, el equipo se compromete con el problema que va a abordar y con los indicadores que le dirán si lo está resolviendo. Cómo exactamente lo va a resolver es una hipótesis que se irá refinando con evidencia.

Esto no significa que los roadmaps de producto no puedan tener ninguna especificidad. Significa que la especificidad debe llegar después de la validación, no antes. Y que en el nivel estratégico, lo que debe guiar la planificación son preguntas como: "¿Qué necesita cambiar en el comportamiento de nuestros usuarios para que nuestro negocio crezca?" o "¿Qué fricción está impidiendo que los usuarios consigan lo que vienen a buscar?"

Outcomes, métricas y la falsa precisión

Adoptar una orientación a outcomes no resuelve automáticamente el problema. Genera uno nuevo: elegir los outcomes correctos y medirlos sin caer en una trampa diferente pero igualmente perniciosa —la de las métricas proxy que acaban siendo confundidas con el objetivo real. Este fenómeno tiene un nombre: la Ley de Goodhart, formulada originalmente por el economista Charles Goodhart en 1975 y popularizada en contextos de gestión: cuando una medida se convierte en objetivo, deja de ser una buena medida. Un equipo que fija como outcome "aumentar el número de usuarios que completan el onboarding" puede conseguirlo simplificando el proceso hasta el punto de que los usuarios que completan el onboarding no entienden realmente el producto. La métrica mejora. El negocio no.

Es por esto que OKRs, por ejemplo, puede resultar útil, pero requiere disciplina en su aplicación. Los Key Results deben medir cambios observables de comportamiento o condición, no actividades. "Lanzar tres nuevas integraciones" es un output disfrazado de KR. "Aumentar en un 15% el porcentaje de usuarios que utilizan el producto más de tres veces por semana" es un outcome medible.

La distinción de Jeff Gothelf y Josh Seiden (2021) entre métricas de comportamiento y métricas de actividad resulta muy útil aquí. Las métricas de actividad cuentan cosas que el equipo hace (features lanzadas, sprints completados, tickets cerrados). Las métricas de comportamiento cuentan cosas que cambian en usuarios o en el negocio como resultado de lo que el equipo hace. Solo las segundas son outcomes.

Dicho esto, no toda organización tiene la madurez analítica para medir comportamientos de usuario con la granularidad que algunos frameworks ideales presuponen. Y aquí conviene ser honesto: la orientación a outcomes no es una palanca que se activa de un día para otro. Requiere instrumentación de producto, cultura de experimentación y, sobre todo, tiempo. Para muchos equipos, el camino hacia los outcomes pasa por etapas intermedias que no hay que menospreciar.

El papel del Discovery y la validación continua

Si los outcomes son la estrella norte, el discovery continuo es el proceso que permite navegar hacia ella. Teresa Torres ha articulado con rigor cómo equipos de producto de alto rendimiento integran la investigación de usuarios como una actividad continua, no como una fase que precede al desarrollo.

En Continuous Discovery Habits, Torres propone el Opportunity Solution Tree como herramienta para conectar el outcome deseado con las oportunidades identificadas en la investigación de usuarios, y estas con las posibles soluciones a explorar. Esta estructura visual no es solo un artefacto de planificación —es una forma de pensar que mantiene visible la cadena causal entre lo que se construye y el cambio que se pretende generar.

El riesgo de omitir esta cadena causal es construir soluciones brillantes a problemas que los usuarios no tienen, o a versiones del problema que el equipo imaginó sin validación suficiente. Este patrón no es exclusivo de startups —se reproduce en equipos internos de grandes organizaciones que, con todos los recursos del mundo, construyen funcionalidades que nadie usa.

¿Cómo sabes, en tu equipo, cuántas de las features entregadas en el último año tienen evidencia de uso sostenido? ¿Cuántas se lanzaron, generaron algo de actividad inicial y luego cayeron en el olvido? Estas no son preguntas retóricas: son el tipo de auditoría que equipos maduros hacen de manera regular.

La dimensión organizacional: cuando el problema no está en el equipo

Llegados a este punto, conviene resistir la tentación de reducir este problema a una cuestión de metodología o de habilidades individuales. La orientación a outcomes requiere ciertas condiciones organizacionales que no siempre están presentes, y sería poco honesto ignorarlo. Cagan es categórico en este punto: los equipos no pueden perseguir outcomes si la organización les dicta outputs. Si el liderazgo presenta roadmaps comprometidos con funcionalidades concretas a clientes o a inversores, si los contratos con proveedores especifican entregables, si la cultura de performance evalúa al equipo por lo que produce y no por el impacto que genera —en ese contexto, pedirle al equipo que "piense en outcomes" es pedirle que nade a contracorriente de todo el sistema en el que opera.

Esto no significa resignarse. Significa ser estratégico. Algunos cambios pueden empezar en el nivel del equipo: formular hipótesis explícitas antes de construir, medir el impacto de lo entregado, proponer métricas de éxito antes de la planificación. Otros cambios requieren conversaciones con liderazgo sobre qué quiere la organización medir realmente. Y algunos, seamos francos, no son posibles sin una transformación más profunda que va más allá de lo que un equipo de producto puede gestionar solo.

Dave Snowden y su marco Cynefin nos recuerdan que en entornos complejos no existen mejores prácticas universales, sino prácticas buenas para un contexto específico. La pregunta no es "¿debería mi organización orientarse a outcomes?", sino "¿cuál es el camino hacia esa orientación dado mi contexto organizacional específico?"

Pequeños pasos que están en nuestra mano

Sin pretender ofrecer recetas universales, hay algunas prácticas que distintos equipos han encontrado útiles para avanzar hacia una mayor orientación a outcomes, independientemente del nivel de madurez de la organización.

1. Formular hipótesis antes de comprometer soluciones. Antes de escribir una user story, preguntarse:

• ¿Qué comportamiento del usuario queremos cambiar con esto?
• ¿Cómo lo mediremos?
• ¿Qué evidencia tenemos de que esta solución es la adecuada?

Este hábito, practicado consistentemente, cambia la naturaleza de las conversaciones de planificación.

2. Incluir criterios de éxito en las user stories. No solo "como usuario quiero poder X" sino también "sabremos que esta feature tiene éxito cuando veamos Y". Esto obliga al equipo a pensar en impacto antes de construir, y proporciona una base para evaluar las decisiones después del lanzamiento.
3. Revisar el impacto de lo entregado. Dedicar tiempo regularmente —puede ser parte de la retrospectiva, puede ser una sesión separada— a revisar métricas de uso y comportamiento de las features lanzadas en ciclos anteriores. ¿Qué funcionó como esperábamos? ¿Qué no? ¿Qué aprendimos?
4. Proponer métricas de outcome antes de la planificación. En lugar de llegar a la planificación con una lista de features, llegar con una pregunta: "¿Qué indicador queremos mover este trimestre, y cuánto?" Esto reorienta la conversación hacia el impacto antes de comprometer soluciones.

Ninguna de estas prácticas es una bala de plata. Son puntos de entrada. Lo que hace que funcionen (o no) depende en gran medida del contexto organizacional y de la voluntad de las personas con autoridad para sostenerlas en el tiempo.

Al final, la distinción entre output y outcome no es solo una discusión metodológica. Es una pregunta sobre el propósito del trabajo que hacemos. ¿Estamos aquí para construir cosas o para generar cambios? ¿Medimos nuestra capacidad de producir o nuestra capacidad de aprender y adaptarnos?

No hay una respuesta única. Pero la forma en que una organización responde a estas preguntas define en gran medida qué tipo de equipo de producto es capaz de ser.

¿Dónde situarías hoy a tu equipo en este espectro? ¿Qué conversación tendrías que tener con tu organización para que la orientación a outcomes fuera algo más que un ideal declarado?

Bibliografía

• Cagan, M. (2017). Inspired: How to Create Tech Products Customers Love (2ª ed.). Wiley.
• Cagan, M., y Jones, C. (2020). Empowered: Ordinary People, Extraordinary Products. Wiley.
• Doerr, J. (2018). Measure What Matters: OKRs — The Simple Idea That Drives 10x Growth. Portfolio/Penguin.
• Edmondson, A. C. (2018). The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth. Wiley.
• Gothelf, J., y Seiden, J. (2021). Lean UX: Designing Great Products with Agile Teams (3ª ed.). O'Reilly Media.
• Goodhart, C. A. E. (1975). Problems of Monetary Management: The U.K. Experience. Papers in Monetary Economics, Reserve Bank of Australia.
• Perri, M. (2018). Escaping the Build Trap: How Effective Product Management Creates Real Value. O'Reilly Media.
• Seiden, J. (2019). Outcomes Over Output: Why Customer Behavior Is the Key Metric for Business Success. Sense & Respond Press.
• Snowden, D. J., y Boone, M. E. (2007). A Leader's Framework for Decision Making. Harvard Business Review, 85(11), 68–76.
• Torres, T. (2021). Continuous Discovery Habits: Discover Products That Create Customer Value and Business Value. Product Talk LLC.