I 5 migliori diagrammi utilizzati per spiegare i concetti di gestione del prodotto

Ci sono molte cose di cui i product manager sono responsabili e responsabili. Un product manager non è solo responsabile della strategia creando una roadmap, ma deve anche articolare il ciclo di rilascio di un nuovo prodotto per il team insieme a tutto ciò che si trova nel mezzo.

Sono inoltre tenuti ad avere l'esperienza nel sapere come identificare i compiti prioritari e gestire il team di conseguenza. Non solo questo, ma anche i product manager mobili hanno la responsabilità di analizzare le funzionalità aggiunte a un prodotto (app mobile) e se sono sincronizzate con gli obiettivi del cliente.

Tutto sommato, ogni processo, attività e decisione associata a un prodotto viene sincronizzato e allineato dal product manager mobile. Ciò che aiuta questi product manager a raggiungere i loro KRA è un certo insieme di abilità .

Ora, ovviamente, sarà loro richiesto di spiegare alcune idee di gestione del prodotto ai membri del loro team in modo che siano tutti sulla stessa pagina. Ma la cosa da chiedersi è: come spiegano tutti i concetti di gestione del prodotto e le idee chiave?

Bene, penso che alcuni diagrammi utili per i product manager facciano il trucco. Se sei interessato a sapere cosa sono questi diagrammi e come e quando vengono utilizzati dai gestori di prodotti mobili, attieniti fino alla fine.

Diagramma 1 – Colli di bottiglia della comunicazione

Resta inteso che come manager, devi essere consapevole di cosa sta succedendo nel tuo team e di come i membri del team gestiscono i loro compiti. Ma è ridicolo per qualsiasi persona essere coinvolta in ogni comunicazione e decisione: una persona non può gestire tutte le cose da sola, giusto? Non è per questo che è stata inventata la delega?

Ora, è naturale che tu voglia essere incluso in tutte le conversazioni importanti tra squadre e squadre, ma devi riflettere su una cosa: è necessario? È qualcosa che dovresti fare mettendo da parte le tue altre responsabilità?

La risposta è: analizzare se il team è in grado di comunicare che non dipende da te. E se lo è, devi prendere alcune decisioni consapevoli per assicurarti che cose importanti come una comunicazione fluida non dipendano solo da te. Di seguito è riportato uno schema che può spiegare efficacemente il caso in questione.

