MVP vs. prototype vs. PoC: vælg det rigtige første skridt

Stiftere og produktteams får ofte at vide, at de skal „bygge en MVP“, når det, de i virkeligheden har brug for, er en prototype eller et proof of concept. Hver af dem besvarer et forskelligt spørgsmål, kræver en forskellig indsats og giver et forskelligt resultat. At vælge den rigtige sparer tid og bevarer budgettet til det skridt, der reelt har brug for det. Denne guide forklarer forskellene og giver en enkel måde at beslutte på.

Hvad det er

Et proof of concept (PoC) besvarer et teknisk spørgsmål: kan det lade sig gøre? Det kan teste, om et API returnerer de data, I har brug for, om en model kan klassificere dokumenter tilstrækkeligt præcist, eller om to systemer kan integreres inden for acceptable grænser. Et PoC er normalt snævert, kan kasseres og vises ikke til kunder. En prototype besvarer et spørgsmål om design og brugervenlighed: giver det mening for brugerne? Det kan være klikbare skærmbilleder eller en let frontend uden rigtige data, der bruges til at teste flows, indsamle feedback og skabe fælles forståelse blandt interessenter. Et minimum viable product (MVP) besvarer et markedsspørgsmål: vil rigtige brugere bruge det, og vil de komme tilbage eller betale? En MVP er fungerende software med rigtige data, udrullet til rigtige brugere og bevidst begrænset til det mindste sæt funktioner, der leverer kerneværdien. Fordi rigtige mennesker bruger den, kræver en MVP ordentlig opmærksomhed på autentifikation, datahåndtering og vedligeholdelse, selv hvis funktionssættet er lille.

Hvem er det for?

Denne sammenligning er nyttig for:

Stiftere, der forbereder sig på at bestille deres første udvikling
Produktteams i etablerede virksomheder, der undersøger en ny digital tjeneste
Investorer eller bestyrelser, der spørger, hvad den næste milepæl skal levere
Teams, der har bygget en prototype og er usikre på, om den kan blive til produktet

Hvad det hjælper med at afklare

At vælge mellem dem hjælper med at afklare:

Hvilken risiko der er størst lige nu: teknisk gennemførlighed, brugervenlighed eller efterspørgsel i markedet
Hvilken evidens den næste beslutning kræver, og hvem der skal træffe den
Hvor meget af arbejdet der forventes bevaret, og hvor meget der kasseres
Om krav til sikkerhed, databeskyttelse og app-butikker allerede gælder

Hvad er inkluderet

Vælg et PoC, hvis kerneteknologien, integrationen eller datakilden ikke er afprøvet
Vælg en prototype, hvis arbejdsgangen eller brugeroplevelsen er uklar, eller interessenterne er uenige om, hvordan produktet skal se ud
Vælg en MVP, hvis gennemførligheden og kerneflowene er forstået, og I har brug for evidens fra reel brug
For enhver mulighed: skriv ned, hvilket spørgsmål den skal besvare, og hvordan I vil bedømme resultatet
Definér, hvad der sker derefter for hvert udfald: fortsæt, justér eller stop
Beslut tidligt, om kode fra et PoC eller en prototype skal genbruges; normalt bør den ikke det
For en MVP: bekræft valg af autentifikation, datalagring, privatliv og hosting før udviklingen

Hvad er ikke inkluderet?

En påstand om, at nogen af disse tilgange sikrer product-market fit eller udbredelse
At gøre en prototype, der var beregnet til at blive kasseret, til produktionssoftware uden gennemgang
Markedsføring eller brugerakkvisition
Faste budgettal; indsatsen afhænger af omfanget, som bekræftes skriftligt

Hvornår du skal vælge det

Hvis I kan formulere jeres største ubekendte i én sætning, kan I som regel vælge. „Vi ved ikke, om integrationen virker“ peger på et PoC. „Vi ved ikke, om brugerne forstår flowet“ peger på en prototype. „Vi ved ikke, om brugerne vil tage det i brug“ peger på en MVP. Hvis I endnu ikke kan formulere det ubekendte, så start med et afklaringsarbejde for at definere det.

Vores tilgang

Arbejd i den rækkefølge, der fjerner mest risiko for mindst indsats. Mange produkter har gavn af en kort afklarings- eller blueprintfase, et fokuseret PoC på det sværeste tekniske spørgsmål og derefter en MVP bygget på det, der er lært. Vores tjeneste Technical Feasibility & PoC leverer et beslutningsnotat om gennemførlighed og et valideringsresumé for et defineret teknisk spørgsmål. Vores tjeneste App MVP Sprint leverer en afgrænset, fungerende første version med overdragelsesmateriale, bygget med opmærksomhed på autentifikation og datahåndtering fra starten. Hvor brugere, flows eller omfang stadig er uklare, kan et Discovery Sprint-forløb eller en opgave med Product Blueprint & Scope komme først. Uanset hvilken vej I vælger, så aftal spørgsmålet, afgrænsningen og overdragelsen skriftligt, før arbejdet begynder, så resultatet kan bedømmes i forhold til det tilsigtede.

App MVP Sprint

Se siden for tjenesten App MVP Sprint