Modelo de teoría del cambio: el marco del sector no lucrativo que les falta a tus OKRs

Pídele a un responsable de programas de una ONG que defienda una solicitud de financiación y, en menos de cinco minutos, sacará un diagrama: insumos, actividades, productos, resultados, impacto, cada casilla conectando lógicamente con la siguiente. Pídele a un product manager que explique por qué un elemento del roadmap va a mover una cifra de ingresos, y normalmente recibirás un encogimiento de hombros, una diapositiva con un gráfico en forma de palo de hockey, o un «porque nuestro competidor lanzó algo parecido».

Ese diagrama que te mostró el responsable de programas tiene nombre. Es un modelo de teoría del cambio, una de las herramientas de planificación más rigurosas que existen, y casi ningún equipo de negocio la usa. No porque no se aplique. Porque casi nadie fuera de la cooperación internacional, la salud pública y la financiación educativa la ha conocido jamás.

Es una pena. La lógica que hay detrás de un modelo de teoría del cambio, una cadena explícita de tipo si-entonces que conecta lo que haces con lo que cambia como resultado, es precisamente lo que falta en la mayoría de los OKRs, roadmaps y planes estratégicos. Los equipos se comprometen con iniciativas continuamente sin escribir nunca por qué creen que esa iniciativa moverá la métrica que persiguen. Un modelo de teoría del cambio obliga a poner esa creencia por escrito, en público, donde alguien pueda realmente rebatirla.

Esto es lo que es realmente un modelo de teoría del cambio, por qué la versión del sector no lucrativo no sobrevive al contacto con una empresa, y cómo aplicar uno sin que acabe convertido en otra diapositiva que nadie vuelve a abrir.

Lo que realmente es un modelo de teoría del cambio

Un modelo de teoría del cambio traza la cadena causal entre lo que hace una organización y el cambio que intenta generar, normalmente a lo largo de cinco etapas:

• Insumos: los recursos que aportas (personas, presupuesto, tiempo)
• Actividades: lo que haces realmente con esos recursos
• Productos: el resultado directo y cuantificable de la actividad (un programa ejecutado, una funcionalidad lanzada)
• Resultados: el comportamiento o la condición que cambia a raíz del producto
• Impacto: el objetivo a más largo plazo al que todo esto debería servir

Lo que lo diferencia de un simple plan de proyecto son las flechas, no las casillas. Entre cada etapa hay una suposición: si hacemos esta actividad, entonces se obtendrá este producto, por esta razón concreta. Un modelo de teoría del cambio te pide nombrar esa razón en voz alta, en lugar de dar por hecho que todo el mundo ya está de acuerdo.

Aquí es también donde se suele confundir con un modelo lógico. Un modelo lógico traza las mismas cinco casillas y documenta sobre todo lo que se supone que debería pasar. Un modelo de teoría del cambio va un paso más allá y documenta por qué crees que va a pasar, incluyendo las suposiciones y riesgos que podrían romper la cadena por el camino. En la práctica, la mayoría de la gente usa ambos términos indistintamente, pero si quieres ser preciso: un modelo lógico es el mapa, y una teoría del cambio es el mapa más el razonamiento que lo sustenta.

Por qué la versión del sector no lucrativo no sobrevive al contacto con una empresa

Las ONG construyen modelos de teoría del cambio para satisfacer a los financiadores, no para gestionar la organización semana a semana. Se crea una vez, antes de una solicitud de subvención, recibe un bonito tratamiento gráfico de quien se le dé bien la pizarra, y luego acaba en una carpeta hasta que el siguiente ciclo de financiación obliga a alguien a desempolvarlo.

Los equipos de negocio que toman prestado el marco suelen cometer exactamente el mismo error. Aparece como una diapositiva en un offsite estratégico, todos asienten, y nadie vuelve a mencionarlo hasta que, seis meses después, alguien pregunta «espera, ¿por qué estamos haciendo este proyecto?» y nadie recuerda bien el razonamiento original. El documento nunca estuvo mal. Simplemente nunca se pensó para usarse más de una vez.

Cómo encaja esto con los OKRs

Si ya trabajas con OKRs, básicamente ya tienes dos tercios de un modelo de teoría del cambio, solo que sin la capa de razonamiento. El Objective es el impacto. Los Key Results son los resultados. Las iniciativas debajo de cada Key Result son las actividades y los productos.

(ver también: Productos frente a resultados)

