Cum construiești o roadmap de produs din feedback

Construirea unei roadmap de produs se reduce la asta: strângeți ce au cerut deja clienții, grupați cererile după problema din spatele fiecăreia, ordonați grupurile cu o regulă pe care o puteți explica, decideți cât de siguri sunteți de fiecare și publicați rezultatul într-un format potrivit celui care citește. Ordinea contează. Echipele care pornesc de la un aspect și îl umplu cu idei obțin un document care arată terminat și nu are nicio dovadă în spate. Echipele care pornesc de la cereri obțin o roadmap mai scurtă, cu un motiv în spatele fiecărui rând.

De unde porniți când construiți o roadmap de produs?

Porniți de la dovezile pe care le aveți deja, nu de la o pagină goală. Cererile de funcționalități deschise, conversațiile din suport etichetate cu aceeași plângere, notițele de la apelurile de vânzări și datele de utilizare din propriul produs sunt toate intrări. Puneți-le într-o singură listă și notați de unde vine fiecare element.

Cererile ajung rar într-o formă utilizabilă. „Adăugați integrare cu Slack” și „anunțați-mi echipa când se schimbă un task” pot fi aceeași nevoie. De aceea pasul următor e gruparea și de aceea merită un tracker care unește duplicatele; cererile de funcționalități duplicate arată cum. Țineți minte că tichetele de suport și cererile de funcționalități poartă feluri diferite de semnal, iar o roadmap construită doar dintr-unul va înclina într-o parte greșită.

Cum transformați cererile în elemente de roadmap?

Grupați cererile după problemă, numiți fiecare grup ca un rezultat și păstrați numărătoarea. Un grup de paisprezece cereri care descriu toate pierderea unui filtru după reîncărcare devine un singur element: „Se păstrează filtrul folosit data trecută”. Numărul merge în coloana sursei, așa că oricine citește roadmap-ul vede greutatea din spatele lui.

Scrieți rezultatul pe limba clientului. „Implementare persistență pentru view-uri salvate” îi spune unui inginer ce să construiască și nu-i spune nimic unui client. Formularea ca rezultat ridică și o întrebare utilă: dacă nu puteți spune ce se schimbă pentru client, poate ați dat peste o sarcină internă care aparține altei liste.

Cum decideți ce merge primul?

Alegeți o singură regulă de scorare, notați-o și aplicați-o fiecărui element. RICE, care punctează reach, impact, încredere și efort, e cea mai răspândită; articolul Intercom despre RICE e sursa originală. O regulă mai simplă merge la fel de bine dacă o puteți explica: numărul de cereri, ponderat după dacă cel care cere e un cont plătitor activ, împărțit la un efort aproximativ.

Important e ca regula să fie declarată, pentru că primul client care întreabă de ce cererea lui nu e pe listă va vrea un răspuns. Acolo unde regula și judecata voastră nu se potrivesc, spuneți-o în rând. Prioritizarea cererilor de funcționalități parcurge metodele de scorare, întrebarea ponderării după venit și ce arată și ce nu arată voturile.

Cât de siguri sunteți de fiecare element?

Marcați fiecare element cu nivelul lui de încredere înainte să publicați ceva. O scală simplă cu trei valori ajunge: angajat înseamnă că echipa ar fi surprinsă să nu-l livreze în fereastră, estimat înseamnă că e planul dacă nu se schimbă ceva, iar în explorare înseamnă că nu există nicio promisiune.

Această singură coloană previne cea mai mare parte din stricăciunile unei roadmap. Fără ea, un client citește un element în explorare ca pe un angajament, vânzările îl citează, iar peste un trimestru e o reclamație. Eseul lui Marty Cagan despre alternativa la roadmap-uri susține argumentul de fond: o listă de funcționalități cu date e o listă de presupuneri prezentate drept planuri, iar remediul e să spuneți explicit ce știți.

Ce format ar trebui să aibă roadmap-ul?

Alegeți aranjarea la urmă, după cititor. Clienții care întreabă dacă i-ați auzit au nevoie de o vedere publică scurtă. Conducerea care întreabă de ce contează această muncă are nevoie de teme sau de rezultate. O echipă care își schimbă direcția lunar se descurcă bine cu Now, Next și Later, fără date. Exemplele de roadmap de produs arată șase formate cu elemente realiste și cum eșuează fiecare, iar șablonul de roadmap de produs vă dă câmpurile de copiat după ce ați ales.

Majoritatea echipelor ajung la două documente: o roadmap strategică pentru cititorii interni și una publică redusă, care arată doar ce sunteți dispuși să vi se ceară socoteală. Dacă o publicați pe aceasta, roadmap publică descrie cum s-o conduceți din etichetele issue-urilor pe care le urmăriți deja.

Cum împiedicați roadmap-ul să se învechească?

Dați fiecărui rând o dată de revizuire și țineți roadmap-ul acolo unde se află deja munca. O roadmap actualizată de mână într-un instrument separat se învechește, pentru că munca zilnică a nimănui nu o include. Dacă fiecare coloană corespunde unei etichete de pe issue, roadmap-ul se schimbă când se schimbă eticheta.

Închideți bucla când un element se livrează. Cei care au cerut ar trebui să afle, iar intrarea din changelog e locul obișnuit; bucla de feedback a clientului descrie întregul drum. Dacă decideți să nu construiți ceva, spuneți și asta. Un „nu” clar îi folosește celui care a cerut, iar refuzul cererilor de funcționalități acoperă formularea.

FAQ

Care sunt pașii pentru a construi o roadmap de produs? Strângeți cereri și date, grupați-le după problema din spatele fiecăreia, ordonați-le cu o regulă scrisă, marcați fiecare element cu cât de siguri sunteți, alegeți un format pentru cititor și fixați o dată de revizuire. Pornind de la dovezi, roadmap-ul rămâne scurt și ușor de apărat.

Pe ce ar trebui să se bazeze o roadmap de produs? Pe cererile clienților, temele din suport, datele de utilizare și strategia voastră, în ordinea în care sunt de obicei sărite. O roadmap fără sursă în spatele rândurilor e o listă de dorințe.

Cât ar trebui să acopere o roadmap de produs? Destul cât să fie utilă și destul de puțin cât să fie credibilă. Pentru multe echipe mici, asta înseamnă trimestrul curent în detaliu și următorul sau următoarele două ca teme. Tot ce e mai departe aparține sub „later”, fără date.

Cine ar trebui să participe la construirea unei roadmap de produs? Responsabilul de produs decide, ingineria verifică fezabilitatea și efortul, iar suportul și vânzările aduc cererile și temele pe care le aud. Clienții văd rezultatul într-o versiune publică, dar nu o editează.

Afirmațiile tehnice din acest articol nu au fost verificate independent. Dacă ceva nu e corect, spune-ne și vom corecta.

Pe changeloop: Documentație pentru dezvoltatori, Exemple de changelog