Guía Didáctica: OKRs y estrategia de producto

Volver Descargar PDF

OKRs y estrategia de producto

Skill Arena - Scrum Manager

Febrero 2026

Tabla de Contenidos

  1. Mentalidad de outcome vs. output.
  2. Métricas Leading vs. Lagging.
  3. Redacción y alineamiento.
  4. Conexión con roadmap y priorización.
  5. Rituales de producto y check-ins.
  6. Validación y aprendizaje.
  7. Trampas del "feature factory" y cultura.
  8. Cierre y síntesis.
  9. Anexos.

Introducción

Propósito y alcance de la guía

Esta guía didáctica está diseñada para entrenar la capacidad de definir y gestionar estrategias basadas en resultados (outcomes) en lugar de entregables (outputs). Su propósito es desarrollar competencias prácticas en la selección de métricas, la priorización del roadmap y la toma de decisiones basada en datos.

Esta guía incluye:

  • Definición de objetivos cualitativos y Key Results cuantitativos.
  • Métricas leading (predictivas) versus lagging (de resultado).
  • Conexión entre OKRs y roadmap de producto.
  • Técnicas de priorización y negociación con stakeholders.
  • Rituales de seguimiento y check-ins efectivos.
  • Validación de hipótesis y OKRs de aprendizaje.
  • Identificación de antipatrones culturales.

Esta guía no incluye:

  • Tutoriales de herramientas específicas (Jira, Lattice, etc.).
  • Gestión de recursos humanos ligada a bonos salariales individuales.
  • Metodologías predictivas de gestión de proyectos (Waterfall/Gantt).

Cómo usar esta guía

Esta guía está estructurada en siete capítulos que corresponden a las competencias evaluables del tema. Cada capítulo comienza con los resultados de aprendizaje esperados, desarrolla los conceptos clave con profundidad, y proporciona criterios operativos, marcos de decisión y ejercicios prácticos.

Se recomienda abordar los capítulos en orden, ya que existe una progresión lógica desde la mentalidad fundamental (outcomes vs. outputs) hasta las aplicaciones más complejas (rituales, validación y cultura).

Cómo aprender usando el banco de preguntas

El banco de preguntas de Skill Arena está diseñado para reforzar el aprendizaje mediante la práctica deliberada. Al responder cada pregunta, presta especial atención a:

  • El feedback de cada opción: las explicaciones de por qué una respuesta es correcta o incorrecta revelan los criterios de calidad y las distinciones clave del tema.
  • Los escenarios y artefactos: las situaciones presentadas reflejan decisiones reales que enfrentan los profesionales de producto. Analiza no solo qué hacer, sino por qué ciertas acciones son preferibles.
  • Los patrones de error: los distractores representan confusiones comunes. Identificar por qué parecen razonables pero son incorrectos fortalece tu criterio profesional.

1. Mentalidad de outcome vs. output

Qué vas a conseguir

Al completar este capítulo serás capaz de:

  • Reformular una solicitud de feature en un objetivo orientado a cambio de comportamiento o impacto en negocio.
  • Redactar Key Results que definan el éxito independientemente de la solución técnica implementada.
  • Identificar KRs que son listas de tareas disfrazadas de resultados.
  • Distinguir objetivos binarios (hecho/no hecho) de métricas de impacto genuinas.
  • Argumentar por qué el despliegue de una funcionalidad no garantiza la creación de valor.

Conceptos clave

La distinción fundamental

Un output es algo que produces: una funcionalidad, un documento, un despliegue. Un outcome es el cambio que ese output genera en el mundo: un comportamiento diferente del usuario, una métrica de negocio que se mueve, un problema que se resuelve.

Esta distinción es la piedra angular de los OKRs aplicados a producto. Cuando defines el éxito como "lanzar la feature X", creas un incentivo perverso: el equipo optimizará para entregar, no para generar valor. Puede ocurrir que la feature se despliegue, el equipo celebre, y sin embargo ningún usuario cambie su comportamiento ni ninguna métrica se mueva.

Por qué importa esta distinción

Cuando mides outputs, celebras deploys. Cuando mides outcomes, celebras impacto. La primera mentalidad lleva a la "fábrica de features" donde el éxito se define por la velocidad de entrega. La segunda lleva a equipos que cuestionan constantemente si lo que están construyendo realmente importa.

Un equipo orientado a outcomes se pregunta: "Si construimos esto y nadie lo usa, ¿habremos tenido éxito?". La respuesta debería ser "no". Pero si tu KR es "desplegar el módulo de reportes", entonces técnicamente sí habrías cumplido. Esa es la trampa.

El objetivo cualitativo

El Objetivo en un OKR describe la dirección aspiracional. Debe ser cualitativo, inspirador y comprensible por todos. No incluye números porque su función es dar sentido y dirección, no medir. Un buen objetivo responde a la pregunta "¿qué queremos lograr?" sin imponer el "cómo".

Cuando el objetivo se redacta como una cifra ("Conseguir 5.000€ de revenue incremental"), pierde su función orientadora y se confunde con un Key Result. El objetivo debería expresar la intención ("Mejorar la monetización sin dañar la confianza del usuario") y dejar que los KRs cuantifiquen el éxito.

El Key Result orientado a resultado

Un Key Result bien formulado mide un cambio observable en usuarios o negocio. La prueba más simple es preguntar: "¿Podríamos lograr este KR de múltiples maneras completamente diferentes?". Si la respuesta es sí, probablemente estás midiendo un resultado. Si la respuesta es no, probablemente estás midiendo una tarea específica.

Criterios de calidad para distinguir outcomes de outputs

Un KR es probablemente un output si:

  • Incluye verbos como "entregar", "desplegar", "implementar", "lanzar", "completar".
  • Se puede marcar como "hecho" el día del despliegue sin esperar a medir nada.
  • Especifica la solución técnica concreta que se va a construir.
  • El porcentaje de avance se calcula por tareas completadas.

Un KR es probablemente un outcome si:

  • Mide un cambio en una métrica de comportamiento o negocio.
  • Múltiples soluciones diferentes podrían lograrlo.
  • El éxito se verifica observando a usuarios o datos de negocio.
  • Se expresa como movimiento de una cifra: "de X a Y".

Marcos de decisión

Cómo transformar una petición de feature en un OKR orientado a outcome

