Hva er et Minimum Viable Product (MVP)-prosjekt, og hvordan hjelper det informasjonshåndtering?


Hva er et minimum levedyktig produkt (MVP)?
Før vi dykker inn i hva et minimum levedyktig produkt er, la meg spørre deg dette: Hva har de kjente appene Instagram, Uber og Groupon til felles?
Deres tidligste versjoner var mye enklere enn appene vi ser i dag. De har modnet. De har dratt nytte av år med utvikling og store mengder ressurser som er strømmet inn i dem. De ble ikke bare til som de velutviklede appene de er i dag.
Det er en flott metafor for konseptet med minimum levedyktig produkt (MVP). MVP-konseptet er stort i oppstartsfellesskapet der det betyr: en versjon av produktet som kun inneholder funksjonene som lar deg slippe det ut på markedet, som løser et kjerneproblem for et sett med brukere. Målet er å levere umiddelbar verdi og samtidig minimere utviklingskostnadene.
I sin bestselgende bok The Lean Startup sa Eric Ries:
"Minste levedyktige produkt er den versjonen av det nye produktet som lar et team samle inn maksimal mengde validert læring om kunden med minst mulig innsats"
Den vanligste illustrasjonen for hvordan man bygger en MVP på riktig måte er kjøretøyeksemplet.
Men jeg liker godt eksempelet Ravi Vadrevu viser i denne artikkelen . Han destillerer MVP-prosessen ned til tre trinn:
- Start med et enkelt, enkelt produkt som løser en liten del av et stort problem;
- Fortsett å iterere, mens du hele tiden løser større relaterte problemer på vei til å løse det store problemet;
- Fortell hele tiden visjonen om det store problemet som vil bli løst.
Og så utvider han disse trinnene til et spesielt stort problem: Menneskeheten trenger billig, effektiv belysning i mørket .
1. MVP: Brann. Mennesker så lyn sette trær i brann og skapte ild selv med pinner. Men ild er ikke særlig bærbar, før...
2. MVP: Oljelamper, stearinlys og gasslys . Nå kan mennesker bære lys med seg. Men stearinlys og gasslamper lyser ikke, og vinden blåser dem ut, helt til...
3. MVP: glødepærer . Tidlige lyspærer ble drevet av batterier og mer pålitelige enn et stearinlys. Men befolkningen vokste og det var ikke noe strømnett før...
Fjerde MVP: Allment tilgjengelig elektrisitet . Kraftverk og nettet sørger for utstrakt tilgjengelighet av belysning. Men verdens etterspørsel etter strøm vokser for raskt, inntil...
5. MVP: Solenergi . Lav-watt lyspærer spiller inn og solenergi blir billigere å produsere. Det er på en måte der vi er nå inntil solenergi blir mer utbredt.
Du skjønner ideen. Så dette MVP-konseptet er spesielt nyttig for startups som opererer i et veldig magert miljø. De kan rulle ut en MVP på et budsjett, teste den, få tilbakemeldinger og legge til funksjoner som kundene etterspør.
Men en Minimum Viable Product-tilnærming kan også fungere for allerede modne produkter i implementeringen av disse produktene. Er det en bærekraftig tilnærming for informasjonshåndteringsløsninger ? Det tror vi. Her er hvorfor.
Hvordan kan MVP-tilnærmingen brukes til å implementere tekniske løsninger (som informasjonsadministrasjon)?
Da jeg først hørte begrepet Minimum Viable Product, var konnotasjonen litt merkelig. Jeg tenkte: "Minimumsprodukt? Hvorfor vil noen ha minimumsproduktet når de bare kan få hele greia?» Det virket som om sluttkunden ble shortet på en eller annen måte. Men etter hvert som jeg dykket dypere inn i konseptet, innså jeg at det er akkurat det motsatte. Kunden blir ikke shortet. De får akkurat det de trenger med plass til å vokse inn i den komplette produktpakken – alt uten å måtte betale for den suppede Lamborghinien rett fra starten.
La oss tenke på hvordan en MVP-tilnærming kan fungere for implementering av mangefasetterte teknologiløsninger som en informasjonsadministrasjons- eller dokumentadministrasjonsplattform. Med det mener vi dette: en planlagt, faset tilnærming der plattformen kan rulles ut til en bestemt gruppe (som HR eller finans) for å møte deres behov og deretter utvides til andre avdelinger eller hele selskapet senere. En annen måte å fase det inn på vil være å implementere plattformen i en mindre kapasitet som møter kundenes behov og deretter legge til andre muligheter, etter behov.
Det er en riktig måte og en feil måte å gjøre dette på. I stedet for å gi kunden bare grunnleggende funksjonalitet, på bekostning av brukervennlighet, pålitelighet og design, er det generelt bedre å gi kunden en del av dem alle og utvide etter behov.
Det er faktisk enorme fordeler med en trinnvis progresjon for kunden. Les videre for noen viktige fordeler med en MVP-tilnærming til teknologiimplementering.
Sørg for at produktet oppfyller dine behov under reelle forhold
I stedet for bare å se for seg hvordan en informasjonsadministrasjonsplattform kan møte dine behov etter å ha sett en demo, lar MVP en organisasjon faktisk bruke plattformen i sanntid og under reelle forhold. De kan oppleve det og begynne å finne ut om og hvordan det kan være mer verdi å hente med en mer ekspansiv utrulling.
Fokus på nøkkelfunksjonene i produktet
Under implementeringen kan teamet fokusere på funksjonene og egenskapene som beveger nålen mest. De kan begynne å bygge en liste over must-haves og nice-to-haves. Med en trinnvis tilnærming har kunden friheten til å rangere de egenskapene de trenger og ønsker og ta toppen, og legge til etter behov. Så i stedet for å kaste bort ressurser på funksjoner som ingen ville bruke, kan de konsentrere seg om viktige funksjoner som gir maksimal verdi.
Reduser produktkostnad og tid
Hvorfor skulle du kjøpe en Boeing 747, når alt du egentlig trengte å gjøre var å komme deg til matbutikken? En sykkel hadde vært helt greit. På samme måte kan en kunde løse noen problemer uten en enorm investering av tid og penger. Hvis produktet gjør det du trenger, kan du fase inn andre evner eller fase det inn i andre deler av organisasjonen. Kunder kan til syvende og sist skape forretningsfordeler innenfor et realistisk budsjett i begynnelsen. De kan implementere plattformen uten å bruke tre måneder på å lage en massiv plan som kan være irrelevant ved slutten av prosessen.
Iterativ prosess gir mulighet for innfasing av produktet i det tempoet som passer kunden
Ved å implementere et MVP-informasjonshåndteringsprodukt i en del av organisasjonen din, kan du begynne å finne ut hva du liker med det og hvor du kanskje kan utvide bruken av det til andre deler av organisasjonen. Det er vanlig for våre kunder å implementere M-Files inn i deres juridiske avdeling, for eksempel bli forelsket i det, og før du vet ordet av det, fases andre avdelinger inn i produktet.
Siden en minimum levedyktig produktimplementering betyr at kunden vil komme i gang med kjernefunksjoner og funksjonaliteter, lar den dem identifisere de beste brukerbasene i organisasjonen deres og finne de beste brukstilfellene for dem. MVP-tilnærmingen tillater iterasjoner av plattformen - iterasjoner som kommer fra et mer informert sted. Disse fremtidige fasene inkluderer ting som:
- hvilke andre funksjoner å legge til
- hvilke aspekter som vil bidra til å øke avkastningen
- og nøyaktig hvor budsjettet kan tildeles for å få mest mulig verdi ut av plattformen
Se, hvis en kunde vil ha hele settet med funksjoner som følger med M-Files , vil vi absolutt underholde det med dem og hjelpe dem med å finne ut, på en rådgivende måte, om det er det de trenger. Men på slutten av dagen, hvis du vurderer informasjonsadministrasjonsplattformer som M-Files – eller hvilken som helst annen mangefasettert teknologi, for den saks skyld – som fremmer en faset MVP-tilnærming, vet at de har din beste interesse på hjertet. Hvis en leverandør ønsket å selge meg den dyreste versjonen av et produkt med hver eneste funksjon (som jeg kanskje trenger eller ikke trenger), ville jeg bekymret meg for at de var ute etter det store salget i stedet for å se etter behovene mine.