Il ciclo di vita del prodotto: viaggio di una caratteristica del prodotto

Questo è il quarto post di una serie in cinque parti che scrivo con l'obiettivo di aiutare un aspirante prodotto ad entrare nel mondo del Product Management.

Nel mio ultimo post , ho suddiviso la disciplina del Product Management in quattro parti con l'obiettivo di aiutare gli aspiranti al Product Management a comprendere la loro traiettoria di carriera all'interno di un'azienda o in generale. In questo post parlerò del percorso di vita di una caratteristica di un prodotto, dall'ideazione all'abbandono, per aiutare un aspirante al Product Management ad avere una prospettiva a 360 gradi su cosa comporta il ruolo di Product Manager.

T – 30 giorni

Si dice che la necessità sia madre dell'invenzione. Questo è letteralmente il caso in cui è coinvolta la nascita di una caratteristica del prodotto. Tutto inizia con un certo livello di disagio.
Qualche dipendente in azienda si trova a disagio nel portare a termine una delle sue attività quotidiane – forse la base di utenti è aumentata e non è in grado di gestirla con i vecchi processi. Alcuni dirigenti dell'azienda esaminano un foglio excel e pensano che l'azienda stia perdendo troppi soldi a causa, diciamo, di un numero elevato di cancellazioni di prodotti. O forse un concorrente ha lanciato una caratteristica del prodotto che sta facendo sì che i clienti lascino il prodotto di detta società. Qualcuno che ha esaminato il funnel di conversione del marketing ha notato cali elevati in una determinata fase e ha ritenuto che l'ottimizzazione di ciò avrebbe potuto aiutarlo a raggiungere il suo obiettivo trimestrale. Oppure potrebbero essere 100 ragioni diverse da un numero elevato di reclami dei clienti per un problema comune a una nuova funzionalità richiesta dalla maggior parte degli utenti intervistati la settimana precedente. Il punto è che tutto inizia con un certo livello di disagio.

Ora, questo disagio viene portato all'attenzione del Product Manager; o forse il Product Manager è quello che se ne accorge per primo. Questo è il punto che avvia una catena di eventi che potrebbe portare alla nascita di una nuova funzionalità.

T – 25 giorni

È tempo che il Product Manager rimugini sull'affermazione del problema. Va a parlare con i clienti o gli stakeholder interni che hanno segnalato il disagio e poi quelli che lo stanno effettivamente vivendo; il tutto con un unico obiettivo: assicurarsi di aver identificato l'affermazione del problema "radice". Se questa fase viene presa alla leggera o il Product Manager non ci dedica abbastanza tempo, le caratteristiche del prodotto nate sono fragili, distorte e raggiungono la loro fine abbastanza rapidamente.
Una volta che il Product Manager ha identificato la dichiarazione del problema principale, decide se vale la pena risolverla. Il disagio è davvero grande o è un po' esagerato o peggio, solo inventato? Risolverlo aggiungerebbe effettivamente un valore significativo al cliente e/o all'azienda? Risolverlo non imporrebbe una penalità significativa al cliente e/o all'azienda? C'è un modo per risolvere questo problema con una piccola modifica nei processi o attraverso qualsiasi attività che non richieda modifiche al prodotto, ad esempio cambiare un fornitore, negoziare un prezzo migliore da un fornitore esistente, ottenere un software di terze parti per risolvere il problema, assumere un dipendente in più, modifiche ai contenuti, alla grafica, al pulsante di invito all'azione, ecc.?

Fondamentalmente, se c'è un modo in cui possiamo ottenere un valore aggiunto simile da un metodo che non comporta modifiche al prodotto, allora lo faremmo piuttosto che cambiare qualsiasi cosa nel prodotto, sia che ciò significhi aggiungere o rimuovere. Una volta che il Product Manager è convinto che risolvere l'affermazione del problema fornirà un valore significativo e una modifica del livello di prodotto darà molto più ROI (considerando tempo, denaro e impegno rispetto al valore) rispetto a una modifica del livello non di prodotto, i semi di un nuovo caratteristica del prodotto sono piantati.

T – 15 giorni