Cuando alguien pide una funcionalidad específica, el proceso de traducción a outcome sigue esta secuencia:

  1. Clarifica el problema y el usuario afectado. Antes de aceptar la solución propuesta, entiende qué problema resuelve y para quién.

  2. Define el cambio de comportamiento o impacto esperado. ¿Qué harán diferente los usuarios? ¿Qué métrica de negocio debería moverse?

  3. Elige la métrica que evidenciará el cambio. Esta métrica debe poder medirse independientemente de qué solución construyas.

  4. Solo entonces, explora posibles soluciones. La feature original es ahora una hipótesis entre varias para mover la métrica.

Preguntas de diagnóstico

Para evaluar si un KR está midiendo un resultado genuino:

  • ¿Qué pasaría si completamos todas las tareas pero la métrica no se mueve? ¿Consideraríamos que tuvimos éxito?
  • ¿Podríamos declarar este KR cumplido el día del despliegue, antes de observar cualquier dato de uso?
  • ¿Existe alguna forma de lograr este KR que no involucre construir nada nuevo?

Si las respuestas son "sí, tendríamos éxito", "sí, podríamos declararlo cumplido" y "no, requiere construir algo específico", entonces probablemente estás midiendo un output.

Errores típicos y cómo corregirlos

Error 1: confundir "hacer" con "lograr"

Manifestación: el equipo redacta KRs como "Publicar el rediseño de la pantalla de onboarding" o "Completar 6 experimentos de onboarding y documentarlos".

Por qué ocurre: es más fácil y menos arriesgado comprometerse a hacer cosas que a lograr resultados. Entregar está bajo nuestro control; el impacto depende también de factores externos.

Corrección: reformula preguntando: "¿Qué cambio esperamos ver si esta entrega funciona?". El nuevo KR debería ser ese cambio esperado. Por ejemplo: "Aumentar la activación de nuevos usuarios del 28% al 40%".

Error 2: KRs que son listas de tareas (milestones)

Manifestación: los KRs enumeran entregables: "KR1: Entregar 12 iniciativas del roadmap. KR2: Cerrar 40 tickets. KR3: Publicar 8 releases".

Por qué ocurre: es tentador usar el sistema de OKRs para dar visibilidad al trabajo del equipo y demostrar productividad.

Corrección: pregunta: "Si entregamos todo esto y ninguna métrica de usuario o negocio cambia, ¿habremos tenido un buen trimestre?". Reemplaza la lista de tareas por el resultado que esas tareas deberían producir.

Error 3: asumir que el despliegue garantiza el valor

Manifestación: el equipo celebra cuando la feature está en producción, sin esperar a ver si alguien la usa o si mueve alguna métrica.

Por qué ocurre: el despliegue es un hito visible y satisfactorio. Esperar semanas para validar el impacto requiere paciencia y disciplina.

Corrección: define por adelantado qué señal considerarás suficiente para declarar éxito. Incluye un período de observación en tu definición de "hecho".

Ejercicio guiado

El equipo de ventas solicita urgentemente un "módulo de reportes avanzados" porque varios clientes enterprise lo han pedido.

  • Paso 1: ¿Cuál es el problema real? Probablemente los clientes necesitan tomar decisiones basadas en datos que actualmente no pueden ver fácilmente.

  • Paso 2: ¿Qué cambio de comportamiento esperamos? Si el módulo funciona, los clientes deberían ser capaces de responder sus preguntas de negocio sin contactar a soporte, y quizás tomar mejores decisiones que aumenten su uso del producto.

  • Paso 3: ¿Cómo mediríamos ese cambio? Posibles métricas: reducción de tickets de soporte relacionados con datos, aumento del engagement con funciones de análisis, mejor retención de cuentas enterprise.

  • Paso 4: ¿Cuál sería un KR orientado a outcome? En lugar de "Desplegar módulo de reportes avanzados", considera: "Reducir los tickets de soporte relacionados con acceso a datos de 45/mes a 15/mes" o "Aumentar el NPS de cuentas enterprise del 32 al 50".

2. Métricas Leading vs. Lagging

Qué vas a conseguir

Al completar este capítulo serás capaz de:

  • Seleccionar métricas predictivas (leading) que permitan actuar durante el ciclo del trimestre.
  • Conectar métricas de producto con KPIs de negocio mediante una cadena causal explícita.
  • Identificar y descartar métricas vanidosas que dan falsa sensación de progreso.
  • Diseñar un conjunto de indicadores que combine señales tempranas con resultados finales.
  • Argumentar por qué medir solo resultados finales impide la corrección a tiempo.

Conceptos clave

Métricas leading: indicadores predictivos

Una métrica leading es un indicador que anticipa el resultado final. Cambia primero, antes que el resultado que te importa, y te permite actuar cuando todavía hay tiempo. Son las "señales tempranas" de que algo va bien o mal.

En un producto de suscripción, la tasa de activación en la primera semana es leading: si los usuarios no se activan, probablemente no retendrás. El churn rate a 90 días es lagging: cuando lo mides, ya es tarde para cambiar el comportamiento de esos usuarios.

La clave de una métrica leading es que sea accionable: el equipo puede tomar decisiones que la afecten en un plazo corto (días o semanas, no meses).

Métricas lagging: indicadores de resultado

Una métrica lagging refleja el resultado final que te importa: revenue, retención anual, beneficio neto. Son importantes porque representan el éxito real del negocio, pero tienen un problema práctico: cuando detectas que van mal, ya es tarde para reaccionar dentro del ciclo.

Los OKRs trimestrales necesitan incluir métricas leading porque permiten check-ins útiles. Si tu único KR es "aumentar el ARR un 15%", en la semana 6 del trimestre no sabrás si vas bien hasta que cuentes el dinero al final. En cambio, si mides "demos cualificadas" o "conversión de prueba a pago", puedes ajustar tus tácticas durante el camino.

La cadena causal: de leading a lagging

Las métricas leading y lagging no existen de forma aislada; están conectadas por una hipótesis de causalidad. Por ejemplo:

  • Leading: porcentaje de usuarios que completan el onboarding en la primera sesión
  • Intermedia: frecuencia de uso semanal durante el primer mes
  • Lagging: tasa de retención a 90 días
  • Muy lagging: revenue recurrente anual

Esta cadena representa tu teoría de cómo el producto crea valor. Documentarla explícitamente permite validar si tus supuestos son correctos. A veces descubres que la métrica leading que elegiste no predice realmente el resultado lagging que te importa.

Métricas vanidosas: la falsa sensación de progreso

Una métrica vanidosa es aquella que siempre sube (o nunca baja) y da la ilusión de progreso sin reflejar la salud real del producto o negocio. El ejemplo clásico es "usuarios totales registrados": solo puede crecer, incluso si el producto está muriendo y nadie lo usa activamente.

