Il ruolo delle operazioni di prodotto ha ricevuto una crescente attenzione negli ultimi anni, ma proprio come molti ruoli che lavorano per raggiungere la maturità, sorgono molta confusione e incertezza.

Uno dei maggiori dubbi riguarda dove si trovano le operazioni di prodotto all'interno dell'organizzazione, cosa guidano/possiedono e dove possono portare valore. Particolarmente impegnativo quando si introducono Product Operations in un'organizzazione che non ha mai lavorato con Product Operations.

Considerando l'adattabilità del ruolo e della funzione dipendente dall'organizzazione, potremmo potenzialmente sostenere che qualsiasi cosa è un gioco e potenzialmente rientra nel nostro ambito.

È mia opinione che se manteniamo i principi di base dritti, il ruolo è facilmente adattabile a qualsiasi organizzazione e l'ambito facile da definire.

Ma cosa significa in realtà?

La parola chiave è attivatore

Anche gli esperti hanno opinioni e punti di vista diversi sull'argomento, ma una parola che continua a emergere è essere un facilitatore o abilitare il team.

Come Antonia Landi ha affermato in modo così eloquente in un recente aggiornamento di Linkedin :
“Ho imparato qualcosa di importante di recente: non spiegare Product Ops come 'rendere la vita delle persone più facile'.

Come abilitatore del lavoro è facile voler essere d'aiuto a tutti i costi, ed è una storia facile da "vendere" a nuovi colleghi e parti interessate. Dopotutto, sono qui per renderti la vita più facile, perché non mi vorresti intorno?"

E poi riassume bene la sua visione finale con: "Il mio lavoro è consentire alle persone del nostro dipartimento di fare un ottimo lavoro".

Penso che l'aspetto importante sia che essere chiari sul nostro ruolo di abilitatori, ci aiuta a definire uno scopo e un ambito più chiari.

Come abilitatori, saremo i moltiplicatori di forza come suggerito da Marty Cagan nel suo articolo piuttosto che un ruolo di riempimento.

Ma in termini pratici, cosa significa e come applichiamo questa logica quando pensiamo al ruolo e alla portata?

Abilitare non possedere

Per quanto vorremmo essere in grado di presentare una risposta standard sull'ambito e la responsabilità delle operazioni di prodotto, non possiamo perché dovrà adattarsi, a seconda di vari fattori:

• Le esigenze specifiche dell'organizzazione
• Dove le operazioni del prodotto si trovano all'interno dell'organizzazione
• La maturità dell'organizzazione del prodotto

Quando abilitiamo, sblocchiamo opportunità. Aiutiamo a connettere le persone per costruire le giuste relazioni. Creiamo le infrastrutture per supportare il team piuttosto che forzare il team.

Diamo un'occhiata all'esempio pratico del feedback dei clienti. Indipendentemente dal fatto che l'azienda abbia ricerca, successo dei clienti, vendite, operazioni con i clienti o nessuno dei precedenti, comprendiamo che il feedback dei clienti è una parte importante del processo di sviluppo del prodotto.

La sfida è che il feedback dei clienti proviene da varie fonti e ognuno vuole essere sicuro che il feedback dei clienti raggiunga le persone giuste per prendere le decisioni giuste.

A questo punto, le operazioni del prodotto potrebbero facilmente vedere come loro responsabilità oliare la macchina e assicurarsi che ciò accada.

La verità è che ci sono diversi modi per affrontare la situazione, a seconda dei fattori sopra menzionati.

Come facciamo a farlo funzionare senza pestare i piedi a nessuno?

Come regola generale, suggerisco personalmente il seguente approccio incrementale.

Passaggio 1: inizia collegando i punti

Il primo passaggio consiste nell'identificare le persone, i reparti e le informazioni chiave da collegare.

• Chi possiede cosa?
• Chi ci aiuterà a portare avanti le cose?
• Chi ha bisogno di consumare le informazioni e come?
• Chi può fornire le informazioni e come?

A volte, siamo in grado di scoprire soluzioni già esistenti e portarle alla luce. Se quei sistemi e pratiche di supporto funzionano abbastanza bene, potremmo essere in grado di fare un passo indietro senza troppi interventi.

In altri casi potremmo renderci conto che ci sono troppi collegamenti mancanti tra le soluzioni esistenti e dovremo fornire maggiore supporto per mitigare tali carenze.

