Cum stabiliți domeniul unui MVP: reduceți prima versiune la ceea ce contează cu adevărat

Aproape toți cei care vin la noi cu o idee de aplicație au construit deja versiunea ei completă în mintea lor. Pot descrie tabloul de bord, pagina de setări, programul de recomandări, modul întunecat. Ceea ce de obicei nu vă pot spune este care anume parte din acea imagine, dacă ar funcționa, ar face ca întregul demers să merite. A stabili domeniul unui MVP este munca nespectaculoasă și ușor dureroasă de a găsi acea singură parte — și de a avea curajul de a o lăsa pe restul pentru mai târziu.

Am văzut multe prime produse fiind construite, iar cele care se chinuie aproape niciodată nu eșuează pentru că echipa a fost leneșă. Eșuează pentru că domeniul a fost greșit din prima săptămână. S-a îndesat prea mult în prima versiune, bugetul s-a terminat înainte ca cineva să învețe ceva, iar la lansare echipa cheltuise totul doar ca să ajungă la linia de start — fără bani rămași pentru a reacționa la ceea ce făceau de fapt utilizatorii reali.

Așadar acesta este ghidul pe care îl ofer oamenilor înainte să se scrie o singură linie de cod. Nu este despre ritualuri Agile sau cadre sofisticate. Este despre o singură întrebare onestă — care este cel mai mic lucru pe care îl putem construi care ne spune dacă această idee este reală? — și despre disciplina de a continua să o răspundeți pe măsură ce tentația de a adăuga „încă o singură funcționalitate” se strecoară înapoi. Pentru că întotdeauna se strecoară înapoi.

Ce este de fapt un MVP (și ce nu este)

Expresia s-a tocit de la suprafolosire, așa că să fim preciși. Un produs minim viabil este cea mai mică versiune a ideii dumneavoastră care oferă valoare reală unui utilizator real și vă învață ceva ce nu ați fi putut afla dintr-o prezentare. Cuvântul-cheie pe care oamenii îl uită este viabil. Trebuie să funcționeze cu adevărat pentru cineva, de la cap la coadă, chiar dacă face un singur lucru.

Iată ce nu este un MVP. Nu este o versiune pe jumătate terminată a produsului complet, cu colțuri rupte peste tot. Nu este un prototip pe care îl aruncați. Și cu siguranță nu este „versiunea ieftină” — ieftinul este un efect secundar al unei bune stabiliri a domeniului, nu scopul. Scopul este învățarea. Cheltuiți cât mai puțini bani posibil pentru a răspunde la cea mai scumpă întrebare pe care o aveți: va folosi cineva acest lucru și îl va folosi așa cum cred eu?

Această distincție contează mai mult decât pare. Mentalitatea „primii 20%” duce la un lucru rupt în toate direcțiile și util în niciuna. „Un singur lucru, făcut cum trebuie” duce la ceva ce o persoană poate lua în mână, folosi cu adevărat și despre care își poate forma o părere. Părerile sunt întregul scop. Nu puteți itera pe tăcere.

Capcana construirii excesive și de ce e atât de ușor să cădeți în ea

Nimeni nu pornește cu intenția de a supradimensiona domeniul. Se întâmplă o decizie rezonabilă pe rând. Adăugați autentificarea, pentru că evident aveți nevoie de conturi. Conturile înseamnă un flux de resetare a parolei, verificare prin e-mail și o pagină de setări. Setările înseamnă un profil, care înseamnă încărcări de imagini, care înseamnă un loc unde să le stocați. Fiecare pas e rezonabil în sine. Stivuite împreună, ați cheltuit deja două luni și o parte din buget înainte ca partea care vă face ideea specială să fi măcar început.

Cealaltă jumătate a capcanei este emoțională. A tăia funcționalități pare a recunoaște că ideea dumneavoastră este mică. Nu este — este a recunoaște că nu știți încă ce funcționalități contează, ceea ce este pur și simplu adevărul. Fiecare funcționalitate pe care o construiți înainte de a avea utilizatori este un pariu făcut orbește. Unele dintre acele pariuri vor fi greșite, iar cele pe care le tăiați din MVP sunt cele mai ieftine pariuri în care puteți greși, pentru că nu le-ați făcut niciodată.

Găsiți singura sarcină pe care trebuie să o îndeplinească MVP-ul

Fiecare produs, oricât de mare ar deveni în cele din urmă, are o buclă centrală — singura secvență pe care utilizatorul o repetă și care creează valoarea. Pentru o aplicație de rezervări este găsește un interval, rezervă-l, primește un memento. Pentru o piață este listează un lucru, cineva îl găsește, banii își schimbă stăpânul. Pentru un instrument intern este capturează datele o dată, folosește-le peste tot. Tot restul din produs există pentru a susține, decora sau extinde acea buclă. MVP-ul dumneavoastră este bucla. Doar bucla.

