Der er mange mulige tilgange til lancering af et nyt produkt, og lige så mange forhindringer undervejs. Der er dog en måde at vurdere chancerne for succes, før du dykker i fuldt engagement, og det er her Minimum levedygtigt produkt (MVP) kommer ind.
Hvis du bare vil vise folk den første version af dit produkt, eller du vil få en forståelse af, om din forretningsidé løser et reelt problem, er oprettelse af en MVP vejen at gå. Det giver dig mulighed for at Undgå uønskede scenarier såsom at spilde tid og penge, og du vil helt sikkert Spar måneders indsats bevæger sig i den forkerte retning.
Lad os se på, hvad en MVP er, og fordelene ved at opbygge en.
En MVP er en softwareudviklingsteknik, først brugt af den amerikanske iværksætter Eric Ries, der forsikrer en første arbejdsversion af produktet, med alle de nødvendige krav for at få det til at opfylde sit hovedmål. Det er værdifuldt for brugerne, som det er, og har meget plads til forbedring gennem et sæt funktioner, der ikke overvejes til den oprindelige version, men kan implementeres på et senere tidspunkt.
MVP er et koncept, der er så udbredt, og alligevel, så svært at få ret. En MPV er ikke en prototype, og det er heller ikke en pre-lanceringsversion af et produkt. Det er ikke en betaversion af nogen art, og det går ikke forud for Det rigtige produkt. I softwareudvikling er det heller ikke mest værdifulde spiller, som har den samme initialisme, men den bruges i helt forskellige områder.
Den Hovedmålet med MVP er at teste markedet og få feedback til yderligere produktforbedring. Ved at vide, at indsatsen for at opbygge en MVP er meget mindre end hvad der ville være nødvendigt for at implementere alle de oprindeligt overvejede funktioner, er alle resultater positive, selv i værste tilfælde scenarier.
Hvis brugerne vedtager produktet med det samme på dette tidspunkt, opretter du et fællesskab omkring det og får plads til yderligere forbedringer med mindre pres. Samtidig vil de samme brugere være dem, der påpeger, hvad de mener, produktet mangler, hvilket giver værdifuldt input til den næste runde af forbedringer. Du kan derefter planlægge i overensstemmelse hermed og endda ridse et par funktioner, der blev tænkt inden lanceringen af MVP, i nogle tilfælde.
I det uønskede scenarie, hvor produktet ikke er vedtaget eller ikke tjener sit formål, vil det stadig give værdifuld indsigt i enten at tilpasse eller droppe produktet i henhold til den indsamlede feedback. Måske var det et UI- eller UX-problem, eller måske blev problemet, som produktet skulle løse, fejlbedømt. Derudover er der også eksterne faktorer, der påvirker resultatet af en produktlancering. Med så meget, der muligvis kan gå galt, er der ingen grund til ikke at spille det sikkert fra starten.
I et af ovenstående tilfælde viser det sig at opbygge en MVP at være det bedste valg. Det kan altid afhænge af det tilgængelige budget og af forretningsmål, men ikke desto mindre er MVP ikke en teknik, der kun bør bruges til korte budgetter. Små startups gør det lige så meget som store virksomheder, og det er altid mere et spørgsmål om strategi end det er om pålagte begrænsninger.
Men hvordan begynder man at opbygge en MVP?
Det hele starter med design. At gå direkte fra idé til implementering med minimal indsats på design viser sig normalt at være en meget dårlig idé, uanset projektets art. Det er ikke sådan, at du bare kan få nogen til at male et dejligt lag oven på prototypen, når den er klar og kalde det „designet“.
Når du arbejder med produktdesignere, forstår du, at de er mere som arkitekter end malere. De har brug for støtte fra ingeniører for at designe, men den mest kreative del af deres job er ikke, hvordan produktet vil se ud, men snarere hvad det skal gøre, og hvorfor. Og indtil faktiske brugere bruger produktet, arbejder alle med antagelser (nogle har måske bare mere nøjagtige antagelser end andre).
Med dette i tankerne kan vi prøve at besvare spørgsmålet: skal en MVP være hurtig og nem at gennemgå en reality-check? Hvis du har teamet, der er i stand til at levere det på tre dage, hvorfor gøre mere? Hvis ideen viser sig at blive hilst velkommen af folk, har du tillid og fuld tillid til at investere i 3 måneders indsats og kontanter.
Derefter har du brug for penge til at fortsætte med at vokse til Fuldt produkt, hver gang du øger brugerbasen og ikke bare sidder på dit kontor med hypoteser. Samtidig vil produktdesigneren være i stand til at observere, analysere og fortolke de beviser, du indsamler fra realitychecken, for at hjælpe dig med at investere din tid og penge klogt.
Hvis du tror, at det er umuligt at teste din idé om 3 dage, tager du fejl. Hvad du har brug for er ikke et fuldt funktionelt produkt, men blot et bevis på, at din idé vil skabe en vis interesse, hvilket er noget, der kan opnås med en brøkdel af, hvad du synes, dit produkt skal gøre.
For det andet, uanset hvor genial din idé er, skal implementeringen foregå og styres af en rigtig produktdesigner. Godt design hjælper dig med at fjerne fedtet i ideen, forstå kernen i dit værdiforslag og levere en elegant løsning til at teste den hurtigere.
Husk: Mere design betyder mindre udvikling, og det er normalt fokus for MVP. Det handler ikke om at stable funktioner oven på hinanden, men at koncentrere indsatsen om, hvad der virkelig betyder noget for at frigive et fungerende produkt, der opfylder et specifikt mål.
Der er mange måder at planlægge et MVP-projekt på, men her vil jeg fokusere på en bestemt metode: Scrum, som er afbildet nedenfor.
Konceptet blev introduceret af Hirotaka Takeuchi og Ikujiro Nonaka i forbindelse med produktudvikling i 1986, og det har lidt flere mutationer i de følgende årtier. Kort sagt, det er en proces, der sigter mod at levere små produkt-iterationer over tid, i stedet for at gennemgå hele produktudviklingen i sin endelige version, før den leverer nogen værdi. Det er normalt relateret til Agile udviklingspraksis.
Lad os nu se, hvordan vi kan tilpasse det til opbygning af en MVP.
Produktbackloggen og opgavelisten i venstre side af billedet præsenteret før repræsenterer de forskellige funktioner, du vil implementere på dit produkt. Disse vil blive overvejet på flere sprints, der forekommer i faste tidsrammer bagefter. Afslutningen af hver sprint genererer feedback, der vil blive brugt som input til næste runde, og det vil ske så mange gange, som det er nødvendigt for at fuldføre projektplanen.
Forestil dig, at målet med den første sprint er at opbygge en MVP. Produktet sendes som det er, og opdateres efter samme proces i henhold til fastlagte prioriteter i projektplanen. Den største fordel er den regelmæssige levering af værdi inden for korte tidsrammer og chancen for at reagere hurtigt på ændringer.
Gentagelse af denne proces vil i sidste ende føre til projektets afslutning med flere runder med feedback imellem. Dette er en af de vigtigste egenskaber ved en MVP. Det giver dig mulighed for at have flere kontrolpunkter at gå tilbage til, hvis noget går galt, og samtidig belønner du brugerne gradvist over tid med produktforbedringer baseret på deres behov.
Dette er blot en af mange mulige ruter til at bygge en MVP og arbejde derfra, og den, vi tager til udvikle digitale produkter os selv. Det er baseret på en Agile tankegang, hvor målet er løbende at levere værdifuld software i trin. Andre muligheder er tilgængelige, men de ideer, der understøtter projektet, vil være meget ens i alle tilfælde. Det er op til dig at vælge den, der bedst passer til dine behov.
Glæder du dig til at bygge et nyt produkt? Angiv din forretningsmæssige målTænk på de forskellige strategier som vil gøre det muligt for dig at komme derhen, hvor du vil være og stærkt overvej at tage MVP-ruten.
De vigtigste fordele, der kommer fra det, er Reduceret risiko og indsamling af feedback, og begge vil give dig mulighed for bedre at planlægge de følgende trin. Det er ikke konsekvensen af ikke at have nogen anden mulighed, det er en forretningsstrategi i sig selv, og mange succesrige virksomheder fortsætter med at gøre det som en måde at teste markedet på, før de går all-in.
Det hele starter i design, da det er det vigtigste skridt i opbygningen af en MVP. Produktdesignere vil være i stand til at trimme fedtet og holde produktet til dets væsentlige, før de går videre til udvikling. Projektplanen ender dog ikke i MVP, da det normalt er det første skridt i en meget større proces.
Bundlinjen er, at du altid kan drømme stort, men du skal starte med begge fødder på jorden. Et minimum levedygtigt produkt er et løfte om noget Større og bedre, og at droppe projektet efter dets afslutning ville være en fejl så alvorlig som slet ikke at frigive en MVP.
Baseret på en artikel oprindeligt skrevet af Nicholas Mandelbaum for Imaginary Cloud
Fandt du denne artikel interessant? Du kan måske også lide disse!
Indholdsadministrator, teksteditor, og præsentator for strategiske ideer, sammen med at være en ivrig fan af filmkunst og visuel historiefortælling.
People who read this post, also found these interesting:
