El Product Owner en Equips d'Enginyeria: Com Fer-ho Funcionar
El rol de Product Owner va ser dissenyat per a equips de funcionalitats que construeixen productes orientats a l'usuari. El PO parla amb els clients, entén els seus problemes, escriu històries que descriuen resultats desitjats, i l'equip d'enginyeria esbrина com construir-los. Quan funciona, és una separació neta de responsabilitats: el PO és propietari del "què" i el "per què", l'equip és propietari del "com".
Llavors intentes aplicar el mateix model a un equip de plataforma, un equip d'infraestructura, o qualsevol equip on la majoria del treball és profundament tècnic i invisible per als usuaris finals. El PO escriu històries com "Millorar el rendiment de la base de dades" perquè no entén els detalls. L'equip ignora les històries i treballa amb el backlog mental del tech lead. Les revisions de sprint es converteixen en teatre incòmode on els enginyers fan demos de coses que el PO no pot avaluar de manera significativa. Ningú és feliç.
He vist aquest patró repetir-se desenes de vegades. El problema no és el PO ni els enginyers. És que el model estàndard de PO no va ser dissenyat per a aquest context, i ningú l'adapta.
La Tensió Central
En un equip de funcionalitats, el PO aporta coneixement del domini que els enginyers no tenen. Coneix el client, el mercat, les restriccions de negoci. L'intercanvi de valor és clar: el PO proporciona context sobre què construir, els enginyers aporten experiència sobre com construir-ho.
En un equip d'enginyeria intensiva, aquesta dinàmica es trenca. Els "clients" poden ser altres equips d'enginyeria. El "producte" pot ser una passarel·la d'API, un pipeline de CI/CD, o una plataforma de dades. El coneixement del domini resideix amb els enginyers, no amb el PO. El PO és ara la persona amb menys context sobre en què hauria de treballar l'equip, que és exactament el contrari de com se suposa que ha de funcionar el rol.
Això crea tres modes de fallada específics:
El PO de goma. El PO cedeix completament al tech lead, aprovant qualsevol cosa que proposi l'equip sense aportació significativa. La planificació del sprint és una formalitat. El PO existeix sobre el paper per satisfer el procés però no afegeix cap valor.
El PO frustrat. El PO intenta aplicar els seus instints de producte però continua sent aturat. "No entens les restriccions tècniques." Se sent exclòs i respon desconnectant-se o afirmant autoritat a través de l'únic mecanisme que té: la prioritat.
El PO bloquejador. El PO insisteix a controlar la prioritat sense context tècnic. Desriorititza el treball tècnic crític perquè no s'associa a resultats de negoci visibles. S'acumula el deute tècnic, la plataforma es degrada i, finalment, alguna cosa falla en producció.
Patrons de Comunicació que Funcionen
La solució no és eliminar el PO dels equips d'enginyeria intensiva. És redefinir el que aporta el PO i com es comunica l'equip.
Traduir el treball tècnic en impacte de negoci
Cada peça de treball tècnic té una raó de negoci. La feina de l'equip és fer explícita aquesta raó. No com a exercici polític — com un esforç genuí per connectar el que s'està construint amb el per què importa.
Malament: "Refactoritzar el consumidor de la cua de missatges per utilitzar processament per lots." Millor: "Reduir la latència de processament de comandes de 12 segons a menys de 2 segons, que afecta directament la conversió al checkout."
Malament: "Migrar de Jenkins a GitHub Actions." Millor: "Reduir el nostre pipeline de desplegament de 45 minuts a 12 minuts, permetent que els equips llancin 3 vegades més freqüentment amb la mateixa confiança."
Això no és simplificar les coses. És completar el pensament. Els enginyers que poden articular l'impacte de negoci del seu treball tècnic són més efectius, independentment de qui sigui el seu PO.
Usar spike stories per a la incertesa
Quan l'equip no sap l'enfocament correcte, no fingeixis que ho sap. Una spike story és una tasca de recerca limitada en el temps amb un resultat definit: no codi funcional, sinó una recomanació.
"Spike: Avaluar tres enfocaments per al processament d'events en temps real. Resultat: ADR amb recomanació. Límit de temps: 3 dies."
El PO pot entendre i prioritzar això. Té un lliurable clar i una inversió de temps clara. Quan la spike s'acaba, l'equip i el PO discuteixen la recomanació conjuntament, i les històries d'implementació que segueixen estan millor definides perquè la incertesa s'ha resolt.
Establir un pressupost per a les tech stories
Aquest és el patró únic més efectiu que he vist per gestionar el treball tècnic dins d'un procés liderat per un PO. L'equip i el PO acorden una assignació fixa — típicament el 20% de la capacitat del sprint — dedicada a la millora tècnica que l'equip prioritza de manera independent.
Les regles són senzilles:
- L'equip tria el que entra al 20%. No cal l'aprovació del PO.
- L'equip comunica en què treballen i per què (transparència, no permís).
- El 20% és no negociable. No es pot arrabassar quan s'apropa un termini.
- El 80% restant segueix la priorització normal del PO.
Això funciona perquè elimina la negociació constant. El PO no ha d'entendre per què l'equip necessita actualitzar l'ORM o refactoritzar el middleware d'autenticació. Ja han acordat que el 20% de la capacitat és de l'equip per assignar. I l'equip no ha de justificar cada decisió tècnica a algú que no té el context per avaluar-la.
Drets de Decisió: Qui Decideix Què
L'ambigüitat sobre qui decideix què és la causa arrel de la majoria dels conflictes PO-enginyeria. Fes-ho explícit:
El PO decideix:
- Quins problemes de negoci resoldre i en quin ordre
- El moment del llançament en relació amb les necessitats de negoci
- Les compensacions d'abast quan el temps és limitat ("llança amb solució manual ara, automatitza més tard")
- Si una funcionalitat és "prou bona" des de la perspectiva de l'usuari
El tech lead decideix:
- Com implementar una solució
- Decisions d'arquitectura i tecnologia
- Estàndards de qualitat tècnica (cobertura de proves, requisits de revisió de codi)
- Si alguna cosa està tècnicament llesta per llançar (sense bugs crítics coneguts, rendiment acceptable)
Decideixen junts:
- Quina és la viabilitat dins d'un termini donat
- Quan el deute tècnic hauria de prioritzar-se sobre les funcionalitats
- Com gestionar els incidents i el seu seguiment
- Assignació de la capacitat de l'equip entre treball de funcionalitats i treball tècnic
Escriu-ho. Posa-ho a la wiki de l'equip. Fes-hi referència quan sorgeixin conflictes. La majoria de desacords entre POs i tech leads provenen d'una de les parts prenent una decisió que l'altra creu que és del seu domini. Un marc explícit ho impedeix.
Quan el PO Diu "Simplement Fes-ho Funcionar"
Tots els enginyers ho han sentit. Un PO que no entén la complexitat tècnica ho descarta: "No em preocupa la implementació, fes-ho funcionar per dijous."
La temptació és enfadar-se o cedir i prendre dreceres. Cap de les dues ajuda. El que funciona és traduir la restricció en opcions.
"Entenc que necessites això per dijous. Aquí hi ha tres opcions:
- Solució completa: 2 setmanes. Gestiona tots els casos límit, està ben provada, llesta per a producció.
- Solució del 80%: per dijous. Cobreix el flux principal, necessita intervenció manual per als casos límit, afegeix 3 dies de deute tècnic que haurem d'adreçar el pròxim sprint.
- Prototip: per dimecres. Demostra el concepte, no és segura per a producció, caldria reconstruir-la."
Ara el PO té una decisió real que prendre. Pot triar l'opció 2, cosa que és acceptable — però està prenent una compensació informada, no una demanda ignorant. I el deute tècnic queda registrat, no amagat.
El Model de Partenariat
Les millors relacions PO-enginyeria que he vist funcionen com un partenariat entre el PO i el tech lead, no com una jerarquia on un informa a l'altre.
Parlen diàriament, no només en les cerimònies. El tech lead avisa al PO sobre riscos tècnics emergents. El PO dóna al tech lead senyals anticipades sobre les prioritats de negoci canviants. Presenten un front unificat a l'equip i resolen els seus desacords en privat.
Això requereix dues coses: un PO que respecti genuïnament la complexitat de l'enginyeria sense necessitar entendre cada detall, i un tech lead que respecti genuïnament el context de negoci sense descartar-lo com "no tècnic".
A Conectia, els nostres enginyers s'uneixen a equips que tenen tota mena de dinàmiques de PO — des de partnerships que funcionen perfectament fins a equips on la relació necessita treball. Com que els nostres enginyers són seniors, saben com comunicar decisions tècniques en termes de negoci, com fer contraproposta respectuosament quan les prioritats no contemplen la realitat tècnica, i com construir la confiança que fa productiva la relació PO-enginyeria. Aquesta no és una habilitat de procés — és una habilitat de senioritat.
El rol de PO en equips d'enginyeria intensiva no és trencat. Simplement necessita ser adaptat. I l'adaptació no és complicada: patrons de comunicació clars, drets de decisió explícits, i dos líders que respecten el domini de l'altre.
Necessites enginyers seniors que sàpiguen treballar amb els product owners, no al voltant d'ells? Parla amb un CTO — els nostres enginyers de LATAM aporten les habilitats de comunicació i la profunditat tècnica que fan que els equips interfuncionals realment funcionin.
