Mit tartalmazzon — és mit ne — a SaaS MVP-je az induláskor

A „minimálisan” szó a minimálisan életképes termékben az a rész, amelyet mindenki figyelmen kívül hagy. Az alapítók egyetértően bólogatnak a kicsiben kezdés gondolatára, majd átnyújtanak egy specifikációt negyven képernyővel, három felhasználói szereppel, egy számlázómotorral, egy elemzési vezérlőpulttal és „á, és integrálódnia kell mindennel” felkiáltással. Ez nem MVP. Ez egy teljes termék, a maximumra tekert optimizmussal. És messze ez a legelterjedtebb oka annak, hogy az első indulások későn, túlköltekezve érkeznek, és valahogy mégis épp az az egy dolog hiányzik belőlük, amit az ügyfelek valóban akartak.

Szép számú kisvállalkozásnak és egyedül dolgozó alapítónak segítettem piacra vinni az első szoftvertermékét. A technikai rész ritkán szokta megfogni az embereket. A nehéz rész — minden egyes alkalommal, kivétel nélkül — annak eldöntése, hogy mit ne építsen még meg. Egy MVP nem az álomtermékének egy kisebb, véletlenszerűen lecsiszolt funkciójú változata. Tudatos fogadás: a legkisebb dolog, amit valódi felhasználók elé tehet, és amely bizonyítja, hogy az alapötlet megér több pénzt és időt.

Szóval ez az az útmutató, amelyet azt kívánom, bárcsak több alapító elolvasott volna, mielőtt megírja a specifikációját. Semmi szakzsargon, semmi „mozogj gyorsan és törj össze dolgokat” színjáték. Csupán egy gyakorlatias módszer arra, hogy meghúzza a határt aközött, ami az első kiadásba való, és ami várhat — sőt, várnia is kell.

Mi is valójában egy MVP (és mi nem)

Tisztázzuk a definíciót, mert a zűrzavar nagy része itt kezdődik. Egy MVP a terméke legkisebb, legegyszerűbb változata, amely lehetővé teszi, hogy egy valódi ember megtegye azt az egy értékes dolgot, amit a terméke ígér — és amelyből megtudhatja, vajon visszatér-e, hogy újra megtegye. Ennyi. Ez egy tanulóeszköz, amely történetesen működő szoftverből áll, nem a kész dolog megnyirbált kiadása.

A döntő szó az életképes. Gyakori hiba, hogy az ember elolvassa a „minimálisan” szót, és kiad valami annyira csupaszt, hogy zavarba hozza a felhasználót — egy félbeszakadó folyamat, amely összeomlik, egy regisztráció, amely üres képernyőre vezet. Ez nem minimálisan-életképes, ez minimálisan-hibás. A másik kudarc az ellenkezője: egy annyira „teljes” termék, amelyet egy évig építettek, mire pedig az erőforrásait egy olyan feltevés bizonyítására költötte, amelyet nyolc hét alatt tesztelhetett volna.

Íme a gondolati teszt, amelyet használok. A lista minden funkciójánál kérdezze meg: ha eltávolítanánk, a felhasználó akkor is elérné azt az egy alapvető eredményt, amiért a termék létezik? Ha a válasz igen, akkor szinte biztosan nem MVP. Már csak ez az egy kérdés is a felére vágja a legtöbb specifikációt — és épp azt a felét vágja le, amely megkésleltette volna.

Találja meg azt az egy feladatot, amit a terméke végez

Mielőtt eldönthetné, mit építsen, brutálisan világosan kell látnia azt az egyetlen feladatot, amelyet a terméke valakinek elvégez. Nem a víziót. Nem az ütemtervet. Azt az egyetlen ismételhető cselekvést, amely — ha működik — jobbá teszi valakinek a napját, és hajlandóvá teszi a fizetésre. A legtöbb akadozó specifikáció épp itt homályos — platformot írnak le, nem feladatot.

Próbálja meg hangosan befejezni ezt a mondatot: „A felhasználó azért jön a termékemhez, hogy ______, és úgy távozik, hogy ______.” Egy ütemezőeszköz: a vezető eljön közzétenni a jövő heti beosztást, és úgy távozik, hogy minden műszak betöltve és a csapat értesítve van. Egy számlázóalkalmazás: a szabadúszó eljön kiszámlázni egy ügyfelet, és úgy távozik, hogy van egy elküldött, nyomon követhető számlája. Ha nem tudja tisztán befejezni ezt a mondatot, akkor még nem áll készen a körmeghatározásra — még csak a gondolkodásra áll készen.

Mire van valóban szüksége minden SaaS MVP-nek

Egyes dolgok nem alku tárgyai még a legkarcsúbb első változatban sem — nem azért, mert izgalmasak, hanem mert nélkülük a terméket vagy nem lehet használni, vagy nem tanít meg semmire. Tekintse ezeket a padlónak, nem a plafonnak. Építse őket egyszerűen, de építse őket rendesen.

• Egy mód a bejelentkezésre. Még egyetlen e-mailes és jelszavas bejelentkezés is elég — de valódi és biztonságos, mert minden más azon múlik, hogy tudjuk, ki a felhasználó.
• Az alapvető munkafolyamat, elejétől a végéig. Az egy feladat, a felhasználó első kattintásától addig a pillanatig, amíg megkapja az értékes eredményt — zsákutcák nélkül, „hamarosan” gombok nélkül a kritikus útvonalon.
• Egy hely, ahol az adatok valóban élnek. Valódi tárolás, nem eldobható prototípus, hogy a felhasználó munkája túléljen egy frissítést, és holnap visszatérhessen.
• Egy mód arra, hogy lássa, mi történik. Alapszintű naplózás vagy egy egyszerű adminisztrátori nézet, hogy amikor valami elromlik — és el fog —, kitalálgatás nélkül megtudja, miért.
• Egy mód arra, hogy a felhasználók elérjék Önt. Akár csak egy e-mail-link. A korai felhasználók olyan peremekbe ütköznek, amelyeket nem látott előre; azt akarja, hogy elmondják, ne pedig csendben távozzanak.
• A bizalom abszolút minimuma: egy adatvédelmi megjegyzés, ésszerű adatkezelés, és hogy ne tegyen semmi felelőtlent az emberek adataival.

Figyelje meg, mi nincs azon a listán: számlázás, díszes bevezető folyamat, beállítási oldalak, mobilalkalmazások, integrációk. Hamarosan rátérünk, miért. A padló lényege, hogy elég kicsi a befejezéshez, és elég szilárd a tanuláshoz. Egy működő bejelentkezés, egy folyamat, amely teljesít, valódi adatok, és egy mód a felhasználók megfigyelésére és a velük való beszélgetésre. Ez egy életképes termék.

Mit hagyjon ki tudatosan az 1. verzióból

Ez az a rész, amelynek az alapítók ellenállnak, úgyhogy hadd legyek nyers: az első indulásához nélkülözhetetlennek érzett dolgok többsége nem az. Azért érzi nélkülözhetetlennek, mert egy „valódi terméknek” megvannak — de Ön még nem valódi terméket épít, hanem egy kérdést. Ezek kihagyása nem felületesség. Ez maga az MVP fegyelme.

Automatikus számlázás és összetett árazás

Az első verzióban szinte biztosan nincs szüksége önkiszolgáló számlázómotorra, szintezett csomagokra, időarányos elszámolásra és behajtási logikára. Ha a korai felhasználók fizetni akarnak, kézzel is elveheti a pénzüket — egy számla, egy fizetési link, egy gyors telefon. A kézi számlázás az első tíz ügyfélnél megmond valamit, amit az automatikus számlázás nem tud: hogy egyáltalán fizet-e valaki. A gépezetet akkor építse meg, amikor már bizonyította, hogy van mit beszedni.

Bonyolult szerepkörök és jogosultságok

A többszerepkörös jogosultsági rendszerek — adminisztrátorok, vezetők, megtekintők, finomhangolt hozzáférési szabályok — valódi mérnöki ingovány, és hatalmasan megsokszorozzák a tesztelési felületet. Egy első kiadáshoz szinte mindig elég egyetlen felhasználótípus. A valódi jogosultsági igényeket abból fogja megtanulni, hogy figyeli, ahogy valódi csapatok használják a dolgot, és ezek az igények ritkán azok, amelyeket papíron kitalált volna.

Integrációk, natív mobilalkalmazások és a vezérlőpult

A „mindennel integrálódnia kell” az a kifejezés, amely csendben megduplázza a határidőket. Válasszon legfeljebb egy integrációt, és azt is csak akkor, ha az alapfeladat része. A natív iOS- és Android-alkalmazások szinte mindig várhatnak — egy reszponzív webalkalmazás ma működik egy telefonon. És az az elemzési vezérlőpult, amit mindenki akar? A felhasználók nem tudnak olyan adatot elemezni, amelyet még nem hoztak létre. Adja ki előbb azt, ami az adatot létrehozza; vizualizálja, amikor már van mit mutatni.

Egy egyszerű módszer a határ meghúzására

Ismerni az elvet egy dolog; alkalmazni a saját specifikációjára, ahol minden funkció a saját gyermekének tűnik, nehezebb. Íme egy módszer, amely azért működik, mert minden tételnél döntésre kényszerít, ahelyett hogy hagyná, hogy minden a „nélkülözhetetlen” felé sodródjon.

1. 1
   Sorolja fel minden funkciót, amit elképzelt

   Öntse ki mindet — egyelőre szűrés nélkül. Tegye az asztalra a teljes kívánságlistát, hogy semmi se lapuljon kimondatlanul, és bukkanjon fel az építés közepén meglepetésként.
2. 2
   Mérje mindegyiket az alapfeladathoz

   Minden funkciónál kérdezze meg: szüksége van rá a felhasználónak ahhoz, hogy elejétől a végéig elvégezze az egy alapfeladatot? Jelölje „alapvető”, „hasznos” vagy „valamikor” megjelöléssel. Legyen őszinte — a legtöbb az utóbbi kettőbe esik.
3. 3
   Az 1. verzióhoz csak az „alapvetőt” tartsa meg

   Az MVP-je az „alapvető” kupac és semmi más. A „hasznos” és „valamikor” kupac nincs elutasítva — ezek az ütemterve, oda parkolva, ahová valók.
4. 4
   Ellenőrizze józan ésszel a vágást

   Nézze meg, mi maradt, és kérdezze meg: kaphat-e egy valódi felhasználó valódi értéket pusztán ebből? Ha igen, akkor egy MVP körét határozta meg. Ha valami valóban megtöri az alapfolyamatot, húzzon vissza csak azt az egy tételt — és semmi mást.

A fegyelem a negyedik lépésben van. Mindig ott a kísértés, hogy „húzzon vissza csak még egy dolgot”, aztán még egyet, mígnem csendben újraépítette a teljes terméket. Engedje meg magának, hogy csak azokat a tételeket mentse meg, amelyek valóban megtörik az alapfolyamatot — ne azokat, amelyek pusztán szebbé tennék. A szebb a második verzió dolga.

Az életképes még mindig azt jelenti, hogy valódinak kell hatnia

A határvonal másik oldalán is van egy kudarcforma, és érdemes nevén nevezni. A kicsiben való kiadás kapkodásában egyes alapítók valami elnagyoltat adnak ki — és MVP-nek nevezik. Egy alapfolyamat, amely elveszíti a munkáját, egy regisztráció, amely 404-et dob, helykitöltő szöveggel teli tartalom. Ez nem teszteli tisztességesen az ötletét; azt teszteli, hogy a felhasználók eltűrnek-e egy hibás élményt, és a válasz mindig nem. Arra a következtetésre fog jutni, hogy az ötlet bukott meg, miközben valójában a kivitelezés.

A „minimálisan” a körre vonatkozik, sosem a megtartott rész minőségére. Kevesebb funkció, mindegyik szilárd. Annak az egy folyamatnak, amelyet kiad, késznek kell hatnia — gyorsnak, világosnak és megbízhatónak —, még akkor is, ha ez az egyetlen dolog, amit a termék csinál. Egy jól megcsinált szűk termék minden alkalommal legyőz egy rosszul megcsinált széles terméket, különösen amikor idegeneket kér arra, hogy bízzák Önre a munkájukat.

Az MVP nem a célvonal — hanem az első leolvasás

Íme a rész, amely mindent új keretbe helyez: az indulás nem a cél. A cél az, amit az utána következő hetekben megtanul. Egy MVP, amely elindul, és azt mondja Önnek, „a felhasználók imádják a lényeget, de folyton X-et kérnek”, harsogó siker — még akkor is, ha X egy hónapnyi további munkát jelent. Egy MVP, amely csendbe indul, és senki sem tér vissza, szintén elvégezte a dolgát: megmentette attól, hogy a másik harminc funkciót egy olyan alapra építse, amelyet senki sem akart.

Úgyhogy tervezze meg az első heteket ugyanolyan tudatosan, mint az építést. Figyelje, mit tesznek az emberek valójában, ne azt, amit a kérdőívekben mondanak. Beszéljen azokkal, akik visszatértek, és azokkal is, akik nem. Hagyja, hogy a valódi használat — ne az eredeti specifikációja — döntse el, mi kerül a második verzióba. Az ütemterv, amelyet korábban leparkolt, nem ígéret; ez egy hipotézis, és a felhasználói épp leosztályozni készülnek.

Gyakori kérdések