Un MVP este cea mai mică versiune a unui produs care rezolvă complet o singură problemă, pentru un utilizator real, în condiții reale. Cuvântul-cheie e „complet". Un MVP face un singur lucru și îl face până la capăt, cu tot ce presupune asta: și cazul în care merge bine, și cazul în care merge prost.
Asta e și granița care separă un MVP de ceea ce se vinde adesea sub numele ăsta: o versiune care face cinci lucruri pe jumătate. Prima e utilizabilă și îți spune ceva. A doua nu e nici utilizabilă, nici informativă, și costă la fel.
01.De unde vine termenul și ce a ajuns să însemne
Termenul vine din lumea produselor software, unde ideea inițială era una de învățare: construiește minimul necesar ca să afli dacă presupunerea ta despre utilizatori e adevărată, înainte să investești în restul.
În practica de zi cu zi a ajuns să însemne altceva. E folosit ca sinonim politicos pentru „varianta ieftină" sau, mai rău, pentru „varianta pe care nu am terminat-o". Confuzia e utilă comercial, pentru că permite livrarea a ceva incomplet sub un nume respectabil. Merită să știi diferența înainte de a semna, pentru că e diferența dintre a plăti pentru un experiment și a plăti pentru o promisiune amânată.
02.Trei lucruri care nu sunt un MVP
Nu e o versiune ieftină a produsului complet. Un MVP nu conține toate funcțiile în variantă slabă. Conține câteva funcții în variantă bună. Dacă oferta pe care o primești enumeră toate modulele din viziunea finală și doar taie din calitatea fiecăruia, nu ai în față un MVP. Ai în față un produs subfinanțat.
Nu e o versiune stricată. Un MVP se lansează la utilizatori reali, deci trebuie să funcționeze. Erorile, datele pierdute și fluxurile care se blochează nu sunt „de așteptat la un MVP". Sunt lucrări nefinalizate cu o etichetă convenabilă.
Nu e un demo. Un demo arată cum ar fi. Un MVP e folosit. Diferența practică: demo-ul are date inventate și un traseu pregătit dinainte, MVP-ul are datele clientului tău și traseul pe care îl alege el.
03.Regula care decide ce intră: un singur flux, dus până la capăt
Cea mai utilă regulă pe care o știm pentru a alege conținutul primei versiuni: alege un singur flux complet, de la început până la sfârșit, și construiește-l pe tot.
Un flux e drumul pe care îl face un om ca să obțină un rezultat. Nu e o funcție, e o poveste cu un final. „Un client își face cont" nu e un flux. „Un client își face cont, își rezervă o ședință, primește confirmarea și o poate anula cu 24 de ore înainte" e un flux.
Alegerea corectă a fluxului urmează de obicei una dintre două logici. Ori alegi fluxul care produce bani, pentru că el justifică restul investiției. Ori alegi fluxul care consumă cel mai mult timp manual, pentru că economia e imediată și vizibilă. Ce nu funcționează e alegerea fluxului cel mai ușor de construit, care e tentația firească și te lasă cu ceva ce nu schimbă nimic.
04.Un exemplu concret
Să zicem o clinică mică ce vrea „o aplicație pentru pacienți". Viziunea completă are programări, dosar medical, mesagerie cu medicul, plăți, rețete, notificări, rapoarte pentru administrator.
MVP-ul, ca un singur flux complet: pacientul intră cu un cont, vede intervalele libere ale unui singur medic, își face o programare, primește confirmare pe email, și poate anula până cu 24 de ore înainte. Recepția vede programările într-un ecran simplu și poate anula în locul pacientului dacă sună.
Ce intră, deși pare mult: anularea, notificarea de confirmare, ecranul recepției. Toate trei par „faza a doua" și niciuna nu e, pentru că fără ele fluxul nu e complet. Un pacient care nu poate anula va suna, iar recepția va ține tot un caiet în paralel, ceea ce înseamnă că nu ai testat nimic.
Ce nu intră: dosarul medical, mesageria, plățile, rețetele, rapoartele, și ceilalți medici. Nu pentru că nu contează, ci pentru că nu sunt necesare ca să afli dacă pacienții își fac programări singuri sau tot sună la telefon.
Iar aia e întrebarea. Un MVP se construiește ca să răspundă la o întrebare, iar întrebarea se scrie înainte, nu după.
05.Prototip, MVP sau pilot: trei lucruri diferite
Termenii se amestecă în discuții și fiecare răspunde la altă întrebare.
Prototipul e o machetă care se navighează, fără cod funcțional în spate. Nu salvează date și nu se conectează la nimic. Răspunde la întrebarea „e clar?" și costă cel mai puțin dintre toate trei. E instrumentul potrivit când nu ești sigur de structură sau de fluxul pe ecran.
MVP-ul e software real, folosit de oameni reali, cu datele lor. Răspunde la întrebarea „îl folosesc?".
Pilotul e un MVP lansat controlat, la un grup restrâns și cunoscut, de obicei clienți cu care ai deja o relație bună. Răspunde la aceeași întrebare ca MVP-ul, dar cu riscul de imagine redus, pentru că știi cine îl vede.
Ordinea firească e prototip, apoi MVP sau pilot. Sărirea prototipului e tentantă și, de obicei, se plătește: ajustările pe o machetă costă ore, aceleași ajustări pe cod costă zile.
06.Cum știi dacă a funcționat
Înainte de a construi, scrie propoziția asta și completeaz-o: „Vom ști că a mers dacă, în prima lună, ______."
În exemplul de mai sus: dacă cel puțin un sfert din programări vin din aplicație în loc de telefon. Poate fi orice prag realist, atâta timp cât e ales înainte. Un prag ales după livrare se mută întotdeauna ca să iasă rezultatul bun.
Fără propoziția asta, MVP-ul devine doar o primă tranșă de facturare, iar decizia de a continua se ia pe baza a cât s-a investit deja, ceea ce e cel mai prost criteriu posibil.
07.Greșelile care fac MVP-ul inutil
- Prea multe fluxuri, niciunul întreg. Rezultatul clasic al încercării de a mulțumi pe toată lumea din firmă. Nimeni nu poate folosi produsul pentru ceva real, deci nu afli nimic.
- Zero utilizatori reali. Un MVP testat doar intern, de echipa care l-a comandat, nu produce informație. Oamenii care știu cum ar trebui să funcționeze nu se comportă ca oamenii care nu știu.
- Nicio întrebare formulată dinainte. Dacă nu poți spune ce vrei să afli, vei livra ceva și vei numi rezultatul succes, indiferent care e.
- Design tratat ca fază ulterioară. Dacă produsul e confuz, oamenii nu-l folosesc, iar tu vei crede că ideea a fost greșită când de fapt ecranul era. E cea mai scumpă concluzie falsă din listă.
- Fără plan pentru date. Dacă MVP-ul merge și trebuie aruncat pentru că datele nu pot fi mutate în versiunea următoare, ai plătit de două ori.
08.Ce se întâmplă după
Un MVP se termină cu una din trei concluzii, și toate trei sunt rezultate valide.
Funcționează, se extinde. Adaugi al doilea flux, apoi al treilea, în ordinea valorii. Asta e calea obișnuită și e motivul pentru care merită să construiești pe fundații serioase chiar și la scară mică.
Funcționează parțial, se ajustează. Oamenii îl folosesc, dar altfel decât ai crezut. E cel mai valoros rezultat dintre toate, pentru că ai cumpărat o informație pe care nu o puteai obține altfel.
Nu funcționează, se oprește. Rar, dar real. Ai cheltuit o fracțiune din bugetul complet ca să afli asta, ceea ce e chiar rostul exercițiului. Un proiect oprit după MVP e un proiect care te-a costat mult mai puțin decât unul oprit după lansarea completă.
Despre etapele și termenele fiecărei faze am scris în cât durează o aplicație, iar despre benzile de preț în cât costă o aplicație.
09.Când nu ai nevoie de un MVP
Dacă problema e cunoscută, procesul e stabil și există deja produse care fac lucrul respectiv, nu ai nevoie de un experiment. Ai nevoie de o implementare. MVP-ul e potrivit când există o necunoscută reală despre comportamentul oamenilor. Când nu există, e doar o livrare împărțită în două, ceea ce e în regulă, dar merită numit corect.
Dacă nu ești sigur în care caz ești, discuția e mai devreme și am scris-o separat: ai nevoie de o aplicație sau de un proces mai bun.
10.Recomandarea GOODGLYPH
Dacă iei un singur lucru: scrie întrebarea la care vrei să răspunzi și pragul la care vei numi rezultatul un succes, amândouă înainte de prima linie de cod. Apoi taie din listă până rămâne un singur flux dus până la capăt. Noi lucrăm așa la aplicații pe măsură: prima versiune e mică, dar întreagă și construită pe fundații care suportă restul. Scrie-ne cu fluxul pe care l-ai alege și îți spunem ce mai lipsește din el ca să fie complet, înainte de orice ofertă.
11.Încheiere
Un MVP bun nu e un produs mai mic. E un produs mai îngust. Diferența se vede în prima lună: unul e folosit de oameni reali și îți spune ceva, celălalt e prezentat în ședințe și așteaptă faza a doua.
Întrebări frecvente
Depinde de flux, dar un MVP construit corect stă de obicei în banda de jos a aplicațiilor, de la câteva mii de euro. Dacă oferta pentru un MVP se apropie de prețul produsului complet, cel mai probabil nu s-a tăiat nimic din scop.
