Od SaaS ideje do prve različice: kaj spada v MVP in kaj lahko počaka

V SaaS MVP spada najmanjši celovit potek, s katerim lahko resnični uporabnik opravi pomembno nalogo in ekipa preveri najbolj tvegano poslovno ali produktno predpostavko. Vanj ne spada skrajšana različica vseh prihodnjih funkcij. Če prva izdaja ne odgovori na jasno vprašanje, manjši obseg sam po sebi še ne pomeni dobrega MVP-ja.

MVP mora biti dovolj majhen za osredotočeno izvedbo in dovolj celovit za pošten preizkus vrednosti.

Najprej določite najbolj tvegano predpostavko

Vsaka zgodnja ideja vsebuje več negotovosti:

• ali problem res obstaja;
• ali ga izbrani uporabnik čuti dovolj močno;
• ali bo sprejel predlagani način reševanja;
• ali je potreben dostop do določenih podatkov;
• ali je rešitev tehnično izvedljiva;
• ali je zanjo pripravljen plačati;
• ali jo je mogoče podpreti v realnem delovanju.

Najbolj tvegana predpostavka ni nujno najbolj zapletena funkcija. Je tista, ki bi ob napačnem odgovoru najbolj oslabila celotno zamisel.

Če je vprašanje, ali ekipa sploh želi nov način obdelave dokumentov, napredni sistem naročnin ne pomaga pri prvem preizkusu. Če pa je bistvo produkta plačljiva samopostrežna storitev, je lahko način zaračunavanja del jedra.

Zapišite eno poved: »Prva izdaja mora preveriti, ali [tip uporabnika] lahko oziroma želi [pomembno dejanje] pod [ključnimi pogoji].«

Izberite eno nalogo od začetka do konca

MVP naj podpira celoten uporabniški tok, ne zbirke nepovezanih zaslonov.

Za glavno nalogo določite:

1. kako uporabnik vstopi;
2. katere podatke potrebuje;
3. kaj mora vnesti ali izbrati;
4. kaj sistem obdela;
5. kakšen rezultat uporabnik prejme;
6. kaj se z rezultatom zgodi pozneje;
7. kako ekipa vidi ali podpre težavo.

Primer brez vezave na določen produkt: uporabnik se prijavi, ustvari en tip zapisa, ga obdela skozi glavni potek, prejme rezultat in ga lahko pozneje ponovno odpre. To je uporabnejši MVP kot širok dashboard z več nedokončanimi moduli.

Vloge in prijava naj sledijo resnični potrebi

Avtentikacija ni sama sebi namen. Potrebna je, kadar mora sistem varovati osebne podatke, shranjevati delo, razlikovati organizacije ali nadzorovati dostop.

Za prvo izdajo vprašajte:

• Ali uporabnik potrebuje trajen račun?
• Ali je dovolj ena vrsta uporabnika?
• Ali obstaja administrator?
• Ali več oseb pripada isti organizaciji?
• Kdo lahko vidi, spreminja ali izbriše podatke?
• Kaj se zgodi ob odhodu člana ekipe?

Ne gradite obsežnega sistema pravic samo zato, ker ga bo produkt morda nekoč potreboval. Hkrati ne odložite osnovne izolacije podatkov, če MVP uporablja več uporabnikov ali organizacij.

Razlika med internim orodjem in javnim produktom močno vpliva na te odločitve; primerjava je v članku Interno orodje ali SaaS produkt?.

Zaračunavanje vključite samo, če preverja bistveno vprašanje

Plačila so smiselna v MVP-ju, kadar je pripravljenost za plačilo del predpostavke ali mora uporabnik kupiti dostop, da je potek realen.

Če zgodnja izdaja poteka z majhno skupino ročno vključenih uporabnikov, lahko ekipa cenovni model najprej preveri drugače. Takrat popolna samopostrežna naročnina, računi, kuponi, menjave paketov in davčne posebnosti morda niso nujni za glavno učenje.

Odložitev avtomatizacije ne pomeni, da finančni proces ni pomemben. Pomeni, da se obseg prve izdaje prilagodi vprašanju, ki ga mora produkt preveriti.

Dodajte osnovno opazljivost in podporo

MVP brez vpogleda v napake ni pripravljen za učenje.

Ekipa mora vedeti:

• ali je glavni tok uspel;
• kje je uporabnik obstal;
• ali je prišlo do tehnične napake;
• kateri vhod je težavo povzročil;
• kako varno pomagati uporabniku;
• kako popraviti napačno stanje.

To ne zahteva obsežnega analitičnega sistema. Zahteva pa beleženje pomembnih dogodkov, napak in dovolj konteksta za podporo.

Določite tudi kontaktni kanal, odgovorno osebo in postopek za resno napako. »Beta« ni razlog, da uporabnik izgubi podatke brez pojasnila.

Napišite seznam zavestno odloženega obsega

Odložene funkcije naj bodo zapisane, ne samo pozabljene.

Pogosti kandidati so:

• dodatne vloge;
• napredne nastavitve;
• več cenovnih paketov;
• obsežna poročila;
• javni API;
• mobilna aplikacija;
• avtomatiziran onboarding;
• sekundarne integracije;
• prilagoditve za velike organizacije.

Ob vsaki navedite razlog za odlog in signal, zaradi katerega bi jo ponovno obravnavali. Funkcija naj se vrne v načrt zaradi dokazane potrebe, ne zato, ker je bila dolgo na seznamu.

Določite merila za izdajo

MVP je pripravljen, ko:

• glavni potek deluje od začetka do konca;
• osnovne pravice preprečujejo napačen dostop;
• kritične napake so vidne ekipi;
• obstaja način podpore;
• podatke je mogoče varno upravljati;
• uporabnik razume omejitve izdaje;
• ekipa ve, katero predpostavko spremlja;
• odloženi obseg je dokumentiran.

Merilo ni število funkcij. Je sposobnost izvesti pošten, varen in uporaben preizkus osrednje zamisli.

Obseg MVP-ja je mogoče pripraviti kot fazno izdelavo web aplikacije. Za začetni pogovor opišite glavno predpostavko in uporabniški tok prek kontakta.

← Nazaj na blog