Når bør man lansere en applikasjon, og hvilke funksjoner må være med?

Anbefalingen er tydelig: lanser relativt tidlig for å få rask tilbakemelding fra kunder. Vurder nøye hvilke funksjoner som faktisk er nødvendige for at de første kundene skal kunne teste produktet, kutt ut alt som ikke er essensielt, og sett en intern frist for lansering. Dette er selve kjernen i å bygge en MVP.

MVP står for Minimum Viable Product – «det minste levedyktige produktet». Det er den enkleste versjonen av produktet som likevel løser kundens kjerneproblem godt nok til at de vil bruke det og gi tilbakemelding. Tankegangen kommer fra Lean Startup, en metodikk popularisert av Eric Ries, som handler om å bygge raskt, måle hvordan kundene faktisk reagerer, og lære av det – i en kontinuerlig «build-measure-learn»-sløyfe. Poenget er å unngå å bruke måneder eller år på å bygge noe ingen vil ha.

Hvorfor tidlig lansering lønner seg: Ekte brukere oppfører seg nesten alltid annerledes enn dere forventer. Jo tidligere dere får produktet i hendene deres, jo tidligere oppdager dere hva som faktisk skaper verdi – og hva som var bortkastet arbeid. Dette kan også avdekke om dere bør pivotere, altså gjøre en bevisst kursendring i produkt eller marked basert på det dere lærer.

Konkrete steg: 1) Skriv ned kundens viktigste problem i én setning. 2) List opp alle funksjoner dere har tenkt på, og marker hvilke som er strengt nødvendige for å løse akkurat det problemet. 3) Kutt resten til «senere»-listen. 4) Sett en fast, intern lanseringsfrist – en deadline tvinger frem prioritering. 5) Slipp til en liten gruppe testkunder og samle tilbakemeldinger systematisk. Vanlige fallgruver: å pynte på produktet i det uendelige («feature creep»), og å la frykten for at det ikke er «perfekt» utsette lanseringen. Husk: en MVP skal være litt flau å vise frem – det betyr at dere lanserte i tide.