Com aplicar «Good Strategy / Bad Strategy» als roadmaps de producte
Abans de l'última sessió de planificació trimestral vaig repassar les meves notes sobre «Good Strategy / Bad Strategy» de Rumelt. Va ser un exercici útil, perquè el roadmap que estàvem construint era exactament allò contra què Rumelt adverteix: una llista de coses que volíem fer, ordenada per prioritat, sense cap lògica que les lligués.
Teníem 14 punts. Funcionalitats, infraestructura, integracions, un element vague d'«exploració d'IA» que ningú no sabia definir. Cada stakeholder hi havia aportat alguna cosa. La llista era exhaustiva i completament inútil com a estratègia, perquè una llista de funcionalitats no és un pla: és un inventari.
Així és com s'aplica el nucli (kernel) de tres parts de Rumelt — diagnòstic, política orientadora, accions coherents — a la planificació trimestral de producte.
Pas 1: Diagnòstic — quin és el repte real?
El diagnòstic és el pas més difícil perquè exigeix honestedat. No la versió polida per a la presentació al consell. La veritat incòmoda sobre què frena realment el teu producte.
La majoria d'equips se'l salten del tot. Passen directament a «què hauríem de construir?» sense preguntar-se abans «quin problema estem resolent?». El resultat és un roadmap que ataca símptomes, no causes.
Mal diagnòstic: «Necessitem més funcionalitats per competir.»
Això no és un diagnòstic. És ansietat disfressada d'anàlisi. No identifica cap repte concret i, per tant, no pot guiar cap acció concreta.
Bon diagnòstic: «Els usuaris marxen al setè dia perquè l'onboarding és confús. El 62% dels usuaris de prova no acaben mai la configuració. El tiquet de suport més habitual és “com connecto la meva font de dades?” — un flux que vam dissenyar el 2021 i que no hem tocat des de llavors.»
Fixa't en la diferència. El bon diagnòstic és concret, es basa en evidència i posa nom a la restricció real. És incòmode perquè diu «hem construït una cosa que no funciona prou bé». Però et dona alguna cosa sobre què actuar.
Com arribar-hi: treu les dades de retenció, llegeix-te els últims 100 tiquets de suport, parla amb cinc clients que han marxat (no amb els contents) i pregunta als teus enginyers què arreglarien primer. Ells ho saben: hi conviuen cada dia. El diagnòstic ha de cabre en una o dues frases. Si ocupa una pàgina, és que encara no l'has destil·lat prou.
Pas 2: Política orientadora — l'enfocament
La política orientadora no és una solució. És la direcció estratègica que restringeix quines solucions consideraràs. És la decisió que elimina categories senceres de feina del teu roadmap.
Per al nostre exemple d'onboarding:
Mala política orientadora: «Millorarem l'experiència d'usuari.» Massa vaga. Tot és «millorar l'experiència d'usuari». Això no elimina res.
Bona política orientadora: «Aquest trimestre prioritzarem la retenció per sobre de l'adquisició. Cap funcionalitat nova per a prospectes fins que els usuaris actuals puguin completar l'onboarding sense intervenció de suport.»
Això és una política orientadora perquè tria. Diu «farem això, no allò». Diu a vendes que la integració que volen no arribarà aquest trimestre. Diu a màrqueting que el redisseny de la landing queda desprioritzat. Genera incomoditat — i així és com saps que és una decisió de debò.
La prova d'una bona política orientadora: deixa descontent almenys un stakeholder? Si tothom somriu i assenteix, no has triat res. Has escrit un tòpic.
Pas 3: Accions coherents — què faràs realment
Les accions coherents són els moviments concrets i coordinats que materialitzen la política orientadora. La paraula clau és coherents: les accions s'han de reforçar entre elles. Un grapat de millores inconnexes no és acció coherent, encara que cada millora sigui útil per separat.
Per al nostre trimestre centrat en la retenció:
- Redissenyar el flux de connexió de fonts de dades — el tiquet de suport més freqüent passa a ser la primera prioritat d'enginyeria. Nou flux tipus assistent amb validació a cada pas. A producció la setmana 4.
- Afegir guia d'onboarding dins l'aplicació — tooltips contextuals i un indicador de progrés que mostra a l'usuari en quin punt de la configuració es troba. Només funciona si el flux de base (acció 1) és net.
- Construir un quadre de comandament de salut de l'onboarding — seguiment de la taxa de configuracions completades, del temps fins al primer valor i del volum de tiquets de suport dels usuaris nous. Ens permet mesurar si les accions 1 i 2 han funcionat.
- Llançar una campanya de reactivació per als usuaris encallats a la configuració — correus disparats pel producte al 62% que va abandonar, oferint-los un recorregut guiat amb el flux nou.
Aquestes quatre accions són coherents. Cadascuna reforça les altres. El redisseny del flux fa útil la guia. El quadre de comandament en mesura l'impacte. La campanya de reactivació aplica el flux millorat als usuaris que ja havíem perdut. Treu-ne qualsevol i l'estratègia s'afebleix.
El que no hi ha en aquesta llista importa tant com el que hi ha. La integració que demanava vendes? Aquest trimestre no. L'exploració d'IA? Morta. El redisseny de l'app mòbil? Ajornat. No perquè siguin males idees, sinó perquè no serveixen l'estratègia d'aquest trimestre.
Per què la majoria de roadmaps són una llista de desitjos amb nom d'estratègia
He revisat desenes de roadmaps de producte de les startups amb què treballem. El patró es repeteix:
El bufet d'stakeholders. Vendes vol integracions. Màrqueting vol una landing. El CEO vol IA perquè un competidor l'ha anunciada. Enginyeria vol atacar el deute tècnic. El roadmap acaba sent un bufet: una mica de tot, sense satisfer ningú del tot.
La il·lusió de la matriu de prioritats. Els equips fan servir RICE o MoSCoW per ordenar els punts. Sembla rigorós. Però ordenar una llista de desitjos no és tenir una estratègia. Pots passar 30 elements pel RICE i continuar sense un pla coherent, perquè cap d'aquests elements no està lligat a un repte diagnosticat.
La fàbrica trimestral de funcionalitats. El roadmap es converteix en un calendari de producció: «Al Q4 publiquem les funcionalitats de l'A a l'E.» Sense diagnòstic, sense política orientadora, sense cap explicació de per què aquestes cinc funcionalitats juntes ataquen un problema concret. L'equip les publica totes cinc i el repte de fons continua intacte.
Com dir que no amb el nucli de l'estratègia
El nucli de l'estratègia és la millor eina que he trobat per dir que no sense que sembli arbitrari. Quan un stakeholder pressiona per la seva funcionalitat preferida, no li dius «no és una prioritat». Li dius:
«El nostre diagnòstic és que els usuaris marxen al setè dia perquè l'onboarding no funciona. La nostra política orientadora aquest trimestre és retenció per sobre d'adquisició. La teva petició és una funcionalitat d'adquisició. És una bona idea per al Q1, quan hàgim estabilitzat la retenció, però no serveix l'estratègia amb què ens hem compromès.»
Funciona perquè no és personal ni és vague. Lliga el «no» a una comprensió concreta i compartida del problema. La majoria d'stakeholders accepten un «ara no» ben raonat si n'entenen la lògica. El que no poden acceptar és «hem decidit prioritzar altres coses» — això sí que sona arbitrari, i continuaran insistint.
Documenta el nucli. Posa'l per escrit. Una pàgina. Diagnòstic, política orientadora, accions coherents. Comparteix-lo amb tots els stakeholders a l'inici del trimestre. Quan arribin peticions a mig trimestre (i arribaran), assenyala el document: «Això serveix el repte que hem diagnosticat? Si no, va a la llista de candidates per al Q1.»
La reunió de planificació, redissenyada
Així és com he reestructurat la planificació trimestral:
- Setmana 1: taller de diagnòstic. Producte, enginyeria i customer success en una sala amb les dades al davant. Un sol lliurable: la frase del diagnòstic.
- Setmana 2: política orientadora. La direcció revisa el diagnòstic i pren les decisions difícils. El debat s'espera; l'alineament s'exigeix.
- Setmana 3: accions coherents. Enginyeria i producte tradueixen la política en lliurables coordinats. Abast, seqüència, dependències.
- Setmana 4: comunicació. Es comparteix el nucli amb tota l'empresa. Què fareu, què no fareu i per què.
Això costa més que ordenar un full de càlcul — quatre setmanes en lloc d'una reunió, i aquest sobrecost és l'objecció honesta a tot el plantejament. El que compres a canvi és un trimestre concentrat en lloc d'un de dispers, i això surt més barat que entregar puntualment les cinc funcionalitats equivocades.
A Conectia, els enginyers sènior que integrem als equips dels clients no es limiten a executar punts del roadmap: qüestionen el roadmap mateix. Han vist prou productes per reconèixer quan un roadmap és una llista de desitjos disfressada d'estratègia. Aquest reconeixement de patrons, sumat a la disciplina de preguntar «quin és el problema de debò?», és el que un enginyer amb experiència aporta a un equip.
Necessites enginyers que qüestionin el roadmap, i no només que l'executin? Parla amb un CTO — els nostres enginyers sènior de LATAM aporten el criteri estratègic per convertir llistes de funcionalitats en execució de producte centrada.
