Esto tiene que hacerse, sí o sí.

“La solución no es ‘ganar’ al product owner sino rediseñar cómo decidimos para que la evidencia pese más que la jerarquía.”

Estás en la reunión con un plan razonable, con la visión del problema del usuario que hay que resolver y lo que cabe en el sprint, cuando de pronto alguien pronuncia la frase fatídica: “Esto tiene que entrar; lo pide dirección”. El equipo traga saliva, la agenda se descuadra y la palabra “prioridad” ya no refleja “valor”, sino “quién lo pide”. El objetivo pasa a ser cumplir instrucciones.

El patrón es reconocible: decisiones unilaterales, cambios de alcance sin evidencia y priorización por jerarquía. Y no es por mala intención, sino por urgencias reales o percibidas, por miedo a perder una ventana de oportunidad o por presión de fechas; pero el resultado es el mismo: se deja de hablar de impacto y se empieza a hablar de “lo que hay que hacer”. Las consecuencias son dispersión del foco, aparición de deuda técnica y sensación de correr sin avanzar.

La solución no es una confrontación personal, sino replantear el mecanismo de decisión.

La primera palanca es una pregunta sencilla que rara vez falla: “¿Cuál es el problema del usuario que resolvemos y cómo sabremos si ha merecido la pena? Si no tiene una respuesta clara, no hay priorización posible.

La segunda palanca es el tamaño de lo que se quiere hacer. Frente a una imposición, la tentación es pelear todo o nada. Es más útil proponer una versión mínima que valide la hipótesis con riesgo bajo y aprendizaje alto. No es un truco para entregar menos, es una estrategia para decidir mejor: ya no debatimos si “entra o no”, sino cuánto es necesario construir para obtener evidencia. Ese cambio de marco reduce la temperatura y devuelve la conversación al terreno de lo medible.

La tercera palanca es: la calidad como guardarraíl, no caer en la tentación de “lo metemos y ya lo arreglaremos”. Si el incremento no cumple el estándar, lo que hacemos es dar una patada el problema y nos aparecerá en el futuro con intereses. Cuando se entiende que la calidad es indispensable en la “definición de hecho” y no como capricho del equipo, el debate pasa de “recortar calidad” a “recortar alcance de forma inteligente”.

Pero esto no funciona si en cada discusión se vuelve a empezar desde cero. Por eso se necesita un registro visible de decisiones. Fecha, decisión, evidencia que la sustenta, responsable y próximos pasos. Sin solemnidad, pero con consistencia. Se trata de disponer de una memoria organizativa que desplace el debate del “yo dije/tú dijiste” al “esto hemos aprendido y esto hemos decidido”.

Si el patrón persiste, el problema ya no es de proceso, es de gobernanza. Un buen product owner no es un “jefe del equipo” ni un “gestor de tareas”; es el responsable de maximizar el valor y para eso necesita dos cosas: empoderamiento real para decir “no” y acceso directo a clientes y datos. Si las tiene porque en realidad hay varios “POs” de facto (ventas, dirección, cliente clave), la decisión se diluye y termina mandando la jerarquía. En este caso es necesario concretar quién decide qué, con qué criterios y cómo se valida. No es burocracia; es claridad.

En paralelo, se necesitan números y no voces que metan presión. El “coste de demora” y enfoques como WSJF ayudan a hacer explícitos los trade-offs: “Si priorizamos A, se retrasa B y eso cuesta X”. Si los incentivos premian el “output” (cantidad entregada) en lugar de los “outcomes” (impacto logrado), se valora el hacer “más cosas” por encima de los “mejores resultados”. Cambiar esto puede alterar bonus u objetivos; por eso la review con propósito es clave: no es una demo para aplaudir, sino un espacio para decidir —seguir, parar o pivotar— a la luz de la evidencia.

Todo esto hay que aterrizarlo en momentos tensos. Sirven guiones breves. Ante una urgencia impuesta, reformula: “Entiendo la necesidad. Para elegir bien, ¿qué métrica objetivo movemos y cuánto? Si entra hoy, ¿qué sale y qué coste de demora asumimos allí?”. Si la respuesta es “sí o sí”, es útil llevar la discusión al experimento: “Propongo una versión mínima que valide la hipótesis en dos semanas. Medimos X; si pasa el umbral, escalamos; si no, paramos”. Y si falta evidencia, hay que poner un freno seguro: “Ahora apostaríamos a ciegas. Mejor un test de cinco días con 100 usuarios: si la tasa de activación supera el 20%, seguimos”.

Las cosas cambiarán al cambiar las métricas: tasa de activación, retención, reducción de costes, ingresos incrementales, lead time, variabilidad, defectos en producción, sostenibilidad del ritmo. Se trata de números que hablan de producto y de salud del sistema.