Manglende systematikk i hvordan en MVP (Minimum Viable Product) skal testes ut, samt usikkerhet rundt eiendeler og ansettelser.

Slik løser du det

For å få mer systematikk i hvordan en MVP skal testes ut, anbefaler vi at du lager en MVP av papir for å visualisere flyten, leser deg opp på nødvendig domenekunnskap, og utarbeider en konkret plan for utviklingen og hvilke hypoteser som skal testes. Dette er en svært effektiv og billig måte å komme i gang på, lenge før du bruker penger på koding, eiendeler eller ansettelser. La oss forklare begrepene. MVP står for Minimum Viable Product, på norsk minste brukbare produkt. Det er den enkleste versjonen av løsningen din som likevel gir nok verdi til at en bruker kan teste den og gi tilbakemelding. Poenget er å lære mest mulig med minst mulig innsats. En MVP av papir (også kalt en papirprototype) er rett og slett skisser eller utklipp som viser hvordan løsningen skal se ut og fungere, slik at brukeren kan "klikke" seg gjennom på papir. Med flyt mener vi rekkefølgen av steg en bruker går gjennom, for eksempel fra de åpner appen til de fullfører en oppgave. Domenekunnskap er fagkunnskap om akkurat det området du jobber i (for eksempel helse, bygg eller finans). En hypotese er en antakelse du tror er sann, men som du ikke vet ennå, for eksempel "brukere er villige til å betale 99 kr i måneden". Hele poenget med en MVP er å teste slike hypoteser i virkeligheten. Konkrete steg: 1) Tegn opp brukerflyten på papir, skjerm for skjerm. 2) Skriv ned de viktigste hypotesene dine og hvordan du skal måle dem. 3) Vis papirprototypen til ekte potensielle brukere og observer hvor de blir forvirret. 4) Juster, og gjenta. Når det gjelder eiendeler og ansettelser: vent med store investeringer til hypotesene er bekreftet. En vanlig fallgruve er å bygge for mye for tidlig. Test billig, lær raskt, og bygg bare det brukerne faktisk trenger.