Grundare och produktteam får ofta höra att de ska ”bygga en MVP” när det de egentligen behöver är en prototyp eller en konceptvalidering (PoC). Var och en besvarar en annan fråga, kräver olika mycket insats och ger ett annat resultat. Att välja rätt sparar tid och reserverar budget för det steg som verkligen behöver den. Den här guiden förklarar skillnaderna och ger ett enkelt sätt att välja.
Vad det är
En konceptvalidering (PoC) besvarar en teknisk fråga: går detta att göra? Den kan testa om ett API returnerar de data ni behöver, om en modell kan klassificera dokument tillräckligt exakt eller om två system kan integreras inom acceptabla gränser. En PoC är vanligtvis smal, kastas efteråt och visas inte för kunder. En prototyp besvarar en fråga om design och användbarhet: är detta begripligt för användarna? Den kan bestå av klickbara skärmar eller ett enkelt gränssnitt utan riktiga data och används för att testa flöden, samla in synpunkter och skapa samsyn bland intressenter. En minsta livskraftiga produkt (MVP) besvarar en marknadsfråga: kommer verkliga användare att använda detta, och kommer de tillbaka eller betalar? En MVP är fungerande programvara med riktiga data, driftsatt för verkliga användare och medvetet begränsad till den minsta uppsättning funktioner som levererar kärnvärdet. Eftersom verkliga människor använder den kräver en MVP ordentlig uppmärksamhet på autentisering, datahantering och underhållbarhet, även om funktionsuppsättningen är liten.
Vem det är för
Jämförelsen är användbar för:
- Grundare som förbereder beställningen av sin första utveckling
- Produktteam i etablerade företag som utforskar en ny digital tjänst
- Investerare eller styrelser som frågar vad nästa milstolpe ska leverera
- Team som har byggt en prototyp och är osäkra på om den kan bli produkten
Vad det hjälper till att klargöra
Att välja mellan dem hjälper till att klargöra:
- Vilken risk som är störst just nu: teknisk genomförbarhet, användbarhet eller efterfrågan på marknaden
- Vilket underlag nästa beslut behöver och vem som ska fatta det
- Hur mycket av arbetet som förväntas behållas och hur mycket som kastas
- Om krav på säkerhet, dataskydd och appbutiker redan gäller
Vad ingår
- Välj en PoC om kärntekniken, integrationen eller datakällan inte är beprövad
- Välj en prototyp om arbetsflödet eller användarupplevelsen är oklar, eller om intressenterna är oense om hur produkten ska se ut
- Välj en MVP om genomförbarhet och kärnflöden är förstådda och ni behöver belägg från verklig användning
- För alla alternativ: skriv ned frågan som ska besvaras och hur ni ska bedöma resultatet
- Definiera vad som händer härnäst för varje utfall: fortsätta, justera eller avbryta
- Bestäm tidigt om kod från PoC eller prototyp ska återanvändas; vanligtvis bör den inte det
- För en MVP: bekräfta val av autentisering, datalagring, dataskydd och hosting innan utvecklingen börjar
Vad som inte ingår
- Ett påstående om att någon av dessa metoder säkerställer produkt–marknadsanpassning eller användning
- Att göra en slit-och-släng-prototyp till produktionsprogramvara utan granskning
- Marknadsföring eller användaranskaffning
- Fasta budgetbelopp; insatsen beror på omfattningen, som bekräftas skriftligt
När det passar att välja den
Om ni kan formulera er största osäkerhet i en mening kan ni vanligtvis välja. ”Vi vet inte om integrationen fungerar” pekar mot en PoC. ”Vi vet inte om användarna förstår flödet” pekar mot en prototyp. ”Vi vet inte om användarna kommer att börja använda det” pekar mot en MVP. Om ni ännu inte kan formulera osäkerheten, börja med ett utforskande arbete för att definiera den.
Vår strategi
Arbeta i den ordning som tar bort mest risk med minst insats. Många produkter gynnas av en kort utforsknings- eller planeringsfas, en fokuserad PoC på den svåraste tekniska frågan och därefter en MVP byggd på det man har lärt sig. Vår tjänst Technical Feasibility & PoC levererar ett beslutsunderlag om genomförbarhet och en valideringssammanfattning för en definierad teknisk fråga. Vår tjänst App MVP Sprint levererar en avgränsad, fungerande första version med överlämningsmaterial, byggd med uppmärksamhet på autentisering och datahantering från början. Där användare, flöden eller omfattning fortfarande är oklara kan ett uppdrag av typen Discovery Sprint eller Product Blueprint & Scope komma först. Vilken väg ni än väljer, kom skriftligt överens om frågan, avgränsningen och överlämningen innan arbetet börjar, så att resultatet kan bedömas mot det som var avsett.
Vanliga frågor
Relaterade artiklar
Kom igång
Osäkra på om ni ska börja med en PoC, en prototyp eller en MVP?
Beskriv er idé, den största osäkerheten och det beslut som nästa steg måste stödja. Vi föreslår en proportionerlig omfattning att börja med.
Begär en skriftlig omfattning