Ciclul de viață al produsului: călătoria unei caracteristici a produsului

Aceasta este cea de-a patra postare dintr-o serie de cinci părți pe care o scriu cu scopul de a ajuta un aspirant de produs să intre în lumea managementului de produs.

În ultima mea postare , am împărțit disciplina Managementul Produsului în patru părți, cu scopul de a ajuta aspiranții la Managementul Produsului să-și înțeleagă traiectoria de carieră în cadrul unei companii sau în general. În această postare, voi vorbi despre călătoria de viață a unei caracteristici de produs, de la idee până la abandon, pentru a ajuta un aspirant la Product Management să obțină o perspectivă de 360 ​​de grade asupra a ceea ce implică rolul unui Product Manager.

T – 30 de zile

Se spune că necesitatea este mama invenției. Acesta este literalmente cazul în care este implicată nașterea unei caracteristici a produsului. Totul începe cu un anumit nivel de disconfort.
Unele angajate din companie se confruntă cu disconfort în realizarea uneia dintre sarcinile sale zilnice – poate că baza de utilizatori a crescut și nu este capabil să o gestioneze cu procesele vechi. Unii directori din companie se uită la o foaie Excel și consideră că compania pierde prea mulți bani din cauza, să zicem, a numărului mare de anulări de produse. Sau poate un concurent a lansat o caracteristică a produsului care îi determină pe clienți să părăsească produsul companiei menționate. Cineva care se uită la canalul de conversie de marketing a observat scăderi mari la o anumită etapă și a considerat că optimizarea care l-ar putea ajuta să-și atingă obiectivul trimestrial. Sau ar putea fi 100 de motive diferite, de la un număr mare de plângeri ale clienților pentru o problemă comună la o nouă caracteristică cerută de majoritatea utilizatorilor chestionați săptămâna precedentă. Ideea este că totul începe cu un anumit nivel de disconfort.

Acum, acest disconfort este adus la cunoștința Managerului de Produs; sau poate managerul de produs este cel care observă primul. Acesta este punctul care începe un lanț de evenimente care ar putea duce la nașterea unei noi caracteristici.

T – 25 de zile

Este timpul ca managerul de produs să se gândească la declarația problemei. Merge și vorbește cu clienții sau cu părțile interesate interne care au raportat disconfortul și apoi cu cei care se confruntă cu acesta; toate cu un singur scop – să se asigure că a identificat enunțul problemei „rădăcină”. Dacă această etapă este luată cu ușurință sau Managerul de produs nu petrece suficient timp în acest sens, atunci caracteristicile produsului născut sunt fragile, distorsionate și își întâlnesc finalul destul de repede.
Odată ce managerul de produs a identificat declarația principală a problemei, el decide dacă merită rezolvată. Este disconfortul într-adevăr unul mare sau este cam exagerat sau mai rău, doar machiat? Rezolvarea acesteia ar adăuga de fapt o valoare semnificativă clientului și/sau companiei? Rezolvarea acesteia nu ar impune o penalizare semnificativă clientului și/sau companiei? Există vreo modalitate de a rezolva această problemă cu o modificare minoră a proceselor sau prin orice activitate care nu necesită modificări ale produsului - să zicem schimbarea unui furnizor, negocierea unui preț mai bun de la un furnizor existent, obținerea unui software terță parte pentru a rezolva problema, angajarea un angajat suplimentar, modificări de conținut, grafică, buton de îndemn etc.?

Practic, dacă există o modalitate prin care putem obține o valoare adăugată similară dintr-o metodă care nu implică modificări ale produsului, atunci am merge mai mult decât să schimbăm orice din produs - indiferent dacă asta înseamnă adăugarea sau eliminarea. Odată ce managerul de produs este convins că rezolvarea enunțului problemei va oferi o valoare semnificativă și o schimbare la nivel de produs va oferi mult mai mult ROI (luând în considerare timpul, banii și efortul v/s valoarea) decât o schimbare la nivel non-produs, semințele unei noi caracteristica produsului sunt plantate.

T – 15 zile

