Cum să definești un domeniu MVP în 3 ore

Când am fost adus ca manager de produs de o companie de procesare a plăților în stadiu incipient, afacerea se lupta să creeze și să livreze un sistem de gestionare a stocurilor în timp util. Soluția existentă a fost o aplicație simplă de tastatură care nu era ușor de utilizat și, ca urmare, provoca o renunțare semnificativă la clienți. Sarcina mea a fost să conduc o echipă însărcinată cu construirea sistemului de inventar care să extindă capacitățile aplicației dincolo de funcționalitatea tastaturii.

Deoarece a trebuit să funcționăm pe o cronologie trunchiată, am creat o abordare simplă, dar radical eficientă pentru conceperea, proiectarea și construirea unui produs minim viabil (MVP) cu caracteristici de bază care se potriveau cu ceea ce căutau utilizatorii noștri. Procesul a condensat scopul unui MVP într-o sesiune intensivă de trei ore – în loc de zile sau săptămâni – și a economisit echipei noastre luni de timp în dezvoltare.

Acest proces accelerat de definire a MVP poate fi folosit pentru a ghida orice echipă de produs și poate fi aplicat la crearea oricărui produs zero la unu.

Prezentare generală a cazului de utilizare

Problemă: funcționalitatea simplă a tastaturii aplicației nu le-a oferit utilizatorilor, care erau vânzători, capacitatea de a gestiona inventarul sau de a selecta articole de adăugat la comanda unui client.

Constrângeri: conducerea companiei dorea o soluție livrată în opt săptămâni; o potențială rundă de strângere de fonduri depindea, parțial, de succesul unei versiuni îmbunătățite a produsului.

Context: Dintr-o analiză a pieței și după ce am petrecut timp cu mulți dintre utilizatorii noștri, am stabilit că acești furnizori aveau nevoie de un sistem de gestionare a stocurilor pentru a-și eficientiza fluxul de vânzări. I-am urmărit procesând comenzile clienților: în primul rând, au scris articolele solicitate pe bucăți de hârtie, au folosit calculatoare pentru a număra articolele și apoi au introdus comenzile în aplicație. Foloseau trei instrumente când ar fi trebuit să aibă nevoie doar de unul.

Soluție: trebuia să dezvoltăm o soluție care să le permită utilizatorilor să-și încarce inventarele într-un catalog digital, să gestioneze acele inventare și să atingă articolele selectate pentru a le adăuga în coșul de cumpărături al unui client, totul în cadrul aplicației.

Decizia Design Sprint

Deoarece știam deja ce produs trebuie să dezvoltăm, am optat să renunț la un sprint tipic de design - un atelier de patru până la cinci zile în care echipele colaborează pentru a identifica o provocare majoră de afaceri, pentru a colecta idei de la clienți despre cum să rezolve problema, dezvoltați un concept pentru un produs, proiectați un prototip și începeți să-l testați.

Sprinturile de proiectare sunt o metodă eficientă pentru construirea MVP-urilor – pentru cei care au nevoie să identifice problemele de bază și care au timp apreciabil disponibil pentru a dezvolta soluții. Cu toate acestea, în companiile aflate în stadiu incipient sau în noile unități de afaceri din organizațiile existente, problemele de bază sunt de obicei evidente: au fost dezvoltate concepte și potrivirea produs/piață a fost de obicei determinată înainte ca managerii de produs, inginerii și designerii să fie implicați.

Următoarea diagramă de flux prezintă pașii pe care i-am făcut atunci când am decis că cel mai bun mod de a continua acest proiect a fost să săriți peste sprintul de proiectare și să începeți cu sesiunea de trei ore, cunoscută și sub numele de lansarea echipei. În acea întâlnire, participanții aveau să facă brainstorming și să genereze zeci de idei pentru funcții, apoi să reducă lista doar la ceea ce era necesar pentru MVP.

Procesul de dezvoltare MVP

Pregătirea