Las métricas vanidosas comparten características comunes: son acumulados históricos, carecen de contexto temporal o de segmento, y no permiten comparar períodos ni detectar deterioro. Tener "50.000 miembros en el foro" no significa nada si 48.000 están inactivos.

Criterios para seleccionar métricas accionables

Una métrica es accionable si:

  • El equipo puede tomar decisiones que la afecten en semanas, no en meses.
  • Existe una hipótesis clara de qué palancas la mueven.
  • Puede bajar (no solo subir) si las cosas van mal.
  • Tiene contexto: periodo, segmento, cohorte.
  • Se puede descomponer en componentes que el equipo controla.

Una métrica probablemente es vanidosa si:

  • Es un acumulado histórico que solo puede crecer.
  • No tiene segmentación ni contexto temporal.
  • No cambia el comportamiento del equipo si sube o baja.
  • Se eligió porque es fácil de medir, no porque sea informativa.

Tabla comparativa: Leading vs. Lagging

Aspecto Métrica Leading Métrica Lagging
Momento Ocurre primero en la cadena causal Refleja el resultado final
Accionabilidad Alta: el equipo puede influir rápidamente Baja: cuando se mide, ya es tarde
Uso en OKRs Ideal para KRs de trimestre: permite corrección Válida si se combina con leading
Ejemplo (SaaS) Tasa de activación primera semana Revenue recurrente anual
Ejemplo (E-commerce) Añadir al carrito Valor medio de pedido mensual
Riesgo Puede no predecir el lagging si la hipótesis causal es incorrecta No permite actuar a tiempo

Marcos de decisión

Cómo seleccionar métricas leading para un KR

  1. Parte del resultado lagging que importa al negocio. Este es tu destino final: revenue, retención, NPS.

  2. Mapea las palancas de producto que influyen en ese resultado. ¿Qué comportamientos del usuario preceden al resultado? ¿Qué etapas del funnel lo alimentan?

  3. Elige una métrica leading por cada palanca accionable. Selecciona indicadores que cambien rápido y que el equipo pueda mover con cambios de producto, contenido o comunicación.

  4. Define umbrales y cadencia de revisión. Determina qué valor considerarías "en riesgo" y con qué frecuencia revisarás el dato.

  5. Valida la relación causa-efecto. Con datos históricos, comprueba si la métrica leading realmente predice el resultado lagging. Si no, ajusta tu selección.

Cuándo usar leading vs. lagging en KRs

  • Usa principalmente leading cuando necesitas capacidad de reacción durante el trimestre y el resultado final tarda en manifestarse.
  • Combina leading con lagging cuando quieres mantener la conexión con el objetivo de negocio pero necesitas señales intermedias.
  • Usa lagging con precaución cuando el resultado final se manifiesta rápido (ciclos de venta cortos) o cuando es el único indicador relevante.

Errores típicos y cómo corregirlos

Error 1: medir solo revenue o churn sin palancas de acción

Manifestación: el equipo tiene como único KR "Aumentar el revenue mensual un 8%" sin indicadores intermedios.

Por qué ocurre: revenue y churn son lo que importa al negocio, así que parecen elecciones obvias.

Corrección: mantén el resultado lagging como norte, pero añade métricas leading que el equipo pueda mover semanalmente. Pregunta: "¿Qué señal veríamos en la semana 3 que nos indicaría si vamos bien?".

Error 2: usar métricas acumuladas que siempre suben

Manifestación: un stakeholder propone medir "número total de usuarios registrados" como KR porque es fácil y siempre crece.

Por qué ocurre: las métricas acumuladas son cómodas porque nunca generan malas noticias.

Corrección: prioriza métricas de período o de tasa (usuarios activos mensuales, tasa de activación, retención por cohorte). Si una métrica no puede bajar, no te está diciendo nada útil.

Error 3: no entender la relación causa-efecto

Manifestación: el equipo debate si el KR debería ser "reducir churn" o "aumentar uso semanal" sin datos que conecten ambas métricas.

Por qué ocurre: asumir causalidad sin validarla es tentador porque simplifica la decisión.

Corrección: antes de comprometerte con una métrica leading, haz un análisis rápido de cohortes para verificar si realmente predice el resultado lagging. Si no lo predice, busca otra.

3. Redacción y alineamiento

Qué vas a conseguir

Al completar este capítulo serás capaz de:

  • Redactar Key Results precisos con el formato "De X a Y en fecha Z".
  • Detectar ambigüedades en definiciones cualitativas que llevan a interpretaciones divergentes.
  • Negociar objetivos compartidos entre equipos para evitar dependencias bloqueantes.
  • Evaluar críticamente OKRs propuestos "en cascada" y cuestionar la capacidad real de cumplimiento.
  • Evitar la creación de silos con objetivos de producto desconectados de otras áreas.

Conceptos clave

La precisión como requisito

Un KR ambiguo genera interpretaciones diferentes. Si tu KR es "Optimizar el checkout", UX pensará en menos pasos, Ingeniería en rendimiento, y Negocio en más upsells. Cada área ejecutará algo distinto creyendo que contribuye al mismo objetivo.

La precisión elimina esta divergencia. Un KR como "Reducir la tasa de abandono del checkout del 68% al 52%" no deja espacio para interpretaciones: todos saben qué se mide y cuándo se habrá conseguido.

El formato canónico: De X a Y

El formato más efectivo para un KR incluye tres elementos: el punto de partida (baseline), el punto de llegada (target) y el horizonte temporal. "Aumentar la tasa de activación de nuevos usuarios del 28% al 40% antes del 31 de marzo" contiene toda la información necesaria para alinear al equipo y medir el progreso.

Este formato tiene una virtud adicional: obliga a conocer el baseline actual. Muchos equipos descubren que no saben cuál es su punto de partida, lo cual ya es información valiosa.

Alineamiento vertical: la trampa del cascadeo

El cascadeo de OKRs ocurre cuando un nivel directivo define objetivos y los equipos deben derivar OKRs alineados. El riesgo es aceptar objetivos sin cuestionar si el equipo tiene la capacidad, habilidades o autoridad para impactarlos directamente.

Cuando el VP de Producto asigna "Expandir a 3 nuevos mercados internacionales" y tu equipo es de producto core sin expertise en localización, aceptar un KR de localización es una receta para el fracaso. La alternativa es proponer cómo tu equipo puede contribuir indirectamente (mejorando la escalabilidad técnica, por ejemplo) y negociar un KR realista.

Alineamiento horizontal: objetivos compartidos

Cuando dos equipos tienen dependencias mutuas, el alineamiento se logra mejor mediante objetivos compartidos. Si el equipo de Producto necesita una API del equipo de Plataforma, y cada uno tiene prioridades diferentes, la solución no es escalar el conflicto sino negociar un OKR compartido donde ambos co-responsabilicen el resultado.

