Minimum Viable Product on tuotteen pienin versio, jonka avulla tiimi voi oppia jotain olennaista siitä, haluavatko asiakkaat sitä. Eric Ries teki tästä teoksen The Lean Startup. Määrittelevä ominaisuus ei ole tuotteen pieni koko tai halpa koko, vaan se, että se on rakennettu vastaamaan tiettyyn kysymykseen ja että kysymys koskee validoitua oppimista asiakaskäyttäytymisestä eikä sisäistä mielipidettä toteutettavuudesta.
Toistuvin väärinkäyttö on sen pitäminen synonyyminä ensimmäiselle julkaisulle, jossa on vähemmän ominaisuuksia. Määräaikapaineissa tiimit karsivat julkaisun laajuutta, toimittivat jotain keskeneräistä, kutsuivat sitä MVP:ksi (minimivaatimukset täyttäväksi toimittajaksi) ja sitten eivät mittaa mitään erityistä, mikä ei tuota hyvää tuotetta eikä hyödyllistä oppituntia. Erottava kysymys on, mitä erityistä hypoteesia julkaisu testaa ja mikä tulos saisi tiimin muuttamaan suuntaa. Jos vastausta ei ole, julkaisu on pieni tuote, ei mikään minimivaatimukset täyttävä.
Myös termin toteuttamiskelpoinen puolisko jää huomiotta. Versio, joka on minimaalinen mutta ei toimi tai joka epäonnistuu siinä, mihin sen on tarkoitus, tuottaa näyttöä toteutuksesta pikemminkin kuin kysynnästä. Asiakkaiden hylkäämä tuote sen hitaan, rikkinäisen tai hämmentävän luonteen vuoksi ei kerro tiimille mitään siitä, onko taustalla olevalla ehdotuksella arvoa. Sisällytetyn on oltava riittävän hyvää, jotta idea voidaan testata reilun aikaa, vaikka ympäröivää laajuutta supistettaisiin rajusti.
Useat vakiintuneet mallit vastaavat kysyntäkysymyksiin ilman täydellisen tuotteen rakentamista. Concierge-lähestymistavat toimittavat palvelun manuaalisesti alkuvaiheen asiakkaille, jotta he oppivat, mitä he todella tarvitsevat, ennen kuin mitään automatisoidaan. Ihmemaa Oz -toteutukset tarjoavat toimivan rajapinnan ihmisten kanssa, jotka suorittavat työn sen takana. Laskeutumissivutestit mittaavat, reagoiko kukaan ehdotukseen ennen kehityksen aloittamista. Jokainen näistä tuottaa käyttäytymiseen perustuvaa näyttöä, joka on paljon vahvempaa kuin hypoteettisista tuotteista tehdyissä kyselyissä ja haastatteluissa kerätyt ilmoitetut aikomukset.
Lähestymistapa sopii joihinkin konteksteihin paljon paremmin kuin toisiin. Säännellyillä toimialoilla, turvallisuuskriittisissä järjestelmissä ja yritysmyynnissä, joissa yksi huono ensivaikutelma sulkee markkinat vuosiksi, tarkoituksella keskeneräisen ohjelmiston toimittaminen aiheuttaa kustannuksia, jotka ovat suuremmat kuin oppiminen. Näissä tilanteissa samaa logiikkaa sovelletaan paremmin prototyyppien, informoitujen osallistujien pilottihankkeiden ja vaiheittaisten käyttöönottojen kautta rajoitetulle yleisölle kuin minimaalisen tuotteen julkisen julkaisun kautta.
Harjoituksen merkityksellisyyden tekee se, että etukäteen päätetään, mikä tulos saisi tiimin lopettamaan projektin, ja se on vaihe, joka johdonmukaisimmin jätetään pois. Ilman ennalta sovittua kynnysarvoa mikä tahansa tulos voidaan tulkita rohkaisevaksi: vähäisestä käytöstä tulee markkinointiongelma, heikosta asiakaspysyvyydestä tulee perehdytysongelma, ja projekti jatkuu sen selityksen perusteella, joka säilyttää sen. Ennen julkaisua kirjaa ylös, mikä käyttöönotto- tai asiakaspysyvyyden taso oikeuttaisi jatkamisen, mikä taso oikeuttaisi lähestymistavan muutoksen ja mikä oikeuttaisi täydellisen lopettamisen. Se myös suojelee tiimiä, koska sidosryhmien sopimaa dokumentoitua kynnysarvoa on paljon helpompi käyttää kuin jälkikäteen tehtyä arviota.
Oikein käytettynä konsepti pitää tiimin rehellisenä rakentamisen ja oppimisen välisestä erosta, ja se on arvokkainta silloin, kun kysynnän epävarmuus on todella suurta. Käytännössä hypoteesi ja näyttöstandardi luodaan seuraavien kautta: tuotetutkimus, rakennus sopii tuotekehitysja kurinalaisuus, jonka mukaan etukäteen määritetään, mikä tulos laukaisi suunnanmuutoksen, erottaa lähestymistavan pelkästä aikaisesta käynnistämisestä. startups erityisesti tuo kurinalaisuus määrittää, käytetäänkö rajoitettu kiitotie oppimiseen vai pelkästään kulutukseen.