Gründere og produktteam får ofte høre at de bør «bygge en MVP», når det de egentlig trenger, er en prototype eller et konseptbevis (PoC). Hver av dem besvarer et ulikt spørsmål, krever ulik innsats og gir et ulikt resultat. Å velge riktig sparer tid og holder av budsjett til steget som virkelig trenger det. Denne guiden forklarer forskjellene og gir en enkel måte å avgjøre på.
Hva det er
Et konseptbevis (PoC) besvarer et teknisk spørsmål: lar dette seg gjøre? Det kan teste om et API returnerer dataene dere trenger, om en modell kan klassifisere dokumenter tilstrekkelig nøyaktig, eller om to systemer kan integreres innenfor akseptable grenser. En PoC er vanligvis smal, til engangsbruk og vises ikke til kunder. En prototype besvarer et spørsmål om design og brukervennlighet: gir dette mening for brukerne? Den kan bestå av klikkbare skjermbilder eller en enkel frontend uten ekte data, brukt til å teste flyter, samle tilbakemeldinger og samkjøre interessenter. Et minimum levedyktig produkt (MVP) besvarer et markedsspørsmål: vil ekte brukere ta det i bruk, og vil de komme tilbake eller betale? En MVP er fungerende programvare med ekte data, satt i drift for ekte brukere, bevisst begrenset til det minste settet funksjoner som leverer kjerneverdien. Fordi ekte mennesker bruker den, krever en MVP ordentlig oppmerksomhet rundt autentisering, datahåndtering og vedlikeholdbarhet, selv om funksjonssettet er lite.
Hvem det er for
Denne sammenligningen er nyttig for:
- Gründere som forbereder bestillingen av sin første utvikling
- Produktteam i etablerte selskaper som utforsker en ny digital tjeneste
- Investorer eller styrer som spør hva neste milepæl skal levere
- Team som har bygget en prototype og er usikre på om den kan bli produktet
Hva det hjelper med å klarlegge
Å velge mellom dem bidrar til å avklare:
- Hvilken risiko som er størst akkurat nå: teknisk gjennomførbarhet, brukervennlighet eller etterspørsel i markedet
- Hvilket grunnlag neste beslutning trenger, og hvem som skal ta den
- Hvor mye av arbeidet som forventes beholdt, og hvor mye som kastes
- Om krav til sikkerhet, personvern og appbutikker allerede gjelder
Hva er inkludert
- Velg en PoC hvis kjerneteknologien, integrasjonen eller datakilden ikke er bevist
- Velg en prototype hvis arbeidsflyten eller brukeropplevelsen er uklar, eller interessentene er uenige om hvordan produktet skal se ut
- Velg en MVP hvis gjennomførbarhet og kjerneflyter er forstått og dere trenger bevis fra reell bruk
- For alle alternativer: skriv ned spørsmålet som skal besvares, og hvordan dere skal vurdere resultatet
- Definer hva som skjer videre for hvert utfall: fortsette, justere eller stoppe
- Avgjør tidlig om kode fra PoC eller prototype skal gjenbrukes; vanligvis bør den ikke det
- For en MVP: bekreft valg av autentisering, datalagring, personvern og drift før utviklingen starter
Hva er ikke inkludert
- En påstand om at noen av disse tilnærmingene sikrer produkt-marked-tilpasning eller adopsjon
- Å gjøre en prototype til engangsbruk om til produksjonsprogramvare uten gjennomgang
- Markedsføring eller brukeranskaffelse
- Faste budsjettall; innsatsen avhenger av omfanget, som bekreftes skriftlig
Når skal den velges
Hvis dere kan formulere den største ukjente faktoren i én setning, kan dere vanligvis velge. «Vi vet ikke om integrasjonen fungerer» peker mot en PoC. «Vi vet ikke om brukerne forstår flyten» peker mot en prototype. «Vi vet ikke om brukerne vil ta det i bruk» peker mot en MVP. Hvis dere ennå ikke kan formulere det ukjente, start med et kartleggingsarbeid for å definere det.
Vår tilnærming
Arbeid i den rekkefølgen som fjerner mest risiko for minst innsats. Mange produkter har nytte av en kort kartleggings- eller planfase, en fokusert PoC på det vanskeligste tekniske spørsmålet og deretter en MVP bygget på det man har lært. Tjenesten vår Technical Feasibility & PoC leverer et beslutningsnotat om gjennomførbarhet og et valideringssammendrag for et definert teknisk spørsmål. Tjenesten vår App MVP Sprint leverer en avgrenset, fungerende første versjon med overleveringsmateriell, bygget med oppmerksomhet på autentisering og datahåndtering fra starten. Der brukere, flyter eller omfang fortsatt er uklare, kan et oppdrag av typen Discovery Sprint eller Product Blueprint & Scope komme først. Uansett hvilken vei dere velger, avtal spørsmålet, avgrensningen og overleveringen skriftlig før arbeidet starter, slik at resultatet kan vurderes opp mot det som var tiltenkt.
Ofte stilte spørsmål
Beslektede artikler
Kom i gang
Usikre på om dere bør starte med en PoC, en prototype eller en MVP?
Beskriv ideen, den største ukjente faktoren og beslutningen neste steg må støtte. Vi foreslår et forholdsmessig omfang å starte med.
Be om et skriftlig omfang