Un OKR compartido alinea incentivos: cuando ambos equipos tienen el mismo KR, la colaboración fluye naturalmente porque el éxito de uno es el éxito del otro.

Criterios de calidad para KRs bien redactados

Un KR está bien redactado si:

  • Expresa un cambio medible de X a Y en una fecha específica.
  • Define claramente el alcance o población afectada.
  • Incluye o referencia la definición operativa de cómo se mide
  • Es interpretado de la misma manera por todas las personas involucradas.
  • Puede evaluarse objetivamente como cumplido o no cumplido.

Un KR tiene problemas de redacción si:

  • Usa verbos amplios como "optimizar", "mejorar", "aumentar" sin número.
  • Depende de interpretaciones distintas entre equipos.
  • No especifica el punto de partida actual.
  • No indica el horizonte temporal.

Alineamiento vertical y horizontal

Preguntas antes de aceptar un OKR en cascada

  • ¿Tiene el equipo las habilidades necesarias para impactar este objetivo directamente?
  • ¿Tiene el equipo la autoridad para tomar las decisiones que moverían la métrica?
  • ¿Existen dependencias de otros equipos que no están comprometidas?
  • ¿Cuál es una contribución realista que el equipo puede hacer al objetivo corporativo?

Pasos para negociar un OKR compartido

  1. Identifica la dependencia crítica durante el planning, no después.
  2. Propón a ambos equipos el mismo KR, de modo que el éxito sea conjunto.
  3. Define quién lidera la coordinación y cómo se reportará el avance.
  4. Establece puntos de sincronización y decisión durante el trimestre.

Errores típicos y cómo corregirlos

Error 1: KRs vagos sin número

Manifestación: "Mejorar significativamente los tiempos de carga" o "Aumentar la calidad percibida del servicio".

Por qué ocurre: cuantificar requiere datos que quizás no tenemos, y comprometerse a un número específico da miedo.

Corrección: antes de finalizar el OKR, invierte tiempo en conocer el baseline. Si no tienes datos históricos, ese es tu primer problema a resolver. Define la fórmula de cálculo y documéntala para evitar debates posteriores.

Error 2: aceptar cascadas sin cuestionar la capacidad

Manifestación: el equipo acepta KRs asignados desde arriba aunque no tenga los recursos, habilidades o autoridad para impactarlos.

Por qué ocurre: cuestionar a la dirección es incómodo, y aceptar parece la opción segura.

Corrección: propón alternativas que muestren cómo el equipo puede contribuir indirectamente al objetivo corporativo. Negocia un KR que sea ambicioso pero alcanzable con los recursos disponibles.

Error 3: silos con objetivos desconectados

Manifestación: el equipo de producto define OKRs sin considerar cómo afectan o dependen de ventas, marketing o soporte.

Por qué ocurre: es más fácil definir objetivos aislados que negociar con otras áreas.

Corrección: durante el planning, mapea explícitamente las dependencias y los puntos de contacto con otros equipos. Si hay dependencias críticas, negocia OKRs compartidos o al menos compromisos explícitos.

Checklist de redacción

Antes de finalizar un KR, verifica:

  • [ ] ¿Tiene un valor de partida (baseline) documentado?
  • [ ] ¿Tiene un valor objetivo (target) específico?
  • [ ] ¿Tiene una fecha límite clara?
  • [ ] ¿Está documentada la fórmula de cálculo?
  • [ ] ¿Todas las personas involucradas lo interpretan igual?
  • [ ] ¿El equipo tiene capacidad y autoridad para impactarlo?
  • [ ] ¿Las dependencias externas están comprometidas?

4. Conexión con roadmap y priorización

Qué vas a conseguir

Al completar este capítulo serás capaz de:

  • Usar los OKRs como filtro estratégico para decidir qué iniciativas entran en el roadmap.
  • Descartar o posponer features que no impactan los KRs del trimestre, comunicando el porqué.
  • Priorizar experimentos de validación sobre desarrollos grandes cuando hay incertidumbre.
  • Negociar peticiones fuera de estrategia haciendo visible el trade-off.
  • Justificar cambios de alcance ante stakeholders usando el lenguaje de los OKRs.

Conceptos clave

El roadmap como herramienta estratégica, no como contrato

Un roadmap desconectado de los OKRs se convierte en una lista de compromisos fijos que se ejecuta por inercia. El equipo entrega outputs que pueden ser irrelevantes para los outcomes actuales. Cuando las prioridades cambian durante el trimestre, el roadmap debería adaptarse.

El valor de los OKRs está precisamente en proporcionar un criterio para evaluar qué entra y qué sale del roadmap. Cada iniciativa debería poder responder a la pregunta: "¿Qué KR mueve esto y cómo?". Si no puede responderla, probablemente no debería estar ahí.

Decir "no" con fundamento

Una de las funciones más importantes de los OKRs es proporcionar un lenguaje para rechazar peticiones. Cuando un stakeholder pide una feature que no está alineada, la respuesta no es "no queremos" sino "esto no contribuye a los KRs que hemos priorizado este trimestre; si lo hacemos, afectará nuestra capacidad de cumplir X".

Este enfoque convierte una discusión de preferencias en una discusión de trade-offs. El stakeholder puede entonces argumentar por qué su petición es más importante que los KRs actuales, y la conversación se eleva al nivel estratégico donde debe estar.

Experimentos antes que desarrollos grandes

Cuando hay incertidumbre sobre si una iniciativa moverá un KR, la respuesta no es construir y esperar. Es diseñar un experimento mínimo que produzca evidencia con bajo coste. Si la evidencia es favorable, entonces se justifica el desarrollo a mayor escala.

Esta lógica invierte el orden habitual: en lugar de "construir y luego medir", primero reduces el riesgo con validación barata y solo después comprometes recursos significativos.

OKRs como filtro estratégico

Proceso para evaluar una iniciativa contra los OKRs

  1. Identifica qué KR impactaría la iniciativa. Si no impacta ninguno, es candidata a descarte o postergación.

  2. Estima la magnitud del impacto. ¿Es una palanca principal o marginal para mover el KR?

  3. Evalúa el coste de oportunidad. ¿Qué dejaríamos de hacer si priorizamos esto? ¿Cómo afecta a otros KRs?

  4. Considera el nivel de certidumbre. ¿Tenemos evidencia de que esto funcionará o es una apuesta?

  5. Decide: ejecutar, experimentar, postergar o descartar.

Manteniendo el foco con demasiadas iniciativas