Înainte de sesiunea de trei ore, veți dori să culegeți informații despre persoanele dvs. de utilizator, conversand și observând clienții actuali sau potențiali și efectuând cercetări de piață.

Apoi, creați o prezentare pentru designeri și ingineri. Ar trebui să explice:

• Problema pe care încerci să o rezolvi.
• Produsul pe care îl construiți.
• Cum va rezolva produsul acea problemă atât în ​​ceea ce privește valorile, cât și UX.
• Impactul prognozat al produsului asupra afacerilor dvs. și ale clientului dvs.
• Misiunile și obiectivele și rezultatele cheie la nivel de companie și echipă (OKR), precum și modul în care produsul ajută la îndeplinirea acelor misiuni și la atingerea acelor OKR.

Prezentarea ar trebui să ofere designerilor și inginerilor o înțelegere solidă a produsului pentru a continua cu definirea MVP-ului.

Întâlnirea de lansare de trei ore

Kickoff-ul ar trebui să implice întreaga echipă de dezvoltare, permițându-le să participe la fiecare etapă a procesului, de la idee și crearea poveștii până la dezvoltarea conceptului MVP. Aceasta include managerii de produs seniori, juniori și asociați; proprietarii de produse; cabluri de produs (dacă este cazul); designeri UX; ingineri de software; și ingineri QA.

Sfat rapid: Deși este neortodox, recomand includerea inginerilor înainte de etapa de construcție. De obicei, oferă idei grozave și au o pasiune pentru produsul pe care încearcă să-l îmbunătățească. Cei mai mulți dintre ei le place să fie implicați în definirea MVP-ului; îi ajută să devină mai investiți în proiect și apreciați de celelalte echipe.

Adunați-i pe toți într-o sală de conferințe sau într-un spațiu de lucru virtual. În cazul nostru, am avut 10 persoane. Blocați trei ore.

Călătoriile produsului și ale utilizatorului (60 de minute)

1. Faceți prezentarea. (15 minute)

2. Începeți să identificați toate persoanele de utilizator pentru produsul dvs. Chiar dacă nu ați identificat încă fluxuri sau funcții, puteți defini numărul de fluxuri care trebuie construite. (10 minute)

   Sfat rapid: nu suprainginerești adăugând mai multe persoane decât este necesar. După lansarea MVP, feedback-ul clienților va dezvălui dacă aveți nevoie de roluri suplimentare.

   Exemplu de caz de utilizare: Am avut trei persoane: managerul magazinului (sau administratorul), casierul și clientul final. Au existat și alte persoane potențiale de nivel superior, cum ar fi proprietarul magazinului, dar în scopul unui MVP, acestea ar putea fi acoperite de administrator.

3. Hartă călătoria utilizatorului de la început până la sfârșit. Atribuiți o culoare fiecărei persoane pentru a ajuta la identificarea fiecărui pas al fluxului pe care îl va întâlni utilizatorul. Pentru întâlniri în persoană, postați note lipicioase pe un perete sau folosiți o tablă albă. Pentru întâlniri virtuale, utilizați o tablă FigJam sau ceva similar. (35 minute)

   Sfat rapid: cereți echipei să-și împărtășească toate ideile și obțineți detalii. Fiecare pas al fluxului va deveni o caracteristică care trebuie construită - și fiecare utilizator va avea un flux separat - dar procesul de conturare a pașilor va fi același.

   Exemplu de caz de utilizare: Iată lista de caracteristici pentru personalitatea noastră de casier:

   • Deschideți aplicația de la punctul de vânzare.
   • Conectați-vă folosind un PIN.
   • Identificați primul articol pentru achiziția clientului.
   • Identificați cantitatea pentru articol.
   • Identificați orice articole suplimentare pentru achiziționarea clientului.
   • Adăugați o reducere la un articol (dacă este cazul).
   • Totalul costului tuturor articolelor din coșul de cumpărături (în acest moment, este afișat prețul complet de achiziție, inclusiv taxa de vânzare).
   • Finalizarea procesării plății și a plății.
   • Confirmați achiziția.
   • Permiteți clientului să adauge un pont.
   • Închide vânzarea.
   • Afișați totalul tuturor vânzărilor zilnice.
   • Timpul expirat după o perioadă predeterminată de inactivitate (de exemplu, cinci minute).

   Notă: Această listă detaliază majoritatea caracteristicilor la care ne-am gândit pentru această persoană. Am venit cu aproximativ 60 de funcții totale pentru toate persoanele, cu o suprapunere minimă, în calitate de casier, manager de magazin și client final, toți interacționează cu aplicația în moduri diferite. În funcție de tipul de produs pe care îl dezvoltați, este posibil să existe o suprapunere semnificativ mai mare a funcțiilor între tipurile de utilizatori.

   

