"I team di prodotto hanno bisogno di autonomia per innovare in modo efficace. Ma quando le organizzazioni crescono, quell'autonomia può generare caos senza un framework adeguato".
Come Senior Product Manager di Jira Product Discovery, ho constatato che il problema emerge in molte conversazioni con i clienti, indipendentemente dal settore e dalle dimensioni dell'azienda. La domanda che ricorre è: come dare ai team la libertà di lavorare in autonomia, mantenendo però abbastanza coerenza affinché l'organizzazione funzioni in modo efficace?
Il punto di rottura
Ogni organizzazione in crescita si trova prima o poi a dover affrontare un momento cruciale. Con uno o due team di prodotto, tutto sembra andare liscio. Ma quando si arriva a cinque team, cominciano ad affiorare le prime crepe. E cosa succede quando si arriva a dieci o venti team? È in quel momento che tutto crolla.
Questo schema emerge costantemente nelle conversazioni con i clienti. I team di prodotto non lavorano in isolamento: devono collaborare con la leadership per allinearsi agli obiettivi aziendali, con i team di ingegneria per sviluppare e diffondere le proprie idee, poi con marketing e vendite per promuovere le nuove funzionalità. Quando ci sono solo pochi team che lavorano in modo diverso, il resto dell'organizzazione riesce ad adattarsi. Ma man mano che si cresce, ciò che prima era gestibile si trasforma in caos.
Quello che rende particolarmente interessante questo punto di rottura è che spesso è frutto del successo, non del fallimento. I team di prodotto stanno raccogliendo successi, ciascuno a modo suo: alcuni si concentrano sul soddisfare le esigenze dei clienti con sessioni di co-progettazione e miglioramenti dell'usabilità, altri si occupano della stabilità della piattaforma e delle prestazioni del sistema. Ogni team lavora bene a modo suo, utilizzando processi che funzionano nel contesto di cui si occupa. Ma senza un framework comune che li unisca, questo stesso successo diventa insostenibile.
Soluzioni estreme
Dopo numerose conversazioni con i clienti ho notato due approcci comuni per risolvere questa sfida tra i team di prodotto. Alcune organizzazioni cercano di forzare una standardizzazione totale, facendo in modo che ogni team di prodotto adotti gli stessi processi, modelli e strumenti. Altri optano per l'approccio opposto, lasciando che i team operino in totale autonomia, sperando che le cose si sistemino da sole.
Nessuno dei due approcci estremi funziona. Come mi ha detto un leader delle operazioni di prodotto, "Quando abbiamo cercato di far lavorare tutti i nostri team di prodotto allo stesso modo, abbiamo ottenuto la conformità a scapito dell'impegno. I team seguivano la routine, ma avevano perso la loro energia". Dall'altro lato, la completa autonomia ha portato alla frammentazione e all'inefficienza. I team di prodotto non riuscivano a condividere efficacemente gli apprendimenti, le parti interessante faticavano a vedere il quadro generale e le opportunità di collaborazione venivano perse.
3 elementi chiave per trovare il giusto compromesso
Le organizzazioni di maggior successo affrontano questa sfida con tre elementi chiave che creano equilibrio senza sacrificare l'autonomia.
Il primo è un linguaggio comune: modi condivisi per discutere gli obiettivi, le fasi di sviluppo e gli impegni che consentono una comunicazione chiara senza imporre una procedura. Poi stabiliscono visualizzazioni coerenti che consentono a ogni team di lavorare come meglio crede, offrendo comunque alle parti interessate la chiarezza di cui hanno bisogno. Infine, favoriscono le best practice attraverso una combinazione di cultura, framework flessibili e strumenti di supporto.
In questo articolo esploreremo il modo in cui questi elementi possono interagire per trovare il giusto equilibrio tra autonomia dei team e chiarezza organizzativa. Vedrai esempi specifici di come diversi tipi di team di prodotto, da quelli che si concentrano sulle funzionalità rivolte ai clienti a quelli focalizzati sulle funzionalità della piattaforma, possano mantenere i loro approcci unici, pur contribuendo a un obiettivo condiviso.
Creare un linguaggio comune
Un aspetto fondamentale per i team di prodotto è comprendere che non devono lavorare allo stesso modo, ma che devono solo parlare lo stesso linguaggio. Grazie al nostro lavoro con i clienti abbiamo identificato tre elementi chiave che creano una comprensione condivisa senza sacrificare l'autonomia dei team:
Obiettivi che collegano i team
Prendiamo uno dei nostri clienti che ha fissato l'obiettivo aziendale di aumentare la soddisfazione dei clienti all'80%. I suoi team di prodotto hanno affrontato questo obiettivo in modi completamente diversi, ciascuno in base al proprio contesto:
- Un team si è concentrato sulla riduzione del numero di clic necessari per completare delle azioni comuni.
- Un altro team ha lavorato sul miglioramento dell'affidabilità del sistema e sulla riduzione dei tempi di inattività.
- Un terzo team ha dato priorità all'accuratezza dei risultati delle ricerche.
Stesso obiettivo, approcci diversi, ma tutti hanno capito come il loro lavoro contribuisse all'obiettivo finale.
Fasi che creano chiarezza
Invece di imporre processi rigidi ai team, le organizzazioni di successo standardizzano le milestone. Atlassian ha identificato quattro fasi chiave che funzionano per diversi tipi di team di prodotto:
- incertezza: comprensione completa dell'area problematica;
- esplorazione: soluzione dimensionata e convalidata;
- creazione: distribuzione della funzionalità in tutte le regioni;
- impatto: risultati misurati dopo 3 mesi.
Quando un team di prodotto dice di essere nella fase di "esplorazione", tutti sanno cosa significa: comprendono il problema e stanno convalidando le soluzioni. E come ci arrivano? Dipende dal singolo team.
Valutazione dell'impegno comprensibile
Il terzo elemento è un framework comune per misurare l'impegno. Ciò non significa tutti i team stimano il lavoro allo stesso modo, ma piuttosto che traducono le proprie stime in un linguaggio condiviso. I team della piattaforma potrebbero considerare la complessità del sistema e i rischi legati alla distribuzione, mentre altri team di prodotto si potrebbero concentrare sulla complessità delle interazioni con gli utenti, ma entrambe le valutazioni possono essere comunicate in modo comprensibile a tutti.
Tutto in un unico punto
Vuoi un esempio di come combinare questi tre elementi? Dai un'occhiata al mio webinar, How Product Operations can find the right balance between autonomy and consistency, dove fornisco un esempio pratico di come due team diversi possono lavorare in modi molto differenti per raggiungere lo stesso obiettivo.
Project management
Keeping multiple product initiatives on track is no small feat. The product operations manager supports product managers by coordinating complex projects and timelines, tracking progress against product roadmaps, and managing the countless dependencies between teams. They anticipate potential roadblocks and clear the path for on-time delivery.
Creare visualizzazioni coerenti
Una volta stabilito un linguaggio comune, la sfida successiva è rendere visibile il lavoro in tutta l'organizzazione. Qui molti team di prodotto si trovano ad affrontare una difficoltà ben nota: l'esercizio della roadmap trimestrale.
Succede spesso. I team di prodotto trascorrono ore a creare le proprie roadmap, ognuno utilizzando il formato che più si adatta al proprio lavoro. Alcuni usano fogli di calcolo dettagliati per monitorare dipendenze complesse. Altri preferiscono le slide per le presentazioni alle parti interessate. Altri ancora conservano le roadmap negli strumenti di progettazione per averle a portata di mano nel lavoro di sviluppo.
What businesses need product operations?
Il risultato? I team di product operations si trovano ad affrontare un compito impossibile. Devono costringere ogni team a ricreare le proprie roadmap in un formato standardizzato (soluzione dispendiosa in termini di tempo e soggetta a errori), oppure tentare di unificare formati diversi da soli (soluzione ancora più dispendiosa in termini di tempo e ancora più soggetta a errori).
La soluzione non è obbligare tutti a utilizzare lo stesso strumento, ma creare approcci di visualizzazione che funzionino sia per i team di prodotto che per le parti interessate. Ecco come fanno le organizzazioni di successo:
Visualizzazione alla fonte
Anziché copiare le informazioni da uno strumento all'altro, le organizzazioni leader visualizzano i dati dove si trovano. Ad esempio, un team di prodotto potrebbe preferire una visualizzazione board organizzata per fasi di sviluppo, mentre un altro potrebbe aver bisogno di una visualizzazione timeline per gestire le dipendenze complesse. Ogni team mantiene il proprio flusso di lavoro come meglio crede, ma le parti interessate possono visualizzare una roadmap unificata che mostra informazioni coerenti su obiettivi, fasi e tempistiche per tutti i team. Niente più copia e incolla da uno strumento all'altro, niente più aggiornamenti manuali in posti diversi.
Elementi comuni, visualizzazioni diverse
Il successo delle visualizzazioni coerenti inizia dalla conoscenza del pubblico a cui ti rivolgi. Se i team di prodotto hanno bisogno di informazioni dettagliate per il lavoro quotidiano, in genere alle parti interessate basta un insieme più ristretto di elementi critici che le aiuti a comprendere i progressi e a prendere decisioni. Si tratta di solito di pochi elementi fondamentali:
- Gli obiettivi a cui contribuisce il lavoro, così che la leadership possa monitorare l'avanzamento verso gli obiettivi aziendali.
- La fase attuale dello sviluppo (incertezza, esplorazione, creazione, impatto), che fornisce un chiaro senso dell'avanzamento e delle fasi successive.
- Le tempistiche previste per la consegna, che consentono un coordinamento migliore tra i team e con le parti interessate esterne.
