Ristrutturazione del team di prodotti Braze

La forza trainante più importante dietro qualsiasi prodotto software è il gruppo di persone che lo costruiscono e le loro relazioni reciproche. Pertanto, è importante organizzare i team in un modo che consenta loro di avere quanta più influenza e impatto possibile.

In Braze, abbiamo riflettuto a lungo su come è progettata la nostra organizzazione di prodotti e ingegneria e desideriamo condividere ciò che abbiamo appreso da un'importante riorganizzazione dipartimentale che ci ha aiutato a migliorare notevolmente il modo in cui diamo la priorità alle funzionalità, sviluppiamo le competenze del team e costruiamo il nostro prodotto in modo più efficiente.

Struttura iniziale: adattamento del prodotto/mercato e oltre

Trovare un prodotto/mercato adatto e sfruttarlo per far crescere un business è un crogiolo attraverso il quale devono passare tutte le startup. In questa fase dello sviluppo di una startup, la velocità di sperimentazione e la capacità di capitalizzare rapidamente le opportunità sono fondamentali. A tal fine, la nostra struttura originale del team di prodotto era simile a questa:

Questa struttura, che ha suddiviso il nostro team in base alle specialità funzionali, ha funzionato bene per diversi motivi.

In primo luogo, ci ha permesso di affrontare in modo efficiente le modifiche trasformative del prodotto sulla strada per l'adattamento del prodotto/mercato: gli esperti potevano possedere enormi porzioni della nostra base di codice e utilizzare i linguaggi, i framework e le decisioni di progettazione con cui erano più a loro agio. Alimentati da enormi quantità di caffeina, i "team" del progetto Army of One hanno regolarmente affrontato enormi sforzi. Questi includevano la creazione della nostra API pubblica rivolta ai clienti e la revisione della nostra intera infrastruttura di invio dei messaggi, spesso ricoprendo il ruolo di unico ingegnere, product manager e designer. Questi tipi di misure estreme sarebbero una follia per una grande azienda, ma sono necessari e quasi di routine durante la crescita iniziale.

Inoltre, questa struttura ci ha aiutato a ottenere una profonda padronanza di alcune aree tecniche con solo un team di 10-15 persone. Molti elementi dei nostri prodotti principali, ad esempio il livello del controller di visualizzazione del modello del front-end, le API e il codice per l'invio di messaggi ad alta velocità di trasmissione, sono stati pienamente compresi solo da poche persone.

All'epoca era semplice e tutto ciò di cui avevamo bisogno. Quando la velocità è tutto, l'organizzazione basata su semplici linee guida ha aiutato a ridurre il sovraccarico cognitivo e ci ha permesso di concentrare l'attenzione dove poteva fare il meglio.

Struttura successiva: crescita e ridimensionamento

Man mano che il nostro team cresceva oltre i 30 o 40 anni, tuttavia, questa struttura iniziò a rompersi. Alla fine abbiamo identificato la riorganizzazione del nostro team di prodotto come una soluzione ad alcune delle nostre maggiori sfide. Stavamo spendendo sforzi insostenibili per destreggiarsi tra set di abilità e tempistiche per comporre team per progetti strategici. Abbiamo anche dedicato una quantità eccessiva di tempo alla definizione delle priorità e spesso ci siamo trovati a classificare forzatamente tutte le priorità dei prodotti in tutta l'azienda poiché la nostra struttura del team basata sulla tecnologia non corrispondeva direttamente alle esigenze più essenziali del prodotto. Infine, abbiamo avuto poche opportunità per i membri del team di sviluppare un'esperienza approfondita con casi d'uso particolari dei clienti.

Alla fine siamo passati a un'organizzazione strutturata attorno a team interfunzionali Agile simile al modello Squad/Tribe reso popolare da Spotify. La nostra nuova struttura organizzativa si presenta così:

La maggior parte del nostro team lavora all'interno di "verticali di prodotto", corrispondenti a un'area chiave del nostro prodotto o attività. Per esempio:

• Il nostro team Email & Enterprise gestisce la posta elettronica dall'alto verso il basso, nonché alcune aree di prodotto come la gestione delle autorizzazioni che sono fondamentali per molti dei nostri maggiori clienti.
• Il nostro team di messaggistica e automazione possiede diverse aree di prodotto relative alla segmentazione degli utenti, alla messaggistica e al nostro prodotto di orchestrazione di punta, Canvas.

All'interno di una verticale, ci aspettiamo che la definizione delle priorità sia (relativamente) semplice, poiché ogni verticale corrisponde a un insieme specifico di esigenze del cliente. Alcuni team come Visual Design, DevOps e i nostri gruppi di Infrastructure Engineering coprono l'intera piattaforma, creando coerenza in aree chiave.