Si el roadmap contiene más iniciativas de las que el equipo puede ejecutar mientras cumple los KRs, hay un problema de foco. La solución no es trabajar más horas sino reducir el alcance. Identifica qué iniciativas tienen menor impacto en los KRs actuales y propón despriorizar las que no contribuyen directamente.

Marcos de decisión ante peticiones no planificadas

Cuando llega una petición urgente fuera de los OKRs

  1. Entiende la necesidad y el riesgo de no atenderla. ¿Qué problema resuelve? ¿Qué pasa si la ignoramos?

  2. Comprueba el encaje con objetivos y KRs actuales. ¿Contribuye a algo que ya hemos priorizado?

  3. Si no encaja, propón alternativas. Ajustar alcance, cambiar prioridad de otra cosa, o crear un KR explícito para esta petición.

  4. Acuerda la decisión y comunica el trade-off. Si se acepta, explicita qué KR se verá afectado. Si se rechaza, documenta por qué.

Respuestas tipo ante diferentes situaciones

Situación Respuesta alineada con OKRs
Petición urgente fuera de OKRs Negociar: qué KR se ajusta o qué se desprioriza
Iniciativa grande con impacto incierto Convertirla en experimento con criterio de éxito antes de comprometer build
Iniciativa que podría mover varios KRs Elegir el KR principal y definir guardrails para los demás
Trabajo de mantenimiento sin "métrica sexy" Vincularlo a una guardrail de riesgo/fiabilidad

Errores típicos y cómo corregirlos

Error 1: mantener un roadmap fijo desconectado de los OKRs

Manifestación: el roadmap se definió en enero y nadie lo ha modificado desde entonces, aunque las prioridades estratégicas han cambiado.

Por qué ocurre: cambiar el roadmap requiere conversaciones difíciles con stakeholders que tienen expectativas comprometidas.

Corrección: haz un análisis de impacto: ¿cuántas iniciativas del roadmap contribuyen a los KRs actuales? Propón despriorizar las que no contribuyen, presentando el trade-off claramente.

Error 2: intentar mover demasiados KRs a la vez

Manifestación: el equipo tiene 8 KRs y 12 iniciativas, dispersando el esfuerzo sin mover significativamente ninguna métrica.

Por qué ocurre: es difícil decir que no y el equipo quiere demostrar que está trabajando en todo.

Corrección: prioriza 2-3 KRs de mayor impacto y comunica el ajuste a stakeholders. El foco genera más resultados que la dispersión.

Error 3: no decir "no" a peticiones fuera de estrategia

Manifestación: el equipo acepta toda petición que llega, añadiendo trabajo sin ajustar los OKRs ni el roadmap existente.

Por qué ocurre: decir no es incómodo y se percibe como falta de colaboración.

Corrección: usa los OKRs como escudo y herramienta de negociación. La respuesta es: "Si priorizamos esto, el KR X bajará de verde a rojo. ¿Procedemos?".

5. Rituales de producto y check-ins

Qué vas a conseguir

Al completar este capítulo serás capaz de:

  • Diseñar y facilitar check-ins que generen decisiones, no solo reportes de estado.
  • Actualizar niveles de confianza semanal o quincenalmente con fundamento en datos.
  • Proponer planes de acción concretos cuando un KR entra en estado de riesgo.
  • Distinguir cuándo perseverar con la estrategia actual, cuándo pivotar y cuándo abandonar un objetivo.
  • Evitar el antipatrón de "maquillar" datos para mantener una apariencia de progreso.

Conceptos clave

El propósito de los check-ins

Un check-in de OKRs no es una reunión de reporte donde cada persona lee sus números. Es una sesión de gestión donde el equipo toma decisiones basadas en datos. La pregunta central no es "¿cuánto hemos avanzado?" sino "¿qué hacemos diferente a partir de lo que sabemos?".

Si el check-in termina sin ninguna decisión ni acción concreta, probablemente fue una pérdida de tiempo. El formato ideal incluye actualización de datos, valoración de confianza, identificación de bloqueos, y acuerdo de acciones para el siguiente ciclo.

Niveles de confianza: más que semáforos

El nivel de confianza de un KR (verde, amarillo, rojo) no es simplemente una lectura del progreso actual. Es una predicción: "Dado lo que sabemos hoy, ¿qué probabilidad tenemos de cumplir este KR al final del trimestre?".

Esta distinción importa. Un KR puede estar en 30% de avance a mitad de trimestre y aun así estar en verde si la dinámica es favorable. Otro puede estar en 60% y estar en rojo si se ha estancado y no hay palancas claras para moverlo.

La confianza requiere explicar los supuestos: "Estamos en amarillo porque asumimos que el equipo de datos nos entregará el pipeline la próxima semana. Si eso no ocurre, pasamos a rojo".

El peligro del "set and forget"

Uno de los antipatrones más comunes es definir OKRs al inicio del trimestre y no revisarlos hasta el final. Esto convierte los OKRs en un ejercicio burocrático sin valor práctico. Las métricas pueden haberse movido (o no), pero el equipo no tuvo oportunidad de ajustar su comportamiento en respuesta.

Los check-ins regulares (semanal o quincenal) evitan este problema al crear momentos de reflexión y ajuste. La cadencia debe ser suficiente para detectar problemas a tiempo, pero no tan frecuente que se convierta en overhead improductivo.

Niveles de confianza y estados de un KR

Estado Significado Acción apropiada
Verde (on track) Alta confianza en cumplir el KR al final del trimestre Mantener la estrategia y vigilar guardrails; no añadir trabajo extra por comodidad
Amarillo (riesgo) Confianza moderada; hay señales de alerta pero aún hay opciones Identificar palancas, ajustar plan e incrementar cadencia de seguimiento
Rojo (off track) Baja confianza; el KR probablemente no se cumplirá sin cambios significativos Tomar una decisión: pivotar iniciativa, reducir alcance del KR, o abandonar si no hay causalidad
Sin datos fiables No podemos evaluar el progreso porque la métrica no está instrumentada correctamente Corregir instrumentación urgentemente; definir métrica provisional para no decidir a ciegas

Marcos de decisión: perseverar, pivotar o abandonar

Cuándo perseverar

  • Los datos muestran progreso consistente aunque lento.
  • Los supuestos iniciales siguen siendo válidos.
  • Las palancas identificadas todavía no se han agotado.
  • El equipo tiene claridad sobre qué hacer diferente.

Cuándo pivotar

  • Los datos muestran que la estrategia actual no está funcionando.
  • Hay evidencia de que una aproximación diferente podría funcionar.
  • Todavía hay tiempo suficiente en el trimestre para implementar el cambio.
  • El coste del pivote es menor que el coste de continuar sin resultados.