Dacă managerul de produs are o experiență anterioară, el ar putea propune o soluție bazată pe această experiență. Cu toate acestea, aceasta ar putea să nu fie cea mai bună soluție în toate cazurile.
Dacă declarația problemei necesită o soluție extrem de tehnică, Managerul de produs discută același lucru cu dezvoltatorii și managerii de inginerie și le primește sfatul cu privire la cea mai bună modalitate de a o rezolva. Dacă soluția necesită modificări la nivel de proiectare, poate fi consultat liderul UX. S-ar putea ca managerul de produs și persoana UX să organizeze un sprint de design și să aleagă soluția care este bine primită de utilizatorii actuali ai acestei caracteristici. Uneori, problema este în totalitate legată de afaceri și, prin urmare, necesită o acceptare din partea conducerii superioare.
Deci, pot exista mai multe moduri în care ar putea fi finalizată o soluție. Dar odată ce este, managerul de produs este responsabil pentru transformarea acelei soluții teoretice într-o caracteristică activă a produsului.

T = 0 (alias nașterea caracteristicii produsului)

Când o anumită soluție este identificată, managerul de produs, în colaborare cu echipa relevantă, elaborează o schiță de bază a soluției. Poate include sau nu un prototip al soluției. Uneori, este doar o foaie Excel de bază cu condiții „dacă-atunci” scrise pentru a afișa un anumit CTA unui utilizator etc.
Managerul de produs pune soluția în cuvinte în PRD (documentul privind cerințele produsului). Dacă caracteristica este mică, ar putea fi doar un paragraf dintr-un PRD existent pentru o caracteristică mai mare. Uneori, caracteristica este atât de mare încât necesită un PRD complet doar pentru a o detalia corect. PRD este condus de echipele relevante, iar managerul de produs se asigură că există un consens larg cu privire la caracteristică.

T + 15 zile

Caracteristicile mici ar putea dura mai puțin de o zi pentru a fi înghețate. Funcțiile mari, uneori, durează mai mult de 30 de zile pentru a obține aprobarea tuturor.
Să luăm în medie 15 zile pentru a spune că acesta este momentul în care caracteristica nou-născutului este introdusă dezvoltatorilor. Un design adecvat și predarea PRD au loc în cazul în care dezvoltatorii care lucrează la proiect sunt informați despre cele 5W (Ce, De ce, Când, Unde, Cine) și cazurile de testare (cum ar trebui să se comporte sau nu caracteristica odată ce este lansată) .
Împreună cu managerul de inginerie, se decide un program de lansare adecvat pentru caracteristică, cu termene limită pentru când se va încheia dezvoltarea când va începe testarea, când vor fi remediate erorile raportate și data finală de lansare. Apoi întreaga cronologie este împărțită în sprinturi măsurabile (de obicei 15 zile). Odată ce dezvoltatorii sunt mulțumiți, începe dezvoltarea.

T + 30 de zile

Sprintul 1 se încheie. O parte a caracteristicii produsului este lansată. S-ar putea să nu se confrunte încă cu clienții, dar majoritatea echipelor urmează metodologiile Agile de astăzi pentru dezvoltarea de software – ceea ce înseamnă că construim progresiv și iterativ. Deci, în loc să construim o caracteristică mare în 6 luni și să lansăm toate odată, împărțim totul în părți independente care pot funcționa singure (o grămadă de povești de utilizator) și sunt rapid gata pentru a fi revizuite și repetate.
Managerul de produs se asigură că termenul de lansare este în mod corect prin întâlniri zilnice de scrum și discuții cu managerul de inginerie relevant care lucrează la proiect. În cazul în care există o întârziere, cronologia este ajustată în consecință sau părți mici ale caracteristicilor sunt abandonate pentru a vă asigura că lansarea este la timp. După fiecare sprint, progresul realizat este prezentat managerului de produs și părților interesate relevante într-o întâlnire, iar după aprobare este eliberat.
Un an de program de management al produselor UpGrad

T + x zile

După „n” număr de sprinturi, dezvoltarea este completă și întreaga caracteristică este scoasă. Nu este necesar ca clienții să folosească funcția numai atunci când este eliberată complet. Ar putea să-l folosească de la lansarea la sfârșitul sprintului 1 în sine. Fiecare lansare ulterioară a ciclului de sprint face ca funcția să fie mai robustă și o apropie de ceea ce este destinat să fie.
Lansarea unei funcții este în sine o artă și implică o mulțime de pași pe care îi vom sări peste și doar presupunem că, după multe bătăi de tobe și bătăi în piept, sa declarat lumii că o caracteristică a fost lansată. Acest lucru ar putea fi la fel de complex ca un comunicat de presă complet, în care CEO-ul însuși vorbește despre noua lansare, sau ar putea fi doar ceva despre care este trimis un e-mail către un anumit departament care va folosi funcția și probabil a solicitat-o ​​în locul intai. Deci, acum că funcția este disponibilă, să dăm acestei caracteristici un nume – Mr. Feature.

T + y zile

Chiar și după lansarea finală, uneori lucrurile merg prost. Mr. Feature, care a fost cândva strălucitor și valoros, s-ar putea să nu mai fie același și ar putea exista mai multe motive pentru asta. Această fază a ciclului unui produs se referă la sprijinirea produsului. Într-o bună zi, a fost făcută o altă lansare care a făcut ca Mr. Feature să funcționeze în moduri neintenționate (aka devine bug) sau poate a fost eliminată o altă caracteristică care avea unele dependențe de Mr. Feature și acest lucru a cauzat comportamentul bug-ului. S-ar putea, de asemenea, ca atunci când a fost creată caracteristica, să am subestimat numărul de utilizatori care o vor folosi sau nu au planificat toate cazurile de utilizare, iar acum caracteristica nu poate să se extindă la acești mulți utilizatori sau cazuri de utilizare.

Acest lucru este fie raportat de echipa de testare în revizuirea lor periodică, fie este raportat de un membru al echipei care tocmai l-a descoperit în timp ce folosea funcția însuși. În cazul funcțiilor adresate clienților, aceste reclamații pot veni de la clienții reali ai produsului și pot fi comunicate Managerului de produs prin intermediul echipei Customer Experience.

Managerul de produs încearcă să înțeleagă cauza principală a erorii și, în funcție de prioritate, programează remedierea pentru următorul ciclu de lansare – ar putea fi adăugată în sprintul curent dacă este cu prioritate ridicată sau chiar sprinturile ulterioare. După ce eroarea este remediată și eliberată, Mr. Feature trăiește pentru a vedea o altă zi, deși într-o formă reformată – Mr. Feature 2.0 – datorită managerului de produs și echipei de ingineri. Apreciere!

T + z zile

Se spune că toate lucrurile bune trebuie să se încheie. Din păcate, acesta este și cazul Mr. Feature, indiferent de versiunea sa – poate Mr. Feature 9.263.75! Asta înseamnă că domnul Feature a trăit o viață lungă și fericită, dar acum sfârșitul drumului este aici.
Poate fi din diverse motive. A apărut o nouă caracteristică care a făcut ca nevoia de Mr. Feature să fie complet redundantă. Ar putea fi și ceva extrem – așa cum compania a decis că, deși funcția adaugă valoare utilizatorilor săi, nu mai avea sens economic pentru ei.

Indiferent care ar fi motivul, se comunică Product Managerului (sau el este cel care începe discuția) că serviciile domnului Feature nu vor mai fi necesare. Acum, oricât de sfâșietor este, Managerul de produs are datoria să-l odihnească pe domnul Feature. Deși, înainte de asta, trebuie să se asigure de câteva lucruri, cum ar fi informarea utilizatorilor care foloseau Mr. Feature că nu va fi disponibilă de la o anumită dată, noua caracteristică funcționează bine înainte de a elimina Mr. Feature, nici o altă caracteristică. fluxul este afectat atunci când Mr. Feature dispare și așa mai departe.

Deci, este timpul să îi spunem RIP domnului Feature. În cariera dvs. de management de produs, va trebui să faceți acest lucru de mai multe ori. Dar amintiți-vă, sfârșitul unei caracteristici este începutul alteia și ciclul continuă. Aceasta este viața de management al produsului!

Studiați online cursuri de management de produs de la cele mai bune universități din lume. Câștigă programe de master, Executive PGP sau Advanced Certificate pentru a-ți accelera cariera.

Program recomandat pentru tine: Programul de certificare Design Thinking de la Duke CE