Mberne: /* Recursos */

2026-05-20T09:33:31Z

Recursos

← Older revision		Revision as of 11:33, 20 May 2026
Line 252:		Line 252:

	== Recursos ==		== Recursos ==

	<div class="bok-recurso">		<div class="bok-recurso">
	📄 [https://~~www~~.~~senseandrespond.co/books Outcomes Over Output]<span class="detalle">Libro de Josh Seiden sobre orientación a outcomes en equipos y organizaciones · Sense & Respond Press<~~/~~span>~~		🏦 [https://scrummanager.com/skillarena/okr-estrategia-de-producto '''OKRs y estrategia de producto''']<span class="detalle">Skill Arena · Scrum Manager</span>
	</~~div>~~

	~~<div class="bok~~-~~recurso">~~
	~~📄 [https://www.producttalk.org/shifting~~-~~from~~-~~outputs-to-outcomes/ Shifting from Outputs to Outcomes: Why It Matters and How to Get Started]<span class="detalle">Artículo~~ de ~~Teresa Torres sobre pasar de outputs a outcomes · 2024</span>~~
	~~</div>~~

	~~<div class="bok-recurso">~~
	~~📄 [https://businessofsoftware.org/talks/outputs-to-outcomes/ Shifting From Managing By Outputs To Managing By Outcomes~~]<span class="detalle">~~Charla de Teresa Torres sobre gestión por outcomes · Business of Software~~ · ~~2019~~</span>
	</div>		</div>

Mberne at 09:30, 20 May 2026

2026-05-20T09:30:16Z

← Older revision		Revision as of 11:30, 20 May 2026
Line 1:		Line 1:
	{{Meta-bok\|min=5}}		{{Meta-bok\|min=5}}
	'''Outcome over output''' es el principio de priorizar el impacto generado sobre la mera entrega de artefactos. En gestión ágil y producto, significa evaluar el éxito por cambios observables en usuarios, negocio o aprendizaje, no solo por funcionalidades, tareas o releases completadas.		'''Outcome over output''' es el principio de priorizar el impacto generado sobre la mera entrega de artefactos. En gestión ágil y producto, significa evaluar el éxito por cambios observables en usuarios, negocio o aprendizaje, no solo por funcionalidades, tareas o releases completadas.

	~~Outcome over output no significa dejar de entregar. Significa recordar que la entrega es un medio, no el fin.~~

	Un equipo orientado a outputs pregunta: “¿Qué vamos a construir?”. Un equipo orientado a outcomes pregunta antes: “¿Qué cambio queremos conseguir y cómo sabremos que ha ocurrido?”.		Un equipo orientado a outputs pregunta: “¿Qué vamos a construir?”. Un equipo orientado a outcomes pregunta antes: “¿Qué cambio queremos conseguir y cómo sabremos que ha ocurrido?”.

Mberne at 09:30, 20 May 2026

2026-05-20T09:30:00Z

← Older revision		Revision as of 11:30, 20 May 2026
Line 1:		Line 1:
	{{Meta-bok\|min=5}}		{{Meta-bok\|min=5}}

	~~<div class="bok-def">~~
	'''Outcome over output''' es el principio de priorizar el impacto generado sobre la mera entrega de artefactos. En gestión ágil y producto, significa evaluar el éxito por cambios observables en usuarios, negocio o aprendizaje, no solo por funcionalidades, tareas o releases completadas.		'''Outcome over output''' es el principio de priorizar el impacto generado sobre la mera entrega de artefactos. En gestión ágil y producto, significa evaluar el éxito por cambios observables en usuarios, negocio o aprendizaje, no solo por funcionalidades, tareas o releases completadas.
	~~</div>~~

	Outcome over output no significa dejar de entregar. Significa recordar que la entrega es un medio, no el fin.		Outcome over output no significa dejar de entregar. Significa recordar que la entrega es un medio, no el fin.

Mberne: Created page with "{{Meta-bok|min=5}}
'''Outcome over output''' es el principio de priorizar el impacto generado sobre la mera entrega de artefactos. En gestión ágil y producto, significa evaluar el éxito por cambios observables en usuarios, negocio o aprendizaje, no solo por funcionalidades, tareas o releases completadas.
Outcome over output no significa dejar de entregar. Significa recordar que la entrega es un medio, no el fin. Un equipo orientado a ou..."

2026-05-20T09:29:54Z

Created page with "{{Meta-bok|min=5}} <div class="bok-def"> '''Outcome over output''' es el principio de priorizar el impacto generado sobre la mera entrega de artefactos. En gestión ágil y producto, significa evaluar el éxito por cambios observables en usuarios, negocio o aprendizaje, no solo por funcionalidades, tareas o releases completadas. </div> Outcome over output no significa dejar de entregar. Significa recordar que la entrega es un medio, no el fin. Un equipo orientado a ou..."

New page

{{Meta-bok|min=5}}

<div class="bok-def">
'''Outcome over output''' es el principio de priorizar el impacto generado sobre la mera entrega de artefactos. En gestión ágil y producto, significa evaluar el éxito por cambios observables en usuarios, negocio o aprendizaje, no solo por funcionalidades, tareas o releases completadas.
</div>

Outcome over output no significa dejar de entregar. Significa recordar que la entrega es un medio, no el fin.

Un equipo orientado a outputs pregunta: “¿Qué vamos a construir?”. Un equipo orientado a outcomes pregunta antes: “¿Qué cambio queremos conseguir y cómo sabremos que ha ocurrido?”.

Esta diferencia cambia la estrategia, el roadmap, los OKRs, el discovery, la priorización y la forma de hablar con stakeholders.

== La idea central ==

El principio puede resumirse así:

* [[Output|Output]]: lo que el equipo produce.
* [[Outcome|Outcome]]: el cambio que esa producción genera.
* Outcome over output: medir el éxito por el cambio, no por la producción.

Ejemplo:

{| class="wikitable"
! Mentalidad output
! Mentalidad outcome
|-
| “Lanzar el nuevo módulo de reportes”.
| “Reducir los tickets de soporte sobre acceso a datos de 45 al mes a 15 al mes”.
|-
| “Publicar la nueva app móvil”.
| “Aumentar la frecuencia de uso móvil de 1,2 a 2,5 sesiones semanales por usuario activo”.
|-
| “Completar el rediseño del onboarding”.
| “Aumentar la activación de nuevos usuarios del 28% al 40%”.
|}

En los tres casos, el output puede ser útil. Lo que cambia es que no se acepta como prueba suficiente de éxito.

== Por qué importa ==

Las organizaciones tienden a medir lo que es fácil de observar: tareas cerradas, releases publicadas, puntos completados, iniciativas entregadas. Eso da sensación de progreso, pero puede ocultar una pregunta incómoda: ¿ha cambiado algo relevante?

Outcome over output importa porque:

* evita construir funcionalidades que nadie usa;
* reduce el riesgo de feature factory;
* mejora la conversación con stakeholders;
* fuerza a explicitar hipótesis;
* conecta roadmap y estrategia;
* promueve discovery antes de delivery;
* permite aprender aunque una solución no funcione;
* ayuda a decir “no” a iniciativas sin impacto claro.

La entrega importa, pero el impacto decide si la entrega merecía la pena.

== Relación con la feature factory ==

Una [[Feature factory|feature factory]] es una organización que produce funcionalidades de forma continua sin validar suficientemente si generan valor.

Outcome over output es una respuesta directa a ese antipatrón. Cambia el foco desde “¿cuántas cosas hemos entregado?” hacia “¿qué problemas hemos resuelto?”.

{| class="wikitable"
! Feature factory
! Outcome over output
|-
| Roadmap lleno de funcionalidades comprometidas.
| Roadmap conectado a problemas, oportunidades y resultados.
|-
| Éxito medido por entregas.
| Éxito medido por impacto y aprendizaje.
|-
| Discovery débil o usado para justificar soluciones.
| Discovery orientado a reducir incertidumbre antes de construir.
|-
| Stakeholders piden features.
| Stakeholders discuten resultados, trade-offs y evidencia.
|-
| Los equipos optimizan velocidad.
| Los equipos optimizan valor.
|}

== Outcome over output en OKRs ==

Los OKRs se degradan cuando se convierten en listas de tareas.

Ejemplo de OKR orientado a output:

* Objetivo: mejorar la experiencia de onboarding.
* KR1: lanzar el nuevo onboarding.
* KR2: publicar 5 emails de bienvenida.
* KR3: crear dashboard de seguimiento.

Ejemplo orientado a outcome:

* Objetivo: conseguir que los nuevos usuarios lleguen antes al primer momento de valor.
* KR1: aumentar la activación en la primera semana del 28% al 40%.
* KR2: reducir el abandono en el paso de configuración inicial del 35% al 20%.
* KR3: aumentar del 50% al 70% los usuarios que completan su primera acción clave en las primeras 24 horas.

El segundo ejemplo no impide construir onboarding, emails o dashboards. Simplemente los trata como hipótesis para mover un resultado.

== De la solución a la hipótesis ==

Outcome over output obliga a tratar cada solución como una hipótesis.

En lugar de:

“Vamos a construir X porque nos lo han pedido”.

El equipo formula:

“Creemos que X ayudará a este usuario a conseguir Y, y lo sabremos si observamos Z”.

Esta forma de pensar reduce el apego a soluciones concretas. Si el dato muestra que X no funciona, el equipo puede cambiar de enfoque sin sentir que “ha fracasado”. Ha aprendido que esa hipótesis no movía el resultado esperado.

== Preguntas útiles ==

Para aplicar outcome over output, conviene usar preguntas como:

* ¿Qué problema queremos resolver?
* ¿Para quién?
* ¿Qué comportamiento debería cambiar?
* ¿Qué métrica o señal observaríamos si funcionara?
* ¿Podemos lograr el mismo outcome sin construir esta feature?
* ¿Qué evidencia tenemos de que esta solución moverá el resultado?
* ¿Cuál es el coste de oportunidad?
* ¿Qué dejaremos de hacer si priorizamos esto?
* Si entregamos todo y nada cambia, ¿diremos que tuvimos éxito?

Estas preguntas pueden resultar incómodas, pero evitan dedicar meses a outputs que no importan.

== Relación con roadmap ==

Un roadmap orientado a outputs suele comprometer funcionalidades y fechas. Un roadmap orientado a outcomes comunica problemas, objetivos, oportunidades y apuestas.

El [[Roadmap Now-Next-Later]] encaja bien con este enfoque porque evita dar una falsa precisión a iniciativas futuras. Permite ordenar el trabajo por cercanía, evidencia y prioridad sin convertir cada elemento en una promesa rígida.

Una iniciativa debería entrar en el roadmap porque contribuye a un outcome relevante, no porque alguien la pidió hace meses y quedó comprometida políticamente.

== Relación con discovery y delivery ==

Outcome over output exige conectar discovery y delivery.

* Discovery ayuda a decidir qué outcome perseguir, qué problema resolver y qué solución tiene más probabilidades de funcionar.
* Delivery construye, valida técnicamente y entrega la solución seleccionada.
* La medición posterior comprueba si el output generado ha producido el outcome esperado.

Si discovery y delivery se separan demasiado, el equipo puede descubrir sin construir o construir sin aprender. Outcome over output necesita ambos.

== Cómo aplicarlo en la práctica ==

Un proceso sencillo:

# '''Recibir la petición.''' Puede venir como feature, problema, métrica o queja.
# '''Traducir a problema.''' ¿Qué necesidad hay detrás?
# '''Definir outcome.''' ¿Qué cambio observable queremos?
# '''Identificar métricas.''' ¿Cómo sabremos si mejora?
# '''Explorar opciones.''' ¿Qué soluciones podrían mover esa métrica?
# '''Elegir una apuesta.''' Decidir qué construir o validar primero.
# '''Entregar output.''' Construir, experimentar o lanzar.
# '''Medir outcome.''' Revisar si el cambio ocurrió.
# '''Decidir.''' Perseverar, iterar, pivotar o abandonar.

Este proceso no requiere burocracia. Requiere disciplina para no saltar demasiado pronto de una petición a una solución.

== Outcome over output e IA ==

La IA generativa hace que este principio sea más importante, no menos.

Cuando la IA acelera la producción de código, textos, prototipos, diseños, análisis o documentación, el equipo puede generar más outputs que nunca. Pero si la dirección estratégica no está clara, se acelera también el desperdicio.

En equipos con IA, outcome over output ayuda a evitar tres trampas:

* '''producir más porque cuesta menos''': la facilidad de generación no demuestra necesidad;
* '''confundir prototipo con valor''': que algo funcione en una demo no significa que resuelva un problema real;
* '''medir productividad de IA por volumen''': más código, más documentos o más variantes no implican mejor resultado.

La pregunta clave pasa a ser: “¿Qué outcomes nos permite conseguir la IA que antes eran más difíciles, lentos o caros?”.

== Métricas compatibles ==

Outcome over output no impone una métrica única. Depende del contexto.

Algunas métricas habituales:

* activación;
* retención;
* conversión;
* frecuencia de uso;
* tiempo hasta primer valor;
* reducción de tickets;
* satisfacción de usuario;
* NPS o CSAT, con cautela;
* churn;
* revenue;
* coste operativo;
* tiempo de ciclo;
* adopción de una capacidad crítica;
* calidad de evidencia obtenida;
* hipótesis validadas o invalidadas.

Lo importante es que la métrica permita tomar decisiones, no solo decorar un informe.

== Tensiones habituales ==

Aplicar outcome over output no es fácil. Genera tensiones reales.

=== “Los stakeholders piden fechas” ===

Es legítimo necesitar previsibilidad. El problema no es dar información temporal, sino fingir certeza cuando todavía hay alta incertidumbre. Se puede comunicar horizonte, prioridad y nivel de confianza sin convertir cada output en contrato cerrado.

=== “No todo se puede medir” ===

No todo puede medirse con precisión perfecta, pero casi siempre pueden definirse señales mejores que “lo hemos entregado”. Pueden ser cuantitativas, cualitativas o mixtas.

=== “Hay trabajo técnico que no tiene outcome visible” ===

El trabajo técnico también debe conectarse con resultados: menos incidentes, menor tiempo de despliegue, reducción de deuda, mayor seguridad, menor coste de mantenimiento o capacidad para entregar futuras funcionalidades.

=== “El equipo no controla el outcome completo” ===

Es cierto. Por eso conviene elegir outcomes sobre los que el equipo pueda influir de forma razonable, y distinguir entre outcomes de producto y outcomes de negocio.

== Errores frecuentes ==

Al aplicar outcome over output, aparecen errores típicos:

* usar lenguaje de outcome para esconder outputs;
* elegir métricas vanidosas;
* medir solo outcomes lagging que llegan demasiado tarde;
* abandonar toda planificación de entregables;
* convertir el discovery en análisis infinito;
* usar outcomes como mecanismo de presión sin dar autonomía al equipo;
* pedir resultados sin permitir cambiar la solución;
* penalizar al equipo cuando una hipótesis bien diseñada se invalida.

Outcome over output no es una excusa para exigir impacto sin dar capacidad de decisión. Si se pide responsabilidad sobre resultados, el equipo necesita autonomía para explorar cómo lograrlos.

== Buenas prácticas ==

Para aplicar outcome over output:

* '''Redacta KRs como cambios medibles.''' Evita verbos de entrega.
* '''Asocia cada iniciativa a un outcome principal.''' Si no contribuye, cuestiónala.
* '''Usa métricas leading.''' Permiten corregir antes.
* '''Mantén outputs visibles, pero subordinados.''' El equipo necesita saber qué se construye, pero también por qué.
* '''Revisa outcomes en check-ins.''' No basta con reportar avance de tareas.
* '''Celebra aprendizaje válido.''' Invalidar una hipótesis puede ahorrar mucho coste.
* '''Comunica trade-offs.''' Decir “sí” a un output implica decir “no” a otra cosa.
* '''Evita la falsa certeza.''' Cuanto más lejos en el roadmap, menos detalle debería haber.

== Error frecuente ==

<div class="bok-aviso">
'''Usar “outcomes” como retórica, pero seguir gestionando por outputs.''' Ocurre cuando los documentos hablan de impacto, pero las decisiones reales se toman por número de funcionalidades, fechas comprometidas o tickets cerrados. Outcome over output solo funciona si cambia la forma de priorizar, revisar y decidir, no solo el vocabulario.
</div>

== Recursos ==

<div class="bok-recurso">
📄 [https://www.senseandrespond.co/books Outcomes Over Output]<span class="detalle">Libro de Josh Seiden sobre orientación a outcomes en equipos y organizaciones · Sense & Respond Press</span>
</div>

<div class="bok-recurso">
📄 [https://www.producttalk.org/shifting-from-outputs-to-outcomes/ Shifting from Outputs to Outcomes: Why It Matters and How to Get Started]<span class="detalle">Artículo de Teresa Torres sobre pasar de outputs a outcomes · 2024</span>
</div>

<div class="bok-recurso">
📄 [https://businessofsoftware.org/talks/outputs-to-outcomes/ Shifting From Managing By Outputs To Managing By Outcomes]<span class="detalle">Charla de Teresa Torres sobre gestión por outcomes · Business of Software · 2019</span>
</div>

== Referencias ==

* Cagan, Marty. (2018). ''Inspired: How to Create Tech Products Customers Love''. Wiley.
* Scrum Manager. (2026). ''OKRs y estrategia de producto''. Scrum Manager.
* Seiden, Josh. (2019). ''Outcomes Over Output''. Sense & Respond Press.
* Torres, Teresa. (2021). ''Continuous Discovery Habits''. Product Talk LLC.
* Torres, Teresa. (2024). “Shifting from Outputs to Outcomes: Why It Matters and How to Get Started”, Product Talk.

== Véase también ==

<div class="bok-tags">
[[Outcome]] [[Output]] [[OKR]] [[Feature factory]] [[Product discovery]] [[Roadmap Now-Next-Later]] [[North Star Metric]]
</div>

<div class="bok-ecosistema">
<div class="texto">
<span class="titulo">'''¿Quieres avanzar en agilidad?'''</span>
<span class="sub">Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a [https://scrummanager.com/skillarena/ '''Skill Arena''']: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.</span>
</div>
<div class="botones">
<div class="bok-btn-outline">[https://www.scrummanager.com/website/c/calendar/show-courses.php Buscar convocatorias]</div>
<div class="bok-btn-filled">[https://scrummanager.com/club/ Club Agile]</div>
</div>
</div>

[[Category:Glosario de términos]]
[[Category:Product Management]]

Outcome over output - Revision history

Mberne: /* Recursos */

Mberne at 09:30, 20 May 2026

Mberne at 09:30, 20 May 2026