Pentru a o găsi pe a dumneavoastră, completați această propoziție cu voce tare: „Un utilizator vine la produsul meu ca să ______ și este mulțumit dacă ______.” Primul gol este sarcina. Al doilea este cum veți ști că a funcționat. Dacă nu puteți completa ambele goluri dintr-o suflare, nu ați găsit încă nucleul — și nu sunteți pregătit să stabiliți domeniul, darămite să construiți.

Fiți necruțător privind diferența dintre bucla centrală și lucrurile care par esențiale, dar nu sunt. Autentificarea pare esențială. De obicei nu este, în prima versiune — multe MVP-uri se lansează cu un singur link partajat, o invitație manuală sau fără conturi deloc și învață tot ce le trebuie înainte de a construi mecanismul de autentificare. Tablourile de analiză par esențiale. Nu sunt; puteți citi baza de date manual când aveți unsprezece utilizatori. Reduceți totul la buclă și veți fi uimit cât de mult se desprinde.

Sortați fiecare funcționalitate în: obligatoriu, de dorit și nu acum

Odată ce ați numit bucla centrală, luați lista mare de funcționalități și sortați fiecare element în trei coșuri. Coșurile sunt deliberat tranșante, pentru că tranșantul este ceea ce oprește nesfârșitele conversații „dar poate”.

• Obligatoriu: bucla centrală pur și simplu nu funcționează fără el. Dacă îl eliminați, nu există produs. Țineți această listă șocant de scurtă — de obicei trei până la șase elemente.
• De dorit: face produsul mai bun, dar bucla funcționează și fără el. Tot ce e aici așteaptă versiunea a doua. Fără excepții în prima versiune.
• Nu acum: funcționalitățile pe care alegeți conștient să nu le construiți acum. A le scrie contează — așa vă asigurați pe dumneavoastră și echipa că ideea nu este abandonată, ci doar pusă la rând.

Trucul care face asta să funcționeze este al treilea coș. Cei mai mulți oameni se ceartă doar pe obligatoriu versus de dorit, ceea ce e epuizant și nu se termină niciodată. Lista „nu acum” este unde locuiește ușurarea — este o promisiune pentru dumneavoastră de mâine că ideea grozavă e în siguranță și programată, doar nu acum. Odată ce oamenii au încredere că nimic nu se aruncă, încetează să se lupte ca să țină totul în prima versiune.

Stabiliți domeniul după timp și bani, nu după lista de funcționalități

Iată o schimbare discretă care schimbă totul: încetați să stabiliți domeniul după „ce vrem” și începeți să-l stabiliți după „ce încape în buget și în termen”. Decideți mai întâi câți bani și câte săptămâni sunteți dispus să cheltuiți pentru a răspunde la întrebarea centrală. Apoi potriviți lista de funcționalități în interiorul acelei cutii. Sună invers, dar este cea mai utilă constrângere pe care v-o puteți impune, pentru că forțează prioritizarea pe care altfel ați evita-o.

O cutie fixă face și ceva psihologic. Când bugetul este deschis, fiecare funcționalitate e discutabilă și lista doar crește. Când cutia este fixă — să zicem opt săptămâni și o sumă stabilită — conversația se răstoarnă. Încetează să fie „ar trebui să adăugăm asta?” și devine „ce iese dacă intră asta?” Această a doua întrebare este cea care construiește MVP-uri bune. Compromisurile devin vizibile în loc să rămână ascunse, iar echipa le face intenționat.

Un exemplu real: reducerea domeniului unei idei de management al lucrărilor pe teren

Să fac asta concret cu un caz la care am lucrat — anonimizat, dar fidel modului în care decurg aceste lucruri. O firmă mică de încălzire și instalații sanitare a venit la noi dorind o aplicație pentru echipa de teren. Briefingul, pe hârtie, era enorm: programarea lucrărilor în timp real, urmărirea GPS a dubelor, un portal pentru clienți, facturare automată, inventarul pieselor din fiecare vehicul, un generator de oferte, documentare foto și o suită de raportare pentru patron. Un produs cu adevărat util, în cele din urmă. Ca primă versiune, o cale garantată de a cheltui bugetul pe un an înainte de a învăța ceva.

Așa că am făcut exercițiul. I-am pus patronului propoziția: „Un utilizator vine la asta ca să ______ și este mulțumit dacă ______.” După câteva tatonări, a ieșit la suprafață răspunsul real. Cea mai mare durere zilnică a tehnicienilor nu era programarea sau facturarea — era drumul dus-întors al hârtiei. Terminau o lucrare, mâzgăleau orele și piesele pe o foaie, se întorceau cu mașina, iar apoi cineva din birou retasta totul în sistemul de contabilitate, adesea zile mai târziu, adesea cu erori. Bucla centrală era pur și simplu: capturează ce s-a întâmplat la lucrare, o dată, la fața locului, ca nimeni să nu retasteze.

Ce a intrat în domeniu — și ce nu

Totul a fost sortat. Coșul obligatoriu s-a redus la patru lucruri: o listă cu lucrările zilei pentru fiecare tehnician, un formular simplu pentru a înregistra orele și piesele folosite la fiecare lucrare, atașarea unei fotografii și o modalitate prin care biroul să vadă acele date în momentul în care erau trimise. Acesta era întregul MVP. Fără GPS, fără portal pentru clienți, fără generator de oferte, fără raportare sofisticată — toate parcate, explicit, pe lista „nu acum”, cu o notă că urmează.