Potenzialmente potremmo giungere alla conclusione che non esiste una vera infrastruttura e dovremo essere ancora più attivi rispetto alle due versioni precedenti. Tuttavia, e questo è importante, ciò non significa che dobbiamo assumerci la governance. Potrebbe essere un indicatore precoce, ma ancora non scritto nella pietra.

Passaggio 2: supportare l'infrastruttura

In tutti e tre i casi presentati nel passaggio precedente, ora dovremo fornire un po' di supporto, ma varierà notevolmente per ciascuno.

Nel primo caso, si tratta di supportare quella connettività fino a quando non sarà in grado di supportare se stessa. Non come proprietari, ma come facilitatori o connettori.

Il secondo caso presenta un po' più di complessità, in cui dobbiamo supportare la connettività, ma dobbiamo anche aiutare a definire i modelli di lavoro dei pezzi mancanti. In questo caso, se siamo proprietari dell'opera o solo del supporto dipenderà dal fatto che abbiamo proprietari esistenti che hanno più senso di noi.

Nell'ultimo caso, dobbiamo avere una parte più attiva ea volte dobbiamo essere i driver. Qui siamo i proprietari almeno durante il processo di ideazione, definizione e lancio. Ma non necessariamente proprietari a lungo termine.

Passaggio 3: possedere solo ciò che ha senso, quando ha senso

È qui che dobbiamo essere molto severi sul fatto che ci assumiamo la proprietà di qualcosa o facciamo un passo indietro e lasciamo che i team si assumano la responsabilità da soli.

Nel primo caso è più facile, perché hanno già l'infrastruttura esistente per possedere tutto. Aiutiamo a sbloccare l'efficienza in quelle relazioni e modelli di lavoro. Questo è tutto.

Nel secondo caso, dobbiamo essere sicuri di chi dovrebbe possedere la soluzione. Product Ops potrebbe possederlo temporaneamente fino a quando non esiste il team o l'infrastruttura necessari. Nell'esempio del feedback dei clienti, se esiste un team per il successo dei clienti o operazioni con i clienti, ha molto più senso che ne siano proprietari. Tenerlo in Operazioni non avrebbe senso a lungo termine e "combattere" per esso sarebbe uno sforzo sprecato.

Nell'ultima istanza, analogamente all'opzione precedente, dobbiamo essere chiari sul fatto che la soluzione rientri nell'ambito Product Ops nel lungo periodo. Se ha senso, allora Ops dovrebbe possederlo ed evolverlo.

Se tuttavia non rientra nell'ambito definito per le operazioni del prodotto, dovremmo essere pronti a lasciarlo andare una volta che è pronto.

Dovremmo essere felici di trasmetterlo ai proprietari che hanno più senso. Dovremmo sostenerli nell'assumere la proprietà. Il loro successo fa parte del nostro successo e non lascia andare il nostro "bambino".

Questa è una parte importante dell'essere l'abilitatore. Vogliamo supportare i team attraverso le sfide complesse e quindi aiutarli a essere preparati a possedere quelle soluzioni andando avanti.

Pensieri finali

Probabilmente una delle cose più difficili nell'assumere un ruolo di Product Operations è sapere che lavorerai su molte cose che potenzialmente non possiedi in futuro.

Si tratta di investire il nostro tempo e i nostri sforzi per produrre il nostro miglior lavoro e poi a volte consegnarlo ad altri.

La ricompensa sta nel vedere come gli altri beneficiano del tuo intervento e come loro stessi maturano ed evolvono grazie al tuo supporto e coaching.

Avendo un approccio incrementale, siamo in grado di comprendere meglio il nostro livello di intervento ed evitare di indossare troppi cappelli o assumerci più di quanto possiamo masticare.

Alla fine vogliamo sbloccare i superpoteri dell'organizzazione del prodotto. Volendo possedere tutto, potremmo potenzialmente mostrare un grande impatto inizialmente, ma a lungo termine diventeremmo un ostacolo all'innovazione e all'evoluzione dell'organizzazione.

Non essere il guardiano, sii l'abilitatore!

Link e risorse utili

• Panoramica sulle operazioni del prodotto — Marty Cagan
• Aggiornamento stato Linkedin — Antonia Landi
• Product Ops sta costruendo la tua auto — Chris Compston
• Che cos'è Product Op? — John Cutler