Product Ops: il miglior amico del Product Manager

Quello del Product Ops è un ruolo che si sta sempre più affermando nell’ecosistema del Product Management. Si tratta di una figura che fa da ponte tra i team che sviluppano il prodotto come engineering e prodotto, e quelli che hanno un rapporto con il cliente finale come supporto, sales e customer success.

Ok, ma in che senso? Scopriamolo insieme.

Indice:

• Che cos’è il Product Ops (Product Operations)
• Cosa fa un Product Ops Manager nella pratica
  • Processi poco chiari (e magari pure lenti)
  • Onboarding lungo (e costoso)
  • Educare il cliente (e gestire le aspettative)
  • I dati (questi benedetti)
• Serve proprio avere un Product Ops Manager?
• Come funziona nel mondo reale

Che cos’è il Product Ops (Product Operations)?

Prendiamo l’insieme di attività che normalmente svolge un Product Manager: ecco, il Product Operations Manager ha il compito di massimizzare il valore di queste attività, assicurandosi che i processi siano efficienti e le comunicazioni efficaci e, soprattutto, di non smettere mai di fare analisi dei dati e ricerca.

Cosa fa un Product Ops Manager nella pratica?

In breve, è il Product Manager del team di prodotto e si deve assicurare che tutti gli stakeholder ne siano soddisfatti. Cerchiamo di andare più al sodo e alla pratica: all’interno di un’azienda di prodotto ci scontriamo ogni giorno con alcune difficoltà (che conoscete bene), tra cui:

Processi poco chiari (e magari pure lenti)

Il Product Ops ha il compito di studiare i flussi di lavoro e di comunicazione, i tool usati e gli attori coinvolti e di ottimizzare al meglio potenzialmente ridisegnando il tutto.

Un esempio: Il cliente che chiede una nuova feature.

• Attraverso quali strumenti e persone viene richiesta? In quale formato?
• Come viene digerita la richiesta prima di arrivare al team di prodotto e poi a engineering?
• Il cliente come viene informato?
• Come pesiamo la priorità delle richieste?

Ecco, uno scenario che potrebbe sembrare semplicissimo, coinvolge una moltitudine di reparti, tool e processi aziendali di cui a volte non ci rendiamo conto. È in questo momento, che il Product Operations entra in gioco, portando tutte le persone allo stesso tavolo e definendo un flusso comune di come queste richieste verranno gestite, con quali tempistiche e standard comunicativi interni ed esterni. Successivamente, quanto definito va monitorato, ma non solo. Andrà verificato se il tutto viene rispettato dalle parti ed è quindi efficace, se ci sono dei task ripetitivi o poco strutturati che possono essere migliorati, eccetera. Insomma, non finisce mai.

Onboarding lungo (e costoso)

Nella mia seppur breve carriera ricordo almeno due aziende che mi hanno detto: “il tuo onboarding durerà almeno 6 mesi. Siamo troppo complicati perché tu sia operativo prima”. E questo non riguardava la quantità di materiale da studiare o webinar da guardare, ma la facilità con cui reperire informazioni all’interno di un’organizzazione.

• “A chi posso chiedere di questo?”
• “Chi mi potrebbe spiegare questa cosa da un punto di vista dell’utente finale?”
• “Quel collega è sempre occupato, non ha mai tempo”

In questo caso il Product Ops deve assicurarsi che ogni risorsa che entra a far parte del team abbia la sua “cassetta degli attrezzi” pronta all’uso. Vanno bene i webinar e la documentazione interna, i tutor di riferimento, un glossario con le parole chiave disponibile nella intranet aziendale, un tool che aiuti a sapere “a chi chiedere cosa”, oppure l’organizzazione di momenti interni di ask the expert e di pair working, esattamente come si fa tra sviluppatori.

Il discorso, chiaramente, non vale solo per le nuove assunzioni. Se viene lanciata una nuova feature, tutti i team che possono essere coinvolti devono essere formati. Dunque, il Product Ops deve supportare un programma interno di continuous learning che permetta ad ogni reparto e a qualunque anzianità aziendale di essere il più velocemente aggiornati e pronti.

Educare il cliente (e gestire le aspettative)

Il cliente ha “sempre” ragione se usa il prodotto in maniera diversa da come ci aspettiamo, se tempesta il supporto di richieste su come svolgere alcuni task. Probabilmente abbiamo progettato dei flussi complicati o l’esperienza utente è diversa da come la immaginavamo.

Il Product Ops deve innanzitutto:

• Intercettare questi problemi analizzando i dati a disposizione
• trovare potenziali cluster di clienti che ne sono ‘affetti’
• Dare supporto alle soluzioni

L’adozione di un tool di analytics dei comportamenti dell’utente ci permette di capire quale sia la customer journey che viene fatta per utilizzare una specifica funzionalità. Potrebbe essere fatta sul prodotto vero e proprio (con Amplitude o Pendo) oppure insieme al team di UX in fase di prototipo (con Maze, ad esempio).

L’aggiunta all’interno del prodotto di un sistema di feedback sulle funzionalità o, ancora meglio, di guide all’utilizzo è un altro modo per dare supporto tecnico; se preferiamo quello più umano, è possibile pensare di creare un pool di clienti “eletti” a cui venga rilasciata la versione in fase beta per la validazione prima del rilascio in produzione.

Infine, la comunicazione di una release, spesso sottovalutata è fondamentale. È importante definire il tipo di aggiornamento che viene fatto e tarare il tipo di comunicazione: per dei bugfix può bastare una release notes, per delle funzionalità più avanzate potrebbe essere necessario un video tutorial.

I dati (questi benedetti)

Abbiamo già affrontato il tema della necessità di passare da un processo opinion-driven a quello data-driven: bisogna definire le fonti dati e i KPI, creare grafici e presentarli, evolverli (perché l’appetito vien mangiando), e poi monitorare i miglioramenti e le azioni da svolgere.

Chi si fa carico di questo lavoro? Il Product Ops, ovviamente.

In questo caso, al Product Manager arrivano direttamente gli insight: non si dovrà occupare di fare spreadsheet o aspettare risultati di un tool di BI, ma si focalizzerà solamente su quanto prodotto ed eventualmente correggere il tiro.

Potrà sembrare che il Product Ops si occupi semplicemente del “lavoro sporco”, ma non è così. Il suo lavoro non si deve limitare alla mera estrazione di dati e redazioni di grafi.
Un vero braccio destro deve:

• Suggerire e migliorare
• Saper interpretare quei dati
• Cogliere potenzialità di miglioramento della base dati cliente
• Promuovere l’incrocio di fonti diverse
• Occuparsi della user experience di quei risultati, perché troppo spesso vengono presentati enormi tabulati con assunzioni complicate.

Serve proprio avere un Product Ops Manager?

La risposta vi stupirà ed è NO. Almeno, non sempre. Ma ci sono alcune domande di “autodiagnosi” che ci possono aiutare a capire se ci serve.

C’è qualcuno in azienda che si occupa di svolgere queste attività che per noi rappresentano delle difficoltà?
No? Houston abbiamo un problema! Molto probabilmente non stiamo costruendo un buon prodotto (e nemmeno un buon team).

Quel qualcuno in azienda è forse il Product Manager? 
Se il tempo investito per svolgere le attività toglie spazio alla produttività delle funzioni principali, forse dobbiamo considerare di avere una figura dedicata che se ne occupi. Qualunque sia la condizione in cui ti trovi, promuovere il miglioramento della propria organizzazione di product management non è mai sbagliato e porterà sicuramente dei benefici.

Come funziona nel mondo reale?

Come dicevamo, il POM è una figura molto “fresca” e la sua interpretazione all’interno delle organizzazioni è diversa: alcune hanno un vero e proprio team, con una risorsa dedicata per ogni product manager, altre invece un team più ristretto e trasversale.

Ecco alcuni esempi:

• In Stripe: le fasi chiave sono l’alimentazione delle connessioni tra gli stakeholder del team di prodotto, la coordinazione dei lanci delle feature e l’ottimizzazione dell’onboarding del prodotto;
• JustEat: ha un ruolo più operativo dentro e fuori i team di lavoro, si occupa della formazione interna ma anche esterna, di documentare i piani di implementazione e di svolgere quasi un ruolo da Project Manager per quanto riguarda le integrazioni;
• Twitter: è più simile al ruolo classico che abbiamo visto ma più orientato alle sperimentazioni. Quindi, va a verificare l’efficacia delle soluzioni che vengono messe sul campo e a guidarle attraverso i dati.

Se l’articolo ti è piaciuto e vuoi rimanere aggiornato sui prossimi contenuti, iscriviti alla nostra Newsletter 📩