Se il Product Manager ha qualche esperienza precedente, potrebbe proporre una soluzione basata su tale esperienza. Tuttavia, questa potrebbe non essere la soluzione migliore in tutti i casi.
Se la dichiarazione del problema richiede una soluzione altamente tecnica, il Product Manager discute lo stesso con sviluppatori e responsabili tecnici e prende i loro consigli sul modo migliore per risolverlo. Se la soluzione richiede modifiche a livello di progettazione, è possibile consultare il lead UX. Potrebbe essere che il Product Manager e la persona UX organizzino uno sprint di design e scelgano la soluzione che viene accolta bene dagli utenti effettivi di quella funzionalità. A volte il problema è totalmente correlato all'attività e quindi richiede un'adesione da parte dell'alta dirigenza.
Quindi, ci possono essere diversi modi in cui una soluzione potrebbe essere finalizzata. Ma una volta che lo è, il Product Manager è responsabile della conversione di quella soluzione teorica in una caratteristica attiva del prodotto.

T = 0 (ovvero nascita della caratteristica del prodotto)

Quando viene identificata una particolare soluzione, il Product Manager, in collaborazione con il team competente, traccia una bozza di base della soluzione. Può includere o meno un prototipo della soluzione. A volte è solo un foglio Excel di base con condizioni "if-then" scritte per quando mostrare una particolare CTA a un utente, ecc.
Il Product Manager esprime a parole la soluzione nel relativo PRD (Documento sui requisiti di prodotto). Se la funzionalità è piccola, potrebbe essere solo un paragrafo in un PRD esistente per una funzionalità più grande. A volte la funzionalità è così grande che richiede un PRD completo solo per dettagliarla correttamente. Il PRD è gestito dai team competenti e il Product Manager si assicura che esista un ampio consenso sulla funzione.

T + 15 giorni

Piccole funzioni potrebbero richiedere meno di un giorno per essere congelate. Le grandi funzionalità, a volte, richiedono più di 30 giorni per ottenere il via libera di tutti.
Prendiamo una media di 15 giorni per dire che questo è il momento in cui la funzionalità neonata viene presentata agli sviluppatori. Una corretta progettazione e consegna del PRD hanno luogo in cui gli sviluppatori che stanno lavorando al progetto vengono informati sulle 5W (cosa, perché, quando, dove, chi) e sui casi di test (come dovrebbe comportarsi o meno la funzionalità una volta rilasciata) .
Insieme al responsabile tecnico, viene deciso un programma di rilascio adeguato per la funzionalità con scadenze per la fine dello sviluppo quando inizieranno i test, quando i bug segnalati verranno corretti e la data di rilascio finale. Quindi l'intera sequenza temporale viene suddivisa in sprint misurabili (di solito lunghi 15 giorni). Una volta che gli sviluppatori sono soddisfatti, inizia lo sviluppo.

T + 30 giorni

Lo Sprint 1 finisce. Una parte della funzionalità del prodotto è stata implementata. Potrebbe non essere ancora rivolto ai clienti, ma la maggior parte dei team segue oggi le metodologie Agile per lo sviluppo del software, il che significa che costruiamo in modo incrementale e iterativo. Quindi, invece di creare una grande funzionalità in 6 mesi e rilasciarla tutta in una volta, suddividiamo il tutto in parti indipendenti che possono funzionare da sole (un mucchio di User Story) e sono rapidamente pronte per essere riviste e ripetute.
Il Product Manager si assicura che la sequenza temporale di rilascio sia in linea con le riunioni quotidiane di Scrum e le discussioni con il responsabile dell'ingegneria pertinente che lavora al progetto. In caso di ritardo, le tempistiche vengono adattate di conseguenza o piccole parti delle funzionalità vengono eliminate per assicurarsi che il rilascio sia puntuale. Dopo ogni sprint, i progressi realizzati vengono presentati al Product Manager e alle parti interessate in una riunione e, dopo l'approvazione, vengono rilasciati.
Un anno di programma di gestione del prodotto di UpGrad

T + x giorni

Dopo 'n' numero di sprint, lo sviluppo è completo e l'intera funzionalità è fuori. Non è necessario che i clienti possano utilizzare la funzione solo quando rilasciata completamente. Potrebbero usarlo sin dal rilascio alla fine dello sprint 1 stesso. Ogni successivo rilascio del ciclo di sprint rende la funzionalità più robusta e la avvicina a ciò che dovrebbe essere.
Il lancio di una funzionalità è di per sé un'arte e comporta molti passaggi che salteremo e supponiamo semplicemente che dopo molti tamburi e colpi di petto, è stato dichiarato al mondo che una funzionalità è stata rilasciata. Questo potrebbe essere complesso come un comunicato stampa in piena regola con lo stesso CEO che parla del nuovo lancio, o potrebbe essere semplicemente qualcosa su cui viene inviata una mail a un particolare dipartimento che utilizzerà la funzione e probabilmente l'ha richiesta in il primo posto. Quindi ora che la funzione è disponibile, diamo un nome a questa funzione: Mr. Feature.

T + y giorni

Anche dopo il rilascio finale, le cose a volte vanno storte. Mr. Feature, che una volta era tutto brillante e prezioso, potrebbe non essere più lo stesso e potrebbero esserci molteplici ragioni per questo. Questa fase del ciclo di un prodotto riguarda il supporto del prodotto. Un bel giorno è stata rilasciata un'altra versione che ha causato il funzionamento di Mr. Feature in modi non intenzionali (ovvero diventare buggy) o forse è stata rimossa un'altra funzionalità che aveva alcune dipendenze da Mr. Feature e questo ha causato il comportamento buggato. Potrebbe anche essere che quando è stata creata la funzionalità, abbiamo sottovalutato il numero di utenti che la utilizzeranno o non abbiamo pianificato tutti i casi d'uso e ora la funzionalità non è in grado di scalare fino a questi molti utenti o casi d'uso.

Questo viene segnalato dal team di test nella revisione periodica o viene segnalato da un membro del team che l'ha appena scoperto mentre utilizzava lui stesso la funzione. In caso di funzionalità rivolte al cliente, questi reclami potrebbero provenire dai clienti effettivi del prodotto ed essere comunicati al Product Manager tramite il team di Customer Experience.

Il Product Manager cerca di capire la causa principale del bug e, in base alla priorità, pianifica la correzione per il ciclo di rilascio successivo: potrebbe essere aggiunta nello sprint corrente se è ad alta priorità o anche negli sprint successivi. Dopo che il bug è stato corretto e rilasciato, Mr. Feature vive per vedere un altro giorno, anche se in una forma riformata – Mr. Feature 2.0 – grazie al Product Manager e al team di ingegneri. Complimenti!

T + z giorni

Si dice che tutte le cose belle devono finire. Purtroppo, questo è anche il caso di Mr. Feature, indipendentemente dalla sua versione – forse Mr. Feature 9.263.75! Ciò significa che il signor Feature ha vissuto una vita lunga e felice, ma ora la fine della strada è qui.
Potrebbe essere dovuto a vari motivi. È arrivata una nuova funzionalità che ha reso del tutto ridondante la necessità di Mr. Feature. Potrebbe anche essere qualcosa di estremo, come se l'azienda avesse deciso che, sebbene la funzionalità stesse aggiungendo valore ai suoi utenti, non aveva più senso economico per loro.

Qualunque sia il motivo, viene comunicato al Product Manager (o è lui che avvia la discussione) che i servizi di Mr. Feature non saranno più necessari. Ora, per quanto straziante sia, il Product Manager ha il dovere di far riposare Mr. Feature. Sebbene, prima di ciò, debba assicurarsi di alcune cose come informare gli utenti che stavano utilizzando Mr. Feature che non sarà disponibile da una certa data, la nuova funzionalità funziona bene prima di rimuovere Mr. Feature, nessun altro il flusso viene influenzato quando Mr. Feature è scomparso e così via.

Quindi, è tempo di dire RIP a Mr. Feature. Nella tua carriera nella gestione del prodotto, dovrai farlo più volte. Ma ricorda, la fine di una caratteristica è l'inizio di un'altra e il ciclo continua. Tale è la vita di gestione 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