Slik avgrenser du en MVP: skjær den første versjonen ned til det som faktisk betyr noe

Nesten alle som kommer til oss med en app-idé, har allerede bygget den fulle versjonen av den i hodet. De kan beskrive dashbordet, innstillingssiden, vervekampanjen, mørk modus. Det de som regel ikke kan fortelle deg, er hvilken enkelt del av det bildet som ville gjort hele prosjektet verdt å gjennomføre, dersom den fungerte. Å avgrense en MVP er det uglamorøse, litt smertefulle arbeidet med å finne nettopp den delen — og være modig nok til å la resten vente til senere.

Jeg har sett mange første produkter bli bygget, og de som sliter, mislykkes nesten aldri fordi teamet var lat. De mislykkes fordi avgrensningen var feil allerede fra første uke. Det ble pakket for mye inn i versjon én, budsjettet tok slutt før noen lærte noe, og ved lansering hadde teamet brukt opp alt bare på å nå startstreken — uten penger igjen til å reagere på hva ekte brukere faktisk gjorde.

Så dette er guiden jeg gir folk før en eneste linje kode blir skrevet. Det handler ikke om Agile-ritualer eller fancy rammeverk. Det handler om ett ærlig spørsmål — hva er det minste vi kan bygge som forteller oss om idéen er ekte? — og disiplinen til å fortsette å svare på det mens fristelsen til å legge til «bare én funksjon til» sniker seg tilbake. For den sniker seg alltid tilbake.

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

Uttrykket er slitt glatt av overbruk, så la oss være presise. Et minste levedyktige produkt er den minste versjonen av idéen din som gir reell verdi til en reell bruker og lærer deg noe du ikke kunne lært av en presentasjon. Ordet folk glemmer, er levedyktig. Det må faktisk fungere for noen, hele veien, selv om det bare gjør én ting.

Her er hva en MVP ikke er. Den er ikke en halvferdig versjon av det fulle produktet med ødelagte hjørner overalt. Den er ikke en prototype du kaster. Og den er definitivt ikke «den billige versjonen» — billig er en bivirkning av god avgrensning, ikke målet. Målet er læring. Du bruker minst mulig penger på å svare på det dyreste spørsmålet du har: vil noen bruke dette, og vil de bruke det slik jeg tror?

Det skillet betyr mer enn det høres ut som. «De første 20 prosentene»-tankegangen fører til noe som er ødelagt i alle retninger og nyttig i ingen. «Én ting, gjort skikkelig» fører til noe et menneske kan ta i, bruke på ekte og ha en mening om. Meninger er hele poenget. Du kan ikke iterere på stillhet.

Bygg-for-mye-fellen, og hvorfor den er så lett å falle i

Ingen setter seg fore å avgrense for bredt med vilje. Det skjer én fornuftig beslutning om gangen. Du legger til innlogging fordi du selvsagt trenger kontoer. Kontoer betyr en flyt for tilbakestilling av passord, e-postbekreftelse og en innstillingsside. Innstillinger betyr en profil, som betyr bildeopplasting, som betyr et sted å lagre dem. Hvert steg gir mening i seg selv. Stablet sammen har du brukt to måneder og en bit av budsjettet før delen som gjør idéen din spesiell, i det hele tatt er påbegynt.

Den andre halvdelen av fellen er følelsesmessig. Å skjære funksjoner føles som å innrømme at idéen din er liten. Det er den ikke — det er å innrømme at du ennå ikke vet hvilke funksjoner som betyr noe, noe som rett og slett er sannheten. Hver funksjon du bygger før du har brukere, er et veddemål i blinde. Noen av disse veddemålene blir feil, og de du skjærer bort fra MVP-en, er de billigst mulige veddemålene å ta feil av, fordi du aldri inngikk dem.

Finn den ene oppgaven MVP-en din må løse

Ethvert produkt, uansett hvor stort det til slutt blir, har en kjerneløkke — den ene sekvensen en bruker gjentar, og som skaper verdien. For en booking-app er det finn en time, book den, bli minnet på den. For en markedsplass er det legg ut en ting, noen finner den, penger skifter eier. For et internt verktøy er det fang dataene én gang, bruk dem overalt. Alt annet i produktet finnes for å støtte, pynte på eller utvide den løkken. MVP-en din er løkken. Bare løkken.

For å finne din, fullfør denne setningen høyt: «En bruker kommer til produktet mitt for å ______, og er fornøyd hvis ______.» Den første åpningen er oppgaven. Den andre er hvordan du vet at det fungerte. Hvis du ikke kan fylle inn begge i ett åndedrag, har du ikke funnet kjernen ennå — og du er ikke klar til å avgrense, langt mindre bygge.

Vær nådeløs rundt forskjellen mellom kjerneløkken og tingene som føles essensielle, men ikke er det. Innlogging føles essensielt. Det er det som regel ikke i versjon én — mange MVP-er lanseres med én delt lenke, en manuell invitasjon eller ingen kontoer i det hele tatt, og lærer alt de trenger før de bygger autentiseringsmaskineriet. Analysedashbord føles essensielt. Det er det ikke; du kan lese databasen for hånd når du har elleve brukere. Skjær tilbake til løkken, og du blir forbløffet over hvor mye som faller bort.

Sorter hver funksjon i må, bør og ikke nå

Når du har gitt kjerneløkken et navn, ta den store funksjonslisten din og sorter hvert punkt i tre bøtter. Bøttene er bevisst kontante, fordi kontant er det som stopper de endeløse «men kanskje»-samtalene.

• Må: kjerneløkken fungerer bokstavelig talt ikke uten den. Fjerner du den, finnes det ikke noe produkt. Hold listen sjokkerende kort — vanligvis tre til seks punkter.
• Bør: det gjør produktet bedre, men løkken fungerer fortsatt uten den. Alt her venter på versjon to. Ingen unntak i det første bygget.
• Ikke nå: funksjonene du bevisst velger å ikke bygge nå. Å skrive dem ned betyr noe — det er slik du forsikrer deg selv, og teamet ditt, om at idéen ikke blir forlatt, bare satt i rekkefølge.

Trikset som får dette til å fungere, er den tredje bøtta. De fleste krangler bare om må kontra bør, noe som er utmattende og aldri tar slutt. «Ikke nå»-listen er der lettelsen bor — det er et løfte til ditt fremtidige jeg om at den kule idéen er trygg og planlagt, bare ikke nå. Når folk stoler på at ingenting blir kastet, slutter de å kjempe for å beholde alt i versjon én.

Avgrens etter tid og penger, ikke etter funksjonsliste

Her er et stille skifte som endrer alt: slutt å avgrense etter «hva vil vi ha», og begynn å avgrense etter «hva passer inn i budsjettet og fristen». Bestem først hvor mye penger og hvor mange uker du er villig til å bruke på å svare på kjernespørsmålet ditt. Tilpass deretter funksjonslisten inn i den boksen. Dette høres bakvendt ut, men det er den enkeltstående mest nyttige begrensningen du kan gi deg selv, fordi den tvinger frem prioriteringen du ellers ville unngått.

En fast boks gjør også noe psykologisk. Når budsjettet er åpent, er hver funksjon diskutabel og listen bare vokser. Når boksen er fast — la oss si åtte uker og et bestemt beløp — snur samtalen. Det er ikke lenger «skal vi legge til dette?», men «hva ryker ut hvis dette kommer inn?» Det siste spørsmålet er det som bygger gode MVP-er. Avveiningene blir synlige i stedet for skjulte, og teamet tar dem med vilje.

Et ekte eksempel: å avgrense en idé for oppdragsstyring

La meg gjøre det konkret med en sak vi jobbet med — anonymisert, men tro mot hvordan de pleier å gå. Et lite rørlegger- og varmefirma kom til oss og ønsket en app for feltteamet sitt. Oppdraget var på papiret enormt: sanntids oppdragsplanlegging, GPS-sporing av varebiler, en kundeportal, automatisk fakturering, lager over deler i hvert kjøretøy, en tilbudsbygger, fotodokumentasjon og en rapporteringspakke for eieren. Et virkelig nyttig produkt, til slutt. Som et første bygg en garantert måte å bruke opp et helt års budsjett før man lærte noe.

Så vi gjorde øvelsen. Vi stilte eieren setningen: «En bruker kommer til dette for å ______, og er fornøyd hvis ______.» Etter litt frem og tilbake dukket det virkelige svaret opp. Teknikernes største daglige smerte var verken planlegging eller fakturering — det var papirarbeidets rundtur. De fullførte en jobb, rablet ned timer og deler på et ark, kjørte tilbake, og noen på kontoret tastet alt inn på nytt i regnskapssystemet, ofte dager senere, ofte med feil. Kjerneløkken var rett og slett: fang hva som skjedde på jobben, én gang, på stedet, så ingen taster det inn på nytt.

Hva som kom med — og hva som ikke gjorde det

Alt ble sortert. Må-bøtta kokte ned til fire ting: en liste over dagens jobber for hver tekniker, et enkelt skjema for å logge timer og brukte deler per jobb, et bildevedlegg, og en måte for kontoret å se dataene i samme øyeblikk de ble sendt inn. Det var hele MVP-en. Ingen GPS, ingen kundeportal, ingen tilbudsbygger, ingen fancy rapportering — alt det parkert, uttrykkelig, på «ikke nå»-listen med en merknad om at det var på vei.

