Che cosa è un Product Manager tecnico, Comunque?

Cosa significa veramente essere un Product Manager “Tecnico”? E come è diverso da solo un Product Manager? In questo post, condivido la differenza tra questi titoli più chiave Fare e non per aiutarti ad avere successo come Product Manager tecnico.

Potresti aver notato molte variazioni sul titolo del lavoro di Product Manager. Alcune aziende hanno Product Manager strategici, mentre altre hanno titoli di Product Manager legati a specifici verticali di settore, ad esempio, Product manager di e-commerce e Product Manager energetici. Tra le aziende di software, vedrai spesso i titoli Product Manager, Product Development Manager e Technical Product Manager. Ma qual è la differenza, comunque?

In realtà, il termine Technical Product Manager descrive una persona, non un ruolo. In particolare, descrive un Product Manager che ha un background tecnico e lavora su un prodotto tecnologico. Non descrive un Product Manager che deve effettivamente eseguire attività tecniche, come l’architettura e la codifica del software. Lo stesso vale per un Product Development Manager. In realtà non stanno sviluppando il prodotto: stanno svolgendo un ruolo di gestione del prodotto in stretto coordinamento con un team di sviluppo software.

In breve, affinché un’azienda ottenga il massimo valore dal ruolo, i Product Manager devono concentrarsi sulla gestione del prodotto, non sullo sviluppo. Ma alcuni Product Manager devono comprendere la tecnologia dell’azienda a un livello profondo e interfacciarsi con il team di sviluppo per guidare con successo la strategia per il prodotto. Le aziende possono scegliere di chiamare queste persone “Product Manager tecnici” al fine di attirare il candidato giusto.

A mio avviso, le competenze tecniche sono uno dei quattro pilastri della leadership di prodotto. Un Product Manager esperto di tecnologia ha enormi vantaggi, come ad esempio:

• Comunicazione migliorata (e fiducia) dal tuo team di sviluppo.
• Capacità di comprendere le tendenze tecnologiche, vedere come influenzano la tua roadmap e come guidano l’innovazione.
• Comunicazione migliorata con i clienti, ad esempio quando si parla con CIO e CTO.
• Capacità di comprendere le sfide tecniche e fare compromessi istruiti con il tuo team.

Tuttavia, troppo spesso, i Product Manager tecnici concentrano queste preziose competenze sul tentativo di creare la soluzione tecnica per il loro prodotto, piuttosto che risolvere le esigenze aziendali e degli utenti del loro cliente target.

Da questo punto di vista, diamo un’occhiata alle cose da fare e da non fare per i Product Manager tecnici.

Responsabile tecnico del prodotto Fare:

1. Non concentrarsi sul lato business del ruolo.

Indipendentemente dal settore o verticale, l’idea alla base della gestione del prodotto è quella di guidare la visione e l’esecuzione di un prodotto. È nostra responsabilità portare sul mercato prodotti che gli utenti desiderano, che risolvano un’esigenza aziendale e che generino profitto per l’azienda. Sono sempre affascinato nel vedere i tecnologi lanciare la loro nuova azienda con un prodotto che è un’implementazione tecnica molto intelligente, ma non risolve alcuna reale esigenza del cliente. Inutile dire che queste aziende raramente fanno bene nel mercato.

L’obiettivo di un Product Manager (tecnico o meno) dovrebbe essere quello di capire di cosa hanno bisogno gli utenti e lavorare con tutti i reparti necessari per dare vita al prodotto. In questo senso, il Product Manager tecnico è un ruolo aziendale con una certa attenzione alla tecnologia rispetto a un ruolo di tecnologo senza responsabilità per il successo del mercato del prodotto.

2. Usa le tue abilità tecniche per migliorare la definizione delle priorità e la pianificazione.

Se hai una chiara comprensione di come viene costruito il tuo prodotto, allora sei in grado di valutare il rischio di determinate funzionalità o ottenere una sensazione intestinale più accurata sulla durata delle storie o delle attività. Poiché sei in grado di comunicare con il team di sviluppo in modo molto più dettagliato, puoi comprendere le implicazioni di determinate decisioni e fare compromessi in termini di complessità, profondità o persino scadenze.

Dimostrando la leadership tecnica, sarete in grado di ottenere rapidamente la fiducia del vostro team di sviluppo e saranno più propensi a stare dietro di voi su decisioni difficili che richiedono modifiche rischiose, la priorità bug, o anche negoziare il temuto “debito tecnico.”

3. Sfruttate le vostre competenze tecniche per colmare il divario di comunicazione tra l’ingegneria e il resto del mondo.

Le persone con background tecnico di solito dimenticano che quasi nessuno capisce (o si preoccupa) dei dettagli tecnici. Questa è un’opportunità perfetta per il Product Manager tecnico di utilizzare le sue competenze per tradurre tra Ingegneria e altri reparti, comprese le vendite, Marketing di prodotto, e il cliente.

