Pasar de una organización orientada a demandas a una organización orientada a objetivos implica cambiar la forma en que se toman decisiones.
Hace poco, estaba trabajando con una organización fuertemente guiada por demandas.
La empresa está en plena transición. Quiere trabajar con una mentalidad más orientada a producto, poniendo mayor énfasis en objetivos, resultados y equipos con más autonomía.
Durante una de nuestras conversaciones, una tensión se hizo muy evidente.
Por un lado, la organización todavía funciona en gran medida a través de demandas, proyectos, prioridades y compromisos de entrega.
Por otro, empieza a surgir una lógica diferente, muy conectada con las conversaciones actuales sobre el Product Operating Model: comenzar por los objetivos, dar a los equipos más contexto estratégico y utilizar los resultados para orientar las decisiones sobre dónde invertir tiempo y energía.
Esa tensión me llevó a la idea central de este artículo:
objetivo versus demanda.
No como una batalla entre dos modelos.
Sino como un cambio en la lógica detrás de la toma de decisiones.
¿Qué significa estar guiado por demandas?
El modelo guiado por demandas resulta familiar para casi todos.
Alguien pide algo. La solicitud se registra, entra en una cola o lista de trabajo, se analiza, se prioriza, se planifica, se ejecuta y, finalmente, se entrega.
No hay nada inherentemente malo en esto.
Esta lógica existe en la gestión de proyectos, operaciones, tecnología, servicios financieros y prácticamente cualquier organización grande.
Los clientes hacen solicitudes. Las áreas internas hacen solicitudes. La regulación genera requisitos. Los problemas técnicos generan trabajo. Las operaciones del día a día producen un flujo interminable de necesidades.
Por lo tanto, la demanda en sí misma no es el problema.
La demanda forma parte de la realidad de cualquier organización.
El problema comienza cuando la demanda se convierte en la principal unidad para la toma de decisiones.
La lógica pasa a ser:
“Esta solicitud ha llegado. Tenemos que ejecutarla.”
Y muchas veces se omite una pregunta importante:
“¿Qué objetivo nos ayuda a alcanzar esta demanda?”
Una organización guiada por demandas tiende a organizar el trabajo alrededor de lo que hay que hacer.
Una organización guiada por objetivos empieza por lo que necesita alcanzar. A partir de ahí, decide qué merece la pena hacer.
Ser bueno entregando no es lo mismo que ser bueno alcanzando objetivos
En una organización guiada por demandas, muchas conversaciones empiezan por el trabajo en sí.
¿Qué hay que hacer? ¿Para cuándo? ¿Quién es responsable? ¿Cuánto costará? ¿Cuáles son las dependencias?
En una organización guiada por objetivos, la conversación comienza un paso antes.
¿Qué estamos intentando alcanzar?
¿Cómo sabremos si estamos avanzando?
Y solo entonces:
¿Qué merece la pena hacer para llegar allí?
Este cambio puede parecer sutil, pero modifica el punto de partida de la decisión.
Completar el trabajo planificado es una cosa.
Alcanzar el resultado que justificaba ese trabajo es otra.
Cuando el trabajo viene antes que el resultado
Imaginemos que alguien dice:
“Necesitamos construir un nuevo portal para clientes.”
En un modelo guiado por demandas, la conversación normalmente avanzará rápidamente hacia alcance, funcionalidades, presupuesto, responsables, dependencias y fechas de entrega.
No hay nada malo en hablar de esas cosas.
Pero observemos lo que ya ha sucedido.
El trabajo se ha definido antes de aclarar el resultado deseado.
Ahora imaginemos que empezamos desde otro lugar:
“Queremos reducir en un 30 % el esfuerzo que los clientes necesitan realizar para resolver solicitudes sencillas.”
La conversación cambia.
Tal vez tenga sentido crear un nuevo portal.
Tal vez sea mejor mejorar el portal existente.
Tal vez la automatización genere un impacto mayor.
Tal vez el verdadero problema esté en el proceso interno.
Tal vez podamos eliminar por completo la necesidad de esa solicitud.
Un objetivo abre espacio para elegir.
Una demanda suele llegar con un camino de acción preferido ya incorporado.
En un modelo guiado por demandas, muchas veces decidimos primero qué hacer y discutimos el resultado después.
En un modelo guiado por objetivos, invertimos la secuencia.
Primero aclaramos qué queremos alcanzar.
Después decidimos qué merece la pena hacer para conseguirlo.
Disparar primero y pintar la diana después
Hay una imagen que utilizo en mi libro Team OKR en Acción para describir un error muy común.
“Disparar primero y pintar la diana después”: cuando el trabajo se decide antes de aclarar el objetivo. Imagen de mi libro Team OKR in Action.
Imaginemos que alguien dispara una flecha contra una pared de madera. Después de ver dónde ha caído la flecha, se acerca y pinta una diana alrededor del punto de impacto.
Parece un tiro perfecto.
Pero la diana apareció después del disparo.
A esto lo llamo:
“disparar primero y pintar la diana después.”
Algo parecido ocurre en muchas organizaciones guiadas por demandas.
Primero decidimos qué vamos a hacer.
Después lo planificamos.
Después lo ejecutamos.
Y solo entonces intentamos conectar ese trabajo con un objetivo o explicar qué resultado pretendía generar aquella entrega.
Primero viene el disparo. Después pintamos la diana alrededor.
Esto crea una apariencia de alineamiento, aunque el resultado deseado nunca haya guiado realmente la decisión.
En un modelo guiado por objetivos, el resultado deseado se hace explícito primero.
El trabajo viene después.
El orden importa: objetivo antes que backlog
Otro error frecuente consiste en comenzar por lo que ya está en la lista de trabajo, la lista de tareas o el backlog.
Backlog es un término muy utilizado en tecnología y gestión de producto para describir la lista de trabajo pendiente: solicitudes, tareas, mejoras, problemas, trabajo técnico y otros elementos que un equipo puede necesitar abordar.
En muchas organizaciones, los equipos ya tienen un backlog enorme.
Entonces alguien mira esa lista y pregunta:
“¿Cuál es el objetivo detrás de todo este trabajo?”
El problema es que, en ese momento, el trabajo ya ha sido seleccionado.
El objetivo aparece después, casi como una justificación.
Y muchas veces ni siquiera existe un único objetivo que conecte realmente todos esos elementos. El backlog se parece más a un mosaico de solicitudes de diferentes stakeholders, prioridades en competencia y distintos niveles de urgencia.
En Team OKR in Action, utilizo una imagen sencilla para ilustrar esta diferencia:
El orden importa: el Team OKR debe orientar las prioridades del backlog, en lugar de definir el OKR a partir de una lista de tareas existente. Imagen de mi libro Team OKR in Action.
La idea es sencilla.
No empieces por una lista de trabajo para después intentar encontrar un objetivo que encaje con ella.
Empieza por el objetivo.
Después pregunta:
“Dado este objetivo, ¿qué debería estar realmente en nuestro backlog?”
Esto cambia el papel del backlog.
Deja de ser simplemente un repositorio de trabajo entrante y se convierte en un mecanismo de ejecución que refleja la dirección elegida por el equipo.
¿Dónde encaja OKR?
Si queremos comenzar por el objetivo, resulta útil hacerlo explícito.
Aquí es donde los OKR pueden ayudar.
OKR significa Objectives and Key Results.
Sin embargo, para esta discusión, el framework en sí es menos importante que la lógica que hay detrás.
El Objective responde:
“¿Qué estamos intentando alcanzar?”
Los Key Results ayudan a responder:
“¿Cómo sabremos si estamos avanzando?”
El objetivo proporciona dirección.
Los Key Results proporcionan evidencias de progreso.
Primero aclaramos qué queremos alcanzar.
Después aclaramos cómo sabremos si avanzamos en la dirección correcta.
Solo entonces tiene sentido discutir el trabajo.
De demanda a iniciativa
No todas las demandas deberían pasar directamente al backlog.
Una demanda es algo que llega al equipo: una solicitud, una necesidad, un requisito, una idea, un problema o una oportunidad.
Puede ser importante.
Puede ser urgente.
Incluso puede ser no negociable.
Pero antes de convertirla automáticamente en trabajo, merece la pena preguntar:
“¿Qué objetivo nos ayuda a alcanzar esta demanda?”
Esa pregunta cambia el papel de la demanda.
Deja de tratarse automáticamente como una instrucción que debe ejecutarse y pasa a convertirse en un input para una decisión.
Cuando la conexión con un objetivo está clara, la demanda puede dar lugar a una iniciativa.
En otras palabras:
la demanda es un input.
la iniciativa es una elección.
Una iniciativa es algo que el equipo decide perseguir porque cree que puede contribuir a un objetivo.
Aquí me gusta utilizar una plantilla sencilla:
Creemos que [INICIATIVA]
nos ayudará a alcanzar [OBJETIVO].
Sabremos que estamos avanzando cuando veamos movimiento en [KEY RESULTS].
Las primeras dos palabras son importantes:
Creemos que.
Porque una iniciativa no es una certeza.
Es una apuesta.
Es una hipótesis sobre cómo el equipo puede influir en un resultado.
Basándonos en lo que sabemos hoy, creemos que invertir en esta iniciativa nos ayudará a avanzar hacia el objetivo.
Eso es muy diferente de recibir una demanda y concluir:
“Tenemos que hacer esto.”
La plantilla nos obliga a mantener una conversación más útil:
¿Qué objetivo apoya esta demanda?
¿Qué iniciativa tiene más sentido teniendo en cuenta ese objetivo?
¿Qué resultado esperamos influir?
¿Qué evidencia nos indicaría que estamos avanzando?
La respuesta no siempre será hacer exactamente lo que se solicitó originalmente.
Y este es uno de los cambios más importantes al pasar de un modelo guiado por demandas a uno guiado por objetivos.
Entregar no es lo mismo que alcanzar un resultado
En un modelo guiado por demandas, la pregunta suele ser:
“¿Lo entregamos?”
En un modelo guiado por objetivos:
“¿Alcanzamos el resultado?”
El portal fue entregado. Pero ¿pueden ahora los clientes resolver sus problemas con menos esfuerzo?
La nueva funcionalidad fue lanzada. Pero ¿mejoró la retención?
El nuevo proceso fue implementado. Pero ¿disminuyó el tiempo de atención?
Modernizamos el sistema. Pero ¿mejoró la experiencia del usuario?
El proyecto terminó. Pero ¿se materializó el resultado esperado para el negocio o para el cliente?
La entrega importa.
Sin entrega, nada cambia.
Pero entregar por sí solo no garantiza impacto.
La entrega es un medio. El resultado es lo que justifica la inversión.
La demanda no desaparece. Gana un filtro de decisión
Una organización guiada por objetivos sigue recibiendo demandas.
La diferencia es que no todas las demandas se convierten automáticamente en trabajo comprometido.
Algunas preguntas pueden ayudar:
¿Qué objetivo apoya esta demanda?
¿Sobre qué resultado esperamos que influya?
¿Cómo sabremos si estamos avanzando?
¿Existe otra forma de alcanzar el mismo resultado?
No se trata de añadir burocracia al proceso de entrada de demandas.
Se trata de mejorar la calidad de la decisión antes de comprometer capacidad.
Algunas demandas seguirán pasando casi directamente al backlog, especialmente trabajos regulatorios, operativos, obligatorios o relacionados con riesgos.
Otras deberán discutirse, agruparse, reformularse, cuestionarse o incluso rechazarse.
El objetivo se convierte en un filtro para la toma de decisiones.
Ayuda a determinar qué merece atención ahora, qué puede esperar y qué quizá no merezca ninguna inversión.
¿Dónde encaja el Product Operating Model?
Gran parte de la conversación actual sobre el Product Operating Model está relacionada con este cambio.
No se trata simplemente de sustituir proyectos por productos.
No se trata de sustituir demandas por objetivos.
No se trata de llamar squads a los equipos.
No se trata de eliminar la planificación.
Y, desde luego, no se trata de abandonar la gestión.
Se trata de cambiar cómo se toman las decisiones y dónde reside la autoridad para tomarlas.
La demanda sigue existiendo, pero deja de ser el único punto de partida.
Los objetivos proporcionan dirección estratégica.
El contexto ayuda a los equipos a comprender por qué esa dirección importa.
Y los equipos reciben más autonomía para decidir cómo contribuir de la mejor manera.
Esto viene acompañado de un cambio igualmente importante: más autonomía y más accountability para los equipos de producto.
En lugar de limitarse a recibir solicitudes para ejecutar, los equipos de producto tienen acceso al contexto estratégico, a los objetivos y a los resultados que la organización está intentando alcanzar.
Dentro de un área clara de responsabilidad, disponen de más espacio para decidir dónde enfocarse y qué iniciativas perseguir.
Para simplificar, imaginemos una caja que contiene todo aquello de lo que un equipo es responsable.
Esa “caja” es el producto del equipo.
Definir bien esa caja —especialmente en grandes organizaciones con múltiples unidades de negocio, plataformas compartidas, estructuras complejas y diferentes topologías de equipos— es tema para otro artículo.
El punto aquí es más sencillo.
Dentro de su área de responsabilidad, el equipo necesita suficiente contexto y autoridad para tomar decisiones sobre cómo puede contribuir mejor a los objetivos.
Autonomía no significa libertad para hacer cualquier cosa.
Significa tener autoridad para elegir entre diferentes caminos dentro de una dirección estratégica clara.
Y accountability significa asumir responsabilidad no solo por las entregas, sino también por los resultados sobre los que el equipo intenta influir.
Los objetivos no eliminan la gestión
Cuando las personas oyen hablar de equipos empoderados y organizaciones guiadas por objetivos, a veces imaginan a los líderes definiendo un objetivo y diciendo:
“Aquí está el objetivo. Arréglatelas.”
No es esa la idea.
Los objetivos no eliminan la gestión.
Cambian aquello en lo que se enfoca la gestión y la forma en que los líderes interactúan con los equipos.
En lugar de observar únicamente las actividades completadas, los hitos alcanzados o los proyectos entregados, la conversación se amplía para incluir:
- qué estamos intentando alcanzar;
- qué evidencias de progreso estamos observando;
- qué estamos aprendiendo;
- si nuestras apuestas actuales siguen teniendo sentido;
- y si los resultados realmente están cambiando.
La gestión sigue siendo importante.
Pero la conversación deja de centrarse tanto en controlar la ejecución y pasa a centrarse más en la calidad de las decisiones, el progreso hacia los objetivos, el aprendizaje y los resultados.
Autonomía sin claridad genera confusión.
Accountability sin autoridad para tomar decisiones genera frustración.
El equilibrio está en una dirección clara, autonomía para decidir y accountability por los resultados.
La demanda es lo que llega. La dirección es lo que elegimos.
Quizá esta sea la forma más sencilla de resumir la diferencia.
La demanda es lo que llega.
Un objetivo nos da una dirección que elegimos.
Toda organización necesita convivir con ambas cosas.
Seguirán apareciendo nuevas solicitudes, necesidades, problemas, obligaciones, riesgos y oportunidades.
El objetivo no es eliminar la demanda.
El objetivo es evitar que cada nueva demanda redefina la dirección.
Cuando el objetivo está claro, las demandas que llegan ganan contexto.
Y podemos hacer mejores preguntas:
¿Qué merece atención ahora?
¿Qué debería priorizarse?
¿Qué puede esperar?
¿Qué ha dejado de tener sentido?
Y, sobre todo:
¿Qué nos acercará al resultado que estamos intentando alcanzar?
Un pequeño cambio en la pregunta inicial
Quizá la transición de una organización guiada por demandas hacia una organización más orientada a producto comience simplemente cambiando la primera pregunta que hacemos.
En lugar de empezar con:
“¿Qué tenemos que hacer?”
Empecemos con:
“¿Qué estamos intentando alcanzar?”
Después:
“¿Cómo sabremos si estamos avanzando?”
Y solo entonces:
“¿Qué merece la pena hacer para llegar allí?”
No se trata de impedir que lleguen demandas.
Se trata de evitar que esas demandas determinen la dirección por defecto.
Los objetivos proporcionan dirección.
Las iniciativas son apuestas sobre cómo avanzar.
El backlog organiza el trabajo necesario para poner esas apuestas en práctica.
El orden importa.
Porque cuando empezamos por la demanda, corremos el riesgo de disparar primero y pintar la diana después.
Cuando empezamos por el objetivo, la diana está visible desde el principio.
Podemos elegir hacia dónde apuntar, aprender de lo que sucede y ajustar el siguiente disparo.
Si te ha gustado este artículo y quieres profundizar, hay algunas formas de continuar.
📘 Si te gusta leer, descubre mis libros Lean Inception y Team OKR.
💼 Y si quieres llevar esta conversación a tu equipo u organización, conoce los servicios que ofrezco. También puedes escribirme por LinkedIn o a través de Caroli.org y podemos organizar una conversación.
