10 modi per creare una presentazione della roadmap del prodotto efficace

La presentazione della roadmap del prodotto può essere fastidiosa sia per gli sviluppatori che per i product manager: gli uni hanno lavorato duramente per elaborare una vision, mentre gli altri aspettano di conoscere le incognite che influenzeranno il loro lavoro.

Sentivo questa tensione quando lavoravo come sviluppatore e spesso mi ritrovavo insoddisfatto delle roadmap di gestione dei prodotti messe insieme. Non mi ritrovavo completamente d'accordo con le decisioni e spesso uscivo da una riunione di pianificazione pensando che la decisione raggiunta non avesse senso per me, ma accettandola perché aveva senso per gli altri, o peggio ancora pensando che io e il team avremmo dovuto capire le cose da soli e far sembrare che il nostro lavoro si adattasse alla roadmap.

Si potrebbe dire, forse anche a ragione, che probabilmente il problema era che soffrivo di sindrome NIH (Not Invented Here). Come sviluppatore, avevo un'opinione molto forte su quale fosse la cosa giusta da fare. Ma ora come product manager, vedo cosa ha causato questo distacco e quali conoscenze generali possono trarre i product manager da quest'ultimo per presentare la roadmap in modo efficace. Dopotutto, se il team tecnico è d'accordo e comprende il quadro generale, le decisioni quotidiane di progettazione e implementazione verranno prese nel giusto contesto e sarà possibile realizzare il prodotto immaginato.

Di seguito sono elencati i dieci modi migliori secondo me per conquistare i team con la presentazione della roadmap del prodotto.

Sebbene parole d'ordine come "analisi dei big data", "apprendimento automatico" o "iniziativa Internet of Things (IoT)" possano trovare riscontro tra gli stakeholder aziendali come punti di riferimento generali, non sono elementi utili e fruibili per i team tecnici. Il team tecnico deve sapere esattamente cosa sta compilando, in che modo si relaziona con i prodotti attuali, come dovrebbe essere rilasciato e chi lo utilizzerà alla fine e per quale scopo.

L'impostazione di temi generali è ottima per strutturare la roadmap e il contesto, ma assicurati di non fermarti qui e di avere risposte valide per tutti gli aspetti alla base di ogni elemento generale. Ad esempio, se hai chiamato un tema "servizi intelligenti," assicurati di suddividerlo in iniziative ed epic chiave, necessari per completare questo tema.

I team tecnici hanno bisogno di contesto che spieghi perché si sta creando un prodotto in base a una roadmap. Nessun team tecnico vorrà sapere soltanto cosa deve creare, senza nessun'altra informazione. Gli ingegneri hanno bisogno di vedere le prove del motivo per cui si ritiene che una determinata funzione sia necessaria. Lascia parlare i dati, ma racconta anche una storia potente dal punto di vista degli utenti. Usa gli utenti tipo e parla di alcune alternative che hai escluso e perché. Per aiutare l'intero team a comprendere la roadmap, il "perché" è importante tanto quanto il "cosa".

Una tipica situazione da flag rosso è quando una funzione che non sembra ben pensata o realistica si trova ancora sulla roadmap. Non è consigliabile che il team tecnico abbia l'impressione di dover compilare programmi solo perché l'hai promesso a qualcuno. Ad esempio perché hai preso un impegno nei confronti di un cliente o perché lo vogliono i dirigenti. Quindi prendi gli impegni con saggezza. Anche se una modifica particolare ti viene imposta dall'alto, assicurati di comprendere e trasmettere al team la logica alla sua base e di sostenerla in prima persona.

Avere una vision è positivo, ma è ancora meglio se tutti hanno la sicurezza che sia possibile raggiungerla. Il piano non deve essere preciso, ma se la prima cosa che il development manager vede quando guarda la roadmap è un enorme collo di bottiglia, ad esempio se la roadmap sembra avere una progettazione pesante e incentrata sul front-end, ma il team ha un solo designer e ha avuto difficoltà relative al front-end negli ultimi mesi, allora avrà difficoltà a seguire la roadmap per tutto il resto della presentazione.

Non dimenticare di fare una verifica della realtà dei fatti in anticipo insieme al team e di immaginare vari scenari ipotetici. È necessario avere risposte, un piano d'azione chiaro e una considerazione concisa della fattibilità prima di chiedere l'impegno di tutti.

