Det vanligaste problemet med en MVP är inte tekniskt. Funktionslistan växer på varje möte, eftersom varje funktion känns nödvändig, och några månader senare har du en produkt som gör många saker halvbra och inte svarar på den viktigaste frågan: vill någon använda den.
Börja med en hypotes, inte med funktioner
Innan du listar funktioner, skriv i en mening vad MVP:n ska testa. Till exempel: ”Projektledare på byggföretag kommer att rapportera framsteg varje vecka via mobilen i stället för att mejla kalkylblad.”
Lägg till ett mätetal som bekräftar eller motbevisar hypotesen. Inte ”användarna gillar den”, utan ett beteende som går att räkna: hur många av de inbjudna användarna som kom tillbaka andra veckan, hur många rapporter som skapades, hur många företag som vill betala.
En väg från början till slut
En MVP ska låta användaren gå en huvudväg från första skärmen till resultatet hen kom för. Det är bättre att en väg fungerar helt än att fem fungerar till hälften.
Lista alla funktioner du kommer på och placera var och en i en av tre grupper:
- Nödvändiga för huvudvägen. Utan dem når användaren inte resultatet.
- Görs manuellt. Sådant som en person kan sköta bakom kulisserna i början: skapa konton, skicka rapporter, hantera betalning mot faktura.
- Senare. Allt annat.
Den andra gruppen är mest värdefull. Att sköta de första kunderna manuellt tar tid, men visar vad som faktiskt är värt att automatisera.
Det här kan oftast vänta
- En omfattande adminpanel. I början räcker en enkel datavy eller direkt åtkomst till databasen för teamet.
- Roller och behörigheter. En kontotyp räcker ofta för de första testerna.
- Språkversioner. Om du inte testar produkten på flera marknader samtidigt.
- Aviseringar i många kanaler. Mejl räcker.
- Native-appar. Om huvudvägen fungerar i mobilens webbläsare kan en app i appbutiken vänta.
- Fler integrationer. En, den viktigaste, räcker oftast.
Det här ska inte vänta
”Minsta” gäller omfattningen, inte kvaliteten. Även första versionen behöver:
- säker inloggning och dataskydd, eftersom ett dataläckage i en MVP är lika verkligt som i en mogen produkt,
- analys som mäter hypotesens mätetal, eftersom MVP:n annars inte testar något,
- en genomarbetad huvudväg, eftersom användare bedömer en produkt efter det som fungerar, inte efter planerna,
- grundläggande tillgänglighet och en integritetspolicy.
Prototyp först
Innan du börjar koda, testa huvudvägen på en klickbar prototyp med några personer ur målgruppen. En ändring i en prototyp kostar en bråkdel av en ändring i kod, och de första samtalen ändrar oftast skärmarnas ordning och vad användaren vill se först. Vem du ska prata med och vad du ska fråga beskrev vi i artikeln om B2B-personas.
Fast tid, flexibel omfattning
Det fungerar bäst att bestämma deadline och budget i förväg och låta omfattningen vara det som varierar. Blir något svårare än väntat faller det bort ur första versionen i stället för att skjuta upp lanseringen. Hos oss tar en MVP oftast 6–8 veckor: en användarväg, en integration och driftsättning i produktion.
Efter lanseringen
Några veckor efter lanseringen, gå tillbaka till hypotesen och mätetalet. Det finns tre ärliga beslut: bygga vidare, byta riktning eller avsluta. Vart och ett är en framgång för MVP:n, eftersom det fattades på data och inte på magkänsla.
Planerar du en digital produkt och vill avgränsa den första versionen, se hur vi bygger appar och SaaS.
Låt oss prata om ditt projekt
Det första samtalet tar 30 minuter och är gratis. Efteråt vet du om vi kan hjälpa till och vad det kommer att kosta.
Boka samtal