Vi bygde den kjernen på en håndfull uker i stedet for det meste av et år. Og her er delen som rettferdiggjør hele tilnærmingen: da den først var i drift, viste teamets reelle prioriteringer seg å avvike fra oppdraget. Eieren hadde antatt at GPS-sporing ville bli det neste; teknikerne nevnte det knapt. Det de ville ha, høylytt, var å sende kunden et ankomstvindu på SMS inne fra appen — en funksjon som ikke engang sto på den opprinnelige listen. Fordi MVP-en var liten og billig, var det budsjett igjen til å bygge det de faktisk ville ha, i stedet for det de hadde gjettet på måneder tidligere.

Feilene som stille ødelegger en MVP-avgrensning

Selv team som kjøper «hold det lite», snubler som regel i de samme få tingene. Ingen av dem er dramatiske. Det er trege lekkasjer som blåser avgrensningen opp igjen mens du ikke ser etter, helt til «minimums»-produktet en dag igjen har tretti skjermer og en seks måneders tidsplan.

• Å forgylle kantene: å bruke dager på å perfeksjonere et adminpanel bare du noensinne kommer til å se, mens kjerneløkken fortsatt er grov. Polér det brukerne tar i; la baksiden være stygg og funksjonell.
• Å bygge for skala du ikke har: å arkitektere for en million brukere når du må bevise at de første ti kommer tilbake. Løs skaleringsproblemet når du har det lykkelige problemet skala.
• Å forveksle «må-ha» med «bransjestandard»: bare fordi hver konkurrent har funksjon X, betyr det ikke at MVP-en din trenger den for å teste kjerneidéen din. Du lanserer ikke et ferdig produkt, du kjører et eksperiment.
• Å designe hvert spesialtilfelle på forhånd: å håndtere de sjeldne, rare inndataene før du vet om noen i det hele tatt bruker den vanlige, normale veien. La reell bruk fortelle deg hvilke spesialtilfeller som i det hele tatt er ekte.
• Ingen definisjon av ferdig: uten en nedskrevet linje som beskriver hvordan «ferdig» ser ut, tar bygget aldri slutt. Omfangskryp elsker et prosjekt uten målstrek.

Hvis du bare gardere deg mot én av disse, gjør det til den siste. En klar, nedskrevet definisjon av ferdig — «en tekniker kan logge en jobbs timer og deler på telefonen, og kontoret ser det umiddelbart» — er det enkeltstående mektigste verktøyet for å holde avgrensningen ærlig. Hvert foreslått tillegg holdes opp mot den setningen. Tjener det ikke setningen, er det en idé for versjon to, uansett hvor god den er.

En enkel prosess for å avgrense MVP-en din

For å samle det, her er rekkefølgen jeg ville gått gjennom med hvem som helst før et første bygg starter. Den er bevisst lavteknologisk — det meste kan du gjøre med et dokument og en ærlig samtale, lenge før du trenger en utvikler i rommet.

1. 1
   Gi kjerneløkken et navn

   Fullfør setningen: «En bruker kommer for å ___, og er fornøyd hvis ___.» Kan du ikke, er du ikke klar til å avgrense — fortsett å snakke til den virkelige oppgaven dukker opp.
2. 2
   Tøm ut hver funksjon, sorter deretter

   Få hele ønskelisten ut av hodet og ned på papir. Sorter hvert punkt i må, bør eller ikke nå. Hold «må»-listen brutalt kort.
3. 3
   Lås boksen

   Bestem budsjett og frist før du ferdigstiller funksjonslisten. Få listen til å passe inn i boksen, ikke omvendt.
4. 4
   Skriv definisjonen av ferdig

   Én konkret setning som beskriver den fungerende kjerneløkken. Dette er skjoldet ditt mot omfangskryp resten av prosjektet.
5. 5
   Bygg, lanser, observer, bestem deretter

   Lever kjernen til ekte brukere. Observer hva de faktisk gjør. La atferden deres — ikke de tidligere gjetningene dine — velge hva som kommer fra «bør»-listen som det neste.

Legg merke til at det siste steget fører deg tilbake til starten. En god MVP er ikke en engangshendelse, det er et hjuls første omdreining. Du avgrenser smått, du lanserer, du lærer, og det du lærer, avgrenser det neste bygget på nytt. Teamene som vinner, er ikke de som planla det perfekte produktet på forhånd — ingen gjør det. Det er de som fikk noe ekte foran brukerne raskt nok til at virkeligheten fortsatt kunne styre dem.

Vanlige spørsmål