Devi essere consapevole del livello attuale delle competenze sul prodotto e di team e del livello che desideri raggiungere. È fantastico avanzare in nuovi campi, il che potrebbe richiedere nuove competenze di team o l'abbandono della tecnologia esistente, ma non limitarti a scrivere gli obiettivi che aspiri a raggiungere tra un anno. Pensa invece a come arrivarci realisticamente. Acquisire talenti richiede tempo, l'adozione di nuove tecnologie richiede tempo e l'abbandono dei prodotti esistenti richiede un impegno e un piano di transizione chiari.

Business case? Sì. I team tecnici danno importanza ai business case. Forse non nella stessa misura dei senior manager, ma l'intero team di sviluppo si interessa del perché qualcosa è rilevante per l'azienda, se produce risultati reali e come verrà misurata. Sfrutta l'intelligenza aziendale del tuo team tecnico. Tutti hanno un legittimo interesse nei confronti del successo dell'azienda nel suo insieme e ciò può essere un'ottima fonte di feedback o idee aggiuntive.

Inoltre, la piena chiarezza sull'impatto aziendale e il vederlo realizzato nella pratica può essere una grande motivazione; ottenere risultati dà più soddisfazione dell'aver semplicemente creato e rilasciato una funzione.

Gli ingegneri vogliono creare prodotti unici e innovativi di cui essere orgogliosi. Se si tratta invece della stessa vecchia story già raccontata prima, il team può essere demotivato. Conduci delle ricerche per assicurarti che la tua story sia innovativa come pensi. A parte gli sviluppatori demotivati, l'impatto aziendale causato dalla mancanza di innovazione è ancora peggiore.

Detto questo, anche le roadmap rappresenteranno sempre un bilanciamento tra nuove entusiasmanti funzioni e le funzioni obbligatorie ma non troppo interessanti dal punto di vista tecnico che devono essere create. Fai in modo che persino le attività più ordinarie siano presentate sulla roadmap in modo stimolante.

Creare un prodotto minimo funzionante e quindi una versione 1 è una cosa, ma occorre considerare anche tutto ciò che accade dopo il lancio: operazioni, manutenzione, richieste di funzioni da parte degli utenti, miglioramenti continui e nuove versioni di altri prodotti e/o piattaforme integrate. Una rapida riflessione su quali potrebbero essere le sfide e gli ostacoli successivi al lancio li porterà alla luce senza troppi sforzi e gli ingegneri ti saranno grati per non aver ignorato queste realtà. Da alcune stime approssimative emerge che il lavoro iniziale per la creazione di una nuova funzione rappresenta spesso da un terzo alla metà del lavoro totale dedicato a quest'ultima nel suo intero ciclo di vita. In altre parole: le conseguenze sono più costose della build iniziale e alcune "piccole cose veloci" diventano molto costose a lungo termine.

Le stime sono utili. Danno una guida e sono create al meglio delle conoscenze del product manager in un determinato momento. Tuttavia, molte ipotesi fatte per le stime si rivelano sbagliate una volta che si entra nella fase di implementazione o di perfezionamento di un progetto. Assicurati di preparare e presentare la roadmap in modo che sia flessibile alle modifiche.

Le roadmap servono a fornire indicazioni. Non sono dei piani di esecuzione dettagliati e ogni membro dei team software lo sa. Non c'è bisogno di presentarle come qualcosa di diverso da quello che sono. Quindi, se non hai ancora tutti i dettagli su un argomento, cerca di mantenere un atteggiamento aperto al riguardo. Condividi le informazioni che hai, l'intenzione, quali sono le domande aperte e i rischi più elevati che devono ancora essere affrontati. Indica le aree che richiedono sperimentazione e ulteriori ricerche per definire il "cosa". Ricordati solo di tenere in conto questo tempo di sperimentazione durante la pianificazione.

Il tuo team merita una roadmap che dipinga chiaramente il quadro generale, ma senza trascurare la realtà. Il tuo team merita anche una roadmap che sia motivante, entusiasmante e con dettagli sufficienti in modo che l'intero team software sappia cosa fare nei prossimi 1-2 sprint con la sicurezza di raggiungere ottimi risultati che avranno un impatto materiale per l'azienda.

Serve ulteriore aiuto? Dai un'occhiata alle funzioni delle roadmap in Jira Software e a un modello di roadmap del prodotto in Jira. In alternativa, prova gratuitamente Jira Product Discovery realizzato per i PM.