Minimum levedyktig produkt (MVP)

Et minimumsviabelt produkt er den minste versjonen av et produkt som lar et team lære noe essensielt om hvorvidt kundene ønsker det, popularisert av Eric Ries i The Lean Startup. Den definerende egenskapen er ikke at det er lite eller billig, men at det er bygget for å svare på et spesifikt spørsmål, og at spørsmålet gjelder validert læring om kundeatferd snarere enn intern mening om gjennomførbarhet.

Den mest vedvarende misbruken er å behandle det som et synonym for en førsteutgivelse med færre funksjoner. Under tidsfristpress kutter teamene omfanget, sender ut noe ufullstendig, kaller det en MVP, og måler deretter ingenting spesielt, noe som verken gir et godt produkt eller en nyttig lærdom. Det avgjørende spørsmålet er hvilken spesifikk hypotese utgivelsen vil teste og hvilket resultat som vil føre til at teamet endrer retning. Hvis det ikke finnes noe svar, er utgivelsen et lite produkt, ikke et minimumslevedyktig produkt.

Den levedyktige halvdelen av begrepet blir også neglisjert. En versjon som er minimal, men ikke fungerer, eller som mislykkes med det den er ment å gjøre, produserer bevis om implementeringen snarere enn om etterspørsel. Kunder som avviser et produkt fordi det var tregt, ødelagt eller forvirrende, forteller teamet ingenting om hvorvidt det underliggende forslaget har verdi. Uansett hva som er inkludert, må det være godt nok til å gi ideen en rettferdig test, selv om det omkringliggende omfanget er drastisk redusert.

Flere etablerte mønstre svarer på etterspørselsspørsmål uten å bygge et komplett produkt. Concierge-tilnærminger leverer tjenesten manuelt til tidlige kunder for å lære hva de faktisk trenger før de automatiserer noe. Trollmannen fra Oz-implementeringer presenterer et fungerende grensesnitt med mennesker som utfører arbeidet bak det. Landingssidetester måler om noen reagerer på forslaget før utviklingen starter. Hver av disse produserer atferdsmessige bevis, som er langt sterkere enn de uttalte intensjonene som er samlet inn i undersøkelser og intervjuer om hypotetiske produkter.

Tilnærmingen passer noen kontekster langt bedre enn andre. I regulerte bransjer, i sikkerhetskritiske systemer og i bedriftssalg, der et enkelt dårlig førsteinntrykk stenger et marked i årevis, medfører det å levere bevisst ufullstendig programvare kostnader som oppveier læringen. I disse settingene brukes den samme logikken bedre gjennom prototyper, pilotprosjekter med informerte deltakere og trinnvise utrullinger til et begrenset publikum, snarere enn gjennom offentlig utgivelse av et minimalt produkt.

Å bestemme på forhånd hvilket resultat som vil føre til at teamet stopper, er det som gjør øvelsen meningsfull, og det er det trinnet som oftest utelates. Uten en forhåndsavtalt terskel kan ethvert resultat tolkes som oppmuntrende: lav bruk blir et markedsføringsproblem, dårlig retensjon blir et onboarding-problem, og prosjektet fortsetter basert på den forklaringen som bevarer det. Å skrive ned, før lansering, hvilket nivå av adopsjon eller retensjon som vil rettferdiggjøre fortsettelse, hvilket nivå som vil rettferdiggjøre en endring av tilnærming, og hva som vil rettferdiggjøre å stoppe helt, gjør utgivelsen til en ekte test. Det beskytter også teamet, siden en dokumentert terskel som er avtalt av interessenter er mye lettere å påberope seg enn en vurdering som tas i etterkant.

Brukt riktig, holder konseptet et team ærlig om forskjellen mellom å bygge og å lære, og det er mest verdifullt der usikkerheten rundt etterspørselen er genuint høy. I praksis etableres hypotesen og evidensstandarden gjennom produktforskning, konstruksjonen sitter med produktutvikling, og disiplinen med å definere på forhånd hvilket resultat som ville utløse en retningsendring er det som skiller tilnærmingen fra å bare lansere tidlig. startups spesielt den disiplinen avgjør om begrenset rullebane brukes til læring eller bare brukes.