Gennaio 16, 2023 - di Redazione
Product VS Engineering: quando la crescita del prodotto rallenta
La chiave di ogni startup di successo è la stretta collaborazione tra Product ed Engineering. Avevamo già parlato sul nostro blog della collaborazione tra Product Manager e Software Engineer, che può sembrare facile a dirsi, ma a volte può diventare davvero complessa.
Entrambi possono avere obiettivi contrastanti e diverse definizioni di successo, che in qualche modo devono trovare un accordo.
Engineering potrebbe voler costruire un prodotto perfettamente scalabile per il futuro, con la migliore esperienza secondo i developer;
Product potrebbe voler convalidare rapidamente le proprie ipotesi e realizzare feature che invoglino gli utenti a pagare per il prodotto;
E ancora, le loro Roadmap (Engineering roadmap e Product roadmap), potrebbero essere talmente indipendenti, da creare confusione.
Questi due mindset entrano quindi in contrasto, e la strada più semplice è quella di evitare discussioni e lavorare in silos, vedendosi di rado per fare una release.
Noi siamo convinti che unire le forze e creare team units coese, possa rimuovere le frizioni e migliorare il time to value.
Per realizzare questo contenuto abbiamo tradotto l’articolo “Bottleneck #03: Product v Engineering – Friction Between Product and Engineering; Lack of trust and collaboration slowing down product growth”, una risorsa integrale – che va a compendio delle nostre interviste e che da ulteriori spunti utili – a opera di Rick Kick e Kennedy Collins, rispettivamente North American Head of Modern Application and Platform Services for Thoughtworks e Head of Product and Design for Thoughtworks NA’s Central Market.
Di cosa parleremo in questo articolo:
- Product VS Engineering: come si finisce nel collo di bottiglia?
- Come riconoscere il collo di bottiglia
- Product VS Engineering: come si esce dal collo di bottiglia?
- Saper comunicare con chiarezza il valore che l’azienda genera
- Creare stream-aligned teams multidisciplinari
- Product Vs Engineering: stabilire il lavoro di squadra a tutti i livelli
- L’approccio collaborativo tra Product e Engineering in fase di crescita
- Product Vs Engineering: in sintesi
Product VS Engineering: come si finisce nel collo di bottiglia?
Nelle fasi iniziali di lancio di una startup, essere tutti allineati è naturale perché si tratta di un piccolo team che lavora a stretto contatto, e dove probabilmente, i leader di prodotto e tech si conoscono già da tempo. L’idea iniziale della startup è molto forte e, man mano che si va avanti, il lavoro diventa sempre più chiaro.
Man mano che l’azienda cresce, tuttavia, iniziano a emergere i primi livelli di complessità di gestione, dove non sempre i manager s’impegnano a creare un ambiente sano e di collaborazione con i loro peers. Si concentrano invece su compiti urgenti, come il mantenimento del software o la preparazione di un round di finanziamento. Allo stesso tempo, la startup si trova ad affrontare un momento difficile in cui deve decidere come investire al meglio nel prodotto e ha bisogno di una strategia olistica per farlo.
Le startup gestite bene, lavorano già in team cross funzionali di prodotto. Alcune funzioni lavorano bene insieme perché rientrano nella stessa gerarchia verticale. Un esempio potrebbe essere lo sviluppo e il testing, ben integrati nelle startup, ma spesso isolati nell’IT enterprise tradizionale.
Invece, nelle scaleup con cui lavoriamo, vediamo che i team tech e di prodotto viaggiano su due binari separati. Questo accade perché si lavora con una mentalità più orientata alle attività che ai risultati:
I product manager non sono allineati con i tech lead e gli engineering manager; i director non sono allineati tra di loro; i VP non sono allineati con i VP; i CTO non sono allineati con i CPO.
In ultima analisi, questo collo di bottiglia va a deterioramento delle performance, e soffoca la creazione del valore per i clienti e per il business. Questo causa tensioni organizzative, debito tecnico incontrollato e perdita di velocità.
Fortunatamente, ci sono alcuni segnali chiave che si possono riconoscere. In questo articolo descriveremo questi segnali e le soluzioni da adottare per abbattere le barriere comunicative, costruire un portafoglio d’investimenti equilibrato, massimizzare il ritorno degli stessi e ridurre al minimo i rischi nel lungo periodo.
Product vs Engineering: come riconoscere il collo di bottiglia
Le diverse funzioni si puntano il dito contro
I membri del team si immedesimano con la struttura manageriale o la leadership di funzione, invece che pensare al valore che deve essere generato per il business e per il customer, favorendo l’atteggiamento “noi” contro “loro”.
Nel peggiore dei casi, il “noi contro loro” può diventare così tossico, da arrivare allo scarso rispetto reciproco. L’abbiamo visto, quando i leader di prodotto “gettano” i requisiti oltre il muro e trattano il team di Engineer come una fabbrica di features. Chiudono all’improvviso i progetti quando non raggiungono i risultati prefissati, senza che vi sia alcun preavviso che il progetto non stesse raggiungendo i suoi KPI.
Oppure, al contrario, il team di Engineer delude continuamente il team di Prodotto, bucando le date di consegna senza preavviso.
Il risultato finale è una perdita di fiducia reciproca.
Gli Engineer non hanno sufficiente contesto
Quando i Product Manager condividono features e requisiti senza revisionarli insieme ai Developer (con l’aiuto di strumenti come Jira), si può perdere il contesto critico sia lato business che degli utenti.
Se gli Engineer operano senza contesto, quando devono prendere decisioni di design o sviluppo, devono fermarsi e cercare il PM che gli spieghi, invece che prendere decisioni da soli. Peggio ancora, possono prendere decisioni sbagliate, causando ritardi e codice inutilizzato.
Questa frizione rappresenta uno spreco di tempo nel flusso di generazione del valore.
Le dipendenze non vengono prese in considerazione
Quando gli Engineer operano avendo il minimo contesto, lo scope può essere trascurato o non compreso. I requirements o le stories degli utenti possono mancare di solidità. Le Personas possono essere ignorate, le regole di business non prese in considerazione, e i requisiti tech e cross-functional assenti.
Questo porta ad aggiunte last minute o a interruzioni indesiderate anche lato user.
Il lavoro da fare si insinua nelle falle del sistema
I task si insinuano tra le falle. I membri del team pensano che qualcun altro sarà responsabile di un’attività, sgomitano tra di loro, o peggio ancora, dicono “non è il mio lavoro”.
Questi sono tutti sintomi di ruoli e responsabilità non chiari, scarsa comunicazione e collaborazione e attrito.
La negoziazione del debito tecnico crolla
Il debito tecnico è un sottoprodotto comune dello sviluppo del software moderno, con molte cause di cui abbiamo discusso in precedenza. Quando le aziende di prodotto e Engineering non comunicano o non collaborano efficacemente durante la pianificazione del prodotto, si nota un mix di investimenti non equilibrato. Questo può significare che il backlog del prodotto si concentra maggiormente sullo sviluppo di nuove features e non si presta abbastanza attenzione per ridurre il debito tecnico.
Gli esempi includono:
- Una maggiore frequenza di incidents e maggiori costi di produzione
- Burnout degli sviluppatori che tentano di sfornare funzionalità mentre lavorano alle frizioni
- Un ampio elenco di funzionalità di bassa qualità che i clienti abbandonano rapidamente
I team comunicano ma non collaborano
I team che si incontrano regolarmente per discutere del loro lavoro comunicano. I team che cercano e forniscono input apertamente, mentre lavorano attivamente, collaborano. Avere meeting con cadenza regolare, sullo stato di avanzamento dei lavori, non significa che un team sia collaborativo. La collaborazione avviene quando i team cercano attivamente di capirsi a vicenda e cercano e forniscono apertamente input mentre lavorano.
Product VS Engineering: come si esce dal collo di bottiglia?
Abbattere le barriere tra prodotto ed engineering è fondamentale per creare un team di prodotto performante. I team cross funzionali devono comunicare e collaborare in modo efficace e devono essere in grado di negoziare tra loro il modo migliore per raggiungere i propri obiettivi. Queste sono le strategie che Thoughtworks ha applicato per superare questo collo di bottiglia quando lavorava con i suoi clienti scaleup.
Identificare e rafforzare il “first team”
Nella sua forma più elementare, un team di prodotto è un gruppo d’individui, che si riuniscono congiuntamente, e intorno a un obiettivo comune, per creare valore per il business e per i customer. Ogni team contribuisce alla creazione di valore nel proprio modo o per il proprio specifico ambito.
In qualità di leader, è importante identificare e rafforzare una dinamica di team intorno alla creazione di valore, piuttosto che alla struttura organizzativa. Questo cross functional product team diventa il “first team”. In qualità di leader, quando si definisce il team come il proprio gruppo di riporti diretti, si attiva un concetto tribale che contribuisce a creare una dinamica “noi contro loro”.
La mentalità del first team è stata definita da Patrick Lencioni e citata in molte delle sue opere, tra cui The Advantage e The Five Dysfunctions Of A Team: A Leadership Fable, e anche se di solito viene usato in relazione alla creazione di team di leadership cross-functional, come primary accountability team, lo stesso concetto può valere per il team di prodotto.
Cambiare l’organizzazione e il linguaggio a essa legato, senza modificarne i comportamenti, non avrà un impatto sulla crescita. Tuttavia, è un punto di partenza che affronta gli attriti organizzativi e i problemi culturali più ampi che rallentano le performance.
Cambiare il linguaggio utilizzato
“The more hands-on an organization is willing to be in breaking silos, the more likely it is they will be effectively be breaking some of the implicit ‘versus’ states that have enabled them“. Duena Blomstrom
Adottare un approccio pratico alla “moderazione del linguaggio” è un primo semplice passo per abbattere le barriere.
- Usare il termine squad, pod o qualsiasi altro termine che si adatti alla cultura dell’azienda, è un piccolo cambiamento che può avere un forte impatto;
- Dare un nome ai cross-functional product delivery team, idealmente con il nome del prodotto o del value stream che il team genera, è un altro semplice cambiamento che aiuta ad adottare una nuova identità di team, separata dal contesto organizzativo in cui operano;
- Eliminare “noi” e “loro” dal vocabolario. Questo linguaggio è un autogol, e deve essere aggiunto all’elenco dei “non ammessi”.
Cambiare il comportamento
“Those of us trying to change our organizations’ culture need to define the things we want to do, the ways we want to behave and want each other to behave, to provide training and then to do what is necessary to reinforce those behaviors. The culture will change as a result“.– John Shook
Cambiare la cultura di un’azienda, quando non produce i risultati desiderati, è difficile.
Sono tanti i libri che ne parlano. Definendo e comunicando in anticipo i comportamenti attesi dai team e dai rispettivi membri, si getta le basi della cultura che si sta cercando di creare.
- I leader devono instillare una cultura di NO blaming. Quando qualcosa va storto, è una meravigliosa opportunità di apprendimento, da studiare per migliorare. Una sorta di autopsia senza colpe;
- Stabilite le aspettative e verificate i comportamenti. Ritenete ognuno responsabile e rifiutate le eccezioni;
- Orientate tutti gli sforzi puntando alla generazione del valore anziché alle rispettive funzioni;
- Riconoscete le diverse personalità che compongono il team, e se sono di talento, spostatele per trovare la sinergia ottimale tra i team.
Product Vs Engineering: saper comunicare con chiarezza il valore che l’azienda genera
Un’azienda è, per molti versi, un grande team con un obiettivo condiviso: il successo. Quando product e engineering non hanno chiaro questo concetto, è difficile che capiscano come collaborare per raggiungerlo. Per evitare questo, gli executives devono spiegare e condividere il valore complessivo che l’azienda genera nei confronti degli user, degli investitori e della società.
I leader hanno la responsabilità di descrivere come ogni prodotto e servizio contribuisce a creare valore. Il management deve assicurarsi che tutto il team sia consapevole di come il lavoro che svolge quotidianamente, crei valore per l’organizzazione e i suoi clienti.
L’obiettivo è creare un modello mentale condiviso di come l’azienda crea valore.
Il modo migliore per farlo dipende molto dalla natura della vostra azienda. Noi abbiamo riscontrato che alcuni tipi di asset sono utili e trasversali ai nostri customers scaleup. Li elenchiamo:
Gli asset che descrivono il valore per gli utenti
Sono gli asset che dovrebbero descrivere il valore che i vostri prodotti e servizi creano, per chi lo creano e i modi in cui misurate questo valore. Qualche esempio:
- Business Model Canvas/Lean Canvas
- User Journeys
- Service blueprints
- Personas
- Empathy maps
- Storyboards
- Job forces diagrams
- Panoramica dei prodotti (one-pager, ecc.)
Gli asset che descrivono il modello economico
Dovrebbero descrivere il valore che la vostra azienda riceve dai customer, il costo associato, e come misurate il ritorno. Qualche esempio:
- Volani aziendali
- Value stream maps
- Mappe di Wardley
- Retention/churn models
- Customer acquisition models
- Customer lifetime value models
- Bilanci e conti economici previsionali
Gli asset che descrivono la strategia
Questi documenti devono descrivere il motivo per cui avete scelto di servire questi customer in questo modo, le evidenze sulle quali prendete le decisioni, le leve più alte sulle quali concentrarsi per crescere, e come misurate il ritorno.
- Profili dei clienti target
- Issue trees
- Impact maps
- Opportunity/solution trees
- Hierarchy diagrams
- Causal loop diagrams
- Altri frameworks e modelli custom
Una volta che si dispone di questi asset, è importante usarli in ogni occasione, quando si prendono decisioni e, soprattutto, quando c’è un conflitto. Condividete gli aggiornamenti che fate e il motivo per cui lo fate e sollecitate gli update. Fate in modo che questi facciano parte della vostra routine e non lasciate che diventino carta da parati.
Un modo semplice per capire se la vostra comunicazione è stata efficace, è quella di scegliere un collaboratore a caso e porgli le domande alle quali rispondono i documenti qui sopra Quanto più riuscirà a farlo senza fare riferimento a loro, tanto meglio lavorerà, perché avrà interiorizzato questo approccio. Se non sa dell’esistenza di questi documenti, avete ancora molto lavoro da fare.
L’allineamento e il focus che questi asset generano, permettono un migliore impiego delle risorse organizzative, agevolano la crescita, allontanano tensioni e incomprensioni, e permettono di collaborare e muovere critiche costruttive.
Product Vs Engineering: creare stream-aligned teams multidisciplinari
Quando si è all’inizio, un’azienda ha spesso un solo value stream. Ma quando cresce, ha bisogno di scomporre i suo prodotti e servizi in tanti value streams, in modo che i singoli team possano assumersi la piena responsabilità dei diversi prodotti o di una parte dei prodotti. Il modo migliore per effettuare questa scomposizione va oltre lo scopo di questo articolo (noi personalmente siamo grandi fan delle Topologie dei team come approccio), ma alcune cose fondamentali da considerare sono:
- Il value stream dei prodotti e servizi che lo compongono potrebbero esistere separatamente (anche senza avere pieno successo?)
- È possibile ricondurre i vari value streams a un modo specifico in cui l’azienda genera valore, o a un customer o a utente specifico?
- Come interagiscono tra loro i vari value streams?
Dopo aver definito i value streams, è il momento di riunire attorno a questi un team multidisciplinare, perché la creazione di valore è uno sport di squadra.
Chiedete ai leader dei vari value streams, di creare documenti simili e dettagliati agli asset di cui abbiamo parlato prima, e capite quali skill e capacità sono necessarie nel day by day per deliverare e far evolvere il valore dei prodotti e/o dei servizi nei value streams dall’inizio alla fine.
Riunite queste persone in un team orientato ai risultati (Outcome Oriented), piuttosto che coordinare il lavoro tra team orientati alle attività o team funzionali (Activity Oriented). Nel libro Agile IT Organization Design, Sriram Narayam afferma: “Più processo e mancanza di direzione c’è, e più la collaborazione efficace è difficile. Al contrario, le persone all’interno di un team non devono indire riunioni per collaborare, ma collaborano continuamente e si riuniscono in huddles* quando serve (*riunioni informali ad hoc, virtuali o faccia a faccia)”.
Se da un lato questo modello aiuta a ridurre la latenza all’interno dei team outcome oriented, dall’altro riduce l’attrito tra i membri dei team multidisciplinari.
Tenete presente che, con la crescita dell’azienda, potrebbe essere necessario avere dei “teams of teams”, con più team allineati intorno a un value stream e un team di cross-functional leader. Con l’aumentare della complessità legata alla creazione del valore, aumenta anche l’importanza di avere uno scopo comune per i delivery product teams.
I product manager e i software engineers hanno la responsabilità condivisa di comprendere i bisogni degli utenti in modo da poter definire il lavoro da fare e assegnare le priorità. Non esiste un mix ideale di PM e Engineer; ogni prodotto avrà una ratio diversa. L’importante è sapere che entrambi sono responsabili della comprensione, della definizione delle priorità e della creazione del valore.
Con l’evoluzione del prodotto, anche le esigenze del team si evolvono. Ponete sempre l’attenzione sulle capacità degli stream-aligned teams, fate empowerment e date loro la possibilità di sostenere i propri bisogni. Assicuratevi che i team dispongano di tutte le risorse necessarie per essere autonomi, senza dipendere da risorse esterne inutilmente. I team di prodotto, così organizzati, e operando come un’unica entità a prescindere dalla struttura gerarchica, ridurranno notevolmente le incomprensioni cross-disciplinari.
Product Vs Engineering: stabilire il lavoro di squadra a tutti i livelli
Assicurarsi che ogni membro del team sappia qual è il suo ruolo
I team migliori sono quelli che hanno trovato la strada per lavorare bene da soli. È importante che le aziende sappiano come guidare i team meno maturi a lavorare bene insieme, ma è altrettanto importante che i team abbiano l’autonomia di decidere le responsabilità di ognuno. Questo porta a una maggiore accountability e a un livello di motivazione intrinseca più forte.
Man mano che si formano i nuovi team, tutto questo deve essere codificato come working agreement e messo a fattor comune nel repository di ogni team. Durante le retrospettive, questi working agreement vanno rivisti man mano che il team impara a conoscere meglio i punti di forza e di debolezza di ognuno, e le responsabilità vengono riassegnate di conseguenza.
Questo “accordo” diventa il contratto sociale del team, e anche l’unica “responsibility fingerprint“ che nessun altro team possiede. Quando i nuovi membri del team entrano a farne parte, avere un accordo di questo tipo, accelera l’integrazione e riduce il time to value durante l’onboarding.
Questi accordi contengono spesso:
- Nome del team: Come si distingue il team?
- Missione del team: Perché esiste? Cosa ci si aspetta dal team?
- Metriche del team: Come si misura il successo? Che include le metriche legate alla generazione del valore, e non solo quelle legate alle attività.
- Responsabilità del team: Quale lavoro deve essere svolto per raggiungere il successo e quali membri del team saranno responsabili? (Le aziende possono guidare anche su questo, ma i membri del team sono liberi di riorganizzarsi).
- Competenze del team: Quali competenze sono necessarie in questo particolare team per garantire il successo?
- Norme del team: Linee guida, principi, cerimonie e/o impostazioni predefinite per i membri del team, per allinearsi su come ci si aspetta che i membri del team si comportino, interagiscano e prendano decisioni.
I leader formano i propri team
Questi working agreements sono uno strumento utile per i team cross funzionali, ma sono anche un ottimo strumento per allineare i leader cross funzionali.
“These three holistic view leaders—the head of product, the head of design, and the head of technology—are obviously very valuable individually, but in combination you can see their real power.” – Marty Cagan
Gli executive leader hanno la responsabilità, a livello macro, di allinearsi sulle strategie aziendali e di prodotto e le relative misure di successo. Se non sono allineati sul “mix d’investimenti desiderato tra i prodotti”, i team che devono realizzare tutto questo, non avranno successo.
I functional line managers in un’organizzazione di prodotti digitali, possono non dirigere più gli sforzi quotidiani verso lo stream-aligned team – questa responsabilità ricade sul team e sul product manager di quel team – ma hanno ancora un valore enorme. I manager funzionali hanno la responsabilità di assicurarsi di fornire le persone qualificate che servono. È fondamentale che questi manager siano allineati sui ruoli e sulle responsabilità dei membri dei team di prodotto per evitare conflitti all’interno dei team stessi.
…team members must prioritize the results of the team over their individual or departmental needs – Patrick M. Lencioni
Puntare a un mix equilibrato d’investimenti nel prodotto
Il diagramma precedente mostra lo sweet spot di un mix di investimenti equilibrato, dove l’investimento tech e di prodotto hanno trovato un trade off. L’eccessivo investimento in un prodotto con un backlog pesante in termini di funzionalità di prodotto, indica probabilmente uno scarso investimento nel debito tecnico, che comporta ad under-engineered solutions, mentre un eccesso di investimenti con un backlog importante in termini di tecnologia, indica probabilmente uno scarso investimento nelle funzionalità apprezzate dai clienti e soluzioni sovra-dimensionate. È molto difficile capire quando l’equilibrio è perfetto. È probabile che cambi nel tempo, man mano che l’azienda cresce e si trasforma.
Un esempio di under-engineering che incontriamo spesso, è quando un prodotto ha problemi di availability. Questo problema significa che il team di sviluppo deve passare il tempo a “spegnere gli incendi“, il che riduce la concentrazione e influisce sulla produttività. Sebbene questo può funzionare quando si è piccoli, se l’utilizzo da parte dei customer aumenta (hypergrowth), il team va in sovraccarico a discapito dell’esperienza utente. Quel rimborso del debito, arriverà sempre quando l’azienda non potrà permetterselo.
Un altro squilibrio si verifica quando il team tecnico ottimizza troppo precocemente e finisce col fare over-engineering. Ne sono un esempio le architetture adatte a gestire centinaia di migliaia di utenti quando l’azienda ne ha solo dieci. Quando la startup fa un pivot, molto di quel lavoro finisce per essere buttato via. C’è sempre un equilibrio da raggiungere tra il costruire un prodotto che sia scalabile in futuro, e la costruzione di quello che ora ti serve per sopravvivere.
L’importante è essere in grado d’individuare quando si è arrivati a questo squilibrio, e correggerlo. Un processo di miglioramento continuo è molto importante. Se un team (a livello di team di prodotto o di management) è consapevole del proprio obiettivo condiviso, un gruppo cross-functional può valutare con regolarità la situazione e utilizzare i dati a supporto. Alcuni dati saranno quantificabili, e altri più soggettivi.
Tra le informazioni che si possono utilizzare per orientarsi ci sono:
- Raccogliere le opinioni individuali: un engineer si sente produttivo e motivato? Un product manager ritiene che il team sia efficiente?
- Metriche di produttività – Quanto velocemente possiamo testare e costruire una nuova feature?
- Visione dello stato attuale e dello stato futuro a breve termine – Stiamo complicando eccessivamente il build out in nome della scalabilità futura?
- Crescita del prodotto – Sappiamo come stiamo progredendo verso l’obiettivo di un prodotto? Ci sono abbastanza analisi, test degli utenti e feedback dei clienti per confermare che i nostri investimenti nel prodotto stanno dando i loro frutti?
- Trends – Man mano che sviluppiamo nuove funzionalità o aumentiamo gli utenti, come si evolvono le metriche? Ad esempio, osserviamo metriche come il tempo di creazione, il tempo necessario per il deploy in produzione e la quantità di incidents. Man mano che la complessità aumenta, gli investimenti tech dovrebbero tenerli sotto controllo e ridurre la fatica degli sviluppatori.
Un “tecnologo esperto” che ha scalato una piattaforma tech è molto prezioso. È in grado d’interpretare i dati, utilizzando il proprio intuito per individuare potenziali problemi futuri e adottando un punto di vista pragmatico.
Tenere conto dei requisiti cross funzionali
Un buon prodotto non è solo un prodotto con le ultime funzionalità.
- Deve essere costruito per essere performante, affidabile e stabile;
- Deve essere efficiente dal punto di vista dei costi: i costi di gestione del prodotto non devono superare i ricavi che il prodotto genera;
- L’architettura di base del prodotto deve consentire lo sviluppo di funzionalità future in modo rapido ed efficiente;
- Deve avere in mente l’espansione del cliente ed essere in grado di scalare, senza troppe modifiche;
- Non deve mettere a rischio i dati privati dei clienti o dell’azienda.
Queste e molte altre qualità di un prodotto rientrano nell’ambito dei cross-functional requirements. Se non si tiene conto di questi requisiti nel far uscire nuove funzionalità, i problemi si aggravano.
Alcuni problemi sono più evidenti perché si possono osservare. Si notano quando un customer si lamenta. Altri si noteranno solo a lungo termine. Martin Fowler parla dell’importanza di mantenere alta la qualità interna: fare refactoring, creare test automatizzati, separare le funzionalità. Le aziende in fase di avviamento tendono a trascurare questo aspetto, per ottenere aumenti di produttività a breve termine. Potrebbe essere la decisione giusta, ma una volta che si pensa di aggiungere altri team, la qualità interna deve essere affrontata, altrimenti si rinuncia alla creazione di valore a lungo termine.
Trovare il giusto equilibrio nel gestire il backlog
La creazione di un backlog “equilibrato” inizia con la fiducia, poiché si tratta fondamentalmente di una negoziazione tra prodotto e engineering. Raccomandiamo a ogni leader di prodotto di lavorare per costruire un rapporto stretto e collaborativo con le proprie controparti tecniche e viceversa. Ci saranno e dovranno esserci molte discussioni difficili mentre si lavora per trovare un equilibrio. Una startup ha risorse molto limitate e spesso deve fare compromessi difficili tra il migliorare la developer experience e il creare nuove features.
Una negoziazione produttiva dipende dalla trasparenza, dalla capacità di condividere informazioni dettagliate e dal desiderio di vedere la situazione dal punto di vista dell’altro. Se un product manager comprende l’architettura tecnica e la strategia, può suggerire idee più facili da realizzare. Se un tech comprende il ragionamento e la ricerca alla base di una strategia di prodotto, può suggerire soluzioni alternative a cui il product manager non ha pensato, ad esempio l’utilizzo di ML/AI per risolvere un problema.
Quando si negozia un backlog, le startup spesso trovano difficile capire l’impatto relativo tra i potenziali investimenti e, poiché le metriche di utilizzo e di fatturato sono facili da ottenere e ben comprese, il lavoro che avrà un impatto su di esse viene spesso considerato prioritario, sbilanciando il mix di investimenti. Per ovviare a questo problema, consigliamo di trovare metriche che consentano di misurare anche l’impatto degli investimenti tecnici. Ogni situazione è diversa, ma ci sono alcuni standard de facto, supportati da ricerche, che hanno dimostrato di migliorare la produttività a lungo termine e che possono essere utilizzati come punto di partenza.
- Concentratevi sulle metriche DevOps e DX outcome-driven. La lettura Maximizing Developer Effectiveness è un buon punto di partenza;
- In Thoughtworks Scaleup Studio, abbiamo una serie di defaults, che derivano da uno studio delle pratiche e delle tecnologie utilizzate dalle scaleup di successo. Tra queste, la continuous delivery, i domain-oriented microservices, l’uso prudente del debito tecnico, la costruzione di processi e infrastrutture di sperimentazione;
- Stabilire una soglia di qualità non negoziabile e rispettarla. Ad esempio, ogni lingua ha una serie di buone pratiche che possiamo facilmente verificare in modo automatico.
L’approccio collaborativo tra Product e Engineering in fase di crescita
Fase 1 – Sperimentazione
- La startup stessa è una squadra.
- Working agreements e risorse sono a supporto della mission.
- Mix d’investimenti orientati al prodotto, dove si sperimenta per imparare e non per migliorare un prodotto già esistente (prototipi usa e getta).
- Esperimenti con diversi modelli economici.
Fase 2 – Crescita
- L’azienda si suddivide in sub-team, pur continuando a pensare a se stessa come a un “grande team”.
- Working agreements che diventano più concreti
- Gli asset di valore dei customer vengono ridefiniti e utilizzati nell’onboarding. Il modello economico diventa più chiaro, ma ancora flessibile.
- Si assumono i primi leader di prodotto e di engineering.
- Il mix d’investimenti sono prodotto oriented, e focalizzati a creare e rendere solido il prodotto – fondamentali investimenti per supportare la crescita.
Fase 3 – (Hyper) Growth
- Diventa impossibile muoversi come “un unico grande team”, che si suddivide in stream aligned teams.
- Vengono creati per il middle management cross-functional team formati da leader, e i primi engineering team della piattaforma.
- Non si cercano più nuovi mercati e il mix di investimenti duplica il valore che viene generato dai prodotti.
- Il customer value, la strategia di business, e gli asset del modello economico sono ora più concreti, meno soggetti al cambiamento e pensati per la distribuzione.
- Ogni prodotto e sottoprodotto ha il suo valore specifico e le sue risorse necessarie.
Fase 4 – Ottimizzazione
- I leader devono impegnarsi perché non si creino silos all’interno di ogni linea di funzione.
- La struttura del team inizia a cambiare per promuovere la massima autonomia.
- Nascono strutture che supportano lo sviluppo delle skill e la coerenza tra i gruppi.
- Vengono creati nuovi team per supportare e migliorare il lavoro degli stream aligned team (platform engineering, product ops, design ops, ecc.).
- Il mix di investimenti nei prodotti core inizia a focalizzarsi di più sugli aspetti tech, compreso l’investimento in developer experience.
Product Vs Engineering: in sintesi
Le strutture organizzative funzionali facilitano la gestione di un’azienda. La formazione di gruppi attorno a competenze e capacità comuni, con un manager di linea funzionale responsabile dello sviluppo di tali competenze e dell’avanzamento di carriera, è il fondamento di qualsiasi scaleup. Ma quando i membri del team iniziano a identificarsi e ad allinearsi con il proprio gruppo funzionale, può insorgere il “tribalismo” e di conseguenza degli attriti tra le diverse tribù.
È più facile eliminare le barriere tra i team quando entrambi fanno capo allo stesso manager o dirigente. Ecco perché l’ultima barriera a cadere in molte organizzazioni è quella tra Product e Engineering. Lavorare come un unico Product Team è fondamentale per creare team intrinsecamente motivati, che si impegnino a creare valore per il business e per i customer. Abbiamo individuato alcune strategie chiave da prendere in considerazione per prevenire o risolvere queste frizioni:
- Rafforzare il “first team”: Le organizzazioni funzionali sono ottime per la crescita di figure competenti, ma a prescindere dal ruolo, tutti coloro che forniscono lo stesso valore al business o al cliente fanno parte della stessa squadra.
- Definire e comunicare la value proposition: Assicuratevi che ogni membro del team di prodotto sappia in che modo crea valore per il business e per i customer. È l’unico modo per avere team intrinsecamente motivati.
- Creare stream aligned teams multidisciplinari: Formate Product Team end-to-end con tutte le skill e le capacità necessarie per creare e fornire valore misurabile. Assicuratevi che siano sempre dotati di tutte le risorse necessarie.
- Stabilire team working agreements a tutti i livelli: All’interno di un lightweight governance framework, consentite ai Product Team e ai leader funzionali di auto-negoziare e allinearsi su ruoli e responsabilità. Rivalutate e aggiustate costantemente fino a raggiungere l’equilibrio.
- Negoziare un mix equilibrato d’investimenti: Un team di prodotto di successo è quello che delivera un prodotto stabile, “sicuro” e scalabile, ricco di funzionalità.
Se l’articolo ti è piaciuto e vuoi rimanere aggiornato sui prossimi contenuti, iscriviti alla nostra Newsletter 📩