Caracteristici esențiale ale călătoriilor utilizatorului (45 de minute)

1. Grupați funcțiile pentru fiecare tip de utilizator în părțile discrete ale călătoriei fiecărui utilizator pe o tablă reală sau virtuală. Apoi, trageți o linie orizontală pe tablă. Deasupra liniei, identificați seturile necesare pentru ca produsul să funcționeze. Sub linie, plasați funcții pe care este plăcut să le aveți, dar care pot aștepta până la lansări ulterioare. (30 minute)

   Sfat rapid: împărțiți designerii și inginerii în grupuri pentru a finaliza acest pas, apoi reuniți-vă din nou pentru a compara note. Acest lucru este util în special în întâlnirile de 10 sau mai multe persoane.

   Exemplu de caz de utilizare: pentru aplicația noastră, aveam 12 seturi de caracteristici în acest moment, care au inclus încărcarea articolelor în catalogul de inventar, stabilirea prețurilor acestora, selectarea articolelor pentru a le adăuga în coșul unui client, verificarea și închiderea vânzării, recomandarea stocului redus, și altele. În cele din urmă, am redus numărul de seturi de caracteristici la patru.

   Acest proces de eliminare ne-a ajutat să stabilim că conectarea de securitate a unui utilizator nu a fost necesară în prima iterație a aplicației. Nici să adăugați o reducere sau un bacșiș. De asemenea, am decis că casierul nu trebuie să poată afișa totalul vânzărilor zilnice ca parte a unui MVP, deși managerul sau proprietarul magazinului ar putea.

2. Rafinați lista de caracteristici. Întrebați „Dacă ar fi omis acest lucru, produsul ar mai funcționa?” Dacă răspunsul este da, lăsați acea funcție în afara MVP - păstrați-o pentru o iterație ulterioară a produsului. Dacă răspunsul este nu, trebuie să includeți acea caracteristică în MVP. La sfârșitul acestui proces, veți ști ce este cu adevărat necesar pentru ca produsul dumneavoastră să fie funcțional. Adesea, aceasta va consta din doar trei sau patru caracteristici pentru fiecare set. (15 minute)

   Notă: Evitați să construiți prea multe seturi de caracteristici în MVP. Deși ar trebui să anticipați opiniile divergente cu privire la ceea ce este cel mai important de inclus, este treaba dvs. ca manager de produs să apelați. Ți-ai făcut cercetările și ai date pentru a-ți susține deciziile. Din experiența mea, multe produse sunt inițial construite mai robust decât trebuie, iar majoritatea companiilor ar prefera să pună ceva în mâinile utilizatorilor pentru testare și feedback cât mai repede posibil.

Design de produs, testare și inginerie (75 de minute)

1. Rugați designerii să integreze caracteristicile de bază într-un design wireframe al MVP, pe care inginerii îl vor folosi pentru a construi arhitectura produsului. (45 de minute)