Inoltre, i Product Manager tecnici sono spesso assunti per guidare prodotti mirati a un pubblico molto tecnico, come API, strumenti di sviluppo, software IT, ecc. In questi casi, le caratteristiche del prodotto, il posizionamento del prodotto e la messaggistica devono risuonare con un pubblico molto tecnico. Questa è un’altra opportunità perfetta per sfruttare le tue abilità tecniche per comunicare con il tuo pubblico, ottenere feedback (nella loro lingua) e aiutare a chiudere un accordo parlando con lo staff tecnico del cliente.

Technical Product Manager Non è

1. Non progettare / risolvere il prodotto da soli.

Questa è una fonte chiave di confusione all’interno del ruolo di Product Manager tecnico. Molti Product Manager che provengono da ingegneria hanno difficoltà a lasciare la loro zona di comfort e rendersi conto che il loro valore è ora in un’area diversa. Si concentrano sulla definizione della soluzione tecnica per una particolare funzionalità invece di definire il risultato utente previsto o il valore aziendale. Passano più tempo a parlare con i loro architetti e a guardare oltre le spalle degli sviluppatori, piuttosto che parlare con i clienti e le vendite.

Ciò causa problemi su due fronti:

1. Il team di sviluppo si sente frustrato perché i dettagli della soluzione vengono appena trasmessi loro dal PM. Non hanno la possibilità di progettare e progettare la soluzione, che è una grande parte del loro lavoro, non il tuo.
2. La maggior parte del tempo del PM viene speso nei dettagli tecnici, quindi non c’è più tempo per pianificare e comprendere il cliente.

In poche parole, questo approccio non aggiunge valore agli sviluppatori, agli imprenditori o al prodotto stesso. Anche i Product manager tecnici devono essere associati a lead tecnici o responsabili dello sviluppo forti che possono condurre queste attività. Il mio motto è, ” il fatto che si può, non significa che si dovrebbe.”

Quando scrivi caratteristiche e storie, concentrati sul problema che stai cercando di risolvere e sulla persona che stai prendendo di mira. La definizione dovrebbe includere un diagramma di flusso di quale dovrebbe essere la soluzione (dal punto di vista dell’utente), inclusi i criteri di accettazione. Non dovrebbe essere una spiegazione dettagliata del posizionamento di ogni pixel, degli aggiornamenti al modello a oggetti o delle modifiche richieste alle tabelle del database.

2. Non assumere deliverable di gestione non del prodotto.

Molte aziende (specialmente quelle con un processo di prodotto meno maturo) pensano al Product Manager tecnico come un’estensione del Team di sviluppo. Ho visto molte descrizioni di lavoro che elencano le responsabilità regolari (tabella di marcia, visione, definizione delle funzionalità, ecc.), oltre a responsabilità di sviluppo come la scrittura di codice effettivo, l’esecuzione di test QA, la scrittura di documentazione, ecc. Per me, questo mostra solo un grande fraintendimento del valore del ruolo, e quelle situazioni dovrebbero essere evitate a tutti i costi.

3. Non fatevi prendere in Agile, o qualsiasi metodologia che si sta utilizzando.

Sono sempre stupito dalla quantità di discussioni che vedo online sulla gestione agile e del prodotto. Anche se capisco perché-molti PMS tecnici provengono dallo sviluppo, quindi rimanere estremamente coinvolti nel flusso Agile quotidiano si sente molto a loro agio.

Tuttavia, la realtà è che Agile è una parte molto piccola del ruolo del Product Manager. Concentrarsi troppo su Agile può effettivamente essere un danno quando si sta prendendo tempo lontano dalle responsabilità principali del PM, come interagire con i clienti e le vendite e definire la roadmap.

Per alleviare il carico di lavoro, sono un grande sostenitore di avere persone diverse che svolgono i ruoli di Product Manager e Product Owner. Questo approccio è controverso e potrebbe essere possibile solo in aziende con un processo di prodotto più maturo. Indipendentemente da ciò, penso che ci sia molto valore in questa separazione per garantire che nessun aspetto del ciclo di vita dello sviluppo del prodotto o della gestione del prodotto cada attraverso le fessure, a causa di un PM sovraccarico di lavoro.

Per avere una visione migliore di tutte le responsabilità di un Product Manager, suggerisco di esaminare i framework PM come quelli di Pragmatic Marketing e SiriusDecisions.

In sintesi

Diverse aziende hanno titoli e responsabilità di gestione dei prodotti diversi in base al tipo di prodotto. Ma indipendentemente da ciò, il lavoro principale di un Product Manager è quello di fornire la visione del prodotto, creare la roadmap e guidarne l’esecuzione.

L’aggiunta della parola “Tecnico” al titolo è utile nelle offerte di lavoro per evidenziare la necessità di background tecnico. Ma una volta nel lavoro, le chiavi del successo sono le stesse di ogni Product Manager: mantenere l’attenzione sul cliente, guidare una visione e garantire che il prodotto soddisfi le esigenze del mercato.

Questo è un guest post scritto da Daniel Elizalde, autore di Manager’s Build: best practices & inspiration for Product Manager & Leaders.