Am construit acel nucleu în câteva săptămâni în loc de aproape un an. Și iată partea care justifică întreaga abordare: odată pus în funcțiune, prioritățile reale ale echipei s-au dovedit diferite de briefing. Patronul presupusese că urmărirea GPS va fi următoarea; tehnicienii abia au menționat-o. Ceea ce voiau, zgomotos, era să trimită clientului un interval de sosire prin SMS din interiorul aplicației — o funcționalitate care nici măcar nu fusese pe lista inițială. Pentru că MVP-ul era mic și ieftin, mai rămăseseră bani să construim lucrul pe care îl voiau cu adevărat, în loc de cel pe care îl ghiciseră cu luni înainte.

Greșelile care distrug pe tăcute domeniul unui MVP

Chiar și echipele care adoptă principiul „țineți-l mic” tind să se împiedice de aceleași câteva lucruri. Niciunul nu e dramatic. Sunt scurgeri lente care reumflă domeniul cât timp nu vă uitați, până când într-o zi produsul „minim” are din nou treizeci de ecrane și un termen de șase luni.

• Aurirea marginilor: a petrece zile perfecționând un panou de administrare pe care doar dumneavoastră îl veți vedea, în timp ce bucla centrală e încă brută. Lustruiți ceea ce ating utilizatorii; lăsați biroul din spate urât, dar funcțional.
• Construire pentru o scară pe care nu o aveți: a proiecta arhitectura pentru un milion de utilizatori când trebuie să dovediți că primii zece se vor întoarce. Rezolvați problema scării când aveți problema fericită a scării.
• Confundarea lui „indispensabil” cu „standard în industrie”: faptul că fiecare concurent are funcționalitatea X nu înseamnă că MVP-ul dumneavoastră are nevoie de ea pentru a vă testa ideea centrală. Nu lansați un produs finit, derulați un experiment.
• Proiectarea fiecărui caz limită din start: a trata intrările rare și ciudate înainte de a ști dacă cineva folosește calea comună și normală. Lăsați utilizarea reală să vă spună care cazuri limită sunt măcar reale.
• Lipsa unei definiții a finalizării: fără o frază scrisă care descrie cum arată „terminat”, construcția nu se termină niciodată. Extinderea domeniului adoră un proiect fără linie de sosire.

Dacă vă păziți de una singură dintre acestea, fie aceea ultima. O definiție clară și scrisă a finalizării — „un tehnician poate înregistra orele și piesele unei lucrări pe telefon, iar biroul o vede instantaneu” — este cel mai puternic instrument pentru a menține domeniul onest. Fiecare adăugare propusă este pusă față în față cu acea frază. Dacă nu servește fraza, este o idee pentru versiunea a doua, oricât de bună ar fi.

Un proces simplu pentru a stabili domeniul MVP-ului

Punând totul cap la cap, iată secvența pe care aș parcurge-o cu oricine înainte de a începe o primă versiune. Este deliberat de joasă tehnologie — puteți face cea mai mare parte cu un document și o conversație onestă, cu mult înainte să aveți nevoie de un dezvoltator în cameră.

1. 1
   Numiți bucla centrală

   Completați propoziția: „Un utilizator vine ca să ___ și este mulțumit dacă ___.” Dacă nu puteți, nu sunteți pregătit să stabiliți domeniul — continuați să vorbiți până când iese la suprafață sarcina reală.
2. 2
   Vărsați fiecare funcționalitate, apoi sortați

   Scoateți toată lista de dorințe din cap pe hârtie. Sortați fiecare element în obligatoriu, de dorit sau nu acum. Țineți lista „obligatoriu” brutal de scurtă.
3. 3
   Fixați cutia

   Decideți bugetul și termenul înainte de a finaliza lista de funcționalități. Faceți lista să încapă în cutie, nu invers.
4. 4
   Scrieți definiția finalizării

   O singură frază concretă care descrie bucla centrală funcțională. Acesta este scutul dumneavoastră împotriva extinderii domeniului pe tot restul proiectului.
5. 5
   Construiți, lansați, observați, apoi decideți

   Livrați nucleul către utilizatori reali. Observați ce fac de fapt. Lăsați comportamentul lor — nu presupunerile dumneavoastră anterioare — să aleagă ce iese în continuare de pe lista „de dorit”.

Observați că ultimul pas vă readuce la început. Un MVP bun nu este un eveniment unic, este prima rotire a unei roți. Stabiliți un domeniu mic, livrați, învățați, iar ceea ce învățați redefinește domeniul versiunii următoare. Echipele care câștigă nu sunt cele care au planificat produsul perfect din start — nimeni nu face asta. Sunt cele care au pus ceva real în fața utilizatorilor suficient de repede încât realitatea să le mai poată corecta direcția.

Întrebări frecvente