Diciamo che un Web Engineer ha bisogno di discutere qualcosa con l'analista di prodotto e poi l'AP dice che ha bisogno di discutere qualcosa con lo sviluppatore iOS a questo proposito. Ora, il Web Engineer dovrebbe idealmente avvicinarsi direttamente allo sviluppatore PA e iOS, invece di dipendere dal PM (come mostrato nell'immagine a sinistra).

Il diagramma a sinistra mostra la dipendenza del team dal product manager per comunicare con altri membri di altri team, cosa che influisce negativamente sul flusso di lavoro e lo rallenta. E sulla destra c'è il diagramma che mostra un flusso di comunicazione efficiente e indipendente, eliminando istantaneamente i punti di contatto non necessari.

Diagramma 2: Cascata vs agile

Sebbene ci siano molte risorse là fuori su Internet che partecipano al dibattito sull'approccio Agile vs Waterfall , può sembrare ancora un concetto vago in relazione alla gestione del prodotto. Quindi svuotiamo la nebbia dell'ambiguità.

È generalmente noto che il costo dello sviluppo di app mobili viene calcolato sulla base delle ore necessarie per sviluppare quel prodotto.

Ora, se il product manager di quella società di sviluppo di app mobili sceglie di utilizzare l'approccio Waterfall (ovvero, una versione di grandi dimensioni del prodotto), ciò significherebbe che il prodotto verrà lanciato tutto in una volta.

Ora, quando un prodotto viene rilasciato, ci si aspetta che diventi un successo immediato, cosa che non sarà facile in questo caso, dal momento che il prodotto viene lanciato tutto in una volta ed è sicuramente la causa di alcuni problemi. Il valore che otterranno da questa versione non sarà equivalente all'investimento (tempo) fatto dagli sviluppatori. È perché richiederebbero di risolvere i problemi dall'inizio.

Al contrario, l'approccio agile che supporta piccoli rilasci e iterazioni mostrerebbe risultati di valore istantanei, dal momento che stai identificando gli errori e risolvendoli contemporaneamente. Il diagramma sopra mostra chiaramente la differenza nel risultato finale della scelta di questi approcci di gestione del prodotto .

Diagramma 3: Rappresentazione della dimensione della consegna

Quando si tratta di consegnare un prodotto in tempo, è una parte molto cruciale dell'intero processo di sviluppo . Può letteralmente creare o distruggere il futuro di qualsiasi app mobile. Se il time-to-market è troppo lungo, qualche altra app potrebbe conquistare il mercato e rendere inutile l'app mobile in questione.

Ecco una rappresentazione delle dimensioni delle iniziative intraprese durante lo sviluppo di un'applicazione:

Il diagramma a sinistra mostra il throughput della dimensione della consegna che si occupa solo di lavorare su grandi progetti (grandi blocchi di lavoro contemporaneamente). È assolutamente chiaro che lavorare solo su grandi progetti di un prodotto creerebbe un blocco ad un certo punto nel futuro, poiché questi progetti richiederebbero più tempo, attenzione, risorse, ecc. E se qualcosa va storto, l'impatto sarebbe devastante sull'intero processo, aumentando inevitabilmente il time-to-market.

{Leggi anche il nostro articolo su " Project Manager vs Product Manager: differenze, ruoli e sfide "}

Il diagramma a destra è un classico "da fare". I vantaggi dell'adozione dell'approccio Agile sono arrivati ​​a questa fase anche nel processo di gestione del prodotto . Questo approccio sostiene la combinazione di eseguire piccoli compiti con grandi quantità di lavoro (blu), qualcosa che seguiamo anche in Appinventiv.

Come visibile nel diagramma, a differenza di quello a sinistra, qui piccoli pezzi di lavoro (Rosa) possono passare facilmente attraverso l'imbuto (si può fare facilmente). Se questi hanno successo, i product manager possono portare avanti questa idea (cerchi gialli) e investire completamente. E in caso contrario, possono ripetere l'iterazione e investire di conseguenza.

{Dai un'occhiata a questo articolo dettagliato sui " 10 documenti più importanti che i product manager devono preparare "}

Diagramma 4: Livello di coinvolgimento della leadership

Il diagramma seguente comprende due modelli per l'elaborazione di questo concetto di gestione del prodotto . Uno a sinistra mostra la dimensione dell'iniziativa, il numero di compiti svolti alla volta e il fattore di rischio in essi, e l'altro riguarda il livello di coinvolgimento dei product manager (leadership) corrispondenti a questi compiti e iniziative.

Quella a sinistra è una piramide di compiti/iniziative che il team deve svolgere. La parte inferiore della piramide indica che molti compiti vengono eseguiti contemporaneamente e il diagramma a destra mostra la quantità di coinvolgimento rispetto a questi compiti umili che hanno un rischio basso o nullo.

Man mano che ci spostiamo in cima alla piramide, il numero di attività diminuisce mentre aumentano anche i rischi associati a queste attività, è qui che il product manager DEVE essere consultato, mentre nella forma può essere solo informato. Questo diagramma aiuterebbe non solo i product manager mobili, ma anche i membri del team a sapere quando dipendere dalla leadership.

Diagramma 5: Analisi del valore di segmentazione

Ci sono alcune pratiche che le organizzazioni sono abituate a seguire. Uno di questi è l'abitudine di ottimizzare per la media invece che per un segmento. Ciò significa che tendono a concentrarsi sulla media anziché su segmenti particolari che devono essere migliorati.

Nelle circostanze in cui gli obiettivi e le ipotesi sono abbastanza ampi, diventa difficile per i product manager e i team di sviluppo creare un impatto attraverso il prodotto. È perché stai cercando di soddisfare una varietà di obiettivi allo stesso tempo, il che non è affatto possibile.

I diagrammi, come quelli riportati di seguito, sono un modo per analizzare ciascun segmento per identificare quali stanno influenzando le prestazioni degli altri. Tutto questo per risolvere i problemi prevalenti.

Il diagramma sopra è costituito da tre esperimenti ipotetici 1,2 e 3 con i segmenti A, B, C e D. Su tre esperimenti, nel primo caso, si è verificato un sollevamento nel segmento A, seguito da una diminuzione del secondo caso e terzo senza modifiche.

Dando un'occhiata individuale, nell'esperimento 1, il segmento A si è comportato bene con altri, tranne il segmento B. Ora, il diagramma ha evidenziato il declino in questo segmento giustapposta agli altri. Ciò potrebbe aiutare i product manager a trovare le ragioni di ciò che alla fine migliorerà la media nel lungo periodo.

Una situazione simile si verifica nell'esperimento 3, dove i segmenti A, C, D hanno prestazioni inferiori nel segmento di opposizione B che ha mostrato un cambiamento significativo. Ancora una volta, uno studio chiarirebbe le ragioni di ciò che sta accadendo.

Questi utili diagrammi per i product manager possono essere facilmente personalizzati in base alle proprie esigenze, indipendentemente dal settore in cui operano i product manager. Per quanto riguarda Appinventiv, penso che questi modelli aiutino davvero i nostri team a semplificare il processo e mantenere una comunicazione aperta tra /intra-team.

Domande frequenti

1. Che cos'è un framework di gestione del prodotto?

Tutti i framework sono essenzialmente strumenti utilizzati nel ciclo di vita della gestione del prodotto . Sono utilizzati per vari scopi, ad esempio per illustrare idee e concetti di gestione del prodotto e facilitare altre attività.

2. Qual è il processo di gestione del prodotto?

Il processo di gestione del prodotto si compone di varie fasi. Include: gestione delle idee, road-mapping, aggiunta e determinazione delle specifiche, definizione delle priorità, consegna, analisi e feedback degli utenti.