Marzo 16, 2020 - di Marco Imperato
Il come organizzare un cross-functional Product Team è una delle sfide continue che il Product Manager deve affrontare.
Dico continue perché al cambio dello scenario di mercato, del proprio prodotto o dell’azienda, è necessario riorganizzarsi.
A prescindere dalla combinazione che si sceglie, l’unico modo per sviluppare dei prodotti che oggi hanno senso è lavorare in un team cross funzionale.
Di base, si mettono insieme tutte le persone che possono (e devono) prendere decisioni sul prodotto/feature sul quale andranno a lavorare.
Un product team, che segue questa logica, è in grado di auto-organizzarsi seguendo le metodologie che ritiene più opportune (p.es: Agile Scrum, Kanban o altro), ma soprattutto è capace di rilasciare autonomamente.
Questa è una delle più grandi “innovazioni”, dal punto di vista organizzativo, per 2 motivi:
Se ripenso alla mia esperienza, capire come organizzare (e riorganizzare) il team è stata una delle cose a cui ho dedicato più tempo e che mi ha dato più “mal di testa”.
Qualche tempo fa, quindi, ho semplicemente pubblicato questa immagine su Linkedin chiedendo alla community:
“Com’è organizzato il tuo product team e come lavorate insieme?“.
Così, sono arrivati in soccorso Product Manager e responsabili di Prodotto pronti a raccontare come si organizzano nelle aziende e nelle Startup più interessanti in Italia e in Europa.
Quindi, quello che troverai in questo articolo, è quello che io ho cercato per anni quando ero alle prese con i primi temi legati all’organizzazione e allo scaling dei product team.
Se avessi voglia di condividere il tuo punto di vista o di fare delle domande ai diretti interessati, puoi farlo qui su Linkedin.
[NB: nel post ho preso in considerazione solo le aziende tech di prodotto e non le agenzie perché sono due approcci troppo diversi e rischierebbero di creare ambiguità]
In PayFit c’è un product team globale e dei team per ogni Paese che costruiscono la versione del prodotto per quel determinato mercato.
Per i primi 12-18 mesi, sto strutturando [per l’Italia] l’area product con questi 3 team:
Domanda: Finora non avevo mai visto una “localizzazione” così spinta su Prodotto; da cosa dipende questa scelta dal tuo punto di vista?
Sì è un caso abbastanza raro.
Il motivo è dovuto al fatto che molte tematiche relative al payroll (busta paga e annessi) sono molto diverse da paese a paese; quindi, quello che fa PayFit è costruire tecnologia a livello centrale per le funzioni che sono uguali in tutti i paesi.
Successivamente, mette nelle mani dei singoli paesi un ambiente di sviluppo proprietario che gli permette di costruire localmente tutta la parte di funzioni, specifiche per quel mercato.
Sommando le parti, c’è tantissima tecnologia.
Questo é il motivo per cui i product team sono distribuiti nei vari paesi.
In Alfresco siamo in transizione verso un modello dove PMs (siamo 11), UX Team e Dev Teams (poco più di una decina) sono disaccoppiati.
I Dev Team sono, dove possibile, cross functional (FE Engineers + BE Engineers + QA Engineers).
I PMs lavorano con UX Team e uno o più Dev Team in dipendenza della “feature” di cui si occupano.
In Facile.it (Mortgages) siamo organizzati così:
Ad oggi UX, UI, Data sono trasversali e stiamo lavorando per verticalizzare.
10 mesi fa siamo partiti con uno Scrum puro; attualmente usiamo un modello Scrumban, “prendendo i pezzi” che ci permettono di lavorare bene nel contesto attuale.
Rispetto ai cerimoniali dello Scrum utilizziamo:
Jira e Confluence come strumenti principali.
Credo derivi molto dal prodotto.
Nel nostro caso, ad esempio, parliamo di un sito web dove varie piattaforme si integrano per fornire diverse funzioni.
La nostra mission è: essere l’hub per sviluppare, imparare e cooperare sui prodotti Arm.
Abbiamo utenti nuovi, o che tornano per fare più cose, durante lo user journey, per cui è fondamentale che tutto risulti interconnesso e fornito quando serve.
Quindi se tecnicamente è fondamentale avere team dev dedicati, a causa delle peculiarità delle piattaforme di back-end, stiamo transitando definitivamente a ux cross funzionale che lavori a stretto contatto con PM e PO.
Questo consente di definire le specifiche delle singole interfacce ma anche di creare il senso di un sito unico, con cui l’utente interagisce per risolvere dei bisogni, senza preoccuparsi della piattaforma che sta dietro al servizio di cui sta usufruendo.
Il concetto alla base è fondamentale perché spesso i siti web tendono ad essere lo specchio dell’organigramma interno, più che puntare a capire di cosa l’utente necessiti e a quale punto del suo journey.
In particolare, abbiamo definito dei Design Principles, relativi alla user centricity, alla riutilizzabilità e ad un approccio data-driven: Act quickly – Think Strategically, Be user-centred (una delle mille iterazioni mi e’ venuta molto da slogan 🙂)
Ovviamente è un percorso in continua evoluzione e improvement, ma questo mindset shift è un grande obiettivo raggiunto.
In TheFork, non tutti i team sono organizzati allo stesso modo.
In linea generale, abbiamo dei team di 5/6 dev (BE, FE, iOs/Android) + 1 PM, organizzati in base a scopi funzionali (non in base all’impatto).
Data e UX/UI sono, purtroppo, entità separate e servono da supporto a tutti i team.
L’assenza di un UX/UI all’interno del team si fa sentire, soprattutto nei periodi di rush.
Usiamo scrum a livelli più o meno sofisticati… Io, per esempio, che non sono un’appassionata di scrum, ho mantenuto solo la struttura generale (demo, sprint di 2 settimane…), per allineare i team con il resto dell’azienda.
Per quanto riguarda la costruzione della soluzione, il team di sviluppo è coinvolto al 100% fin dall’inizio delle riflessioni.
In Jobrapido lavoriamo in SCRUM, usando gran parte delle cerimonie standard (esclusa la demo) e siamo così strutturati:
In MotorK ci sono 3 team definiti sulla base delle linee di prodotto (ogni team è composto da product manager e designer insieme).
Ciascuna linea di prodotto ha i suoi team di sviluppo.
Su DriveK (prodotto B2C) ci sono 3 product manager e 2 designer (1 UX e 1 UI).
Poi ci sono 2 team di sviluppo: uno si occupa di tutto ciò che riguarda il sito, il marketing – tutto ciò che è visibile all’utente; l’altro invece gestisce la fornitura di dati (api, ecc), i tool interni e le integrazioni con i clienti.
Entrambi i team lavorano in scrum con sprint di due settimane.
In Subito, dopo diverse iterazioni siamo arrivati ad avere una struttura a tribe e squad completamente cross funzionale.
Ogni squad è composta da minimo 2 dev (fullstack), 2 dev app native, 1 data analyst, 1 UX designer, 1 Product Manager, 1 Eng. Supervisor.
In cross squad abbiamo le figure come Data Scientist, Data Eng., Scrum Master, UX Researcher e DevOps, il tutto moltiplicato per 12 team circa
La struttura è a matrice, complessa ma attualmente funzionale agli scopi.I product team hanno piena autonomia nel raggiungere i risultati.
Dal mio arrivo in Pepper, 4 mesi fa, lavoriamo costantemente sulla nostra configurazione per capire come ottimizzare al meglio il nostro lavoro.
Giá nel 2019 l’azienda ha adottato gli OKR su tutti i dipartimenti per dare una direzione aziendale univoca e questo riduce di parecchio la complessitá del lavoro dei PM, soprattutto nel momento in cui bisogna spiegare agli stakeholders il perché ci si concentra su alcuni aspetti piuttosto che su altri.
In termini di product team, per il 2020, sperimenteremo una configurazione con 4 team cross funzionali: 1 team è esclusivamente dedicato alla componente App mobile, gli altri 3 sono assegnati ad un obiettivo strategico ed N relativi OKR.
I vari team di prodotto condividono:
Ogni team é composto dalle seguenti figure:
Utilizziamo una metodologia simil Scrum per cui abbiamo sprint di due settimane sia in Development che in Design, e adottiamo le seguenti cerimonie:
Piú avanti nell’anno abbiamo intenzione di sperimentare il Dual Track Agile.
Come avrai notato, la necessità di raccontare come organizzare un product team nasce dall’esigenza di avere delle linee guida concrete da seguire.
Imparare, attraverso l’esperienza di chi fa questo quotidianamente, è sicuramente un’importante opportunità di crescita.
Saper organizzare e gestire un cross-functional team permette ai Product Manager o ai responsabili di Prodotto di trovare il modo migliore per risolvere il problema prestando sempre una particolare attenzione al cliente.
Quindi, spero che ciò che hai letto qui possa essere utile a te e al product team della tua azienda.
Se hai qualche domanda puoi lasciare un commento, sarò super felice di risponderti! 🙂
E se questo articolo ti è piaciuto, iscriviti alla nostra Newsletter 📩 🚀.
Co-Founder e Amministratore di Edgemony, società che fonda nel 2020, con il duplice obiettivo di accelerare lo sviluppo del territorio siciliano grazie alle competenze digitali e aiutare aiuta le aziende italiane, e non, a estendere in Sicilia il proprio Tech Team. Crea Product Heroes a fine 2018, la prima community per Product Manager in Italia che conta 6.000 iscritti alla newsletter. Product Heroes è il punto di riferimento per chi fa prodotto, e ha aiutato fino a oggi oltre 180.000 product lovers grazie al Master in Product Management, Programmi B2B, Contenuti ed Eventi on the ground. Dal 2008 guida il dipartimento di Prodotto e Digital Media di Mosaicoon, dal giorno della creazione fino alla chiusura per fallimento 10 anni dopo.
Le slide sono disponibili per studenti ed ex studenti del Master in Product Management
One reply on “Come organizzare un Cross-Functional Product Team”
barbara
Molto interessante grazie! Invece rispetto alle figur più di business come si colloca la struttura più di prodotto? Sarei interessata a capire in maniera più allargata la struttura aziendale senza una focalizzazione solamente sulla parte di prodotto (business, marketin&comunicazione, come sono collocate?)