Impatti

La nostra riorganizzazione ha ridotto significativamente le dipendenze tra i team. In precedenza, abbiamo lottato con il problema della pianificazione simile al Sudoku di inserire il giusto equilibrio di set di abilità specializzate (ingegneria, design, gestione del prodotto, ecc.) su un determinato progetto in un dato momento. Ha anche allineato gli incentivi a breve termine: prima della transizione, i team spesso si trovavano a fare affidamento su controparti che miravano a obiettivi non correlati. Con la nostra nuova struttura, i team di prodotto sono indipendenti, hanno un controllo molto maggiore sulle tempistiche e sono completamente allineati sugli obiettivi, aumentando la produttività e il morale.

Il nuovo design dell'organizzazione ha anche migliorato la definizione delle priorità. Ad esempio, il nostro team Email & Enterprise potrebbe dover decidere tra l'aggiornamento della nostra infrastruttura di posta elettronica, la creazione di una funzionalità di posta elettronica di base o la risoluzione di un problema di usabilità aziendale, una decisione semplice e facilmente quantificabile, poiché tutti e tre si riferiscono alle esigenze dei nostri clienti in modi simili .

Un team alle prese con troppe esigenze ad alta priorità è anche un indicatore del fatto che la loro area di prodotti ha bisogno di più risorse. Ciò ci consente di riformulare i difficili problemi di definizione delle priorità come esigenze di personale, che sono ancora impegnative ma concettualmente semplici da affrontare.

Infine, concentrare la maggior parte dei team su una particolare area di prodotto ha consentito alle persone di costruire nel tempo una profonda esperienza e rapporti di lavoro altamente produttivi. Inizialmente, nei primi anni di costruzione, le persone potevano tenere essenzialmente in testa l'intero prodotto e la base di codice, ma con la crescita questo è diventato impossibile. I problemi del prodotto sono frattali: ogni volta che guardi più da vicino, trovi più sfumature e profondità. Di conseguenza, trascorrere molte ore in una particolare area di un prodotto o di una base di codice e comprenderne a fondo le esigenze aziendali è uno dei modi migliori per ottenere vere innovazioni di prodotto. Inoltre, la creazione di team mirati a lungo termine crea appartenenza e rapporto e consente di creare relazioni di lavoro non dette tra un insieme coerente di collaboratori.

Ovviamente nessun sistema è perfetto. Concentrandoci sui pilastri orientati al prodotto, abbiamo aumentato il potenziale per i team di ottimizzare per esigenze localizzate a scapito delle priorità olistiche. Ad esempio, ci si potrebbe concentrare sul debito tecnologico localizzato ("questo controller è ingombrante") invece che su questioni globali ("cambiare il nostro framework di front-end aumenterebbe la velocità complessiva di ingegneria"). In previsione di questa esigenza, abbiamo adottato misure per stabilire i team trasversali sopra menzionati e abbiamo utilizzato comitati dedicati per altri progetti di ampia portata, ad esempio un comitato per costruire un sistema olistico di prodotto/design di componenti front-end e modelli di progettazione .

La nostra nuova struttura porta anche una maggiore energia di attivazione per cambiamenti di prodotto olistici e trasformativi. Alcune aree del nostro prodotto, come le nostre API di back-end, sono di proprietà congiunta di diversi team. La soglia per apportare modifiche radicali ad aree ampie e trasversali della nostra base di codice è più alta, quindi questo tipo di struttura funziona meglio una volta che lo scheletro del tuo prodotto è ampiamente formato.

Asporto

Nel complesso, siamo rimasti soddisfatti della nostra struttura organizzativa del prodotto riprogettata: abbiamo risolto o notevolmente migliorato le nostre sfide relative alle dipendenze del team, alla definizione delle priorità e alla creazione di competenze di prodotto a lungo termine, e abbiamo anche una tabella di marcia utile per la nostra scalabilità. In particolare abbiamo appreso che:

• La rimozione delle dipendenze e l'allineamento degli incentivi porta a enormi guadagni di efficienza.
• La definizione delle priorità da mele a mele è sia più semplice che più efficace.
• Una profonda esperienza in un particolare cliente o esigenza aziendale porta a risultati di prodotto migliori.
• Lavorare con gli stessi membri del team per un lungo periodo è fondamentale per costruire ottimi rapporti di lavoro.

Consiglierei questa struttura a qualsiasi team che condivida alcune caratteristiche chiave: un'organizzazione interfunzionale in cui esperti funzionali come product manager, designer e ingegneri sono parti interessate alla pari; più di circa 15-20 persone nel team di sviluppo prodotto combinato; e, cosa più importante, un solido adattamento al mercato del prodotto. E se questo tipo di struttura del team ti sembra interessante, stiamo assumendo!