Näin rajaat MVP:n: karsi ensimmäinen versio siihen, mikä oikeasti merkitsee

Lähes jokainen, joka tulee meille sovellusidean kanssa, on jo rakentanut sen täyden version päässään. He osaavat kuvailla hallintapaneelin, asetussivun, suositteluohjelman, tumman tilan. Mitä he eivät yleensä osaa kertoa, on se, mikä yksittäinen osa tästä kuvasta tekisi koko hankkeesta tekemisen arvoisen, jos se toimisi. MVP:n rajaaminen on sitä epäglamourista, hieman tuskallista työtä, jossa löydetään juuri se osa — ja ollaan tarpeeksi rohkeita jättämään loput myöhemmäksi.

Olen katsonut monen ensimmäisen tuotteen rakentumista, ja ne jotka kompuroivat eivät juuri koskaan epäonnistu siksi, että tiimi olisi ollut laiska. Ne epäonnistuvat, koska rajaus oli väärä jo ensimmäisestä viikosta lähtien. Ensimmäiseen versioon ahdettiin liikaa, budjetti loppui ennen kuin kukaan oppi mitään, ja julkaisuun mennessä tiimi oli käyttänyt kaiken pelkästään lähtöviivalle pääsemiseen — ilman rahaa reagoida siihen, mitä oikeat käyttäjät todella tekivät.

Joten tämä on se opas, jonka annan ihmisille ennen kuin yhtäkään koodiriviä on kirjoitettu. Kyse ei ole Agile-rituaaleista tai hienoista viitekehyksistä. Kyse on yhdestä rehellisestä kysymyksestä — mikä on pienin asia, jonka voimme rakentaa ja joka kertoo meille, onko tämä idea aito? — ja kurinalaisuudesta vastata siihen yhä uudelleen, kun houkutus lisätä ”vain yksi ominaisuus lisää” hiipii takaisin. Koska se hiipii aina takaisin.

Mikä MVP oikeasti on (ja mikä se ei ole)

Termi on kulunut liikakäytössä sileäksi, joten ollaan tarkkoja. Minimum viable product on ideasi pienin versio, joka tuottaa todellista arvoa todelliselle käyttäjälle ja opettaa sinulle jotain, mitä et olisi voinut oppia diaesityksestä. Sana, jonka ihmiset unohtavat, on viable eli elinkelpoinen. Sen on oikeasti toimittava jollekulle, alusta loppuun, vaikka se tekisi vain yhden asian.

Tässä mitä MVP ei ole. Se ei ole puolivalmis versio täydestä tuotteesta, jonka kulmat ovat rikki joka suunnasta. Se ei ole prototyyppi, jonka heität pois. Eikä se todellakaan ole ”se halpa versio” — halpuus on hyvän rajauksen sivuvaikutus, ei tavoite. Tavoite on oppiminen. Käytät mahdollisimman vähän rahaa vastataksesi kalleimpaan kysymykseesi: käyttääkö tätä kukaan, ja käyttääkö juuri niin kuin luulen?

Tuo ero merkitsee enemmän kuin miltä kuulostaa. ”Ensimmäiset 20 %” -ajattelu johtaa johonkin, joka on rikki joka suuntaan ja hyödytön missään. ”Yksi asia, kunnolla tehtynä” johtaa johonkin, jonka ihminen voi ottaa käteen, käyttää oikeasti ja muodostaa siitä mielipiteen. Mielipiteet ovat koko pointti. Hiljaisuuden päälle ei voi iteroida.

Liikaa rakentamisen ansa ja miksi siihen on niin helppo langeta

Kukaan ei lähde ylirajaamaan tarkoituksella. Se tapahtuu yksi järkevä päätös kerrallaan. Lisäät kirjautumisen, koska tilejä tietysti tarvitaan. Tilit tarkoittavat salasanan palautusta, sähköpostivarmennusta ja asetussivua. Asetukset tarkoittavat profiilia, joka tarkoittaa kuvien lataamista, mikä tarkoittaa paikkaa niiden tallentamiseen. Jokainen askel on yksinään järkevä. Päällekkäin pinottuna olet käyttänyt kaksi kuukautta ja palan budjettia ennen kuin se osa, joka tekee ideastasi erityisen, on edes aloitettu.

Ansan toinen puoli on tunneperäinen. Ominaisuuksien karsiminen tuntuu sen myöntämiseltä, että ideasi on pieni. Ei se ole — se on sen myöntämistä, ettet vielä tiedä mitkä ominaisuudet merkitsevät, mikä on yksinkertaisesti totuus. Jokainen ominaisuus, jonka rakennat ennen käyttäjiä, on sokkona lyöty veto. Osa näistä vedoista on väärässä, ja ne, jotka karsit MVP:stä, ovat halvimmat mahdolliset vedot, joissa olla väärässä, koska et koskaan lyönyt niitä.

Löydä se yksi tehtävä, joka MVP:si on tehtävä

Jokaisella tuotteella, kuinka isoksi se lopulta kasvaakin, on ydinkierto — se yksi sarja, jonka käyttäjä toistaa ja joka luo arvon. Varaussovelluksessa se on etsi aika, varaa se, saa muistutus. Markkinapaikassa se on listaa jokin, joku löytää sen, raha vaihtaa omistajaa. Sisäisessä työkalussa se on kirjaa tieto kerran, käytä kaikkialla. Kaikki muu tuotteessa on olemassa tukemassa, koristamassa tai laajentamassa tuota kiertoa. MVP:si on se kierto. Pelkkä kierto.

Löytääksesi omasi, päätä tämä lause ääneen: ”Käyttäjä tulee tuotteeseeni ______, ja on tyytyväinen, jos ______.” Ensimmäinen tyhjä kohta on tehtävä. Toinen on se, miten tiedät sen onnistuneen. Jos et pysty täyttämään molempia yhdellä hengenvedolla, et ole vielä löytänyt ydintä — etkä ole valmis rajaamaan, saati rakentamaan.

Ole armoton sen suhteen, mikä on ero ydinkierron ja niiden asioiden välillä, jotka tuntuvat välttämättömiltä mutta eivät ole. Kirjautuminen tuntuu välttämättömältä. Ensimmäisessä versiossa se ei yleensä ole — moni MVP julkaistaan yhdellä jaetulla linkillä, manuaalisella kutsulla tai ilman tilejä lainkaan, ja oppii kaiken tarvittavan ennen tunnistautumiskoneiston rakentamista. Analytiikkapaneelit tuntuvat välttämättömiltä. Eivät ne ole; voit lukea tietokantaa käsin, kun sinulla on yksitoista käyttäjää. Riisu takaisin kiertoon, niin hämmästyt kuinka paljon putoaa pois.

Lajittele jokainen ominaisuus: pakko, pitäisi ja ei nyt

Kun olet nimennyt ydinkierron, ota iso ominaisuuslistasi ja lajittele jokainen kohta kolmeen ämpäriin. Ämpärit ovat tarkoituksella tylyjä, koska tylyys on se, mikä pysäyttää loputtomat ”mutta ehkä” -keskustelut.

• Pakko: ydinkierto ei kirjaimellisesti toimi ilman sitä. Jos poistat sen, tuotetta ei ole. Pidä tämä lista järkyttävän lyhyenä — yleensä kolmesta kuuteen kohtaa.
• Pitäisi: se tekee tuotteesta paremman, mutta kierto toimii silti ilman sitä. Kaikki tämä odottaa versiota kaksi. Ei poikkeuksia ensimmäisessä versiossa.
• Ei nyt: ominaisuudet, jotka tietoisesti päätät jättää rakentamatta nyt. Niiden kirjaaminen ylös merkitsee — se on tapa vakuuttaa itsesi ja tiimisi siitä, ettei ideaa hylätä, vaan vain järjestetään aikajärjestykseen.

Temppu, joka saa tämän toimimaan, on kolmas ämpäri. Useimmat ihmiset väittelevät vain pakon ja pitäisi-asioiden välillä, mikä on uuvuttavaa eikä lopu koskaan. ”Ei nyt” -lista on se, missä helpotus asuu — se on lupaus tulevalle itsellesi, että hieno idea on turvassa ja aikataulutettu, vain ei nyt. Kun ihmiset luottavat, ettei mitään heitetä pois, he lakkaavat taistelemasta pitääkseen kaiken ensimmäisessä versiossa.

Rajaa ajan ja rahan mukaan, älä ominaisuuslistan

Tässä hiljainen muutos, joka muuttaa kaiken: lopeta rajaaminen sen mukaan ”mitä haluamme” ja aloita rajaaminen sen mukaan ”mikä mahtuu budjettiin ja aikatauluun”. Päätä ensin, kuinka paljon rahaa ja kuinka monta viikkoa olet valmis käyttämään ydinkysymykseesi vastaamiseen. Sovita sitten ominaisuuslista tuohon laatikkoon. Tämä kuulostaa takaperoiselta, mutta se on hyödyllisin rajoite, jonka voit itsellesi antaa, koska se pakottaa priorisoinnin, jota muuten välttelisit.

Kiinteä laatikko tekee jotain psykologistakin. Kun budjetti on avoin, jokainen ominaisuus on kyseenalaistettavissa ja lista vain kasvaa. Kun laatikko on kiinteä — vaikkapa kahdeksan viikkoa ja tietty summa — keskustelu kääntyy. Se ei ole enää ”lisäämmekö tämän?” vaan ”mikä lähtee pois, jos tämä tulee mukaan?” Tuo jälkimmäinen kysymys on se, joka rakentaa hyviä MVP:itä. Kompromissit ovat näkyviä piilossa olemisen sijaan, ja tiimi tekee ne tarkoituksella.

Todellinen esimerkki: työnhallintaidean rajaaminen alaspäin

Tehdään tästä konkreettista tapauksella, jonka parissa työskentelimme — anonymisoitu, mutta uskollinen sille, miten nämä etenevät. Pieni lämmitys- ja putkialan yritys tuli meille haluten sovelluksen kenttätiimilleen. Toimeksianto oli paperilla valtava: reaaliaikainen työnaikataulutus, pakettiautojen GPS-seuranta, asiakasportaali, automaattinen laskutus, kunkin ajoneuvon varaosavarasto, tarjouslaskuri, valokuvadokumentointi ja raportointipaketti omistajalle. Aidosti hyödyllinen tuote, lopulta. Ensimmäisenä versiona taattu tapa käyttää vuoden budjetti ennen kuin oppii mitään.

Joten teimme harjoituksen. Kysyimme omistajalta lauseen: ”Käyttäjä tulee tähän ______, ja on tyytyväinen, jos ______.” Jonkin edestakaisin pohdinnan jälkeen todellinen vastaus nousi pintaan. Asentajien suurin päivittäinen tuska ei ollut aikataulutus eikä laskutus — se oli paperityön edestakaisuus. He saivat työn valmiiksi, raapustivat tunnit ja osat lapulle, ajoivat takaisin, ja joku toimistolla naputteli kaiken uudelleen kirjanpitojärjestelmään, usein päiviä myöhemmin, usein virheineen. Ydinkierto oli yksinkertaisesti: kirjaa kerran, paikan päällä, mitä työssä tapahtui, jottei kenenkään tarvitse naputella sitä uudelleen.

Mikä pääsi mukaan — ja mikä ei

Kaikki lajiteltiin. Pakko-ämpäri kutistui neljään asiaan: lista kunkin asentajan päivän töistä, yksinkertainen lomake työn tuntien ja käytettyjen osien kirjaamiseen, valokuvaliite ja tapa, jolla toimisto näkee nuo tiedot heti niiden lähettämisen jälkeen. Siinä oli koko MVP. Ei GPS:ää, ei asiakasportaalia, ei tarjouslaskuria, ei hienoa raportointia — kaikki tämä pysäköitynä, eksplisiittisesti, ”ei nyt” -listalle merkinnällä, että se on tulossa.

Rakensimme tuon ytimen muutamassa viikossa lähes vuoden sijaan. Ja tässä se osa, joka oikeuttaa koko lähestymistavan: kun se oli julkaistu, tiimin todelliset prioriteetit osoittautuivat erilaisiksi kuin toimeksianto. Omistaja oli olettanut GPS-seurannan olevan seuraavana; asentajat tuskin mainitsivat sitä. Mitä he halusivat, äänekkäästi, oli lähettää asiakkaalle saapumisikkuna tekstiviestillä sovelluksen sisältä — ominaisuus, jota ei ollut edes alkuperäisellä listalla. Koska MVP oli pieni ja halpa, budjettia jäi rakentaa juuri se, mitä he oikeasti halusivat, sen sijaan mitä he olivat arvanneet kuukausia aiemmin.

Virheet, jotka hiljaa tuhoavat MVP-rajauksen

Jopa tiimit, jotka ostavat ajatuksen ”pidä se pienenä”, kompastuvat yleensä samoihin muutamaan asiaan. Mikään niistä ei ole dramaattinen. Ne ovat hitaita vuotoja, jotka pumppaavat rajauksen uudelleen täyteen selkäsi takana, kunnes eräänä päivänä ”minimituotteella” on taas kolmekymmentä näkymää ja puolen vuoden aikataulu.

• Reunojen kultaaminen: päivien käyttäminen vain sinun näkemäsi hallintapaneelin viimeistelyyn, kun ydinkierto on vielä karkea. Kiillota se, mihin käyttäjät koskevat; jätä taustatoimisto rumaksi ja toimivaksi.
• Rakentaminen mittakaavalle, jota ei ole: miljoonan käyttäjän arkkitehtuuri, kun pitäisi todistaa, että ensimmäiset kymmenen palaavat. Ratkaise mittakaavaongelma, kun sinulla on mittakaavan onnellinen ongelma.
• ”Pakollisen” sekoittaminen ”alan standardiin”: se ettei jokaisella kilpailijalla on ominaisuus X, ei tarkoita, että MVP:si tarvitsisi sen ydinideasi testaamiseen. Et julkaise valmista tuotetta, vaan ajat kokeilua.
• Jokaisen reunatapauksen suunnittelu etukäteen: harvinaisten, outojen syötteiden käsittely ennen kuin tiedät, käyttääkö kukaan tavallista, normaalia polkua. Anna todellisen käytön kertoa, mitkä reunatapaukset ovat edes todellisia.
• Ei valmiin määritelmää: ilman kirjattua riviä siitä, miltä ”valmis” näyttää, rakentaminen ei lopu koskaan. Rajauksen laajeneminen rakastaa projektia, jolla ei ole maaliviivaa.

Jos varjelet vain yhtä näistä, tee se viimeinen. Selkeä, kirjattu valmiin määritelmä — ”asentaja voi kirjata työn tunnit ja osat puhelimellaan, ja toimisto näkee sen heti” — on yksittäin voimakkain työkalu rajauksen pitämiseen rehellisenä. Jokainen ehdotettu lisäys nostetaan tuota lausetta vasten. Jos se ei palvele lausetta, se on version kaksi idea, oli se kuinka hyvä tahansa.

Yksinkertainen prosessi MVP:n rajaamiseen

Kun vedän tämän yhteen, tässä on järjestys, jonka kävisin läpi kenen tahansa kanssa ennen ensimmäisen version aloittamista. Se on tarkoituksella matalan teknologian — suurimman osan voit tehdä dokumentilla ja rehellisellä keskustelulla, kauan ennen kuin tarvitset kehittäjää huoneeseen.

1. 1
   Nimeä ydinkierto

   Päätä lause: ”Käyttäjä tulee tekemään ___, ja on tyytyväinen, jos ___.” Jos et pysty, et ole valmis rajaamaan — jatka puhumista, kunnes todellinen tehtävä nousee pintaan.
2. 2
   Tyhjennä jokainen ominaisuus, sitten lajittele

   Saa koko toivelista pois päästäsi paperille. Lajittele jokainen kohta: pakko, pitäisi vai ei nyt. Pidä ”pakko”-lista raa'an lyhyenä.
3. 3
   Kiinnitä laatikko

   Päätä budjetti ja aikataulu ennen ominaisuuslistan viimeistelyä. Sovita lista laatikkoon, älä toisinpäin.
4. 4
   Kirjoita valmiin määritelmä

   Yksi konkreettinen lause, joka kuvaa toimivaa ydinkiertoa. Tämä on kilpesi rajauksen laajenemista vastaan koko loppuprojektin ajan.
5. 5
   Rakenna, julkaise, seuraa, sitten päätä

   Toimita ydin todellisille käyttäjille. Seuraa, mitä he oikeasti tekevät. Anna heidän käytöksensä — ei aiempien arvaustesi — valita, mikä lähtee ”pitäisi”-listalta seuraavaksi.

Huomaa, että viimeinen askel johdattaa sinut takaisin alkuun. Hyvä MVP ei ole kertaluonteinen tapahtuma, vaan pyörän ensimmäinen kierros. Rajaat pieneksi, julkaiset, opit, ja se mitä opit rajaa seuraavan version uudelleen. Voittajatiimit eivät ole niitä, jotka suunnittelivat täydellisen tuotteen etukäteen — kukaan ei tee niin. Ne ovat niitä, jotka saivat jotain todellista käyttäjien eteen tarpeeksi nopeasti, että todellisuus saattoi vielä ohjata heitä.

Yleisiä kysymyksiä