I en trial-and-error-verden er det den, der kan finde fejl hurtigst, der vinder. Nogle mennesker kalder denne tilgang for “fail fast”. Eric Ries kalder det Lean, mens Kent Beck og andre softwareudviklere kalder det Agile.
Hvad man end kalder det, gælder det om at finde ud af, hvilke af ens antagelser om produktet der er forkerte, ved at få feedback fra rigtige brugere så hurtigt som muligt.
Den agile metode forudsætter, at produktudviklingen opdeles i sprints, hvilket gør det muligt at reducere risici og reagere hurtigt på nødvendige ændringer.
Da den agile metodologi er bygget op omkring idéen om en iterativ proces baseret på kundefeedback, spiller MVP’en en central rolle i agil udvikling.
Bygning af et minimum levedygtigt produkt (MVP) hjælper med at levere et nyt produkt med tilstrækkelige funktioner til at tilfredsstille de tidlige brugere, hvilket gør det muligt at få værdifuld feedback og opbygge et komplet sæt funktioner senere.
MVP-konceptet praktiseres for det meste i softwareindustrien for at kontrollere produktets levedygtighed. Hvis du leder efter et firma til at bygge MVP’en for dig, så tjek dette softwareudviklingsfirma.
Den største del af softwaren i dag udvikles ved hjælp af Agile-metodologi. I det agile miljø vil du ofte høre udtrykket minimum viable product (MVP).
Dette udtryk betyder ganske enkelt: den mest minimalt udstyrede ting, du kan bygge, som vil adressere muligheden godt nok for de fleste af dine målkunder og validere dit marked og produkt.
Med andre ord: Hvis du tænker på den kernefunktion, som du forsøger at lade kunderne udføre, hvad er så det enkleste produkt, du kan bygge, som gør det muligt for dem at nå dette mål?
Lad os for eksempel sige, at du gik tilbage i tiden og arbejdede på den første version af en app til en avis. Kernefunktionen for en app ville være at informere sine læsere. Derfor ville det nemmeste produkt, du kunne bygge, være en liste over nyhedsoverskrifter og en knap til at opdatere.
Også nøglen til en vellykket MVP er at fokusere på den kerneværdi, som appen giver, nemlig friske nyheder, i stedet for at bruge din tid på at bygge yderligere funktioner i appen.
Bemærk, at MVP ikke betyder, at produktet skal være dårligt. Sandheden er, at det skal være meget godt til det, det gør, men det skal fokusere på kun at udføre nogle få kernefunktioner.
Som en nøddeskal er de vigtigste karakteristika ved MVP:
- Det har tilstrækkelig værdi til, at folk er villige til at bruge det eller købe det i første omgang
- Det demonstrerer tilstrækkelige fremtidige fordele til at fastholde de tidlige adoptanter
- Det giver et feedback loop til at styre den fremtidige udvikling
Hvorfor skal du bruge en agil metodologi til at udvikle MVP’en?
En vigtig forskel mellem Agile og andre metodologier er, at Agile udnytter MVP’er. Med en agil tilgang bygger du det enkleste, du kan, indsamler data om, hvordan kunderne bruger det, og forfiner derefter produktet om nødvendigt.
Derved kan du arbejde ganske effektivt og kun bygge de funktioner, som kunderne ønsker og vil bruge, i stedet for at spilde tid på at bygge ting, som kunderne er ligeglade med.
Sammenlign dette med ikke-MVP-baserede tilgange til produktudvikling. Med andre tilgange kan man ende med at bruge meget tid på at forsøge at bygge det “perfekte” produkt med alle de funktioner, man kan forestille sig, men når det først er ude i den virkelige verden, opdager man, at kunderne ikke bruger halvdelen af de funktioner, man troede, de ville.
Her er et eksempel på et agilt minimum viable product (MVP):
Kilde: Dropbox
Drew Houston – Dropbox’ administrerende direktør – besluttede sig for at skabe et MVP for den nystartede cloud-lagringsvirksomhed i form af en video.
De lavede en forklaringsvideo og delte den med deres netværk for at måle folks reaktioner. Den 3-minutters video forklarede, hvad Dropbox er, og demonstrerede, hvordan det ville hjælpe folk.
Efter offentliggørelsen af videoen øgede virksomheden antallet af tilmeldinger fra 5.000 personer til 75.000 fra den ene dag til den “tidlige adgang” – alt dette uden at have et egentligt produkt.
Så de vigtigste fordele ved at opbygge MVP’en (agil) er:
- Initial Consumer Research
Desto hurtigere produktet når ud til målgruppen, jo hurtigere får du feedback og analyserer kundens udfordringer eller præferencer. Hvis brugerne ikke finder din MVP værdifuld, har du plads til at dreje og teste de andre værditilbud.
Og hvis det modsatte er tilfældet, er du sikker på, at de udviklede funktioner er nyttige for målkunderne, så du kan gå videre. I værste fald kan du fryse projektet for at begrænse dine tab.
- Testfase
Den største fordel ved at udvikle et MVP er, at det giver mulighed for at teste forskellige forretningsmodeller og koncepter.
Gennem at tilbyde kernesættet af funktioner frem for et produkt med mange funktioner kan du verificere, om deres produktkoncept resonerer med din forretningsmodel, hvilket giver mulighed for at ændre et produkts retning på baggrund af resultaterne.
I modsætning til funktionstunge produkter vil du, når MVP’en er lanceret, have mulighed for at identificere, hvilke typer af sociale grupper der er de mest aktive brugere, hvordan de interagerer med produktet, og hvordan du kan tjene penge på det.
- Kosteffektivitet
Kvalitetsprodukterne er resultatet af mange års udvikling med et passende prisskilt. Men fordi disse produkter er blevet skabt iterativt over en længere periode, er omkostningerne spredt over tid.
MVP-tilgangen er også med til at spare ved at forhindre, at produktet bliver for kompliceret. Efterhånden som produktet begynder at få mere fodfæste og indsamle mere information om, hvilken retning produktet bevæger sig i, kan du øge eller reducere dine investeringer.
Hvis du er interesseret i at lære mere om agile og SCRUM-metodologier, anbefaler vi dig at tjekke denne artikel fra SCRUM Institute om, hvordan du bliver SCRUM-master i en detaljeret trin-for-trin-proces. De tilbyder også de mest populære, og de mest økonomiske Scrum certificeringsprogrammer globalt.
Processen med at bygge MVP (Agile)
Nu, når du ved, hvad en MVP er, hvorfor den bruges i Agile, og hvad fordelene ved den er, så lad os se på de 6 trin, der kræves for at bygge en MVP.
Strin 1: Identificer hvilket problem du løser og for hvem
Når du udvikler en version af nye produkter, er de fleste mennesker ikke tilstrækkeligt stringente i forhold til at definere de problemer, de forsøger at løse, og formulere, hvorfor disse problemer er vigtige. Uden denne proces kan produktet gå glip af muligheder og spilde ressourcer. Derfor skal man blive bedre til at stille de rigtige spørgsmål, så de tager fat på de rigtige problemer.
Se på din produktidé og spørg dig selv:
- Hvem er din målgruppe?
Hvis du går i stå i denne fase, så prøv at identificere dine personlige udfordringer. Er der noget, du ville kunne gøre bedre, hvis du havde det rigtige værktøj?
- Hvorfor har din målgruppe brug for dette produkt?
Dette vil hjælpe dig med at identificere hovedformålet med dit produkt og løsningen på dine potentielle kunders behov.
- I hvilken situation ville de bruge det?
Kilde: Metabeta
Note: I processen med at identificere svarene på ovenstående spørgsmål er det vigtigt at holde alting reelt og lave tids- og omkostningsestimater derudover.
Stræk #2: Analyser dine konkurrenter
Så snart du har fundet ud af, hvilket problem du skal løse, er det tid til at se, hvordan andre virksomheder løser dette problem – eller i det mindste forsøger at løse det. På dette tidspunkt er det indlysende, at du skal foretage en konkurrentanalyse, hvis der findes lignende produkter på markedet.
Du skal også huske på, at selv hvis du ikke mener, at du har nogen direkte konkurrenter, vil din tro på dit produkts unikke karakter danne grundlag for, at du trygt kan bringe dit produkt ud på markedet.
Stræk 3: Definer brugerflowet, Wireframe & Design
Den definition af brugerflowet for dit fremtidige produkt indebærer, at du fokuserer direkte på dit primære mål. For at definere det primære brugerflow skal vi først definere processtadierne, hvilket faktisk er nemt, fordi alt du skal gøre er at forklare de trin, der er nødvendige for at nå dit produkts primære mål.
På dette tidspunkt bør du ikke tænke på funktioner – men bør fokusere på grundlæggende opgaver såsom typer af mål, som dine slutbrugere har, når de bruger dit produkt, deres forventninger osv.
Når du er færdig med at definere brugerflowet, kan du gå videre til wireframing, som simpelthen er en illustration af en webside eller en app. En wireframe er et layout, der formulerer, hvilken slags grænsefladeelementer der skal finde en plads på vigtige sider.
Wireframing Eksempel:
Design af brugergrænsefladen (UI) samler koncepter fra interaktionsdesign, visuelt design og informationsarkitektur. Her skal du udnytte det, du har lært i de foregående faser, for at skabe en oplevelse, der vil overraske og glæde slutbrugeren.
Her hos Cleevio foretager vi brugertest, når vi har den første prototype klar (normalt en klikbar mock-up). Brugertest er afgørende for, om den nye app bliver en succes. Når vi har resultaterne af brugertestningen klar, itererer vi wireframes og tester dem på ny på brugerne.
Når wireframes er testet, bør du gå videre til designfasen, som bør være forskellig for hver platform (iOS, Android, Web,…).
Stræk 4: Analyser dine funktioner
Vidste du, at mere end 45 % af de funktioner, der er indbygget i softwareprodukter, sjældent eller aldrig bruges?
Nu, hvor du har oprettet dit brugerflow, kan du begynde at oprette en mere detaljeret liste over funktioner for hvert enkelt trin, men med statistikken i baghovedet.
Når du har opstillet dine funktioner for hver fase, skal du prioritere dem. Hvad er den vigtigste handling, som du ønsker, at dine brugere skal gennemføre? Det bliver din hovedfunktion.
En af metoderne til prioritering af funktioner er MoSCoW, som bruges til at beslutte, hvilke funktioner der skal færdiggøres først, hvilke der skal komme senere, og hvilke der skal udelukkes. En anden teknik, der bruges til at måle nødvendigheden af funktionerne, er baseret på forretningsværdien (tid til at udvikle vs. nice to have vs. omkostninger)
Kilde: ProductPlan
Stræk 5: Udvikling & Testning
Nu, hvor du kender funktionerne i dit minimum levedygtige produkt (MVP), er det tid til at omsætte dem til praksis. Når du går over til udviklingsfasen, skal du teste dit produkt og arbejde på at forbedre dets kvalitet.
Efter godkendelse af Wireframes skal du begynde at arbejde på opsætningsarkitekturen, databasen og begynde at udvikle API, administration og al back-end.
Alpha- og betatest kan hjælpe her, da det er nogle af de mest populære måder at teste et produkts ydeevne i forskellige scenarier. Sørg for at tilpasse testen og kun foretage de ændringer, der påvirker hele brugeroplevelsen.
Som standard bør du implementere følgende tests i et kontrolleret miljø, før appen lanceres:
- Funktionalitetstestning
- Brugervenlighedstestning
- Kompatibilitetstestning
- Folketestning
- Interfacetestning
- Præstationstestning
- Sikkerhedstestning
Under udviklingsprocessen bør du løbende teste alle de implementerede funktioner.
For eksempel, her hos Cleevio, bygger vi mobilapps, og udgivelser af beta builds uploades til Google alpha/beta testing og til Apples TestFlight. Interne test builds er i Appcenter (et officielt værktøj fra Microsoft).
Når “release candidate” (et produkt, der er klar til markedet) er klar, laver vi åbne eller lukkede betatests, hvor vi inviterer så mange relevante brugere ind i betatestprogrammet, og vi indsamler feedback om funktionalitet og fejl.
Stræk #6: Iterativt komme til produkt-markedstilpasning eller fiasko
Hvis du validerer MVP’en, kan du begynde at se på dit produkts omfang og udvide det. På dette tidspunkt kan du enten rejse startkapital for at hjælpe dig med at komme hurtigere på markedet eller fejle.
For en mobilapp laver vi normalt en “blød lancering”, når vi frigiver MVP’en til AppStore og Google Play, men vi opfordrer ikke til markedsføring af appen på dette tidspunkt.
Når appen får flere brugere, kan der dukke nogle fejl op, og vi er sikre på at rette alting ASAP. Normalt udgiver vi nye builds hver anden dag. Når appen er stabil, og vi har en crash-fri brugerrate på over 99,9 %, anbefaler vi at begynde med markedsføring og skaffe flere brugere.
Data er virkelig vigtigt, og derfor anbefaler vi at overvåge brugernes adfærd med Mixpanel eller Google Firebase analytics, så vi kan forstå, hvordan brugerne virkelig bruger appen.
Udviklingen af produktet er aldrig færdig. Meget vigtigt er at bede om brugerens feedback og iterere produktet. Når vi har flere brugere, udfører vi A/B-tests for at kunne teste forskellige løsninger og øge brugerengagementet.
Kilde: ProductPlan
Konklusion
I Cleevio har vi udviklet over 120 MVP’er i løbet af de sidste 10 år, så vi har nok erfaring i bagagen til at vide, hvilke MVP’er der skalerer, og hvilke der brænder og dør.
Vi ved, at det er lidt overvældende at udarbejde en roadmap, dokumentation eller wireframes til din MVP-idé, så du er velkommen til at kontakte os, så giver vi dig gerne gratis rådgivning.
For et konsulentopkald om din MVP send os en e-mail på [email protected] .