Distribuire le responsabilità: il ruolo del product trio

In letteratura è descritto come un modello interfunzionale di leadership per guidare una progettazione più efficace, ma il product trio è anche considerato il minimo sindacale per poter avviare la costruzione di un qualsiasi prodotto tecnologico rivolto ad un essere umano.

Spesso confuso con terminologie più attraenti come “progettazione olistica” o “interdisciplinare”, il trio è poco applicato con metodo, nonostante se ne parli da qualche anno. A dire il vero, quando ho iniziato a considerare questo modello, non mi è sembrato così innovativo: ho sempre lavorato insieme a PO (product owner), TL (technical leader) e PM (project manager), in team più o meno grandi ed in progetti più o meno complessi; ciò che però mi ha convinto a promuoverlo come una pratica consueta è la percentuale di rischi dai quali, grazie alla formalizzazione del trio, il cliente e/o l’utente finale sono, senza esagerare, tutelati. 

In questo articolo analizzeremo l’efficacia del product trio nell’ambito dello sviluppo di prodotti tecnologici nei settori B2B e B2B2C, nei quali le pratiche del design e della progettazione centrata sulle persone faticano ancora oggi ad affermarsi. Allo stesso tempo, è necessario evidenziare come le aziende in questi settori desiderino essere al passo con il progresso tecnologico, che ha impatto in egual misura sulle macchine e sulle persone: macchinari e processi che da manuali diventano automatici, macchine connesse ad una moltitudine di touchpoint per un generale aumento della complessità progettuale.

Maggiore è la complessità, maggiori e diversificati sono i rischi, ed il product trio è in prima linea.

Product trio: un gruppo collaborativo di leadership e decisionale

Product designer, technical leader e product manager sono i tre ruoli che caratterizzano la costituzione del trio. Da un punto di vista interno all’organizzazione che applica questa modalità cooperativa, uno dei ruoli elencati può essere duplicato o triplicato, a seconda della tipologia di progetto o di prodotto. Ogni ruolo corrisponde ad un reparto, che a sua volta è composto da uno o più team.

Il trio è l’anello di congiunzione tra il cliente ed il fornitore.

Mi piace rappresentare i componenti del trio come gli chef di un sushi bar dotato di nastro trasportatore: gli chef al centro del tavolo ricevono le comande (requisiti di business) ed iniziano a produrre le pietanze con le rispettive ricette (user stories) che, una volta finalizzate, finiscono sul nastro e vengono gestite per essere consumate (sviluppo e validazione), cercando di mantenere una velocità costante ed un ordine degno di un pranzo.
Alcune pietanze sono di valore inferiore rispetto ad altre e non vengono consumate immediatamente, restano sul nastro e possono essere consumate più tardi, o per un bis: l’importante è garantire pasto completo che confermi i motivi per cui è stata svolto.
Questa rappresentazione – sicuramente molto allegorica – non è certo sufficiente a descrivere la complessità della progettazione di un prodotto tecnologico ma, se non altro, definisce il perimetro delle  attività del trio. 

Prima di osservare nella pratica cosa, come e quando il trio coopera e produce, individuiamo due aspetti fondamentali che lo caratterizzano: la leadership di prodotto e le decisioni.

Product designer, technical leader e product manager devono avere una visione uguale e condivisa sia sulla qualità intrinseca del prodotto (la natura del prodotto, ossia come è fatto), sia su quella estrinseca (il ciclo produttivo o di sviluppo). Un trio non può funzionare se uno dei reparti che lo compone ignora la visione di prodotto o, peggio ancora, ne formula una propria: la condivisione delle ragioni per cui il prodotto deve esistere produce e rafforza la leadership necessaria, che impatterà poi su coloro che il prodotto lo dovranno costruire. Nei progetti complessi e di ampio respiro, il trio deve avere la capacità di rinnovare e riconfermare la visione di prodotto, affinché sia condivisa dai reparti a tutti i livelli; ciò consente di mantenere gli obiettivi originali e riconfermarne di nuovi.

I processi decisionali, nei progetti nei quali si applica il product trio come modello, sono caratterizzati da un grosso dispendio di risorse: infatti, se le decisioni devono essere condivise e partecipate da più persone, aumentano a dismisura cerimonie e processi di validazione, ma in questo i framework agili possono venirci incontro. Lo vedremo brevemente nell’ultimo paragrafo.

Ma se dal punto di vista decisionale, il product trio comporta uno sforzo maggiore, dal punto di vista del cliente, si notano alcuni vantaggi:

1. Il cliente si sente maggiormente coinvolto nei processi ideativi e progettuali.
   Un trio altamente cooperativo propone un ventaglio di soluzioni che il cliente finale può valutare godendo dei contributi dei tre ruoli: design, strategia ed ingegneria. Ciò consente un maggiore coinvolgimento del cliente finale, che potrà favorire una decisione in base ad un numero di informazioni diversificato
2. Il trio è allineato alla visione di prodotto.
   Le proposte portate dal trio sono allineate ad una visione collettiva: i processi decisionali sono l’occasione per ribadirla e confermarla.
3. Cultura del rispetto.
   Enfatizzare il processo decisionale collaborativo incoraggia ogni persona coinvolta a contribuire con le proprie competenze, proprio come accade all’interno del trio. Ciò promuove una cultura del rispetto, dell’ascolto e del feedback costruttivo.

Vision, leadership e decision making sono aspetti endemici del modello.

Ma come avviene questa cooperazione in pratica?

Descriviamo brevemente i tre reparti fondamentali per la costruzione di un prodotto tecnologico, introducendone un quarto un po’ particolare:

Technical leader (TL): è il responsabile della costruzione del prodotto. Il suo compito è quello di determinare ciò che è fattibile o meno, stimarne i tempi e proporre, in concerto con i membri del team di sviluppo, la migliore soluzione di tecnica in accordo con i requisiti utente e la roadmap di progetto. È in grado di negoziare le milestones della roadmap in base alla maturità ed alla conoscenza tecnica del dominio.

Product manager (PM): è il responsabile della definizione della strategia complessiva e della roadmap di prodotto. Stabilisce le priorità e si assicura che le scelte prese siano allineate con gli obiettivi della committenza. Monitora la velocità ed il consumo del budget dei vari team, dunque può negoziare gli investimenti in termini di risorse durante il ciclo produttivo.

Product designer (PD): è il responsabile dell’usabilità del prodotto. Costruisce i requisiti utente e definisce le modalità più adatte ed economiche per renderli leggibili dal team di sviluppo. Misura il carico di dettaglio necessario in una determinata fase del progetto, evitando di immettere nel ciclo produttivo micro-funzionalità a basso impatto, ma che richiedono moltissimo sforzo.

Product leader – il ruolo fantasma (ghost): è il moderatore del trio. La sua presenza “spirituale” consente al trio di non divergere dai capisaldi di cui abbiamo parlato nel paragrafo precedente. Un grillo parlante: intangibile, ma fondamentale.     

Nel diagramma sono menzionate le aree di competenza di ogni reparto.
Questa rappresentazione però non è sufficiente, così com’è, a descrivere un ciclo di progettazione. È necessario estrapolare tre fasi nelle quali il trio coopera per rilasciare una soluzione: una fase di scoperta, una di definizione del problema ed una di rilascio. In ognuna delle fasi, ogni reparto sarà coinvolto con sforzi e compiti diversi.

Ogni fase evidenzia lo squilibrio di responsabilità per ogni reparto del trio, che comunque coopera come collettivo. Durante la prima fase, quella nella quale avviene il censimento dei problemi del cliente, le figure maggiormente coinvolte sono il product manager ed il product designer. 

Le domande fondamentali da porsi sono:

“Perché vogliamo realizzare questo prodotto?”
“A chi è rivolto?”
“Che tempi ci sono per farlo?”
“Qual è il budget a disposizione?”
“Qual è l’idea di successo che riponete nel prodotto?”
“Quali sono i requisiti minimi che soddisfano lo scopo dei destinatari del prodotto?”

Non sarebbe però un trio, se il technical leader non partecipasse – in ascolto – alle elucubrazioni scaturite dalle domande sopra. Ciò che emerge da questi quesiti aiuta il trio nella formulazioni di una strategia tecnologica ed invita il TL a considerare aspetti quali infrastruttura e architettura del software, se dovesse esistere già una base di partenza per gli sviluppi.
In questa prima fase, gli strumenti a disposizione del trio sono prevalentemente workshop di progettazione collaborativa ed interviste.

Nella seconda fase, l’ultima parola sta al product manager. Raccolta la consapevolezza del trio, si tirano le somme sulla base delle informazioni raccolte, per definire una strategia e posizionare il timone sulla giusta rotta. In ognuno di noi c’è un product leader che emerge nei momenti cruciali: in questo caso ci aiuta a rimanere aderenti ai requisiti di business ed alla vision in generale.

“Qual è lo sforzo per risolvere il problema?”
“Una volta risolto, che impatto avrà sul prodotto e sul destinatario finale?”
“Scegliendo questa direzione come organizziamo il futuro del ciclo produttivo?”

La seconda è la fase più tattica che prepara il trio alla realizzazione del prodotto, che si palesa nella terza fase, durante la quale gli sforzi sono per lo più di tipo operativo.

