Come organizzare il team di Prodotto

Organizzare il team di prodotto è una delle continue sfide che il Product Manager deve affrontare. Dico continue perchè al cambio dello scenario di mercato, del proprio prodotto o semplicemente dell’azienda è necessario di volta in volta riorganizzarsi.

A prescindere dalla combinazione che si sceglie, l’unico modo per sviluppare prodotti che hanno senso nel 2020, non nel 1990, è lavorare in team Cross-funzionali.

Di base si mettono insieme tutte le persone che possono e devono prendere decisioni sul prodotto/feature su cui lavorano.

Il team si auto-organizza, seguendo le metodologie che ritiene più opportune, Agile Scrum o Kanban, o altro, ma soprattutto è in grado di rilasciare autonomamente. Questa è una delle più grandi “innovazioni” dal punto di vista organizzativo, perché consente ai vari responsabili di avere un processo di delega efficace e ai team di poter prendere decisioni che abbiano impatto, assumendosene la responsabilità.

Personalmente capire come organizzare e ri-organizzare il team è stata una delle cose a cui ho più 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 team e come lavorate insieme?“.

Il team Cross-funzionale

Quello che troverai è esattamente quello che ho cercato per anni quando ero alle prese con i primi temi legati all’organizzazione e allo scaling dei team: Product manager e responsabili di Prodotto ci raccontano come si organizzano nelle aziende e start-up più interessanti in Italia e in Europa.

In questo post mi limito a copiare/incollare le loro risposte in ordine cronologico e a inserire eventuali domande che sono state fatte nel thread su Linkedin. Se vuoi aggiungere il tuo punto di vista o fare delle domande ai diretti interessati puoi farlo direttamente da qui su Linkedin o lasciando un commento al post.

[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’e un team di prodotto globale e dei team per ogni paese che costruiscono la versione del prodotto per quel 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

– altre 2-3 persone ci aiutano a capire i requisiti e le implicazioni legali di quello che facciamo -> payroll expert + legal team

– altre 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: Super interessante Francesco, finora non avevo mai visto una “localizzazione” così spinta su Prodotto. Da cosa dipende questa scelta dal tuo punto di vista?

Si é 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 e poi mette nelle mani dei singoli paesi un ambiente di sviluppo proprietario che permette di costruire localmente tutta la parte di funzioni che sono specifiche per quel mercato.

Sommando le parti, c’e tantissima tecnologia. Questo é il motivo per cui i team product 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, abbiamo “preso” i pezzi che ci permettono di lavorare bene nel contesto attuale.

Rispetto ai cerimoniali dello Scrum utilizziamo:

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 farie 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 della singole interfacce ma anche di creare il senso di un sito unico, con cui l’utente interagisce per risolvere dei bisogni, senza preoccuparsi di che piattaforma ci sia dietro il servizio di cui usufruisce

Il concetto alla base è fondamentale, perchè spesso i siti web tendono ad essere lo specchio dell’organigramma interno, più che puntare a capire 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 e’ 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 a 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 teams 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). Ci sono poi  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. 

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.

Piena autonomia dei team 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 Team di prodotto, 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

1 reply on “ Come organizzare il team di Prodotto ”
Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *