Minimum levedyktig produkt: Definer egnethetstypen, metoden og følg enkle byggetrinn

Hvis det var en bok om de mest episke oppstartene mislykkes, ville den ha minst tusen sider. Alle gjør strategiske feil, også slike giganter som Amazon. I 2014 erklærte det et tap på 170 millioner dollar etter feilen av Fire Phone. Årsaken til det var enkel: ingen trengte denne telefonen bortsett fra Amazon. Gadgeten var ment å koble brukere direkte til deres shoppingplattform. Kundene hadde brukt iPhones og Android-smarttelefoner for å koble seg til Amazon. Mangelen på kundeforskning spilte et middel, dyrt triks for Amazon.

Hvis du vil lykkes, må du være sikker på at produktet du skal tilby er akkurat det kundene trenger. Hvordan skal det være? Å utvikle et minimum levedyktig produkt (MVP) kan gi deg svaret.

Hva er en MVP?

Et MVP, eller et minst mulig levedyktig produkt, er den tidligste versjonen av et produkt som bare har nødvendige funksjoner, nok til å levere kjerneverdien og verifisere den til tidlige kunder. I utgangspunktet er MVP distribuert for å samle tilbakemeldinger og se om produktet i det hele tatt er behov for brukere. Tidlige adoptere kan også dele sin visjon om funksjonaliteten, slik at innsikten i kundenes behov og preferanser vil tillate utviklere å justere produktet deretter og planlegge ytterligere oppdateringer.

MVP-strategien gjør det derfor mulig å redusere utviklingskostnadene samt risikoen for økonomisk svikt som følge av å bringe et uønsket produkt til markedet.

Eric Ries, gründer og forfatteren av The Lean Startup, gir en kortfattet definisjon av en MVP som fremhever læringsperspektivet en MVP gir. Ifølge ham er en MVP “den versjonen av et nytt produkt som gjør det mulig for et team å samle inn maksimalt antall validert læring om kunder med minst mulig anstrengelse.”

Det er viktig å forstå at MVP-strategien ikke handler om å bygge et lite produkt for å oppfylle et kortsiktig mål. Teknikken foreslår å utvikle den første, mest forenklede versjonen av et produkt som er tilgjengelig for offentlig bruk. Forbedringene som er gjort i denne versjonen er alltid basert på tilbakemeldinger. Målet med å bygge en MVP er å finne ut hvilke funksjoner og opplevelser produktet skal levere til en målrettet gruppe brukere.

Forskjellen mellom proof of concept (PoC) og MVP

MVP bør ikke forveksles med et bevis på konsept. Det siste kan tolkes annerledes avhengig av bransje.

Først og fremst er konseptbeviset ikke en tidlig versjon av et produkt. En PoC i programvareutvikling beskriver prosesser som tar sikte på å finne ut om programvarekonseptet er teknisk levedyktig. Teamet kan også velge denne tilnærmingen for å bestemme det nødvendige omfanget av arbeid og beste teknologier for utvikling, identifisere mulige tekniske problemer og finne løsninger på dem.

Drew Houston, grunnleggeren av Dropbox, laget og fortalt en forklaringsvideo om hvordan Dropbox skal fungere. Nesten 75 000 mennesker abonnerte på den den første natten. En lignende teknikk kan realiseres via en blogg, der du kan dele ideer med publikum om produktet du ønsker å utvikle. Mens noen anser dette som MVP selv, pleier vi å klassifisere denne forklareren som en PoC.

Betegnelsene MVP og PoC er sammenkoblet, men ikke utskiftbare. Beviset på konsept realisert på en optimal måte blir et minimum levedyktig produkt.

Typer MVPer

Det er mange tilnærminger til å bygge en MVP. La oss diskutere hovedtypene.

The Wizard of Oz (noen kaller det også Flinstone MVP). De to navnene for denne typen levedyktige minimumsvarer er for arbeidsprinsippet. Akkurat som Flinstones ønsket å skape en illusjon om at de har en ekte bil og trollmannen fra Oz brukte triks for å late som om det er et gigantisk grønt hode, en fe, en ildkule eller et monster, synes denne typen MVP bare å være fullstendig funksjonell. I virkeligheten gjør en startupper hele jobben manuelt i stedet for å bruke et programvaresystem, eller et team blir ansatt om nødvendig. Det er ingen underliggende programvare i det hele tatt, men et produktkonsept som krever bekreftelse.

Nick Swinmurn, grunnleggeren av Zappos, har bevist at denne strategien fungerer. I begynnelsen brukte han null dollar på skokjøp og lagerleie. Han la ut skobilder på et nettsted. Når kundene begynte å bestille sko, gikk han til en butikk, kjøpte det nødvendige paret og sendte det. Etter å ha innsett at prosjektet er levedyktig, la han til funksjonalitet på nettstedet.

Concierge MVP. Gründere som velger en concierge MVP tilbyr også praktiske tjenester. Men i dette tilfellet vet en kunde at en ekte person står bak en levert tjeneste. Wealthfront, en tjeneste for økonomisk planlegging og investeringer, startet fra en concierge MVP. Wealthfront-arbeidere kommuniserte direkte med klienter som trengte hjelp til styring av formue. En annen viktig forskjell fra Wizard of Oz er at portvakttypen er rettet mot å generere ideer om fremtidens produkt, tilby tjenester, kommunisere med kunder osv., I stedet for å verifisere dem.

Piecemeal MVP. Ideen med stykkevis er å levere verdi ved å bruke eksisterende verktøy i stedet for å bygge en tilpasset løsning. En produktprototype ser imidlertid ut som et komplekst produkt. Du kan bruke enkel programvare, sette den sammen og legge til nødvendig funksjonalitet etter at du har fått tilbakemelding. Groupon er et flott eksempel på en stykkevis MVP. Grunnleggeren, Andrew Mason, lanserte et WordPress-nettsted og la ut bilder manuelt av måltider manuelt hver dag. Han genererte tilbud som PDF-dokumenter ved hjelp av AppleScript og mailet dem via Apple Mail. Slik validerte han Groupon-hypotesen.

Et produkt med en funksjon. Og til slutt, en MVP kan være den virkelige programvaren med det minste minimum av funksjoner, bare de viktigste som er nødvendige for bekreftelse. Med sin hjelp vil du kunne begrense en målgruppe, motta og analysere tilbakemeldinger og konsentrere deg om testing.

Men uansett type du velger, er det flere hovedtrinn å følge for å lage en MVP.

Fremgangsmåte for å bygge en MVP

Et produkt starter alltid med en idé. Det som skiller et vellykket produkt fra et uforutsett produkt er at et populært produkt er et resultat av en gjennomførbar idé transformert gjennom en grundig utviklingsplan.

Vi tilbyr en trinn-for-trinn-guide for hvordan du validerer ideen din og gjør den til et produkt. Du vil være klar til å begynne å bygge en MVP i syv trinn. Trinn null er en introduksjon til hovedprinsipper og teknikker. Åttende og niende trinn handler om prosjektledelsesmetoder du kan bruke og hvordan du kan teste et produkt.

Trinn 0. Erkjenn de grunnleggende MVP-prinsippene og -teknikkene

Før et faktisk arbeid, er det verdt å bruke litt tid på å skissere de grunnleggende MVP-prinsippene og -teknikkene, og deretter sørge for at teamet ditt følger dem gjennom hele prosessen. Følgende punkter er kritiske for alle faser i MVP-initiativet ditt.

Prøv å bruke så lite penger og krefter som mulig. Hele ideen om en MVP er å kutte tiden og ressursene som er nødvendige for å bekrefte forretningsidéen din. Identifiser den enkleste typen MVP som er tilstrekkelig til å generere tilbakemelding og holde seg til den.

Fokuser på å bygge bevissthet. Utnytt så mange mediekanaler som mulig for å sikre at du har et kritisk antall tidlige adoptere. Dette kan gjøres innenfor PoC-aktivitetene dine.

Prøv å forhåndsselge produktet. Du kan bruke Kickstarter, andre crowdfunding-plattformer, eller direkte selge produktet for å oppfylle to hovedmål. Den første og viktigste er å få tilbakemeldinger, og den andre er å investere disse pengene i videreutvikling. Du kan se om folk liker produktets konsept i utgangspunktet.

Intervju kunder hele tiden. Uavhengig av trinnet du går i, invester tid på å intervjue potensielle kunder for å starte justeringer så tidlig som den første wireframe og fortsette aktivt å intervjue til du går over fra MVP-scenen til versjon 1.0. Etter det bør du fortsatt følge denne praksisen, men forbedre den med A / B-testing og andre avanserte verifiseringsmetoder. Du kan bruke undersøkelsesformer online eller snakke ansikt til ansikt. Å formulere de riktige spørsmålene vil ikke bare hjelpe deg å lære om problemene som plager brukerne, men også finne ut om de er verdt å løse. Spør hva som forstyrret dem mest når de møtte problemet og hvorfor, når de sist opplevde det. La dem fortelle deg hvordan de prøvde å løse problemet og hva de ikke likte med løsningene de brukte.

Sett opp en tilbakemeldingssløyfe. Tilbakemeldingene du får enten gjennom intervjuer eller andre kanaler, bør være systematiske og ha reell, kortsiktig innvirkning på produktet ditt. Hold oversikt over all tilbakemelding, generaliser og konverter ideer du mottar til konkrete oppgaver for teamet ditt.

I tillegg til prinsipper, for å sette en tilbakemeldingssløyfe, bør du vurdere hovedkanalene for å la brukerne prøve produktet og gi midler til å dele ideer og bekymringer.

Lag en destinasjonsside. Siden skal inneholde beskrivelsen av produktet og dets funksjoner samt et påmeldingsskjema med gratis og betalte løsninger. Med landingssiden kan du definere optimal prisfastsettelse for produktet ditt.

Bruk sosiale medier. Slike plattformer som Facebook, Reddit og YouTube vil være de mest enkle kildene til innsikt, gitt at du har fått nok oppmerksomhet. Vi anbefaler også å bruke bloggeverktøy, enten eide eller offentlige, som Medium.

Start en annonsekampanje. Du kan bruke slike plattformer som Google, Facebook og Twitter for å se om MVP når sin målgruppe. Disse annonseringsplattformene har veldig fleksible og detaljerte segmenteringskapasiteter, så du kan teste personasens hypoteser ved å målrette mot flere smale brukersegmenter.

Trinn 1. Definer et problem du vil løse

Det første du bør gjøre er å artikulere produktets formål. Prøv å svare på spørsmålet "Hva trenger jeg dette produktet til?" Når du tydelig har kommunisert verdien med et produkt i flere ord, kan du gå videre til neste trinn. For eksempel, hvis du ønsker å åpne en levering av måltider, kan problemet du vil løse høres slik ut: "Tillat brukere å få måltider fra lokale restauranter å gå."

Trinn 2. Definer målgruppen og begrense den

Å prøve å tilfredsstille den bredeste gruppen mennesker er en feil. Øk sjansene dine, og velg et bestemt publikum du vil tilby produktet ditt til. Lag en fullstendig beskrivelse av en person som ikke bare vil like produktet ditt, men også vil kjøpe det uten å nøle. Du bør vite hvor gammel og hvor utdannet denne personen er, hva han eller hun gjør for å leve, og hvilket opptjeningsnivå denne jobben gir ham eller henne. Vaner og hobbyer vil fullføre en beskrivelse av en potensiell kunde. For å lære mer om hvordan du lager personlige kjøpere, sjekk historien vår om å starte en SaaS-virksomhet.

Kunnskapen om kundens livsstil lar deg finne ut om fremtidens produkt stemmer overens med det eksakte problemet han eller hun står overfor.

Trinn 3. Evaluer konkurrentene

Ikke overvurder eksklusiviteten til produktet ditt, spesielt ikke når du vet at det er andre selskaper i din bransje. Evaluer konkurrentene dine. Finn ut de sterke og svake punktene dine for å definere funksjonaliteten til ditt fremtidige produkt. Du kan også gruppere dem etter måten de konkurrerer om markedsandeler.

Definer konkurrentene og merverdien de gir. Analyser hvem de tre beste rivalene dine er, hvor lenge de har vært i markedet, hvilke produkter eller tjenester de tilbyr. Definer om de har et konkurransefortrinn og estimer din evne til å tilby noe bedre.

Finn deres markedsandel. Du bør forske på tidligere og nåværende strategier, salgsvolum, inntekter, økonomiske og markedsføringsmål. Disse dataene vil hjelpe deg å forstå hvor lønnsomme og vellykkede de er.

Bruk primære og sekundære informasjonskilder. Informasjonen selskapene deler om seg selv er den mest pålitelige, primære kilden for analyse. Besøk nettstedene deres for å lese presentasjoner, meldinger, årsrapporter, blogger, reklamemateriell og andre publikasjoner. Sekundære informasjonskilder, som magasin- og avisartikler, videoer, undersøkelsesrapporter og bøker, representerer opinionen om spillerne. Selv om disse kildene kanskje er mindre pålitelige enn primære, kan de gi deg et større bilde av bransjen.

Grave dypere. Ikke nøl med å besøke forretningsbegivenheter som konkurrenter deltar i, ta kontakt med sin tidligere arbeidsgiver og selvfølgelig bruke produktet og analysere tilbakemeldingene på det.

Bruk analytisk programvare. Ulike online verktøy for konkurransedyktig analyse vil gjøre livet ditt enklere. Slike tjenester som Similar Web, Ahrefs, Quantcast, App Annie eller AppFollow samler inn data om nettsteder og apper. Med dem kan du finne rangeringen til konkurrentens app eller et nettsted, den månedlige trafikken, publikumsinteresser, geografiske beliggenhet for kunder og se relaterte produkter.

Noen av de eksisterende verktøyene gir grunnleggende funksjonaliteter gratis. De andre, som Moz og SensorTower, er abonnementsbaserte.

Når du kjenner viktige markedsaktørers svakheter og styrker, vil du kunne vite hva som gjør produktet ditt unikt eller hva det mangler for å bli det.

Trinn 4. Gjør SWOT-analysen

SWOT står for styrker, svakheter, muligheter og trusler. Selv om rammene vanligvis brukes i strategisk planlegging for modne selskaper, er det enkelt nok til å brukes til å kvalifisere MVP-ideen. For å utføre SWOT-analysen, må du svare objektivt på en serie spørsmål relatert til de ovennevnte kategoriene. La oss se på hvordan SWOT-analysen kan se ut for eksempelet for levering av måltider vi nevnte ovenfor.

Den beste fremgangsmåten for SWOT-analysen er å holde beskrivelsene korte og enkle å forstå for alle teammedlemmer

Målet med SWOT-analyse er å fokusere innsatsen på styrker, definere og minimere svakheter, unngå trusler, samt å bruke eksisterende muligheter for videre utvikling. Styrker og svakheter er vanligvis knyttet til interne faktorer. I sin tur er muligheter og trusler de eksterne.

Det hjelper også selskaper med å analysere konkurrenter og velge markedsposisjonering.

Trinn 5. Definer brukerflyten

Brukerflyt er en vei en bruker tar for å oppnå sitt hovedmål når han bruker et produkt. Og denne veien må være logisk og tydelig.

Brukerflyt er en veiledning for innhold og designkrav for et nettsted eller app. Du bør forstå hva kundene forventer å få mens du bruker produktet ditt for å bygge en god brukerflyt. Forsikre deg om at du gir brukerne litt tilleggsinformasjon hvis de trenger det, og finn ut mulige avvik som kan hindre dem i å gå til et neste trinn.

Som et eksempel, la oss liste oppgaver brukerne må ta for å oppnå et primært mål vi uttalte i trinn 1, få måltider å gå fra lokale restauranter. Brukerflyten vil være: tilpasse ordre, administrere ordre, betale for et måltid, motta bestillingen. Etter at trinnene er bestemt, er det på tide å definere funksjoner for hver av dem.

Trinn 6. Lag en liste over funksjoner og ordne dem i henhold til deres prioritet

Du må liste alle nødvendige funksjoner for fremtidig produkt. Historiekartlegging (eller brukerhistorikkartlegging) teknikk vil hjelpe deg på dette planleggingsstadiet. For øvrig gjenspeiles det i brukerflyteksemplet ovenfor.

Historiekartlegging er en todimensjonal tilnærming til å håndtere brukerhistorier. Det gjør det mulig å konsentrere seg om deler av funksjonalitet og samtidig ikke miste det store bildet av et produkt.

Teknikken ble laget for å hjelpe utviklere med å velge både nyttige og verdifulle funksjoner først og fremst fra brukerens synspunkt. Dets forfatter og utøver, Jeff Patton, antyder at en funksjonsbeskrivelse bør inneholde en handling utført av en person i stedet for midlene til implementering.

Vi har listet opp fire trinn som brukere gjør for å løse problemet ved hjelp av vårt produkt: tilpasse en ordre, administrere ordren, betale for et måltid, motta bestillingen.

Nå må vi beskrive funksjoner for hvert trinn og skrive dem ned på kort.

For å tilpasse en ordre, kan en bruker for eksempel:

  • Velg hvor hun eller han bor
  • velg et kjøkken
  • Velg restaurant
  • velg en tallerken
  • velg en drink
  • les beskrivelsen av et valgt element
  • legg bestillingen i en handlekurv

Etter at du er ferdig med beskrivelser, tegner du en horisontal rad som viser brukerflyten, plasserer de viktigste trinnene på kartet og funksjonene deres.

Funksjonene er ikke prioritert på dette stadiet ennå

La oss prioritere funksjoner. Du bør finne ut hvor viktig og verdifull funksjonen er, hvor ofte funksjonen brukes, hvor mange brukere som vil bruke den, og hvor risikabel den er.

Når du har ordnet funksjoner i henhold til prioriteringen, tegner du en vertikal linje og plasserer dem der de hører hjemme. De viktigste og ofte brukte bør være øverst på listen, minst - nederst.

Prioritering vil bidra til å definere omfanget av en MVP

Trinn 7. Definer omfanget av MVP

Etter at du har prioritert funksjonene, kan du definere omfanget av MVP. Den første horisontale raden på et kart kalles et vandrende skjelett. Det gående skjelettet er den minste anvendelige versjonen av et produkt som mangler kjøtt, dvs. funksjonalitet. Vi bør bygge et vandrende skjelett først.

I noen tilfeller faller MVP sammen med et vandrende skjelett; noen ganger har MVP en viss funksjonalitet. For å forstå hva skillene er mellom vandrende skjelett, et minst mulig levedyktig produkt, og dets videre konsept, bør du kategorisere funksjoner under overskriftene must-have, nice-to-have og vil ikke ha.

Tegn nå en linje for å skille kjernefunksjoner fra ikke-viktige funksjoner. Funksjonene du gir høyest rangering representerer MVP. Resten av dem kan legges til etter implementering av MVP og tilbakemeldingsanalyse.

Ettersom funksjoner blir prioritert, er du god til å starte prosjektering

Trinn 8. Velg den best egnede styringsmetoden og konstruer en MVP

Med et definert arbeidsomfang kan du endelig begynne å utvikle et levedyktig minimumsprodukt. La oss nå finne ut hvilke prosjektstyringsmetoder som er aktuelle for å bygge en MVP.

Lene seg. Lean er en av Agile programvareutviklingsmetoder som er basert på flere kjerneprinsipper: eliminere avfall, levere så raskt som mulig, forsterke læring og bygge integritet i. Praktisk anvender Lean iterativ utvikling med build-measure-learning-mønsteret. Med Lean kan utviklere utsette de fleste av designvedtakene, sette en rask tilbakemeldingssløyfe og sørge for at de bygger et etterspurt produkt.

Scrum. Scrum er en annen iterativ tilnærming til programvareutvikling. Det er avhengig av effektiv arbeidsdeling, som hjelper team å levere raskere. Du kan administrere utviklingen av funksjoner for MVP i spurter (korte sykluser om to og fire uker lange) og ansette en scrum-master som vil føre tilsyn med å holde hele Scrum-prosessen i gang. MVP kan bli utgitt etter den første sprinten, og utviklingsteamet kan oppdatere produktet i henhold til brukernes tilbakemeldinger i alle påfølgende sprint. Selv om Scrum er mer tidkrevende enn Lean, kan det være mindre stressende for ingeniører og passer til langsiktig, trinnvis utvikling.

Kanban. Kanban fokuserer på den fremdriftsmodellen, og i motsetning til Lean og Scrum har ikke syklisk progresjon. I stedet foreslår Kanban å fokusere på oppgaver slik de ser ut. Dette gjør det mulig å justere omfanget av arbeid med teamets kapasitet. I utgangspunktet kan ingeniører kontinuerlig legge til oppgaver til en rørledning når de får tilbakemeldinger fra brukere. Kanban kan brukes etter at den første versjonen av MVP er utgitt. Det vil være en kraftig metode hvis tilbakemeldinger pågår.

Ekstrem programmering. XP er et sett med ingeniørpraksiser, for eksempel kodefaktoring, små utgivelser, enkel design, kodingsstandarder, som gjør det mulig å forbedre koden og oppgradere den innen kortest mulig tidsramme. Utviklingssykluser med XP overstiger ikke en uke, så du kan levere den første versjonen raskt og deretter skalere. XP vil passe godt for MVP-er som er veldig avhengige av kodekvalitet.

Å velge en av de iterative utviklingsmetodene er kritisk, ettersom det lar deg bygge en jevn feedback-loop.

Trinn 9. Bruk Alpha- og Beta-testing

Alpha er en såkalt interntest: En begrenset gruppe mennesker, hovedsakelig venner og familiemedlemmer, evaluerer et produkt. Hvis et produkt har bestått denne testen, kan du gå videre til en betatest og la de virkelige brukerne prøve et produkt i en til to uker. Analyser tilbakemeldingene og bestemme hvilke funksjonaliteter du trenger å legge til eller erstatte for å gjøre produktet bedre og mer komplekst.

Etter at du har samlet nok tilbakemeldinger, kan du begynne å oppgradere produktet, teste det og samle tilbakemeldinger igjen. Antall og tidsrammer for bygg-test-læringssykluser avhenger av produktet. Etter at du har fullført flere sykluser, kan du enten gå tilbake til trinn 0 og svinge eller fortsette å forbedre deterativt produktet.

Endelig råd

MVP spiller rollen som en kollisjonspute og gir en mulighet til å forutsi et kommersielt og teknisk potensial for et produkts visjon, så vel som implementering. Det gir deg muligheten til å ta forretningsmessige og tekniske beslutninger basert på fakta snarere enn forutsetninger. Derfor er å teste konseptet eller produktet i markedet det viktigste målet for å bygge en MVP.

Opprinnelig publisert på AltexSofts blogg: "Minimum levedyktig produkt: Definer den beste passformen, metoden og følg enkle byggetrinn"

Denne historien er publisert i The Startup, Middels største entreprenørskapspublikasjon fulgt av 292.582+ personer.

Abonner for å motta topphistoriene våre her.