MVP, MMF, PSI, WTF? Osa 1: MVP:n ymmärtäminen
Työskennellessäni uusien tuoteomistajien kanssa huomaan usein, että joudumme TLA:iden (Three Letter Acronyms, kolmikirjaimiset lyhenteet) mereen, kun on aika ryhtyä muuttamaan ideoiden backlogia julkaisukelpoisiksi lisäarvoiksi.
Ajatus työn pilkkomisesta – suurten, suunniteltujen tuotejulkaisujemme pilkkomisesta pienemmiksi arvonlisäyksiksi on se, missä monet uudet tuoteomistajat kamppailevat. Miten otamme tämän tuotetiekartan ja muutamme sen joksikin sellaiseksi, mitä Scrum-tiimini voivat todella toimittaa lyhyellä, säännöllisellä aikataululla? Miten voin muuttaa tämän valtavan luettelon erittäin tärkeistä ominaisuuksista (Very Important Features, VIF) iteratiiviseksi joukoksi tilaisuuksia oppia, tuottaa arvoa ja todella antaa jotain asiakkaillemme? Toisin sanoen….
”Mikä on meidän MVP:mme?”
”Onko se meidän MMF:mme?”
”Voimmeko julkaista tämän PSI:n MVP:nä, vai tarvitsemmeko vielä lisää tarinoita, ennen kuin meillä on MMF?”
Seuraavasti….mitä???
Mitä tarkoittavat nämä TLA:t? Miten ne eroavat toisistaan? Miten ne liittyvät toisiinsa? Miksi minun pitäisi välittää?
Alkaen MVP:stä (Minimum Viable Product), tämä kolmiosainen sarja auttaa aloittelevia agilisteja ymmärtämään, mitä nämä TLA:t tarkoittavat. Miten ne eroavat toisistaan? Miten ne liittyvät toisiinsa? Miksi minun pitäisi välittää? Se auttaa myös muistuttamaan niitä, jotka ovat työskennelleet ketterästi jo jonkin aikaa, miksi nämä käsitteet ovat ketteryyden kulmakiviä.
Neuvojat, jotka vasta alkavat oppia Scrumista, voivat kääntyä Scrum-oppaan puoleen… ja oppivat nopeasti, että Scrum-oppaassa ei puhuta siitä, miten tuote muutetaan kokoelmaksi pieniä, julkaisukelpoisia arvonlisäyksiä.
Tiedon puute tästä tärkeästä aiheesta voi olla todella turhauttavaa uusille tuoteomistajille. Toivottavasti tämän artikkelin loppuosa selventää MVP:tä, ja aina on olemassa Certified Scrum Product Owner -kursseja, joihin voi tutustua saadakseen lisätietoa. Sukelletaan toistaiseksi Minimum Viable Productiin.
The MVP
Olet tehnyt tutkimusta, käynyt asiakaskohderyhmien kanssa läpi muutaman Buy a Feature -kierroksen ja tehnyt joitakin päätöksiä siitä, miltä seuraava julkaisusi voisi näyttää. Itse asiassa olet ottanut markkinointitiimisi mukaan ja iteroit ideoita siitä, miten tehdä iso pläjäys – mainoksia ammattilehdissä, mainostettuja twiittejä, Facebook-postauksia…
Mutta joihinkin ominaisuuksiin, joiden parissa työskentelet, liittyy vielä joitakin askarruttavia kysymyksiä. Olet miettinyt niitä, olet analysoinut niitä, mutta päässäsi on ääni, joka kysyy: ”Mutta mistä tiedät?”
Tässä kohtaa MVP astuu kuvaan – ei Steph Curry, vaan (ehkä väärin nimetty) Minimum Viable Product.
The Lean Startup Conundrum
Kirjassaan ”The Lean Startup” Eric Reis määrittelee hämmentävästi uudelleen termin ”Minimum Viable Product”, minkä hän selittää haastattelussa vuonna 2015. Lyhyesti:
”Joitakin varoituksia heti alkuun. MVP ei nimestään huolimatta tarkoita minimaalisten tuotteiden luomista. Toiseksi, se, että määritelmässä käytetään sanoja maksimi ja minimi, tarkoittaa, että se ei selvästikään ole kaavamainen.”
Jos siis tuoteomistajuuden maailma ja ketterä yhteisö ovat määritelleet Minimum Viable Productin uudelleen siten, että siinä ei ole kyse vähimmäismäärän tai tuotteiden luomisesta, mitä se sitten on?
All About the Learning
Tuo nalkuttava ääni takaraivossasi, joka miettii, onko olemassa ulospääsyä analyysihalvausloukusta, jossa olet, yrittäen keksiä keinon, jolla voisit oikeasti tietää vastaukset joihinkin kysymyksiisi sen sijaan, että analysoisit itsesi yhä syvempään väärän turvallisuuden tunteeseen? Juuri tässä kohtaa tulee kuvaan Minimum Viable Product (vähimmäiskelpoinen tuote).
Siinä missä PSI (Potentially Shippable Increment, potentiaalisesti toimituskelpoinen lisäosa) tarkoittaa mahdollisuuden luomista potentiaalisesti toimittaa jotakin arvokasta ja MMF (Minimum Marketable Feature, vähimmäismarkkinakelpoinen ominaisuus) näiden arvokkaiden osien yhdistämistä ominaisuuksien kokoelmaksi, joka ratkaisee asiakasongelmia, MVP:ssä on kyse siitä, että tiimisi tekee vähimmäismäärän töitä, jotka ovat mahdollisia validoidun oppimissilmukan sulkemiseksi.
Tuotekehityksen Lean Startup -menetelmässä yksi tärkeimmistä tavoista omaksua on tapa validoida hypoteeseja ja luoda kokeiluja. Perinteisemmin riskejä välttelevissä organisaatioissa uskomus siitä, että riski on analysoitava pois tuotteesta ennen lanseerausta, johtaa pitkiin läpimenoaikoihin ja turhauttavasti dataan perustuviin oletuksiin asiakkaiden toiveista ja tarpeista. Jos olemme todella hyviä tilastollisessa analyysissä ja jos meillä on todella hyvää dataa tilastollisesti merkittävästä osasta asiakkaitamme, voimme tehdä melko hyvää työtä muotoillaksemme valistuneen arvauksen siitä, mitä asiakkaamme haluavat.
Mutta loppujen lopuksi se on silti vain arvaus.
Luotuamme MVP:itä rakennamme tarkoituksellisesti juuri sen verran toiminnallisuutta, että voimme kysyä asiakkailtamme oikeita kysymyksiä – ostaisitko tämän tuotteen? Onko näissä kuvakkeissa järkeä? Turhaako tämä työnkulku sinua vai auttaako se sinua löytämään seuraavan suosikkiravintolasi?
Tässä vaiheessa tarkastelemme paperiprototyyppejä, verkkosivujen rautalankakehyksiä, käyttöliittymämock-upeja; kävelemme kadun toiselle puolelle ostoskeskukseen näyttääksemme mallejamme lähimmille mahdollisille ihmisille vain validoidaksemme nopeasti, että olemme oikealla tiellä.
Hyvän MVP:n luomisen taika ei kuitenkaan ole työkaluissa tai tekniikoissa; se on kurinalaisuudessa, kun haluat analysoida verkkosivuston lämpökartasta saatua dataa selvittääksesi, mikä värimaailma toimii parhaiten, tarttua sen sijaan tusseihin ja paperiin, hahmotella pari matala-uskottavaa ratkaisua ja kysyä joltakulta: ”Kummasta näistä pidät enemmän?”