Cuándo abandonar

  • La hipótesis fundamental se ha invalidado.
  • No hay palancas realistas que el equipo pueda accionar.
  • El coste de oportunidad de seguir es demasiado alto.
  • El KR ya no es relevante debido a cambios en el contexto.

Errores típicos y cómo corregirlos

Error 1: "Set and forget" - revisar OKRs solo al final

Manifestación: el equipo define OKRs en enero y los revisa por primera vez en marzo, descubriendo que varios están en rojo sin posibilidad de recuperación.

Por qué ocurre: los check-ins se perciben como overhead burocrático y se posponen ante la presión del trabajo diario.

Corrección: integra los check-ins con el ritmo natural del equipo (por ejemplo, en la revisión semanal de producto). Define señales tempranas de riesgo para cada KR y acuerda quién es responsable de actualizarlas.

Error 2: check-ins que son solo reportes sin decisiones

Manifestación: el check-in consiste en leer números y estados, pero termina sin ninguna acción acordada ni decisión tomada.

Por qué ocurre: es más fácil informar que decidir. Tomar decisiones requiere confrontar problemas y hacer trade-offs incómodos.

Corrección: estructura el check-in para que termine siempre con acciones. Pregunta obligatoria al final: "¿Qué vamos a hacer diferente esta semana? ¿Quién es responsable de qué?".

Error 3: maquillar datos para parecer "en verde"

Manifestación: el equipo ajusta interpretaciones o definiciones para que los KRs parezcan mejor de lo que están, evitando conversaciones difíciles.

Por qué ocurre: hay miedo a las consecuencias de reportar mal progreso, especialmente si los OKRs están vinculados (incorrectamente) a evaluaciones de desempeño.

Corrección: crea un ambiente donde reconocer problemas temprano sea valorado, no penalizado. Los OKRs deben ser herramientas de aprendizaje, no de control. Si descubres que un KR está en riesgo, eso es información valiosa que permite actuar.

6. Validación y aprendizaje

Qué vas a conseguir

Al completar este capítulo serás capaz de:

  • Definir KRs de validación para fases de incertidumbre cuando no hay métricas históricas.
  • Diseñar OKRs que midan reducción de riesgo antes de comprometer recursos de construcción.
  • Aceptar y comunicar el "aprendizaje negativo" (invalidar hipótesis) como un resultado valioso.
  • Evitar la trampa de medir ejecución de actividades en lugar de insights generados.
  • Crear objetivos para iniciativas de discovery que sean verificables y útiles.

Conceptos clave

OKRs en contextos de alta incertidumbre

Cuando trabajas en productos nuevos o funcionalidades innovadoras, no tienes datos históricos sobre los que basar tus KRs. No sabes qué métrica deberías mover porque todavía no sabes qué va a funcionar. En estos contextos, los OKRs tradicionales orientados a métricas de negocio no aplican directamente.

La solución es definir OKRs de aprendizaje: objetivos cuya medida de éxito es la reducción de incertidumbre, no el movimiento de una métrica de negocio.

KRs de validación: midiendo aprendizaje

Un KR de validación mide si has obtenido evidencia suficiente para tomar una decisión. En lugar de "Aumentar la conversión de X a Y", el KR podría ser "Validar o invalidar la hipótesis de que los usuarios pagarían por [funcionalidad], con al menos 20 entrevistas cualificadas y un test de concepto con tasa de conversión definida".

La clave es que el criterio de éxito está definido antes de empezar: qué señal considerarías suficiente para continuar, qué señal te llevaría a pivotar, y qué señal te haría abandonar la iniciativa.

El aprendizaje negativo como éxito

Invalidar una hipótesis es un resultado valioso. Si después de 12 entrevistas descubres que los usuarios no ven valor en tu propuesta, eso no es un fracaso: es información que te ahorra meses de construcción innecesaria.

La tentación es maquillar los resultados negativos para que parezcan positivos, o simplemente no reportarlos. Esto destruye el valor de los OKRs. Un equipo que aprende rápido qué no funciona es más valioso que uno que construye mucho sin validar.

OKRs para reducción de riesgo

Tipos de riesgo a validar

  • Riesgo de deseabilidad: ¿Los usuarios quieren esto? ¿Resuelve un problema real?
  • Riesgo de factibilidad: ¿Podemos construirlo con la tecnología y recursos disponibles?
  • Riesgo de viabilidad: ¿Tiene sentido económico? ¿Es sostenible?

Proceso para definir OKRs de discovery

  1. Declara las hipótesis críticas a validar. ¿Qué asumes que es verdad y que, si no lo fuera, cambiaría tu decisión?

  2. Define los criterios de validación e invalidación. ¿Qué señal considerarías suficiente para decir "confirmado" o "descartado"?

  3. Elige el método mínimo para obtener evidencia. ¿Cuál es la forma más rápida y barata de aprender?

  4. Redacta el KR como criterio de validación. Por ejemplo: "Validar la hipótesis de [X] con al menos [Y] evidencias que cumplan [criterio Z]".

  5. Planifica cómo documentarás y comunicarás los hallazgos.

El aprendizaje negativo como resultado válido

Cómo tratar el aprendizaje negativo

  1. Documenta el resultado honestamente. Describe qué se probó, qué se aprendió, y por qué la hipótesis no se sostuvo.

  2. Extrae las implicaciones para el roadmap. ¿Qué iniciativas deberían eliminarse o replantearse?

  3. Comunica el valor del aprendizaje. El equipo ahorró tiempo y recursos al no construir algo que no hubiera funcionado.

  4. Propón el siguiente paso. ¿Hay una hipótesis alternativa que probar? ¿Es momento de pivotar a otro problema?

Errores típicos y cómo corregirlos

Error 1: exigir ROI inmediato a iniciativas de innovación

Manifestación: un stakeholder pide métricas de revenue para un producto que todavía está en fase de discovery y no tiene usuarios reales.

Por qué ocurre: es natural querer ver retorno de la inversión, pero aplicar métricas de negocio maduro a productos inciertos es prematuro.

Corrección: explica las fases del producto y propón métricas apropiadas para cada fase. En discovery, el éxito es aprender rápido, no generar revenue.

Error 2: no poner objetivos a la fase de research

Manifestación: el equipo hace discovery sin KRs específicos, dedicando tiempo a entrevistas y análisis sin un criterio claro de cuándo habrán terminado o qué decisiones tomarán.

Por qué ocurre: el research se percibe como actividad exploratoria que no puede comprometerse a resultados específicos.

