El Product Owner en equipos muy técnicos: cómo hacer que funcione
El rol de Product Owner se diseñó para equipos que construyen funcionalidades de cara al usuario. El PO habla con los clientes, entiende sus problemas, escribe historias que describen el resultado deseado, y el equipo de ingeniería resuelve cómo construirlo. Cuando funciona, es una separación limpia de responsabilidades: el PO es dueño del qué y del porqué; el equipo, del cómo.
Luego intentas aplicar el mismo modelo a un equipo de plataforma, de infraestructura o a cualquier equipo donde la mayor parte del trabajo es profundamente técnica e invisible para el usuario final. El PO escribe historias como "Mejorar el rendimiento de la base de datos" porque no domina los detalles. El equipo ignora esas historias y trabaja con el backlog mental del tech lead. Las sprint reviews se convierten en un teatro incómodo donde los ingenieros enseñan demos que el PO no puede evaluar con criterio. Nadie está contento.
He visto este patrón repetirse decenas de veces. El problema no es el PO ni son los ingenieros. Es que el modelo estándar de PO no se diseñó para este contexto, y nadie lo adapta.
El PO pasa a ser quien menos contexto tiene
En un equipo orientado a funcionalidades, el PO aporta un conocimiento del dominio que los ingenieros no tienen. Conoce al cliente, el mercado, las restricciones del negocio. El intercambio de valor está claro: el PO pone el contexto sobre qué construir; los ingenieros, la experiencia sobre cómo construirlo.
En un equipo muy técnico, esa dinámica se rompe. Los "clientes" pueden ser otros equipos de ingeniería. El "producto" puede ser un API gateway, un pipeline de CI/CD o una plataforma de datos. El conocimiento del dominio vive en los ingenieros, no en el PO. El PO pasa a ser la persona con menos contexto sobre lo que el equipo debería estar haciendo, justo lo contrario de cómo se supone que funciona el rol.
Esto produce tres modos de fallo concretos:
El PO que firma sin mirar. El PO delega por completo en el tech lead y aprueba lo que el equipo proponga sin aportar nada sustancial. La sprint planning es un trámite. El PO existe sobre el papel para cumplir con el proceso, pero no añade valor.
El PO frustrado. El PO intenta aplicar su instinto de producto, pero se topa una y otra vez con un muro: "no entiendes las restricciones técnicas". Se siente excluido y reacciona o bien desconectándose, o bien imponiendo su autoridad con la única palanca que le queda: la prioridad.
El PO que bloquea. El PO se empeña en controlar la prioridad sin contexto técnico. Desprioriza trabajo técnico crítico porque no se traduce en resultados de negocio visibles. La deuda técnica se acumula, la plataforma se degrada y, tarde o temprano, algo revienta en producción.
Patrones de comunicación que funcionan
El arreglo tentador es eliminar al PO y dejar que el tech lead sea el dueño del backlog. Y concedo el punto donde toca: en un equipo pequeño de herramientas internas con un único stakeholder, eso funciona de verdad. Pero la mayoría de los equipos de plataforma dan servicio a varios equipos con demandas que compiten entre sí, y alguien tiene que asumir ese arbitraje con el negocio — un tech lead que lo absorbe en solitario acaba haciendo dos trabajos mal. La solución no es eliminar al PO. Es redefinir qué aporta el PO y cómo se comunica el equipo.
Traducir el trabajo técnico a impacto de negocio
Todo trabajo técnico tiene una razón de negocio detrás. El trabajo del equipo es hacerla explícita. No como ejercicio político — como un esfuerzo genuino por conectar lo que están construyendo con el porqué importa.
Mal: "Refactorizar el consumidor de la cola de mensajes para procesar en lotes." Mejor: "Reducir la latencia de procesamiento de pedidos de 12 segundos a menos de 2, lo que afecta directamente a la conversión del checkout."
Mal: "Migrar de Jenkins a GitHub Actions." Mejor: "Bajar nuestro pipeline de despliegue de 45 minutos a 12, lo que permite a los equipos lanzar el triple de veces con la misma confianza."
Esto no es simplificar el mensaje. Es completar el pensamiento. Un ingeniero capaz de articular el impacto de negocio de su trabajo técnico es más efectivo, sea quien sea su PO.
Usar historias de spike para la incertidumbre
Cuando el equipo no tiene claro el enfoque correcto, no hay que fingir que lo tiene. Una historia de spike es una tarea de investigación con tiempo acotado y un resultado definido: no código funcional, sino una recomendación.
"Spike: evaluar tres enfoques para procesar eventos en tiempo real. Resultado: ADR con recomendación. Tiempo acotado: 3 días."
Esto el PO lo puede entender y priorizar. Tiene un entregable claro y una inversión de tiempo clara. Cuando el spike termina, el equipo y el PO discuten juntos la recomendación, y las historias de implementación que vienen después quedan mejor delimitadas porque la incertidumbre ya está resuelta.
Establecer un presupuesto de historias técnicas
Este es el patrón más efectivo que he visto para gestionar el trabajo técnico dentro de un proceso liderado por un PO. El equipo y el PO acuerdan una asignación fija — típicamente el 20% de la capacidad del sprint — dedicada a mejora técnica que el equipo prioriza por su cuenta.
Las reglas son simples:
- El equipo elige qué entra en ese 20%. Sin aprobación del PO.
- El equipo comunica en qué está trabajando y por qué (transparencia, no permiso).
- El 20% no se negocia. No se toca cuando se acerca una fecha de entrega.
- El 80% restante sigue la priorización normal del PO.
Funciona porque elimina la negociación constante. El PO no tiene que entender por qué el equipo necesita actualizar el ORM o refactorizar el middleware de autenticación: ya ha acordado que el 20% de la capacidad la asigna el equipo. Y el equipo no tiene que justificar cada decisión técnica ante alguien que no tiene contexto para evaluarla.
Derechos de decisión: por escrito
La ambigüedad sobre quién decide qué es la causa raíz de la mayoría de conflictos entre PO e ingeniería. Hazlo explícito:
El PO decide:
- Qué problemas de negocio resolver y en qué orden
- El momento de cada lanzamiento respecto a las necesidades del negocio
- Los recortes de alcance cuando el tiempo aprieta ("salimos ahora con un workaround manual, automatizamos después")
- Si una funcionalidad está "suficientemente acabada" desde la perspectiva del usuario
El tech lead decide:
- Cómo implementar una solución
- Las elecciones de arquitectura y tecnología
- Los estándares de calidad técnica (cobertura de tests, requisitos de revisión de código)
- Si algo está técnicamente listo para salir (sin bugs críticos conocidos, rendimiento aceptable)
Deciden juntos:
- Qué es viable dentro de un plazo dado
- Cuándo la deuda técnica debe priorizarse por encima de las funcionalidades
- Cómo gestionar los incidentes y su seguimiento
- El reparto de la capacidad del equipo entre trabajo de producto y trabajo técnico
Escríbelo. Ponlo en el wiki del equipo. Recurre a él cuando surja un conflicto. La mayoría de los desacuerdos entre POs y tech leads nacen de que una parte toma una decisión que la otra considera de su terreno. Un marco explícito lo evita.
Cuando el PO dice "tú haz que funcione"
Todo ingeniero lo ha oído alguna vez. Un PO que no entiende la complejidad técnica la despacha con un gesto: "la implementación me da igual, haz que funcione para el jueves".
La tentación es enfadarse, o ceder y recortar esquinas. Ninguna de las dos ayuda. Lo que funciona es traducir la restricción en opciones.
"Entiendo que lo necesitas para el jueves. Te planteo tres opciones:
- Solución completa: 2 semanas. Cubre todos los casos límite, está bien probada, lista para producción.
- Solución al 80%: para el jueves. Cubre el flujo principal, necesita intervención manual en los casos límite y añade 3 días de deuda técnica que tendremos que abordar el próximo sprint.
- Prototipo: para el miércoles. Demuestra el concepto, no es seguro para producción y habría que reconstruirlo."
Ahora el PO tiene una decisión real entre manos. Puede que elija la opción 2, y está bien — pero está asumiendo un trade-off informado, no imponiendo una exigencia a ciegas. Y la deuda técnica queda registrada, no escondida.
Colaboración, no jerarquía
Las mejores relaciones entre PO e ingeniería que he visto funcionan como una colaboración entre el PO y el tech lead, no como una jerarquía donde uno reporta al otro.
Hablan a diario, no solo en las ceremonias. El tech lead avisa al PO de los riesgos técnicos que asoman. El PO da al tech lead señales tempranas de que las prioridades del negocio están cambiando. Presentan un frente común ante el equipo y resuelven sus desacuerdos en privado.
Esto exige dos cosas: un PO que respete de verdad la complejidad de la ingeniería sin necesitar entender cada detalle, y un tech lead que respete de verdad el contexto de negocio sin despacharlo como "cosas no técnicas".
En Conectia, nuestros ingenieros se incorporan a equipos con dinámicas de PO de todo tipo — desde colaboraciones que funcionan a la perfección hasta equipos donde la relación necesita trabajo. Como son senior, saben comunicar decisiones técnicas en términos de negocio, plantarse con respeto cuando las prioridades ignoran la realidad técnica y construir la confianza que hace productiva la relación entre PO e ingeniería. Eso no es una habilidad de proceso: es una habilidad de seniority.
El rol de PO en equipos muy técnicos no está roto. Solo hay que adaptarlo. Y la adaptación no es complicada: patrones de comunicación claros, derechos de decisión explícitos y dos líderes que respetan el terreno del otro.
¿Necesitas ingenieros senior que sepan trabajar con el product owner en lugar de sortearlo? Habla con un CTO.
