Come organizzare un Cross-Functional Product Team

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: 

1. Consente ai responsabili di avere un processo di delega efficace;
2. Dà ai product team la possibilità di potersi assumere la responsabilità di prendere decisioni che abbiano impatto.

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à]

Francesco Scalambrino – CPO Italia, Payfit

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:

• circa 8 persone si occuperanno della costruzione del software, sono degli ibridi tra product managers e developers, noi li chiamiamo product builders-> product builder team;
  
• 2-3 persone ci aiutano a capire i requisiti e le implicazioni legali di quello che facciamo-> payroll expert + legal team;
  
• 3-4 persone si occupano di controllare e fare a mano quello che il software non può fare in automatico, in particolare le dichiarazioni agli enti governativi-> declaration 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.

Francesco Corti – Technical Product Manager, Alfresco

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.

Raffaele Scozzafava – Product manager, Facile.it

In Facile.it (Mortgages) siamo organizzati così:

• 2 Product Manager
• 1 Team Lead (Tecnico)
• 5 Developers (1 Frontend + 4 Backend)
• 1 QA/Automation tester

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:

• Daily Standup;
• Retrospective;
• Planning & Stime (anche questo molto dinamico);
• Demo (quando necessario).

Jira e Confluence come strumenti principali.

Viviana Lobosco – Senior Product Manager, Arm.

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.

Silvana De Santis – Lead Product Manager, The Fork

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. 

Matteo Adami – Product Manager, Jobrapido

In Jobrapido lavoriamo in SCRUM, usando gran parte delle cerimonie standard (esclusa la demo) e siamo così strutturati:

• 2 SCRUM team cross funzionali composti da 1 Front-End Developer, 3-4 Back-End Developer e 2 Data Engineer;
  
• 4 Product Manager che assumono il ruolo di Product Owner delle varie iniziative di prodotto che possono avere in progress con uno o entrambi i team (di fatto ogni SCRUM team ha una relazione con multipli Product Owner in un dato Sprint);
  
• 1 UX/UI Specialist, 1 QA Assistant e 1 Data Scientist a supporto dei Product Manager;
  
• 1 SCRUM Master condiviso da entrambi gli SCRUM Team;

• 1 Head of Product, 1 Back-End + Front-End Tech Lead + 1 Data Tech Lead, che fungono da team leader verticali degli specifici ruoli di riferimento;
  
• 1 team di 4 DevOps/Infrastructure Engineer a supporto;
  
• 1 VP of Product, 1 VP of Technology

Emanuela Premoli – Head of Product, Motork

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.

Federico Battistella – Product Lead, Subito

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.

Giacomo Giorgianni – Product Manager, Pepper.com

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:

• 1 CPO che gestisce la comunicazione con il board;
  
•  1 Head of Product che collabora strettamente con il CPO e gestisce le integrazioni tra i vari Product team;
  
• 1 Head of Design che gestisce i vari Product Analyst;
  
• 1 Integration Project Manager che si occupa di scouting, negoziazione e maintenance per l’integrazione con tool di terze parti;
  
• 2 Product Analyst condivisi che a tendere vogliamo integrare all’interno del team;
  
• Team DevOPs;
  
• Team Internal API

Ogni team é composto dalle seguenti figure:

• 1 Product Manager;
  
• 1 Product Designer che al momento supporta anche nella parte di UX;
  
• 1 QA Tester;
  
•  1 Team Lead;
  
• 2-4 BackEnd Developer

Utilizziamo una metodologia simil Scrum per cui abbiamo sprint di due settimane sia in Development che in Design, e adottiamo le seguenti cerimonie:

• Daily Scrum Meeting;
  
•  Backlog grooming;
  
• Sprint Planning;
  
• Sprint Retrospective.

Piú avanti nell’anno abbiamo intenzione di sperimentare il Dual Track Agile.

Conclusioni

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 📩 🚀.