I detta kapitel diskuteras resultaten som beskrevs i föregående kapitel. En jämförelse mellan projektgruppens MVP och respektive företags MVP kommer att göras. Det kommer även diskuteras om hur utvecklingsprocessen kan har formats av gruppens mål av att skapa en
A.6. Diskussion
MVP och till sist kommer en diskussion föras om vilket värde kunden kan ha haft av att använda gruppens MVP.
A.6.1
Jämförelse med MVP:er gjorda av företag
Ser man till de MVP:er som togs upp i föregående kapitel kan man se likheter med Grou- pon och Dropbox och deras MVP-versioner. Skissen som projektgruppen gjorde och visade för kunden kan likställas med Dropbox informativa video. I båda fallen hade varken projekt- gruppen eller Dropbox en fungerande version av programmet att visa sina kunder, men båda lyckades ändå dra lärdomar av att visa ett koncept på hur deras program eller tjänst skulle fungera. Den senare versionen som levererades till kund kan jämföras med Groupons tidi- ga MVP. I detta fall hade visserligen Optily kommit mycket närmare en färdig slutprodukt, men båda visade upp en version av sin tjänst som innehöll grundläggande funktioner. Ingen direkt likhet kan ses med Food on the Tables MVP där grundarna manuellt utförde tjänsten. Denna form av MVP är heller inget gruppen skulle tjäna på. Grundarna av Food on the Table utförde denna variant av MVP för att få en första kund och för att se om idén höll. I projekt- gruppens fall fanns redan kunden och problemet var redan ett definierat sådant. Man skulle kunna se det som att Ionbond själva gjorde den MVP:n då detta var sättet de arbetade förut. De optimerade mer eller mindre manuellt, visserligen med hjälp av ett Excelark, var objekten skulle placeras.
Den största skillnaden mellan företagens MVP:er och projektgruppens MVP var att fö- retagen använde sina MVP:er som investeringsstöd vilket inte var fallet för projektgruppen. Projektgruppen hade inget behov av något monetärt stöd för att fortsätta sin utveckling och till skillnad från företagen var gruppens insats mycket lägre. Behovet av projektgruppens produkt var redan säkerställt vilket det inte var för företagen. Företagen gick in med mycket högre insatser där eventuell återkoppling potentiellt skulle kunna tvinga dem att helt och hållet byta riktning. I och med att de inte utvecklade på beställning av en kund fanns det en möjlighet att marknaden inte alls var intresserade av deras produkter. Detta är inte något som skulle kunna hända projektgruppen då kunden beställt produkten till ett etablerat pro- blem. Det värsta som skulle kunna hända projektgruppen var ett missförstånd i tolkningen av problemet vilket skulle kunna leda till att projektgruppen behövde fundera över ett nytt implementeringssätt. Det är här den stora skillnaden mellan en klassisk startup och projekt- gruppen finns, dvs. den extrema osäkerheten en startup opererar i var inget gruppen behövde göra även om det till viss del fanns osäkerhet även för gruppen.
A.6.2
MVP:ns påverkan på utvecklingsprocessen
Att utvecklingsprocessen såg ut som den gjorde känns som en naturlig konsekvens av att ha målet av att skapa en MVP. I och med att man med en MVP vill försöka få en minimal produkt där alla grundläggande funktioner finns med trots att de inte behöver vara välpole- rade är det rimligt att gruppen gjorde som de gjorde under utvecklingsprocessen, nämligen att varje gruppmedlem tog på sig ett huvudområde inom programmet. Varje gruppmedlem blev således expert på just sin del av programmet. Detta betydde inte att gruppmedlemmar- na inte hjälpte varandra då de stötte på problem, men huvudansvaret för ett område låg hos en enskild gruppmedlem. Detta var inte formellt bestämt utan föll sig naturligt. Genom det- ta sätt att arbeta fick gruppen vid varje sprints slut funktionalitet från många olika delar av programmet. Trots att denna inte alltid var helt komplett bidrog detta till att funktioner från varje del av den tänkta slutprodukten infördes efter varje sprint. Att arbeta på detta sätt bi- drog till ett väldigt välstrukturerat arbetsflöde. Att arbetsflödet var välstrukturerat är något som Scrum-metodiken bidragit med, men att arbetsuppgifterna hade den breda spridningen är en direkt påverkan av att gruppen ville skapa en MVP efter varje sprints slut.
A.6.3
MVP:n värde för kunden
Något direkt applicerbart värde av skissen som kan ses i figur A.1 finns inte sett ur kundens perspektiv eftersom det bara skiss på ett papper. Det är inget som kunden direkt kan använda sig av för att lösa sitt problem. Det värde som skissen kan ha gett är en slags försäkran att projektgruppen har förstått problemet kunden hade och att de har designat något som ser ut att lösa detta problem. Kunden fick som tidigare nämnts en genomgång av skisserna och hur det var tänkt att de skulle relatera till slutprodukten. Att ha visat upp skissen för kund och fått den godkänd har haft ett betydande värde för projektgruppen då detta tjänade som en utgångspunkt att börja utveckla ifrån. Värdet som kunden fick av att börja använda den tidiga versionen av Optily var mycket större än av skissen. Då denna version av Optily ändå var relativt nära den slutgiltiga versionen kunde kunden faktiskt börja använda programmet i sin dagliga verksamhet. Att börja använda programmet gav kunden möjlighet att enkelt få en känsla av hur det skulle vara att använda den slutgiltiga versionen av programmet. Det gav dem även möjligheten att inse saker som de önskade att programmet skulle kunna göra som var svårt för dem att tänka på då programmet diskuterades i teorin. Att börja använda MVP:n gav alltså kunden chansen att ge mer direkt återkoppling som i sin tur gjorde att de kan få ett mer skräddarsytt program som passar just deras arbetsflöde.