Når skal man slutte å legge til ny funksjonalitet før lansering?

Slik løser du det

Spørsmålet om når man skal slutte å legge til ny funksjonalitet før lansering er en klassisk gründerutfordring, fordi det alltid frister å bygge bare én funksjon til. Vårt råd er å definere kjernefunksjonaliteten som gir verdi for brukeren. I ukene før lansering bør du slutte å legge til nye funksjoner og heller fokusere på å finjustere eksisterende funksjonalitet og fikse bugs. Dette handler om begrepet MVP, Minimum Viable Product, på norsk gjerne kalt et minste brukbare produkt. En MVP er den enkleste versjonen av produktet som likevel løser brukerens kjerneproblem og gir reell verdi. Tanken kommer fra Lean Startup, en metode for å bygge oppstartsbedrifter der man lærer raskt og billig ved å lansere tidlig, måle hvordan folk bruker produktet, og forbedre basert på det, i stedet for å bruke årevis på å bygge i det skjulte. Kjernefunksjonaliteten er de få funksjonene som er helt nødvendige for at produktet skal være nyttig. Alt annet er fint-å-ha, men kan vente. Grunnen til at du bør stoppe med nye funksjoner i ukene før lansering, er at hver nye funksjon introduserer ny risiko for feil og forsinker lanseringen, mens du heller bør sørge for at det du allerede har fungerer knirkefritt. Bugs er feil i programvaren som gjør at noe ikke fungerer som det skal. Et produkt med få, men solide funksjoner gir et bedre førsteinntrykk enn et med mange funksjoner som er halvferdige eller buggy. Konkrete steg: Skriv ned brukerens viktigste problem, list opp funksjonene som løser akkurat det, og kutt resten fra første versjon. Sett en lanseringsdato, og innfør en funksjonsfrys (feature freeze) noen uker før, der dere kun retter feil og finpusser. En vanlig fallgruve er funksjonskryp (scope creep), at omfanget stadig vokser. Vær disiplinert, og lanser. Du kan alltid legge til mer senere basert på ekte tilbakemeldinger. En Spark*-veileder kan hjelpe deg å definere kjernen.