Suggerimento per i Product Manager: collega i Product Backlog con la Product Vision

Una delle sfide costanti per un team di sviluppo agile basato sul prodotto è mappare ciò che stanno facendo "in questo momento" su ciò che il prodotto dovrebbe assumere, ad esempio, tra 2-3 anni.

Non si tratta di team che non sanno a cosa stanno lavorando, ma più del fatto che potrebbero rimanere troppo concentrati sulle loro attività quotidiane, minando invariabilmente la sensibilità dell'impatto del loro lavoro "presente" nel quadro generale . Le decisioni o le scelte effettuate oggi in fase di esecuzione possono avere un grande impatto futuro, soprattutto quando il prodotto è in evoluzione.

Facciamo un esempio di vita reale.

Facevo parte di un team agile che stava cercando di introdurre un servizio di traduzione di testi per i contenuti del sito . La decisione è stata presa ed è stato utilizzato uno strumento di traduzione automatica di terze parti. Tuttavia, la roadmap del prodotto alla fine menzionava che, in futuro, gli utenti dovrebbero essere in grado di correggere e fornire la propria traduzione contestuale, il che significa che la capacità di traduzione dovrebbe avere un'intelligenza artificiale in modo che possa imparare da sola, sulla base del feedback.
Data questa evoluzione, la scelta fatta non è stata azzeccata e ha quindi richiesto un discreto grado di rielaborazione perché il quadro generale non era legato a ciò che il team agile era incaricato nello sprint.

Si può sostenere che i team possono fare uno sforzo consapevole per ottenere queste informazioni, ma il punto è che perché questi obiettivi "a lungo termine" non possono essere catturati negli strumenti agili e nei dashboard esistenti?

I team agili eseguono compiti ben definiti e specifici in un ciclo di sviluppo, ma ciò significa che deve essere a costo di essere indifferenti all'evoluzione del prodotto? No, non credo.

Da quanto ne so, non esiste uno strumento o un framework rapido che sostenga o raccomandi queste informazioni al team agile, nel suo funzionamento quotidiano, ma è possibile creare tale visualizzazione nella visualizzazione esistente? Vale la pena provare? Vediamo come possiamo farlo.

Inizieremo con l'artefatto più comune nell'agile: il product backlog.
Secondo l'Istituto SCRUM, un product backlog è l'elenco delle cose che devono essere fatte in un progetto. Queste cose possono includere miglioramenti e/o bug. Un elenco numerato non è utile a meno che il team non sappia quale sia la struttura di priorità degli elementi. È qui che entra in gioco il Product Owner che ha la responsabilità generale di lavorare con le parti interessate per ottenere requisiti chiari, risolvere le interdipendenze e ottenere un elenco prioritario per gli elementi del backlog del prodotto.

È possibile che durante questo processo un elemento di lavoro più grande e dipendente venga ulteriormente suddiviso in piccole parti in modo che sia facile da sviluppare per il team. Questi elementi del product backlog sono suddivisi in blocchi più piccoli ed eseguiti in cicli di sprint che vanno da due a quattro settimane, rispondendo alla componente "come" dello sviluppo del prodotto.

D'altra parte, gli elementi del product backlog sono anche mappati al "vero nord" del prodotto, spesso definito come la visione del prodotto. Questo è lo stato desiderato del prodotto che viene spesso raggiunto attraverso più versioni di rilascio e si collega strettamente a ciò che il pubblico o i clienti di destinazione desiderano e al valore che apporta loro.

Questa catena di elementi che collega il team agile ai clienti (inclusi product backlog e vision) può essere rappresentata come:

Legame a distanza tra un team agile e ciò di cui il cliente ha bisogno...

Con la mancanza di una visione che colleghi chiaramente gli sprint alla visione del prodotto, i product owner corrono spesso il rischio di concentrarsi troppo sulla parte "come" e di perdere di vista l'obiettivo più grande e importante del "cosa", che può portare a una definizione errata delle priorità.

L'approccio che discuto qui è quello di creare una vista semplice ma potente che colleghi entrambi i componenti. Questo è noto come Product Vision Matrix (PVM). L'obiettivo è collegare la visione del prodotto a elementi di sviluppo granulari. Questa matrice diventa un fattore chiave nell'analisi dei progressi del team rispetto allo sviluppo del prodotto. Serve anche come dashboard del prodotto per il senior management dell'organizzazione e li tiene aggiornati sulla raggiungibilità degli obiettivi del prodotto.

Come suggerisce il nome, PVM è una matrice in cui le colonne rappresentano le dimensioni (da micro a macro) che vengono acquisite. Comprendiamo il PVM con l'aiuto di un'app di ordinazione di cibo in cui la visione è quella di fornire un'esperienza alimentare agli utenti e il punto di partenza è l'ordinazione di cibo. La matrice di esempio si presenta così:

La Product Vision Matrix può avere i seguenti campi:

• Versione del prodotto: questa è la versione del prodotto che rappresenta la pietra miliare del rilascio ufficiale ed è spesso ciò che il cliente riceve.
• Articolo Big Rock: questa è la categoria o il tema a cui appartiene anche una caratteristica. Questi articoli possono anche essere le aree di necessità del prodotto a lungo termine della visione del prodotto.
• Caratteristica: questa è la caratteristica del prodotto in fase di sviluppo. La funzione può appartenere a uno o più temi (grandi oggetti rock).
• Sprint ID: questo è il numero di sprint in cui viene sviluppata una funzione.
• Stato di sviluppo: questo campo indica lo stato di avanzamento dello sviluppo (pianificato, progettazione completata, sviluppo completo, testato e rilasciato).

Si noti che la struttura della matrice è indicativa qui. Si può essere più creativi nell'identificare le colonne che possono catturare la visione del prodotto.

Il vantaggio di questo approccio è la chiara visibilità che ogni membro del team ha sugli obiettivi generali del prodotto. Per un prodotto in evoluzione, i membri del team dovrebbero avere una migliore comprensione del quadro più ampio. Ciò non solo consente loro di contribuire in modo efficace, ma consente loro anche di assumersi una maggiore responsabilità. Il risultato è un team più concentrato e adattivo che ha sempre un dito sul polso dei propri clienti e riconosce la differenza che i loro sprint possono fare nel contribuire alla visione e all'eventuale successo del prodotto.

Studia i corsi di Product Management online dalle migliori università del mondo. Guadagna master, Executive PGP o programmi di certificazione avanzati per accelerare la tua carriera.

Programma in primo piano per te: programma di certificazione Design Thinking di Duke CE