El product owner en equips molt tècnics: com fer que funcioni
El rol de product owner es va pensar per a equips de funcionalitats que construeixen producte de cara a l'usuari. El PO parla amb els clients, n'entén els problemes, escriu històries que descriuen el resultat que es vol, i l'equip d'enginyeria decideix com construir-lo. Quan funciona, és una separació de responsabilitats neta: el PO és l'amo del què i del perquè; l'equip, del com.
Després intentes aplicar el mateix model a un equip de plataforma, d'infraestructura o a qualsevol equip on la major part de la feina és profundament tècnica i invisible per a l'usuari final. El PO escriu històries com «Millorar el rendiment de la base de dades» perquè no en domina els detalls. L'equip ignora les històries i treballa a partir del backlog mental del tech lead. Les sprint reviews es converteixen en un teatre incòmode on els enginyers ensenyen coses que el PO no pot avaluar de debò. I no hi ha ningú content.
He vist aquest patró desenes de vegades. El problema no és el PO, i tampoc no són els enginyers. És que el model estàndard de PO no es va dissenyar per a aquest context, i ningú no l'adapta.
El PO passa a ser qui té menys context
En un equip de funcionalitats, el PO aporta un coneixement del domini que els enginyers no tenen. Coneix el client, el mercat, les restriccions del negoci. L'intercanvi de valor és clar: el PO posa el context sobre què cal construir; els enginyers, l'expertesa sobre com construir-ho.
En un equip molt tècnic, aquesta dinàmica es trenca. Els «clients» poden ser altres equips d'enginyeria. El «producte» pot ser un API gateway, un pipeline de CI/CD o una plataforma de dades. El coneixement del domini és a mans dels enginyers, no del PO. El PO passa a ser la persona amb menys context sobre què hauria de fer l'equip — exactament el contrari de com se suposa que ha de funcionar el rol.
D'aquí en surten tres modes de fallada molt concrets:
El PO que només posa el segell. Ho delega tot al tech lead i aprova el que l'equip proposi sense aportar-hi res. La sprint planning és pur tràmit. El PO existeix sobre el paper per complir el procés, però no afegeix cap valor.
El PO frustrat. Intenta aplicar el seu instint de producte i topa sempre amb el mateix mur: «No entens les restriccions tècniques.» Se sent exclòs i reacciona desconnectant-se o imposant-se amb l'única palanca que té: la prioritat.
El PO que bloqueja. S'entesta a controlar la prioritat sense context tècnic. Desprioritza feina tècnica crítica perquè no es tradueix en resultats de negoci visibles. El deute tècnic s'acumula, la plataforma es degrada i, tard o d'hora, alguna cosa peta a producció.
Patrons de comunicació que funcionen
La solució temptadora és eliminar el PO del tot i deixar que el tech lead sigui l'amo del backlog. I concedeixo el punt on toca: en un equip petit d'eines internes amb un sol stakeholder, això funciona de debò. Però la majoria d'equips de plataforma donen servei a diversos equips amb demandes que competeixen entre elles, i algú ha d'assumir aquest arbitratge davant del negoci — un tech lead que se'l carrega tot sol acaba fent malament dues feines. La solució no és treure el PO. És redefinir què hi aporta i com es comunica l'equip.
Traduir la feina tècnica a impacte de negoci
Tota feina tècnica té una raó de negoci al darrere. La feina de l'equip és fer-la explícita. No com a exercici polític, sinó com un esforç honest de connectar el que es construeix amb el perquè importa.
Malament: «Refactoritzar el consumidor de la cua de missatges perquè processi per lots.» Millor: «Reduir la latència de processament de comandes de 12 segons a menys de 2, cosa que afecta directament la conversió al checkout.»
Malament: «Migrar de Jenkins a GitHub Actions.» Millor: «Passar el pipeline de desplegament de 45 minuts a 12, perquè els equips puguin desplegar tres vegades més sovint amb la mateixa confiança.»
Això no és rebaixar el nivell. És acabar el pensament. Un enginyer que sap articular l'impacte de negoci de la seva feina tècnica és més efectiu, tingui el PO que tingui.
Fer servir spike stories per a la incertesa
Quan l'equip no sap quin és l'enfocament correcte, que no faci veure que ho sap. Una spike story és una tasca de recerca acotada en el temps amb un lliurable definit: no codi que funcioni, sinó una recomanació.
«Spike: avaluar tres enfocaments per processar esdeveniments en temps real. Lliurable: un ADR amb recomanació. Temps màxim: 3 dies.»
Això el PO ho pot entendre i prioritzar. Té un lliurable clar i una inversió de temps clara. Quan la spike acaba, equip i PO discuteixen plegats la recomanació, i les històries d'implementació que venen després queden més ben acotades perquè la incertesa ja s'ha resolt.
Establir un pressupost de tech stories
És el patró més efectiu que he vist per gestionar la feina tècnica dins d'un procés liderat per un PO. Equip i PO acorden una assignació fixa — normalment el 20% de la capacitat de cada sprint — dedicada a millora tècnica que l'equip prioritza pel seu compte.
Les regles són senzilles:
- L'equip tria què entra en aquest 20%. Sense aprovació del PO.
- L'equip explica en què treballa i per què (transparència, no permís).
- El 20% no es negocia. No es toca quan s'acosta un termini.
- El 80% restant segueix la priorització normal del PO.
Funciona perquè elimina la negociació constant. El PO no ha d'entendre per què cal actualitzar l'ORM o refactoritzar el middleware d'autenticació: ja ha acordat que el 20% de la capacitat és de l'equip. I l'equip no ha de justificar cada decisió tècnica davant d'algú que no té el context per avaluar-la.
Drets de decisió: posa'ls per escrit
L'ambigüitat sobre qui decideix què és l'arrel de la majoria de conflictes entre PO i enginyeria. Fes-ho explícit:
El PO decideix:
- Quins problemes de negoci es resolen i en quin ordre
- Quan es llança, en funció de les necessitats del negoci
- Les renúncies d'abast quan el temps mana («surt ara amb una solució manual; ho automatitzem després»)
- Si una funcionalitat és «prou bona» des del punt de vista de l'usuari
El tech lead decideix:
- Com s'implementa una solució
- Les tries d'arquitectura i de tecnologia
- Els estàndards de qualitat tècnica (cobertura de tests, requisits de revisió de codi)
- Si una cosa està tècnicament a punt per sortir (cap bug crític conegut, rendiment acceptable)
Decideixen junts:
- Què és viable dins d'un termini determinat
- Quan el deute tècnic passa per davant de les funcionalitats
- Com es gestionen els incidents i el seu seguiment
- Com es reparteix la capacitat de l'equip entre funcionalitats i feina tècnica
Posa-ho per escrit. Penja-ho a la wiki de l'equip. Recupera-ho quan hi hagi conflicte. La majoria de desacords entre POs i tech leads neixen del fet que una part pren una decisió que l'altra considera del seu terreny. Un marc explícit evita aquests xocs.
Quan el PO diu «fes que funcioni i prou»
Tots els enginyers ho hem sentit alguna vegada. Un PO que no entén la complexitat tècnica ho despatxa amb un gest: «La implementació m'és igual; fes que funcioni per dijous.»
La temptació és enfadar-se, o bé cedir i retallar pel camí. Cap de les dues coses no ajuda. El que funciona és convertir la restricció en opcions.
«Entenc que ho necessites per dijous. Tens tres opcions:
- Solució completa: 2 setmanes. Cobreix tots els casos límit, està ben provada i és a punt per a producció.
- Solució del 80%: per dijous. Cobreix el flux principal, demana intervenció manual als casos límit i afegeix 3 dies de deute tècnic que haurem de resoldre en el següent sprint.
- Prototip: per dimecres. Demostra el concepte, no és apte per a producció i s'hauria de reconstruir.»
Ara el PO té una decisió de debò entre mans. Potser tria l'opció 2, i no passa res — però estarà assumint una renúncia amb coneixement de causa, no fent una exigència a cegues. I el deute tècnic queda escrit, no amagat.
Tàndem, no jerarquia
Les millors relacions PO-enginyeria que he vist funcionen com un tàndem entre el PO i el tech lead, no com una jerarquia on l'un reporta a l'altre.
Parlen cada dia, no només a les cerimònies. El tech lead avisa el PO dels riscos tècnics que apunten. El PO dona al tech lead senyals primerenques quan les prioritats de negoci es mouen. Davant de l'equip presenten un front comú, i els desacords els resolen en privat.
Això demana dues coses: un PO que respecti de debò la complexitat de l'enginyeria sense necessitat d'entendre'n cada detall, i un tech lead que respecti de debò el context de negoci sense despatxar-lo com a «no tècnic».
A Conectia, els nostres enginyers s'incorporen a equips amb tota mena de dinàmiques de PO — des de tàndems que funcionen perfectament fins a equips on la relació necessita feina. Com que són seniors, saben comunicar decisions tècniques en termes de negoci, saben plantar-se amb respecte quan les prioritats no tenen en compte la realitat tècnica, i saben construir la confiança que fa productiva la relació entre PO i enginyeria. Això no és una habilitat de procés: és una habilitat de senioritat.
El rol de PO en equips molt tècnics no està espatllat. Només cal adaptar-lo. I l'adaptació no és complicada: patrons de comunicació clars, drets de decisió explícits i dos líders que es respecten el terreny l'un a l'altre.
Necessites enginyers seniors que sàpiguen treballar amb el product owner, i no pas esquivar-lo? Parla amb un CTO.
