Anatomia unui MVP Supra-Scopat: O Analiză Critică

Există o versiune a pitch-ului de MVP pe care o auzim frecvent. Fondatorul a petrecut două-trei luni modelând ideea, deck-ul este lustruit, poveștile utilizatorilor sunt detaliate. Și când deschidem documentul de scop, găsim patruzeci și șapte de funcționalități, trei roluri de utilizator, o aplicație mobilă nativă și un panou de administrare.

Acesta nu este un MVP. Este un lansare de produs deghizată în test de ipoteză.

MVP-ul supra-scopat este una dintre cele mai costisitoare greșeli pe care le poate face un startup, nu pentru că este mai scump de construit, ci pentru că amână momentul adevărului. Fiecare săptămână petrecută construind funcționalități pe care nimeni nu le-a cerut este o săptămână în care nu afli dacă ideea de bază funcționează.

Ce vedem

Tiparul este consistent: un fondator a identificat o problemă reală și are suficientă convingere pentru a finanța dezvoltarea. Acea convingere, necesară pentru a construi orice, devine și ceea ce ucide disciplina de scop. Logica este: „Dacă tot o construim, s-o facem cum trebuie."

Rezultatul este un spec care include:

• Un panou de administrare din prima zi (cine este administratorul? tu, fondatorul. Folosește un client de baze de date)
• Trei roluri distincte de utilizator înainte ca un singur utilizator să se fi înregistrat (nu știi încă ce rol contează)
• iOS și Android native înainte ca produsul web să aibă un singur utilizator activ
• Notificări email, push și în-aplicație (alege una)
• Un flux complet de onboarding cu tooltip-uri, stări goale și o listă de „Primii pași"
• Pagini de setări și gestionare a contului pe care utilizatorii reali nu le vor atinge în primele treizeci de zile
• Un API public „ca să putem lăsa partenerii să se integreze mai târziu"

Niciuna dintre acestea nu este o funcționalitate greșită. Sunt funcționalități greșite pentru această etapă.

De ce eșuează

Un MVP supra-scopat eșuează din două motive care se compun.

În primul rând, petreci trei-patru luni construind funcționalități care nu ating ipoteza de bază. Ipoteza ta nu este „putem construi o pagină de setări bine proiectată?" Este „vrea cineva acest lucru și va plăti pentru el?"

În al doilea rând, lansezi cu atât de multe componente în mișcare încât atunci când ceva nu funcționează (și ceva nu funcționează niciodată) nu poți izola motivul. Este fluxul de onboarding? Cele trei roluri de utilizator care creează confuzie de permisiuni? Faptul că aplicația mobilă are un comportament diferit față de versiunea web? Un MVP supra-scopat produce un semnal ambiguu.

Analiza critică

Iată cum lucrăm printr-un document de scop când ajunge cu patruzeci și șapte de funcționalități.

Tăiem: panoul de administrare. Primul tău administrator ești tu. Ai o bază de date și un terminal. Construiește funcționalitate de administrare când ai o echipă de operațiuni care nu poate folosi niciunul.

Tăiem: rolurile multiple de utilizator. Alege utilizatorul care contează cel mai mult acum. Lansează pentru ei. Adaugă roluri când ai un motiv real, adică un utilizator real a cerut o distincție pe care nu o poți servi cu un singur rol.

Tăiem: aplicația mobilă. Dacă produsul tău nu este intrinsec mobil (un instrument pentru lucrători de teren, o experiență axată pe cameră), validează mai întâi pe web. Mobilul dublează suprafața și timpul de construcție. Lansează un produs web responsiv. Dacă utilizatorii întreabă „unde este aplicația?" suficient de des, ai validarea ta.

Tăiem: toate cele trei canale de notificare. Alege emailul. Este cel mai fiabil, cel mai ușor de implementat și cel pe care cei mai mulți utilizatori îl citesc efectiv. Adaugă push când ai suficiente date de retenție pentru a ști că ar îmbunătăți engagement-ul.

Tăiem: API-ul public. Aceasta este o funcționalitate pentru al doilea an, nu pentru prima lună. Un API pe care nimeni nu îl folosește este o povară de întreținere și o suprafață de securitate.

Tăiem: pagina de setări. Codifică valorile implicite. Lucrurile pe care utilizatorii vor să le configureze sunt cele pe care ți le spun că vor să le configureze, nu cele pe care le anticipezi tu. Când un utilizator spune „mi-aș dori să pot schimba X," construiești setarea. Nu înainte.

Păstrăm: parcursul de bază al utilizatorului. Singurul lucru pe care un utilizator îl face și care face produsul tău valoros. Totul ar trebui tăiat în jurul acestuia.

Cum arată un MVP lean

Un MVP lean are un tip de utilizator, un flux de bază și suficientă calitate vizuală încât să nu-ți fie rușine să îl arăți unui potențial client, dar nu atât de mult încât să fi petrecut timp pe lucruri care se vor schimba imediat ce utilizatorii interacționează cu produsul.

De obicei conține:

• Autentificare (înregistrare, logare, resetare parolă)
• Funcționalitatea de bază: lucrul pentru care există produsul
• Suficientă interfață cât funcționalitatea să fie utilizabilă fără o prezentare
• Gestionare de bază a erorilor, astfel încât eșecurile să nu fie silențioase
• O modalitate de a te contacta (adesea doar un link de email)

Acesta este scopul. Va părea prea mic. Lansează oricum.

Metoda noastră de 6 Săptămâni pentru MVP există tocmai pentru a menține această disciplină pe durata construcției: scop fix, termen fix, fără adăugiri târzii. Disciplina este produsul.

Ce urmează

Dacă ești în procesul de scopare a unui MVP acum, Estimatorul de MVP este un punct de pornire util: parcurge funcționalitățile, scoate la iveală deciziile de scop și îți oferă un interval înainte să te angajezi la un termen.

Dacă vrei o conversație mai directă despre ce să tai, facem și asta. Conversația de scopare este de obicei cea mai valoroasă oră din întreaga colaborare.

---

Scoparea este o abilitate. Necesită practică pentru a te obișnui cu ceea ce lași în afară.