Što Vaš SaaS MVP treba — i ne treba — sadržavati pri lansiranju

Riječ "minimalan" u minimalno održivom proizvodu dio je koji svi ignoriraju. Osnivači kimaju glavom ideji da krenu skromno, a zatim predaju specifikaciju s četrdeset ekrana, tri korisničke uloge, sustavom naplate, analitičkom nadzornom pločom i "a, da, treba se integrirati sa svime." To nije MVP. To je potpuni proizvod s optimizmom navijenim do maksimuma. I to je najčešći razlog zbog kojeg prva lansiranja stignu kasno, izvan proračuna i nekako još uvijek bez one jedne stvari koju su kupci doista željeli.

Pomogao sam priličnom broju malih tvrtki i samostalnih osnivača da izbace svoj prvi softverski proizvod. Tehnički dio rijetko je ono što ljude spotakne. Teški dio — svaki put — jest odlučiti što ne graditi još. MVP nije manja verzija vašeg proizvoda iz snova s nasumično skinutim značajkama. To je promišljena oklada: najmanja stvar koju možete staviti pred stvarne korisnike, a koja dokazuje da temeljna ideja vrijedi više vašeg novca i vremena.

Dakle, ovo je vodič koji bih volio da više osnivača pročita prije nego što napišu svoju specifikaciju. Bez žargona, bez kazališta "kreći se brzo i lomi stvari". Samo praktičan način da povučete granicu između onoga što pripada u vaše prvo izdanje i onoga što može — i treba — pričekati.

Što MVP zapravo jest (i što nije)

Razjasnimo definiciju, jer ovdje počinje većina zbrke. MVP je najmanja, najjednostavnija verzija vašeg proizvoda koja stvarnoj osobi omogućuje da učini onu jednu vrijednu stvar koju vaš proizvod obećava — i omogućuje vam da naučite hoće li se vratiti da je ponovno učini. To je to. To je alat za učenje koji se slučajno sastoji od softvera koji radi, a ne osiromašeno lansiranje gotove stvari.

Ključna je riječ održiv. Česta je pogreška pročitati "minimalno" i lansirati nešto tako ogoljeno da posrami korisnika — polutok koji se ruši, registracija koja vodi na prazan ekran. To nije minimalno-održivo, to je minimalno-pokvareno. Drugi je promašaj suprotan: proizvod toliko "potpun" da je trebala godina da se izgradi, a do tada ste potrošili svoj kapital dokazujući pretpostavku koju ste mogli testirati u osam tjedana.

Evo mentalnog testa koji koristim. Za svaku značajku na popisu pitajte: kad bismo je uklonili, bi li korisnik i dalje mogao dobiti onaj jedan temeljni ishod radi kojeg proizvod postoji? Ako je odgovor da, gotovo sigurno nije riječ o MVP-u. To pitanje samo prepolovit će većinu specifikacija — a polovica koju odreže jest ona koja bi vas zakasnila.

Pronađite jedan posao koji vaš proizvod obavlja

Prije nego što odlučite što graditi, morate biti brutalno jasni oko jednog posla koji vaš proizvod obavlja za nekoga. Ne vizija. Ne plan razvoja. Jedna ponovljiva radnja koja, ako uspije, nečiji dan čini boljim i čini ga spremnim platiti. Većina problematičnih specifikacija nejasna je upravo ovdje — opisuju platformu, a ne posao.

Pokušajte naglas dovršiti ovu rečenicu: "Korisnik dolazi mojem proizvodu da ______, a odlazi pošto je ______." Alat za raspoređivanje: voditelj dolazi objaviti raspored za sljedeći tjedan, a odlazi sa svakom smjenom popunjenom i obaviještenim timom. Aplikacija za fakturiranje: slobodnjak dolazi naplatiti klijentu, a odlazi s poslanim, pratljivim računom. Ako tu rečenicu ne možete čisto popuniti, niste spremni odrediti opseg — još uvijek ste spremni razmišljati.

Što svaki SaaS MVP doista treba

Neke stvari nisu pregovorive, čak ni u najvitkijoj prvoj verziji — ne zato što su uzbudljive, nego zato što se bez njih proizvod ili ne može koristiti ili vas ničemu ne može naučiti. Smatrajte ih podom, a ne stropom. Gradite ih jednostavno, ali gradite ih kako treba.

• Način prijave. Čak je i obična prijava e-poštom i lozinkom u redu — ali stvarna i sigurna, jer sve ostalo ovisi o tome da znate tko je korisnik.
• Temeljni tijek rada, od početka do kraja. Onaj jedan posao, od prvog korisnikova klika do trenutka kad dobije vrijednan ishod — bez slijepih ulica, bez gumba "uskoro" na kritičnoj putanji.
• Negdje gdje podaci doista žive. Pravo pohranjivanje, a ne jednokratni prototip, kako bi korisnikov rad preživio osvježavanje i mogao se vratiti sutra.
• Način da vidite što se događa. Osnovno bilježenje ili jednostavan administratorski prikaz, kako biste, kad se nešto pokvari — a hoće — mogli otkriti zašto bez nagađanja.
• Način da vas korisnici dosegnu. Makar samo poveznica e-pošte. Rani korisnici naletjet će na rubove koje niste predvidjeli; želite da vam to kažu, a ne da tiho odu.
• Najmanji mogući minimum povjerenja: napomena o privatnosti, razumno postupanje s podacima i da ne radite ništa nepromišljeno s podacima ljudi.

Primijetite što nije na tom popisu: naplata, otmjeno uvođenje korisnika, stranice postavki, mobilne aplikacije, integracije. Doći ćemo do toga zašto za koji trenutak. Smisao poda jest da je dovoljno malen da se dovrši i dovoljno čvrst da iz njega učite. Prijava koja radi, jedan tijek rada koji isporučuje, stvarni podaci i način da promatrate korisnike i razgovarate s njima. To je održiv proizvod.

Što namjerno izostaviti iz v1

Ovo je dio kojemu se osnivači opiru, pa da budem izravan: većina stvari koje se čine ključnima za vaše prvo lansiranje to nisu. Čine se ključnima jer ih "pravi proizvod" ima — ali vi još ne gradite pravi proizvod, gradite pitanje. Izostaviti ih nije rezanje uglova. To je cijela disciplina MVP-a.

Automatizirana naplata i složeno određivanje cijena

Gotovo sigurno vam u prvoj verziji ne treba samoposlužni sustav naplate, stupnjeviti planovi, razmjerno obračunavanje i logika opomena. Ako rani korisnici žele platiti, njihov novac možete uzeti ručno — račun, poveznica za plaćanje, kratak poziv. Ručna naplata za vaših prvih deset kupaca govori vam nešto što automatizirana naplata ne može: hoće li itko uopće platiti. Stroj gradite tek kad dokažete da ima novca za naplatiti.

Razrađene uloge i dopuštenja

Sustavi dopuštenja s više uloga — administratori, voditelji, promatrači, granularna pravila pristupa — pravi su inženjerski mulj i golemo umnožavaju površinu testiranja. Za prvo izdanje jedna vrsta korisnika gotovo je uvijek dovoljna. Stvarne potrebe za dopuštenjima naučit ćete promatrajući kako prave ekipe koriste stvar, a te su potrebe rijetko ono što biste pretpostavili na papiru.

Integracije, izvorne mobilne aplikacije i nadzorna ploča

"Treba se integrirati sa svime" izraz je koji tiho udvostručuje rokove. Odaberite najviše jednu integraciju, i to samo ako je dio temeljnog posla. Izvorne iOS i Android aplikacije gotovo uvijek mogu pričekati — responzivna web aplikacija danas radi na telefonu. A analitička nadzorna ploča koju svi žele? Korisnici ne mogu analizirati podatke koje još nisu stvorili. Prvo lansirajte stvar koja stvara podatke; vizualizirajte ih tek kad ima što pokazati.

Jednostavna metoda za povlačenje granice

Poznavati načelo jedno je; primijeniti ga na vlastitu specifikaciju, gdje svaka značajka djeluje kao vaše dijete, teže je. Evo metode koja djeluje jer prisiljava na odluku o svakoj stavci umjesto da pusti da sve odluta u "ključno".

1. 1
   Popišite svaku značajku koju ste zamislili

   Sve istresite — još bez filtriranja. Stavite cijeli popis želja na stol da ništa ne vreba neizrečeno i ne iskoči usred izgradnje kao iznenađenje.
2. 2
   Označite svaku u odnosu na temeljni posao

   Za svaku značajku pitajte: treba li je korisnik da bi dovršio onaj jedan temeljni posao, od početka do kraja? Označite je 'temeljna', 'korisna' ili 'jednom'. Budite iskreni — većina završi u zadnje dvije.
3. 3
   Za v1 zadržite samo 'temeljne'

   Vaš je MVP hrpa 'temeljnih' i ništa drugo. Hrpe 'korisno' i 'jednom' nisu odbijene — to je vaš plan razvoja, parkiran tamo gdje pripada.
4. 4
   Provjerite rez zdravim razumom

   Pogledajte što je ostalo i pitajte: može li stvarni korisnik dobiti stvarnu vrijednost samo od ovoga? Ako da, odredili ste opseg MVP-a. Ako nešto doista lomi temeljni tijek, povucite natrag samo tu jednu stavku — i ništa drugo.

Disciplina je u četvrtom koraku. Uvijek postoji iskušenje da se "povuče još samo jedna stvar", pa još jedna, dok tiho ne izgradite cijeli proizvod ispočetka. Dopustite si spasiti samo stavke koje doista lome temeljni tijek — ne stavke koje bi ga tek učinile ljepšim. Ljepše je ono za što služi druga verzija.

Održivo i dalje znači da se mora doimati stvarnim

Postoji način neuspjeha na drugoj strani granice i vrijedi ga imenovati. U žurbi da lansiraju skromno, neki osnivači lansiraju nešto aljkavo — i nazovu to MVP-om. Temeljni tijek koji gubi vaš rad, registracija koja vraća 404, tekst pun rezerviranog mjesta. To pošteno ne testira vašu ideju; testira hoće li korisnici tolerirati pokvareno iskustvo, a odgovor je uvijek ne. Zaključit ćete da je ideja propala, a zapravo je propala izvedba.

"Minimalno" se odnosi na opseg, nikad na kvalitetu dijela koji zadržavate. Manje značajki, svaka čvrsta. Onaj jedan tijek rada koji lansirate trebao bi se doimati gotovim — brz, jasan i pouzdan — čak i ako je to jedino što proizvod radi. Uzak proizvod dobro napravljen svaki put pobjeđuje širok proizvod loše napravljen, osobito kad od stranaca tražite da vam povjere svoj rad.

MVP nije ciljna crta — on je prvo očitanje

Evo dijela koji sve postavlja u novo svjetlo: lansiranje nije cilj. Cilj je ono što naučite u tjednima nakon njega. MVP koji se lansira i kaže vam "korisnici vole srž, ali stalno traže X" golem je uspjeh — čak i ako X znači još mjesec dana posla. MVP koji se lansira u tišinu, bez ikoga tko se vraća, također je obavio svoj posao: spasio vas je od izgradnje onih ostalih trideset značajki na temelju koji nitko nije htio.

Zato isplanirajte prve tjedne jednako promišljeno kao i izgradnju. Promatrajte što ljudi doista rade, a ne što kažu u anketama. Razgovarajte s onima koji su se vratili i s onima koji nisu. Pustite da stvarna uporaba — a ne vaša izvorna specifikacija — odluči što ide u drugu verziju. Plan razvoja koji ste ranije parkirali nije obećanje; to je hipoteza, a vaši korisnici upravo će je ocijeniti.

Česta pitanja