2. Permiteți specialiștilor de produse și designerilor să lucreze împreună la unele teste UX ușoare ale designului wireframe. (15 minute)

   Notă: Există foarte puține scenarii de management al produsului în care ar trebui să construiți fără a implica clientul final, dar în cazul testării și dezvoltării rapide, puteți testa un prototip de design intern sau cu prietenii și familia care nu vă cunosc produsul. Dacă sunt confuzi, vor fi și unii dintre utilizatorii tăi.

3. Dă-le inginerilor wireframes proiectate pentru ca aceștia să înceapă construirea arhitecturii MVP. Ei nu vor avea tot ce au nevoie – sau timpul – pentru a construi o soluție completă, dar pot începe, iar arhitectura pe care o construiesc va fi folosită la finalizarea MVP. Între timp, echipele de produs și de proiectare pot continua testarea pe wireframes-urile lor, cu membrii echipei interne sau prietenii și familia acționând ca utilizatori. Dacă echipele lucrează concomitent la acest pas, economisește timp. (15 minute)

Pe măsură ce deveniți mai abil în utilizarea acestui proces, va deveni mai ușor să identificați care caracteristici sunt componente de bază ale unui MVP și care pot fi construite mai târziu. Practica vă va împiedica, de asemenea, să construiți lucruri greșite: s-ar putea să aveți ceva în minte pentru lista „mai târziu”, doar pentru a afla ulterior că niciun client nu vrea.

Rezultate și concluzii cheie

Înainte de eforturile noastre, aplicația noastră era o tastatură cu numerele de la 0 la 9, un punct zecimal și un buton de încărcare. Din cauza acestei limitări și a fluxului de lucru ineficient pe care l-a creat, pe parcursul unui an, retenția noastră fusese scăzută – în jur de 20%. Deși am obținut noi utilizatori mai repede decât concurența noastră, i-am pierdut aproape la fel de repede.

De-a lungul procesului de creare a MVP-ului, am construit patru seturi de caracteristici cheie, toate având o amploare minimă, dar de înaltă calitate. Un utilizator ar putea acum:

1. Încărcați articole în inventar direct de pe un dispozitiv mobil pur și simplu folosind o cameră, introducând un nume și introducând un preț.
2. Selectați acele articole și adăugați-le în coșul de cumpărături al unui client.
3. Închideți vânzarea în timp ce vizualizați articolele vândute.
4. Vedeți numărul de articole vândute într-un interval de timp dat.

Clienții au apreciat produsul îmbunătățit. Rata de reținere a fost de 45% în rândul utilizatorilor noi care au profitat de funcționalitatea catalogului pentru achiziție de cel puțin cinci ori în prima săptămână de încărcare a articolelor.

Datorită eficienței procesului nostru de definire a MVP, am construit și livrat aplicația noastră complet terminată în aproximativ două luni. Acest proces ar fi durat probabil patru luni sau mai mult cu o abordare tradițională de dezvoltare – dacă produsul ar fi fost vreodată construit.

Acest proces accelerat economisește timp și bani. Un sprint complet de design poate fi costisitor. Începând cu întâlnirea de lansare, procesul meu devine mai economic de la început, iar aceste economii sunt amplificate de termenul general de dezvoltare mult mai scurt.

Cu toate acestea, cele două procese pot funcționa și în tandem: dacă echipa dvs. a finalizat un sprint de proiectare pentru a defini o problemă de bază de afaceri și soluția pe care trebuie să o creați, puteți utiliza procesul meu pentru a vă defini mai eficient domeniul de aplicare al MVP.

Amintiți-vă că acest proces este doar începutul: un MVP este o lucrare în desfășurare care va fi perfecționată și mai mult în versiunile ulterioare. Odată ce este complet construit și gata pentru a fi livrat, recomand să adăugați un comutator beta pe care utilizatorii îl pot dezactiva pentru a reveni la vechea experiență de aplicație. Utilizarea software-ului de comportament, cum ar fi Heap, pentru a urmări câți utilizatori exercită această opțiune, vă va oferi o idee bună despre ceea ce trebuie adăugat sau modificat pentru a vă îmbunătăți produsul în următoarea iterație.