Se uniamo i puntini di quanto detto finora, possiamo osservare che il modello del product trio funziona bene se non si creano squilibri in termini di leadership, perimetro del ruolo e vision.
Lo sbilanciamento fra i reparti con carichi di responsabilità mal gestiti sono spesso causa di dinamiche interpersonali ed aspettative poco chiare che hanno, inevitabilmente, un impatto nella produzione.

Le tre “r” del trio: relazioni, responsabilità e rischi

Oltre agli aspetti che si riflettono nella produzione, vi sono delle poi implicazioni contingenti di cui il trio deve tenere di conto.
È naturale che la distribuzione “equa” di responsabilità e potere decisionale inneschi un inevitabile incremento delle relazioni che, oltre ad intasare i calendari, produce ridondanza e difficoltà di tracciamento delle informazioni. È implicito all’applicazione del modello un approccio alla raccolta di informazioni che potremmo definire ecosistemico, che si basa sulla partecipazione di tutti coloro che possono portare valore nello sviluppo del prodotto. Gestire questa mole di connessioni è utilissimo quanto difficile, ed il rischio di incomprensioni nel trio è dietro l’angolo.
Identificare i momenti e gli stakeholder giusti per centralizzare la raccolta delle informazioni è di grande aiuto in tutto il processo produttivo. Di contro, per il trio, è estremamente rischioso lasciare che alcuni processi di analisi e raccolta dei requisiti restino in carico ad un solo reparto del trio: scoprire che un database è troppo lento potrebbe avere impatto sulla risposta che l’utente otterrà nell’interfaccia, e risolvere il problema potrebbe impattare la roadmap.

Quando si lavora basandosi sul trio le connessioni e le relazioni aumentano a dismisura ed il progetto è esposto a più persone con punti di vista diversi.

Per efficientare questa rete al meglio, è compito del trio produrre deliverable chiari ed usabili a più livelli della scala gerarchica del cliente.

Che sia documentazione tecnica o una rappresentazione grafica dell’interfaccia collocata in un macchinario industriale, il deliverable deve sempre garantire una capacità autoesplicativa: il trio non può sottomettersi a questo sforzo rappresentativo. La chiarezza nella realizzazione e trasmissione dei deliverables è una caratteristica fondamentale del trio: che si tratti di documentazione tecnica o di una rappresentazione della futura interfaccia, il deliverable deve sempre essere autoesplicativo. È uno sforzo narrativo e di rappresentazione a cui il trio non può sottomettersi.

Se da una parte interrompere un processo decisionale costa, in termini di tempo, più che non decidere, un po’ meno coraggiosa dev’essere la gestione del rischio. Il trio nasce sì per discutere le migliori soluzioni e scovare le più proficue opportunità, ma le relazioni su cui si basa il rapporto tra i tre reparti devono essere in grado di far emergere i problemi nei tempi utili per poterli risolvere. 

Il segreto del trio? La dieta!

Ogni professionista sa che non deve farsi ingolosire da ciò che più lo appassiona.

Un’interfaccia troppo complessa potrebbe essere inutile per i primi rilasci, un codice scritto in modo troppo lezioso potrebbe richiedere un tempo superiore alle stime, così come l’assenza di elasticità su budget e carico ore potrebbero innervosire il committente.
Sapersi autodisciplinare aiuta tutto il team, non solo il trio, e consente di rimanere focalizzati sulla visione di prodotto, disinnescando sul nascere personalismi e processi decisionali intrapresi in autonomia.
Il prodotto è lo scopo, e la soddisfazione dei destinatari finali rappresenta la metrica di successo condivisa dal trio.

A tal proposito, serve l’entità spirituale del “product leader”, il saggio e intangibile angelo custode del progetto, che compare sulla spalla e spegne le fiamme del diavoletto tentatore.

Product trio e frameworks agile

Il trio fa parte di un’organizzazione ed il suo ruolo deve servire ad efficientare l’agilità dei team, cercando di incrementare l’innovazione ed il rendimento da due punti di vista: quello culturale e quello produttivo.

L’applicazione del trio consente ai tre membri team una più libera interpretazione delle direttive, con un conseguente incremento dell’autonomia nella costruzione delle soluzioni: ciò emerge maggiormente quando si applicano frameworks basati su iterazioni e affinamenti progressivi, le cui sessioni di sviluppo sono temporizzate e devono concludersi sempre con un risultato tangibile.

Aumentare l’autonomia dei membri dei team, sfruttando al massimo i momenti di condivisione proposti dai framework agili, aiuta la crescita di rapporti di fiducia ed incentiva la creatività, lasciando a coloro che costruiscono le soluzioni un ampio margine di libertà.