Ce ar trebui — și ce nu ar trebui — să includă MVP-ul SaaS la lansare

Cuvântul „minim” din produsul minim viabil este partea pe care toată lumea o ignoră. Fondatorii dau din cap aprobator la ideea de a începe mic, apoi vă întind o specificație cu patruzeci de ecrane, trei roluri de utilizator, un motor de facturare, un tablou de bord cu analize și „a, și ar trebui să se integreze cu tot”. Acela nu este un MVP. Acela este un produs complet, cu optimismul dat la maximum. Și este, de departe, cel mai frecvent motiv pentru care primele lansări ajung târziu, peste buget și, cumva, tot fără singurul lucru pe care clienții îl voiau cu adevărat.

Am ajutat destul de multe firme mici și fondatori independenți să-și scoată pe piață primul produs software. Partea tehnică rareori îi încurcă pe oameni. Partea grea — de fiecare dată, fără excepție — este să decizi ce să nu construiești încă. Un MVP nu este o versiune mai mică a produsului visat, cu funcționalități șlefuite la întâmplare. Este un pariu deliberat: cel mai mic lucru pe care îl puteți pune în fața unor utilizatori reali și care dovedește că ideea de bază merită mai mulți bani și mai mult timp.

Așa că acesta este ghidul pe care mi-aș dori să-l fi citit mai mulți fondatori înainte de a-și scrie specificația. Fără jargon, fără spectacolul „mișcă-te repede și sparge lucruri”. Doar o modalitate practică de a trasa linia dintre ce aparține primei versiuni și ce poate — și ar trebui — să aștepte.

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

Să lămurim definiția, pentru că majoritatea confuziei începe aici. Un MVP este cea mai mică și mai simplă versiune a produsului dumneavoastră care îi permite unei persoane reale să facă acel singur lucru valoros pe care produsul îl promite — și vă permite să aflați dacă se va întoarce să-l facă din nou. Atât. Este un instrument de învățare care, întâmplător, este făcut din software funcțional, nu o lansare ciuntită a produsului finit.

Cuvântul crucial este viabil. O greșeală frecventă este să citești „minim” și să lansezi ceva atât de gol încât îl pune pe utilizator în încurcătură — un flux pe jumătate care se blochează, o înscriere care duce la un ecran gol. Acela nu este minim-viabil, este minim-defect. Cealaltă greșeală este opusul: un produs atât de „complet” încât a durat un an să-l construiești, moment în care v-ați cheltuit resursele dovedind o presupunere pe care ați fi putut-o testa în opt săptămâni.

Iată testul mental pe care îl folosesc. Pentru fiecare funcționalitate de pe listă, întrebați: dacă am elimina-o, ar putea utilizatorul tot să obțină acel singur rezultat esențial pentru care există produsul? Dacă răspunsul este da, aproape sigur nu este parte din MVP. Doar această întrebare va reduce majoritatea specificațiilor la jumătate — iar jumătatea pe care o taie este chiar cea care v-ar fi întârziat.

Găsiți singura sarcină pe care o face produsul

Înainte de a decide ce să construiți, trebuie să fiți brutal de clar cu privire la singura sarcină pe care produsul o face pentru cineva. Nu viziunea. Nu foaia de parcurs. Acea singură acțiune repetabilă care, dacă funcționează, îi face ziua mai bună unei persoane și o face dispusă să plătească. Majoritatea specificațiilor problematice sunt vagi exact aici — descriu o platformă, nu o sarcină.

Încercați să completați cu voce tare această propoziție: „Un utilizator vine la produsul meu ca să ______ și pleacă după ce a ______.” Un instrument de planificare: un manager vine să publice programul săptămânii viitoare și pleacă cu fiecare tură acoperită și echipa anunțată. O aplicație de facturare: un freelancer vine să factureze un client și pleacă cu o factură trimisă și care poate fi urmărită. Dacă nu puteți completa curat această propoziție, nu sunteți pregătit să stabiliți sfera — sunteți încă pregătit doar să gândiți.

De ce are cu adevărat nevoie orice MVP SaaS

Unele lucruri nu sunt negociabile, nici măcar în cea mai suplă primă versiune — nu pentru că sunt incitante, ci pentru că fără ele produsul fie nu poate fi folosit, fie nu vă poate învăța nimic. Considerați-le podeaua, nu tavanul. Construiți-le simplu, dar construiți-le ca lumea.

• O modalitate de autentificare. Chiar și o singură autentificare cu e-mail și parolă e suficientă — dar una reală și sigură, pentru că tot restul depinde de a ști cine este utilizatorul.
• Fluxul de bază, de la cap la coadă. Singura sarcină, de la primul clic al utilizatorului până în momentul în care obține rezultatul valoros — fără fundături, fără butoane „în curând” pe traseul critic.
• Un loc unde datele chiar trăiesc. Stocare reală, nu un prototip de unică folosință, ca munca utilizatorului să supraviețuiască unei reîncărcări și să se poată întoarce mâine.
• O modalitate prin care să vedeți ce se întâmplă. Jurnalizare de bază sau o vedere de administrator simplă, ca atunci când ceva se strică — și se va strica — să aflați de ce fără să ghiciți.
• O modalitate prin care utilizatorii să vă contacteze. Chiar și doar un link de e-mail. Primii utilizatori vor da peste limite pe care nu le-ați prevăzut; vreți să vă spună, nu să plece în tăcere.
• Minimul absolut de încredere: o notă de confidențialitate, o gestionare rezonabilă a datelor și să nu faceți nimic nesăbuit cu informațiile oamenilor.

Observați ce nu se află pe acea listă: facturarea, integrarea elegantă în produs, paginile de setări, aplicațiile mobile, integrările. Vom ajunge imediat la de ce. Rostul podelei este că e suficient de mică încât să o termini și suficient de solidă încât să înveți din ea. O autentificare care funcționează, un flux care livrează, date reale și o modalitate de a urmări și a vorbi cu utilizatorii. Acela este un produs viabil.

Ce să lăsați deliberat în afara versiunii 1

Aceasta este secțiunea la care fondatorii opun rezistență, așa că permiteți-mi să fiu direct: majoritatea lucrurilor care vi se par esențiale pentru prima lansare nu sunt. Par esențiale pentru că un „produs adevărat” le are — dar dumneavoastră nu construiți încă un produs adevărat, construiți o întrebare. A le lăsa în afară nu înseamnă a tăia colțuri. Este însăși disciplina unui MVP.

Facturare automată și prețuri complexe

Aproape sigur nu aveți nevoie de un motor de facturare autoservire, planuri pe niveluri, calcul proporțional și logică de recuperare a plăților în prima versiune. Dacă primii utilizatori vor să plătească, le puteți lua banii manual — o factură, un link de plată, un telefon scurt. Facturarea manuală pentru primii zece clienți vă spune ceva ce facturarea automată nu poate: dacă va plăti cineva, în general. Construiți mașinăria după ce ați dovedit că există bani de colectat.

Roluri și permisiuni elaborate

Sistemele de permisiuni cu mai multe roluri — administratori, manageri, vizualizatori, reguli de acces granulare — sunt o adevărată mlaștină inginerească și multiplică enorm suprafața de testare. Pentru o primă versiune, un singur tip de utilizator este aproape întotdeauna de ajuns. Veți afla nevoile reale de permisiuni urmărind echipe adevărate folosind produsul, iar acele nevoi sunt rareori cele pe care le-ați fi ghicit pe hârtie.

Integrări, aplicații mobile native și tabloul de bord

„Trebuie să se integreze cu tot” este expresia care dublează în tăcere termenele. Alegeți cel mult o integrare și doar dacă face parte din sarcina de bază. Aplicațiile native iOS și Android pot aproape întotdeauna să aștepte — o aplicație web responsivă funcționează pe un telefon astăzi. Iar tabloul de bord cu analize pe care îl vrea toată lumea? Utilizatorii nu pot analiza date pe care încă nu le-au creat. Lansați mai întâi lucrul care creează datele; vizualizați-le odată ce există ceva de arătat.

O metodă simplă de a trasa linia

A cunoaște principiul e una; a-l aplica propriei specificații, unde fiecare funcționalitate ți se pare propriul copil, e mai greu. Iată o metodă care funcționează pentru că forțează o decizie asupra fiecărui element, în loc să lase totul să alunece spre „esențial”.

1. 1
   Listați fiecare funcționalitate la care v-ați gândit

   Aruncați-le pe toate afară — încă fără filtrare. Puneți toată lista de dorințe pe masă, ca nimic să nu pândească nespus și să reapară în mijlocul construirii ca o surpriză.
2. 2
   Evaluați fiecare în raport cu sarcina de bază

   Pentru fiecare funcționalitate, întrebați: are utilizatorul nevoie de ea ca să completeze singura sarcină de bază, de la cap la coadă? Marcați-o „esențială”, „utilă” sau „cândva”. Fiți sincer — majoritatea cad în ultimele două.
3. 3
   Păstrați doar „esențialul” pentru v1

   MVP-ul dumneavoastră este grămada „esențială” și nimic altceva. Grămezile „utilă” și „cândva” nu sunt respinse — sunt foaia dumneavoastră de parcurs, parcate acolo unde le e locul.
4. 4
   Verificați tăietura din rațiune

   Priviți ce a rămas și întrebați: poate un utilizator real să obțină valoare reală doar din asta? Dacă da, ați stabilit sfera unui MVP. Dacă ceva chiar rupe fluxul de bază, trageți înapoi doar acel element — și nimic altceva.

Disciplina stă în pasul patru. Există mereu tentația de a „mai trage înapoi doar un lucru”, apoi încă unul, până când ați reconstruit în tăcere produsul complet. Permiteți-vă să salvați doar elementele care chiar rup fluxul de bază — nu elementele care l-ar face doar mai plăcut. Mai plăcut e treaba versiunii a doua.

Viabil înseamnă totuși că trebuie să pară real

Există un mod de eșec de cealaltă parte a liniei și merită numit. În graba de a lansa mic, unii fondatori lansează ceva de mântuială — și îl numesc MVP. Un flux de bază care îți pierde munca, o înscriere care dă eroare 404, text plin de marcaje de poziție. Asta nu vă testează corect ideea; testează dacă utilizatorii vor tolera o experiență defectă, iar răspunsul este mereu nu. Veți concluziona că ideea a eșuat, când de fapt execuția a eșuat.

„Minim” se aplică sferei, niciodată calității părții pe care o păstrați. Mai puține funcționalități, fiecare solidă. Singurul flux pe care îl lansați ar trebui să pară terminat — rapid, clar și demn de încredere — chiar dacă e singurul lucru pe care produsul îl face. Un produs îngust făcut bine bate de fiecare dată un produs larg făcut prost, mai ales când le cereți unor străini să vă încredințeze munca lor.

MVP-ul nu este linia de sosire — este prima lectură

Iată partea care reașază totul: lansarea nu este scopul. Scopul este ceea ce învățați în săptămânile de după. Un MVP care se lansează și vă spune „utilizatorilor le place esența, dar cer mereu X” este un succes răsunător — chiar dacă X înseamnă încă o lună de muncă. Un MVP care se lansează în tăcere, fără ca nimeni să se întoarcă, și-a făcut și el treaba: v-a scutit să construiți celelalte treizeci de funcționalități pe o fundație pe care nimeni nu o voia.

Așa că planificați primele săptămâni la fel de deliberat ca pe construire. Urmăriți ce fac oamenii de fapt, nu ce spun în sondaje. Vorbiți cu cei care s-au întors și cu cei care nu. Lăsați utilizarea reală — nu specificația dumneavoastră inițială — să decidă ce intră în versiunea a doua. Foaia de parcurs pe care ați parcat-o mai devreme nu este o promisiune; este o ipoteză, iar utilizatorii dumneavoastră sunt pe cale să o noteze.

Întrebări frecvente