Går du i tankar på att utveckla en MVP? Försök i så fall att undvika de här vanliga misstagen. 

Misstag #1: Förvänta sig en färdig produkt

Ett vanligt misstag är någon i projektets ledning glömmer att man beställt en Minimum Viable Product och istället förväntar sig en helt färdig produkt. Om det finns en uttalad eller outtalad önskan om att få en komplett produkt i handen så går själva idén om en MVP förlorad.

Tanken med MVP:n är att testa om produktens mest centrala funktioner uppfyller kundens behov. Den är alltså bara förstadiet till den färdiga produkten!

För att undvika det här misstaget bör du 1. få en tydlig bild av den tjänst du vill utveckla, till exempel genom att samla kundinsikter eller med en service blueprint, och 2. tydligt definiera från start hur du prioriterar bland alla möjliga funktioner.

En lösning är att utse en produktägare som har fullt mandat att prioritera bland funktionerna (givetvis behöver styrgruppen och produktägaren vara överens om vissa grundläggande begränsningar och prioriteringar). Vilka funktioner som ska ingå in MVP:n bestäms sedan av förväntat affärsvärde och slutkundens önskemål. 

Misstag #2: Utveckla alltför minimalistisk produkt

Ibland händer det att man inkluderar ett “lagom” antal funktioner i sin MVP, men inte de som de flesta kunder faktiskt vill ha. Tänk dig en app för löpare där du kan logga distans, vikt, mat och dagsform men inte vilket tempo du springer i!

Att välja ut rätt funktioner är en av de största utmaningarna med att utveckla en MVP. Men med ett grundligt förarbete så hinner du få användarnas feedback i god tid innan du investerat i fel funktioner. Att samla kundinsikter, användartesta prototyper (se nästa punkt) och jobba efter principen design först är några metoder som kan hjälpa dig på traven.

Misstag #3: Underskatta vikten av prototyper

Prototypen är första “dummyversion” av produkten så att användare och andra nyckelpersoner får något att se, känna och testa på. Prototypen kan till exempel vara en klickbar mockup som ser ut som den färdiga produkten men inte innehåller någon riktig data. Det är ett ovärderligt verktyg för att samla insikter från potentiella användare och omvandla dessa till förbättringar. Att hoppa över eller slarva med prototypen kan därför leda till att man missar avgörande feedback!

Misstag #4: Inte agera på feedback

Att utveckla en MVP är som framgår ovan på många sätt ett experiment. Tanken är att se om en produkt flyger – om den löser användarnas problem och om de är beredda att betala för det. Därför är det viktigt att vara beredd att omsätta feedback i handling.

Det kan visa sig att användarna föredrar andra funktioner än vad du trodde, eller ännu värre – det kan hända att de sågar produkten helt och hållet! Det kan bero på två saker:

  • Bristfällig kvalitet i design eller funktionalitet
  • Produkten gav inte tillräckligt med värde för användarna

I så fall är det bara att återgå till ritbordet. Kom ihåg att en MVP som inte flyger är inte ett misslyckande. Under hela processen har du lärt dig mer om vad dina användare söker, så att du kan backa bandet och fokusera på andra funktioner eller en annan produkt om så skulle behövas.

Misstag #5: Välja fel team

Det är lätt att tro att det bästa teamet är det som levererar exakt det man beställt när man beställt det. Det stämmer bara delvis.

Du behöver visserligen ett snabbt utvecklingsteam med specialistkompetens inom de tekniker som ingår i din MVP. De får också givetvis gärna vara bra på att estimera tidsåtgång och hålla deadlines. Men ett modernt team ska också ha ett agilt förhållningssätt till produktutveckling, det vill säga vara beredda att byta riktning. De måste känna till hur man samlar in feedback från användarna och omsätter detta i rätt funktioner. Ett sådant team måste våga och kunna göra snabba svängar under utvecklingsstadiet.

Om du väljer den första bästa lösningen – till exempel genom att outsourca din produkt till det billigaste teamet du hittar – kan det i längden gå ut över din produkt. Ett kompetent team kostar ofta mer men levererar därefter. Ett sådant team ska kunna kommunicera öppet med dig ifall funktioner eller tidsramar behöver ändras och gör allt för att din MVP ska lyckas.

Misstag #6: Utveckla ineffektivt

Det här går hand i hand med valet av team. Grovt förenklat så finns det två metoder att följa: agila metoder eller vattenfallsmetoden.

Numera råder det i princip konsensus om att agil systemutveckling fungerar bäst. Trots detta krävs det mer för att lyckas med agila metoder än att bara följa rutinerna med stand ups, sprints och så vidare. Du som beställare behöver vara beredd att ta ett större löpande ansvar för din produkt och vara beredd att ta emot feedback från teamet för att fatta beslut om relevanta ändringar i funktioner, budget eller tid.

Kanske behöver du också fundera på hur du skriver ett smart avtal med ditt utvecklingsteam. För att tillåta ett agilt arbetssätt behöver avtalet ge utrymme för de där ändringarna i funktioner, budget och tid – såvida du inte har en deadline som är högsta prioritet.

Nyfiken på MVP? 

En MVP är det perfekta sättet att testa din idé i praktiken! Vill du veta mer om hur det går till? Snart släpper vi vår guide Från hisspitch till MVP – så utvecklar du en digital produkt. Prenumerera på Invativa insikter här så blir du en av de första som får guiden!