La parte que casi todo el mundo se salta es la suposición que conecta una iniciativa con un Key Result: el «porque» que explica por qué este trabajo concreto debería mover esa cifra concreta. Si te la saltas, los OKRs se convierten en una lista de tareas con un marcador pegado encima. Si la incluyes, los OKRs se convierten en lo que deberían ser, una capa de traducción entre la estrategia y la ejecución, que es exactamente el papel que describimos en ejecución de la estrategia. Un modelo de teoría del cambio no es más que una forma más disciplinada de escribir esa traducción antes de comprometer recursos reales en ella.

Un método en cuatro pasos para que no se quede obsoleto

1. Escribe la cadena para una iniciativa a la vez, no para toda la empresa. Un modelo de teoría del cambio a nivel de toda la empresa es demasiado abstracto como para que nadie pueda rebatirlo. Uno a nivel de iniciativa, «si lanzamos X, entonces Y, porque Z», es lo bastante concreto como para que alguien pueda realmente no estar de acuerdo.
2. Nombra la suposición en cada flecha, no solo las casillas. «Vamos a crear una checklist de onboarding» es una actividad. «Porque un time-to-value más rápido causa menos churn, y no solo correlaciona con él» es la suposición que hace todo el trabajo de verdad.
3. Vincúlalo a una cadencia, no a un documento de planificación anual. Un modelo de teoría del cambio que solo se reabre una vez al año es un documento de subvención de ONG disfrazado de traje de oficina. Combínalo con los mismos check-ins que ya haces para tus OKRs, para que la suposición se ponga a prueba contra cifras reales en lugar de quedarse solo en el recuerdo.
4. Revisa y poda los eslabones rotos. Cuando un resultado no se mueve como predecía la cadena, la solución no suele ser una nueva táctica pegada a la misma suposición. Es admitir que la suposición era errónea y reescribir ese eslabón antes de que el siguiente trimestre repita el mismo error.

Un ejemplo trabajado

Un equipo de SaaS B2B de 40 personas cree que su problema de churn a 90 días es en realidad un problema de time-to-value. Escrito correctamente, su modelo de teoría del cambio queda así:

• Insumos: dos ingenieros, un diseñador, tres semanas
• Actividades: crear una checklist de onboarding dentro de la app que cubra los cinco pasos de configuración que correlacionan con la retención de cuentas
• Productos: porcentaje de cuentas nuevas que completan la checklist durante la primera semana
• Resultados: el time-to-first-value mediano baja de 12 a 4 días; el churn a 90 días entre quienes completan la checklist disminuye
• Impacto: la net revenue retention mejora para esa cohorte

La suposición que está en la flecha entre el producto y el resultado es la que merece la pena discutir antes de que nadie escriba una línea de código: ¿completar la checklist más rápido realmente causa menos churn, o las cuentas con más probabilidad de completarla rápido ya eran, de todos modos, las que tenían más probabilidad de quedarse? Es una pregunta comprobable, no retórica. Un check-in semanal sobre el indicador adelantado, la tasa de finalización de la checklist, le dice al equipo en menos de un mes si la teoría se sostiene, en lugar de descubrir en el siguiente QBR que todo un trimestre de tiempo de ingeniería persiguió una correlación en vez de una causa.

Errores habituales

• Partir de la métrica de impacto y trabajar hacia atrás hasta llegar a actividades que suenan plausibles, en lugar de partir de lo que el equipo puede controlar realmente y avanzar hacia delante.
• Saltarse la suposición y tratar una historia que suena plausible como si fuera el propio plan.
• Tratarlo como un documento en lugar de como una hipótesis. Archivado en vez de probado, revisado o, de vez en cuando, descartado.
• Confundirlo con un roadmap. Un roadmap dice qué estás construyendo y cuándo. Un modelo de teoría del cambio dice por qué crees que importa, que es justo la parte que un roadmap suele omitir por completo.

Dónde encaja Tability

Nada de esto requiere software nuevo. Requiere escribir la suposición en algún sitio donde todos puedan verla, y revisarla con una cadencia en lugar de una vez al año. Herramientas como Tability están hechas exactamente para eso: un lugar donde vincular una iniciativa al Key Result que debe mover, con un historial de check-ins continuo que muestra si la suposición subyacente se sostiene o se va desmoronando en silencio. Es la misma capa operativa que hemos descrito en StratOps y en el framework de OKRs.

Si estás intentando que tu equipo discuta las suposiciones antes de comprometer todo un trimestre de tiempo de ingeniería en ellas, o si estás construyendo la función de StratOps que convierte ese tipo de pensamiento en rutina, regístrate gratis en Tability o reserva 30 minutos con nosotros y te ayudaremos a averiguar cómo sería para tu equipo. Con Tability o sin él, escribir el «porque» merece la pena de todas formas.