Corrección: define KRs de aprendizaje: qué hipótesis vas a validar, con qué método, y qué criterio usarás para decidir el siguiente paso.

Error 3: medir ejecución de entrevistas en lugar de insights validados

Manifestación: el KR es "Realizar 30 entrevistas" en lugar de "Validar o invalidar las 3 hipótesis críticas de la propuesta de valor".

Por qué ocurre: es más fácil medir actividad (entrevistas hechas) que resultado (decisiones informadas por aprendizaje).

Corrección: reformula el KR para que el criterio de éxito sea el aprendizaje accionable, no el volumen de actividad. Pregunta: "Si hacemos 30 entrevistas y no cambia ninguna decisión, ¿habremos tenido éxito?".

7. Trampas del "feature factory" y cultura

Qué vas a conseguir

Al completar este capítulo serás capaz de:

  • Detectar señales de sandbagging (metas deliberadamente fáciles) y proponer intervenciones.
  • Argumentar por qué ligar OKRs a bonos individuales distorsiona el sistema.
  • Identificar la falta de foco como antipatrón sistémico y proponer límites prácticos.
  • Reconocer cuando un equipo opera como "feature factory" y facilitar la transición a orientación por outcomes.
  • Evaluar si los OKRs de una organización funcionan como herramienta de aprendizaje o de control.

Conceptos clave

La "feature factory" y sus síntomas

Una "feature factory" es una organización de producto que mide el éxito por velocidad y volumen de entrega, no por impacto generado. Los síntomas incluyen: KRs que miden porcentaje de completitud de tareas, roadmaps que definen fechas de entrega sin métricas de éxito, y equipos que celebran deploys sin validar cambios en comportamiento del usuario.

Esta cultura emerge cuando los incentivos están mal alineados: si se recompensa la entrega y se penaliza la incertidumbre, los equipos optimizarán para producir outputs predecibles en lugar de outcomes valiosos.

Sandbagging: metas deliberadamente fáciles

El sandbagging ocurre cuando los equipos proponen metas que saben que cumplirán sin esfuerzo significativo. Surge especialmente cuando los OKRs están vinculados a consecuencias negativas (bonos reducidos, mala evaluación) por incumplimiento.

La lógica es perversa pero comprensible: si el sistema castiga no cumplir, el incentivo racional es prometer poco. El resultado es una organización que sistemáticamente se pone metas por debajo de su capacidad real.

OKRs y compensación individual

Vincular OKRs directamente a bonos individuales es uno de los errores más dañinos que una organización puede cometer. El problema es que crea incentivos contraproducentes: metas conservadoras, falta de colaboración entre equipos, y maquillaje de datos para asegurar el pago.

Los OKRs funcionan mejor como herramienta de aprendizaje y alineamiento, no como mecanismo de control y evaluación. La evaluación de desempeño individual debería basarse en otros factores (calidad del trabajo, colaboración, crecimiento) separados del cumplimiento de OKRs.

Antipatrones estructurales

Demasiados objetivos y KRs

Cuando un equipo tiene 10+ KRs, ha perdido el propósito de los OKRs. En lugar de foco estratégico, hay dispersión. El equipo hace un poco de todo sin mover significativamente ninguna métrica.

El límite práctico recomendado es 2-3 objetivos con 2-4 KRs cada uno por trimestre. Si no puedes priorizar, todo se convierte en prioridad, que es lo mismo que nada lo sea.

Copiar OKRs sin contexto

Los OKRs de Google, Spotify o cualquier empresa exitosa no son plantillas transferibles. Cada organización tiene un contexto diferente: mercado, madurez, recursos, cultura. Copiar OKRs de otros sin adaptarlos lleva a objetivos desconectados de la realidad local.

OKRs como herramienta de control

Cuando los OKRs se usan para vigilar a los empleados y justificar decisiones de recursos humanos, pierden su valor como instrumento de gestión estratégica. Los equipos aprenden a manipular el sistema en lugar de usarlo honestamente.

Señales de alerta y cómo intervenir

Señal de alerta Qué indica Intervención
KRs propuestos muy por debajo del histórico Posible sandbagging Comparar con línea base y preguntar por las palancas
Más de 8 KRs por equipo Falta de priorización Consolidar y reducir, comunicando qué no se hará
Discusión de bonos durante el planning de OKRs OKRs ligados a compensación Separar los procesos y explicar el propósito distinto
Todos los KRs en verde siempre Metas fáciles o maquillaje Revisar nivel de ambición y cultura de honestidad
Celebración de deploys sin métricas Cultura de feature factory Introducir métricas de impacto en la definición de "hecho"

Errores típicos y cómo corregirlos

Error 1: usar OKRs como herramienta de control de empleados

Manifestación: los managers usan el cumplimiento de OKRs para justificar decisiones de promoción, despido o bonos individuales.

Por qué ocurre: es tentador tener una métrica "objetiva" para evaluar personas.

Corrección: separa explícitamente el sistema de OKRs del sistema de evaluación de desempeño. Los OKRs son para equipos y productos; la evaluación individual debe considerar otros factores.

Error 2: tener demasiados KRs por equipo

Manifestación: el documento de OKRs tiene 12+ KRs porque nadie quiso decir que no a ninguna métrica importante.

Por qué ocurre: es políticamente más fácil incluir todo que priorizar y dejar cosas fuera.

Corrección: aplica un límite estricto (por ejemplo, máximo 3 objetivos con 3 KRs cada uno). Revisa qué KRs realmente cambian decisiones y elimina los demás.

Error 3: copiar OKRs de otras empresas sin adaptar

Manifestación: el equipo implementa OKRs "tipo Google" sin considerar que su contexto, tamaño y madurez son completamente diferentes.

Por qué ocurre: es más fácil copiar una práctica "probada" que diseñar una adaptada al contexto propio.

Corrección: usa los principios de OKRs como guía, pero define objetivos y métricas específicos para tu realidad. Pregunta: "¿Qué necesita nuestra organización ahora?" en lugar de "¿Qué hacen las empresas famosas?".

Cierre y síntesis

Relaciones entre los conceptos clave

                    ┌─────────────────────────────────────┐
                    │   ESTRATEGIA DE LA ORGANIZACIÓN     │
                    └─────────────────┬───────────────────┘
                                      │
                                      ▼
┌─────────────────────────────────────────────────────────────────────┐
│                         OBJETIVO (Cualitativo)                      │
│        Dirección aspiracional: ¿Qué queremos lograr?                │
└─────────────────────────────────┬───────────────────────────────────┘
                                  │
                                  ▼
┌─────────────────────────────────────────────────────────────────────┐
│                     KEY RESULTS (Cuantitativos)                     │
│              De X a Y en fecha Z: ¿Cómo sabremos que lo logramos?   │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐           │
│  │   Leading    │───▶│  Intermedia  │───▶│   Lagging    │           │
│  │ (Predictivo) │    │   (Cadena)   │    │ (Resultado)  │           │
│  └──────────────┘    └──────────────┘    └──────────────┘           │
└─────────────────────────────────┬───────────────────────────────────┘
                                  │
                                  ▼
┌─────────────────────────────────────────────────────────────────────┐
│                           ROADMAP                                   │
│         Iniciativas priorizadas según impacto en KRs                │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐           │
│  │  Experimento │    │    Build     │    │ Descartado/  │           │
│  │ (Validación) │    │  (Delivery)  │    │  Postergado  │           │
│  └──────────────┘    └──────────────┘    └──────────────┘           │
└─────────────────────────────────┬───────────────────────────────────┘
                                  │
                                  ▼
┌─────────────────────────────────────────────────────────────────────┐
│                          CHECK-INS                                  │
│           Revisión periódica: datos → confianza → decisiones        │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐           │
│  │  Perseverar  │    │   Pivotar    │    │  Abandonar   │           │
│  └──────────────┘    └──────────────┘    └──────────────┘           │
└─────────────────────────────────────────────────────────────────────┘

Síntesis de principios operativos

  1. Outcomes sobre outputs: define el éxito por el impacto generado, no por lo entregado. Pregunta siempre: "Si desplegamos esto y nada cambia, ¿habremos tenido éxito?".

  2. Métricas que permitan actuar: combina indicadores leading (que puedes mover en semanas) con lagging (que importan al negocio). Evita métricas vanidosas que solo crecen.

  3. Precisión en la redacción: usa el formato "De X a Y en fecha Z". Define operativamente cómo se mide. Si no puedes cuantificarlo, probablemente no puedes gestionarlo.

  4. El roadmap sirve a los OKRs: las iniciativas entran al roadmap porque impactan KRs, no por inercia ni compromiso político. Aprende a decir "no" con el lenguaje de los trade-offs.

  5. Check-ins que generan decisiones: revisar OKRs no es reportar números; es decidir qué hacer diferente. Si el check-in termina sin acciones, fue una reunión vacía.

  6. Aprendizaje como resultado válido: en contextos de incertidumbre, validar o invalidar hipótesis es un outcome valioso. El aprendizaje negativo te ahorra construir lo que no funciona.

  7. Cultura sobre proceso: los OKRs son herramientas de aprendizaje y alineamiento, no de control. Sepáralos de bonos individuales. Valora la honestidad sobre el optimismo.

Recomendaciones de estudio

Para consolidar tu dominio del tema, te recomendamos:

  • Practica la reformulación: toma cualquier solicitud de feature que recibas y transfórmala en un OKR orientado a outcome. Hazlo sistemáticamente hasta que sea automático.

  • Diagnostica OKRs existentes: revisa los OKRs de tu equipo u organización con los criterios de esta guía. Identifica qué mejorarías y por qué.

  • Experimenta con check-ins: si tus check-ins actuales son solo reportes, introduce la pregunta "¿qué decisión tomamos?" y observa cómo cambia la conversación.

  • Enfrenta las conversaciones difíciles: la habilidad más valiosa de un profesional de producto es decir "no" con fundamento. Practica usando el lenguaje de trade-offs.

Anexos

Anexo A: glosario

Baseline: valor de partida de una métrica antes de comenzar a trabajar hacia el objetivo.

Check-in: sesión periódica de revisión de OKRs para actualizar progreso y tomar decisiones.

Feature factory: cultura organizacional que mide éxito por velocidad/volumen de entrega, no por impacto

Guardrail: métrica que monitoreas para asegurar que no se deteriore mientras persigues otro objetivo.

Key Result (KR): medida cuantitativa que indica el progreso hacia el objetivo.

Lagging indicator: métrica de resultado final que refleja el éxito pero llega tarde para corregir.

Leading indicator: métrica predictiva que anticipa resultados y permite actuar a tiempo.

Métrica vanidosa: indicador que siempre crece y da falsa sensación de progreso.

Objetivo: dirección cualitativa y aspiracional que indica qué se quiere lograr.

OKR: objectives and Key Results: sistema de definición de objetivos y métricas.

Outcome: resultado o cambio observable: comportamiento del usuario o impacto en negocio.

Output: entregable o producto del trabajo: funcionalidad, documento, despliegue.

Sandbagging: práctica de proponer metas deliberadamente fáciles para asegurar cumplimiento.

Target: valor objetivo al que se aspira llegar con un KR.

Trade-off: intercambio o sacrificio entre opciones; lo que se deja de hacer al priorizar algo.

Anexo B: plantilla de diagnóstico de OKRs

Usa esta plantilla para evaluar un set de OKRs existente:

1. Análisis del objetivo

  • [ ] ¿Es cualitativo e inspirador?
  • [ ] ¿Describe qué se quiere lograr sin imponer cómo?
  • [ ] ¿Es interpretado de la misma manera por todos los involucrados?
  • [ ] ¿Evita cifras que deberían estar en los KRs?

2. Análisis de cada Key Result

  • [ ] ¿Tiene formato "De X a Y en fecha Z"?
  • [ ] ¿El baseline (X) está documentado y es conocido?
  • [ ] ¿El target (Y) es ambicioso pero alcanzable?
  • [ ] ¿Se puede medir objetivamente?
  • [ ] ¿Mide un resultado (outcome) y no una tarea (output)?
  • [ ] ¿Múltiples soluciones podrían lograrlo?
  • [ ] ¿Incluye métricas leading, no solo lagging?
  • [ ] ¿Evita métricas acumuladas que siempre suben?

3. Análisis del conjunto

  • [ ] ¿Hay entre 2-4 KRs por objetivo?
  • [ ] ¿El total de KRs del equipo es manejable (≤10)?
  • [ ] ¿Están claras las dependencias con otros equipos?
  • [ ] ¿Hay OKRs compartidos donde corresponde?
  • [ ] ¿El roadmap está alineado con los KRs?

4. Análisis de la cultura

  • [ ] ¿Los OKRs están separados de compensación individual?
  • [ ] ¿Hay espacio para honestidad sobre riesgos?
  • [ ] ¿Se valora el aprendizaje negativo?
  • [ ] ¿Los check-ins generan decisiones, no solo reportes?

Resultado del diagnóstico:

Fortalezas identificadas:

Áreas de mejora prioritarias:

Acciones recomendadas: