Hva SaaS-MVP-en din bør — og ikke bør — inneholde ved lansering

Ordet «minimum» i minste levedyktige produkt er den delen alle overser. Gründere nikker med til ideen om å starte i det små, og leverer så en kravspesifikasjon med førti skjermer, tre brukerroller, en faktureringsmotor, et analysedashbord og «å ja, og den skal integrere med alt». Det er ingen MVP. Det er et fullt produkt med optimismen skrudd helt til topps. Og det er den enkeltstående vanligste grunnen til at de første lanseringene kommer for sent, over budsjett og likevel på et eller annet vis mangler den ene tingen kundene faktisk ville ha.

Jeg har hjulpet en god del småbedrifter og solo-gründere med å få det første programvareproduktet sitt ut. Den tekniske delen er sjelden det som feller folk. Det vanskelige — hver eneste gang — er å avgjøre hva man ikke skal bygge ennå. En MVP er ikke en mindre versjon av drømmeproduktet ditt med funksjoner slipt tilfeldig bort. Det er et bevisst veddemål: det minste du kan sette foran ekte brukere som beviser at kjerneideen er verdt mer av pengene og tiden din.

Så dette er guiden jeg skulle ønske flere gründere leste før de skrev kravspesifikasjonen sin. Ingen sjargong, ingen «beveg deg fort og knus ting»-teater. Bare en praktisk måte å trekke grensen mellom hva som hører hjemme i den første lanseringen og hva som kan — og bør — vente.

Hva en MVP faktisk er (og hva den ikke er)

La oss få definisjonen på plass, for det er her det meste av forvirringen starter. En MVP er den minste, enkleste versjonen av produktet ditt som lar en ekte person gjøre den ene verdifulle tingen produktet ditt lover — og lar deg lære om de kommer tilbake for å gjøre det igjen. Det er alt. Det er et læringsverktøy som tilfeldigvis er laget av fungerende programvare, ikke en avskrellet lansering av det ferdige produktet.

Det avgjørende ordet er levedyktig. En vanlig feil er å lese «minimum» og lansere noe så bart at det gjør brukeren flau — en halv flyt som krasjer, en registrering som fører til en tom skjerm. Det er ikke minimum levedyktig, det er minimum ødelagt. Den andre fiaskoen er det motsatte: et produkt så «komplett» at det tok et år å bygge, og da har du allerede brent kapitalen din på å bevise en gjetning du kunne ha testet på åtte uker.

Her er tankeprøven jeg bruker. For hver funksjon på listen, spør: hvis vi fjernet den, kunne en bruker likevel oppnå det ene kjerneresultatet produktet eksisterer for? Hvis svaret er ja, er den nesten helt sikkert ikke MVP. Det spørsmålet alene halverer de fleste kravspesifikasjoner — og halvparten det kutter bort, er den som ville gjort deg forsinket.

Finn den ene jobben produktet ditt gjør

Før du kan avgjøre hva du skal bygge, må du være brutalt klar over den ene jobben produktet ditt gjør for noen. Ikke visjonen. Ikke veikartet. Den ene gjentakbare handlingen som, hvis den fungerer, gjør en persons dag bedre og gjør dem villige til å betale. De fleste strevende kravspesifikasjoner er vage akkurat her — de beskriver en plattform, ikke en jobb.

Prøv å fullføre denne setningen høyt: «En bruker kommer til produktet mitt for å ______, og går igjen etter å ha ______.» Et vaktplanverktøy: en leder kommer for å publisere neste ukes vaktliste og går igjen med hver vakt dekket og teamet varslet. En faktureringsapp: en frilanser kommer for å fakturere en kunde og går igjen med en sendt, sporbar faktura. Hvis du ikke kan fylle inn den setningen rent, er du ikke klar til å avgrense — du er fortsatt klar til å tenke.

Hva enhver SaaS-MVP faktisk trenger

Noen ting er ikke til forhandling, selv i den slankeste første versjonen — ikke fordi de er spennende, men fordi produktet uten dem enten ikke kan brukes eller ikke kan lære deg noe. Tenk på disse som gulvet, ikke taket. Bygg dem enkelt, men bygg dem ordentlig.

• En måte å logge inn på. Selv en enkel innlogging med e-post og passord holder — men en ekte, sikker en, for alt annet henger på å vite hvem brukeren er.
• Kjerneflyten, fra ende til annen. Den ene jobben, fra brukerens første klikk til øyeblikket de får det verdifulle resultatet — ingen blindveier, ingen «kommer snart»-knapper i den kritiske stien.
• Et sted der dataene faktisk bor. Ekte lagring, ikke en bruk-og-kast-prototype, så en brukers arbeid overlever en oppdatering og de kan komme tilbake i morgen.
• En måte for deg å se hva som skjer. Grunnleggende logging eller en enkel admin-visning, slik at når noe ryker — og det vil det — kan du finne ut hvorfor uten å gjette.
• En måte for brukere å nå deg på. Selv bare en e-postlenke. Tidlige brukere treffer kanter du ikke forutså; du vil at de forteller deg det, ikke forsvinner i stillhet.
• Det aller minste av tillit: en personvernnotis, fornuftig databehandling og å ikke gjøre noe uvøren med folks opplysninger.

Legg merke til hva som ikke er på listen: fakturering, fancy onboarding, innstillingssider, mobilapper, integrasjoner. Vi kommer til hvorfor om et øyeblikk. Poenget med gulvet er at det er lite nok til å bli ferdig og solid nok til å lære av. En innlogging som virker, én flyt som leverer, ekte data og en måte å observere og snakke med brukere på. Det er et levedyktig produkt.

Hva du bevisst skal la være ute av v1

Dette er delen gründere gjør motstand mot, så la meg være direkte: de fleste tingene som føles uunnværlige for den første lanseringen din, er det ikke. De føles uunnværlige fordi et «ekte produkt» har dem — men du bygger ikke et ekte produkt ennå, du bygger et spørsmål. Å la disse være ute er ikke å ta snarveier. Det er hele disiplinen i en MVP.

Automatisk fakturering og kompleks prising

Du trenger nesten helt sikkert ikke en selvbetjent faktureringsmotor, nivådelte planer, proratering og purrelogikk i versjon én. Hvis tidlige brukere vil betale, kan du ta pengene deres manuelt — en faktura, en betalingslenke, en rask telefon. Manuell fakturering for de første ti kundene dine forteller deg noe automatisk ikke kan: om noen i det hele tatt vil betale. Bygg maskinen når du har bevist at det er penger å kreve inn.

Innfløkte roller og tillatelser

Tillatelsessystemer med flere roller — administratorer, ledere, lesere, finkornede tilgangsregler — er en ekte ingeniørmyr, og de mangedobler testflaten enormt. For en første lansering er én slags bruker nesten alltid nok. Du lærer de reelle tillatelsesbehovene ved å se faktiske team bruke greia, og de behovene er sjelden det du ville gjettet på papiret.

Integrasjoner, native mobilapper og dashbordet

«Den må integrere med alt» er frasen som stille dobler tidsplaner. Velg høyst én integrasjon, og bare hvis den er en del av kjernejobben. Native iOS- og Android-apper kan nesten alltid vente — en responsiv webapp fungerer på en telefon allerede i dag. Og analysedashbordet alle vil ha? Brukere kan ikke analysere data de ikke har laget ennå. Lanser først det som lager dataene; visualiser dem når det er noe å vise.

En enkel metode for å trekke grensen

Å kjenne prinsippet er én ting; å anvende det på din egen kravspesifikasjon, der hver funksjon føles som barnet ditt, er vanskeligere. Her er en metode som fungerer fordi den tvinger fram en beslutning på hvert punkt i stedet for å la alt drive over i «uunnværlig».

1. 1
   List opp hver funksjon du har sett for deg

   Tøm ut alt — ingen filtrering ennå. Få hele ønskelisten på bordet, slik at ingenting lurer uutalt og dukker opp midt i byggingen som en overraskelse.
2. 2
   Marker hver enkelt mot kjernejobben

   For hver funksjon, spør: trenger en bruker den for å fullføre den ene kjernejobben fra ende til annen? Marker den «kjerne», «nyttig» eller «en gang». Vær ærlig — de fleste lander i de to siste.
3. 3
   Behold bare «kjerne» til v1

   MVP-en din er «kjerne»-bunken og ingenting annet. «Nyttig»- og «en gang»-bunkene er ikke forkastet — de er veikartet ditt, parkert der de hører hjemme.
4. 4
   Fornuftssjekk kuttet

   Se på hva som er igjen, og spør: kan en ekte bruker få reell verdi av bare dette? Hvis ja, har du avgrenset en MVP. Hvis noe genuint bryter kjerneflyten, trekk bare det ene punktet tilbake — og ingenting annet.

Disiplinen ligger i trinn fire. Det er alltid en fristelse til å «trekke bare én ting til tilbake», og så enda en, til du stille har bygget opp igjen hele produktet. Tillat deg selv å redde bare punkter som genuint bryter kjerneflyten — ikke punkter som bare ville gjort den hyggeligere. Hyggeligere er det versjon to er til for.

Levedyktig betyr fortsatt at den må føles ekte

Det finnes en feiltilstand på den andre siden av grensen, og den er verdt å navngi. I hastverket med å lansere i det små lanserer noen gründere slurvete — og kaller det MVP. En kjerneflyt som mister arbeidet ditt, en registrering som gir 404, tekst full av plassholdertekst. Det tester ikke ideen din rettferdig; det tester om brukere vil tolerere en ødelagt opplevelse, og svaret er alltid nei. Du vil konkludere med at ideen feilet, når det egentlig var gjennomføringen.

«Minimum» gjelder omfang, aldri kvaliteten på den delen du beholder. Færre funksjoner, hver enkelt solid. Den ene flyten du lanserer, bør føles ferdig — rask, klar og pålitelig — selv om det er det eneste produktet gjør. Et smalt produkt gjort godt slår et bredt produkt gjort dårlig hver gang, særlig når du ber fremmede om å betro deg arbeidet sitt.

MVP-en er ikke målstreken — den er den første avlesningen

Her er delen som omformulerer alt: lanseringen er ikke målet. Målet er hva du lærer i ukene etter den. En MVP som lanseres og forteller deg «brukerne elsker kjernen, men spør stadig etter X», er en brølende suksess — selv om X betyr en måned mer arbeid. En MVP som lanseres inn i stillhet, uten at noen kommer tilbake, har også gjort jobben sin: den reddet deg fra å bygge de andre tretti funksjonene oppå et fundament ingen ville ha.

Så planlegg de første ukene like bevisst som byggingen. Observer hva folk faktisk gjør, ikke hva de sier i undersøkelser. Snakk med dem som kom tilbake og dem som ikke gjorde det. La den reelle bruken — ikke den opprinnelige kravspesifikasjonen din — avgjøre hva som går inn i versjon to. Veikartet du parkerte tidligere, er ikke et løfte; det er en hypotese, og brukerne dine er i ferd med å gi den karakter.

Vanlige spørsmål