Varoitus. Tämä kolmiosainen artikkeli on melko kantaaottava, ja saatat olla eri mieltä joistakin valinnoistamme ja lähestymistavoistamme. Se ei kuitenkaan haittaa! Olemme havainneet asiakkaidemme kanssa työskennellessämme, että tietyt teknologiset ja toiminnalliset valinnat tekevät asioista sujuvampia. Voit vapaasti olla niistä eri mieltä ja kertoa meille, mitä tiimisi tekee toisin.
Me Identiolla työskentelemme erilaisten yksityisen ja julkisen sektorin asiakkaiden kanssa, jotka ovat elinkaarensa eri vaiheissa. Mielestämme tässä kuvattu lähestymistapa on suhteellisen helposti sovitettavissa eri asiakkaille, mutta se toimii parhaiten alkuvaiheen startup-yrityksille tai yrityksille, joilla on pieni määrä olemassa olevia ohjelmistopalveluja, jotka halutaan integroida uuteen tuotteeseen. Tässä sarjassa tarkastellaan käsitteenä ja kehitysprosessina MLP-tuotetta (Minimum Lovable Product), jonka tavoitteena on tuottaa teknisesti toimivan ohjelmiston lisäksi myös sellainen ohjelmisto, jota käyttäjät käyttävät mielellään.
Olemme jakaneet tämän artikkelin kolmeen osaan, jotka julkaisemme noin viikon välein ja joissa käsittelemme alustavaa tiedonkeruuvaihetta, Minimum Lovable Productin toimittamista ja seuraavia vaiheita, jotka toteutetaan, kun tuotteen ensimmäinen versio on käyttäjien käsissä.
Minimum Lovable Product
Lyhyen johdannon tarjoamiseksi asiaan perehtymättömille, MLP on tuote, joka on kehitetty ja suunniteltu niin, että käyttäjät ottavat sen innokkaasti käyttöön. Helpoin tapa määritellä Minimum Lovable Product käsitteenä, on vertailla sitä ja monille tutumpaa Minimum Viable Productia.
Minimum Viable Product
- Alustava Proof of Concept -tasoinen runko.
- Yksinkertaiset ominaisuudet vaatimusten tyydyttämiseksi.
- Antaa käyttäjille mahdollisuuden testata ideaa, mutta ei tavallisesti ole tarpeeksi vetovoimainen.
Minimum Lovable Product
- Kaikki edellä mainitut.
- Käyttäjäkokemuksen kehittäminen ensisijaisten työnkulkujen osalta.
- Herättää käyttäjissä myönteisiä tunteita.
Määritelmän mukaan MVP:llä saadaan työ tehtyä, mutta usein ohjelmistotuotteet eivät saa käyttäjiä, tai käyttäjät käyttävät työkaluja vastahakoisesti vaihtoehtojen sijaan. Kun käyttäjäkokemus vaikuttaa käyttäjiin suuresti tai kun tavoitteena on saavuttaa laaja käyttäjäkunta, kannattaa nähdä ylimääräistä vaivaa, jotta tuotteen elinkelpoisuus muuttuu rakastettavuudeksi.
Ennen kuin aloitamme
Tuotekehityksen alussa on yleensä muutaman viikon jakso, jolloin tutkimme asioita ja keskustelemme yksityiskohdista, kuten sopimuksista. Aloitamme oppimisprosessin jo osana myyntiprosessia, mutta tutustumme asiakkaaseen kunnolla yhteistyön alkaessa – kick-offin tai design sprintin yhteydessä.
Asiakkaan ymmärtäminen
Haluamme tuntea asiakkaamme ja heidän liiketoimintansa hyvin. Tutustumme tiimiin tai tiimeihin, joiden kanssa työskentelemme, alaan, jolla he työskentelevät sekä heidän päivittäiseen liiketoimintaansa. Alkuvaiheen startup-yrityksissä tämä tarkoittaa yleensä sitä, että tapaamme tiimin ja opimme tuntemaan heidät ja heidän asiantuntemuksensa.
Tuotteen ensimmäisen version rakentaminen on usein pohjimmiltaan selkeää viestintää ja ongelman, jota haluamme ratkaista, ymmärtämistä. Mielestämme on tärkeää ottaa asiakas mukaan kehitysprosessiin jo varhaisessa vaiheessa. Läpinäkyvä tiedonvaihto tekee asioista helpompia myöhemmässä vaiheessa.
Tuotteen vision ymmärtäminen
Kun olemme saaneet selkeämmän käsityksen asiakkaasta, on aika syventyä paremmin ongelmaan. Yleensä se tapahtuu asiakkaan tarjoaman kuvauksen ja tietojen perusteella. Tiimimme ovat parhaimmillaan työskennellessään liiketoimintaongelmien ja teknisten ratkaisujen kehittämisen risteyskohdassa. Pyrimme ymmärtämään parhaamme mukaan seuraavat asiat:
- Miksi asiakas on kiinnostunut rakentamaan tämän tuotteen ongelman ratkaisemiseksi?
- Miksi asiakas on nimenomaan kiinnostunut ongelman ratkaisemisesta?
- Miksi hän haluaa ratkaista ongelman juuri nyt?
Kun saamme vastaukset näihin kysymyksiin, voimme rajata tuotteen ensimmäisen iteraation laajuutta. Ensimmäinen versio tarjoaa yleensä vain osan lopullisen tuotteen toiminnallisuuksista, jotta voimme toimittaa jotain käyttökelpoista, testattavaa ja käyttäjille mieluisaa.
Käyttäjien ymmärtäminen
Vain harvoin asiakas on tuotteen suora käyttäjä, jolloin pelkkä asiakkaan ymmärtäminen riittäisi. Vaikka asiakkaalta saattaisikin saada hyvin selkeän käsityksen käyttäjistä, kannattaa eri käyttäjäryhmien ymmärtämiseen silti käyttää aikaa. Tämä saattaa tarkoittaa esimerkkikäyttäjäpersoonien luomista sekä heidän tarpeidensa ja käyttötapaustensa määrittelyä. Todellisten potentiaalisten käyttäjien ottaminen mukaan alustavaan käyttötapausten määrittelyyn on erittäin hyödyllistä. Käyttäjäkeskeinen lähestymistapa edellyttää jatkuvaa vuoropuhelua aiottujen käyttäjien kanssa, jotta voimme keskittyä ratkaisua vaativaan ongelmaan ja välttää suunnittelemasta ratkaisua, joka ei ratkaisekaan keskeistä ongelmaa.
Kun pureudutaan perustavanlaatuisimpaan asiaan, saattaa myös paljastua, että eri käyttäjäsegmenttien tarpeet ja käyttötapaukset eroavat toisistaan. Niiden ymmärtäminen auttaa myös päättämään, pitäisikö keskittyä yhteen segmenttiin vai voidaanko eri käyttötapaukset ottaa huomioon vaarantamatta käyttäjäkokemusta ja siten tuotteen rakastettavuutta.
Resurssien keskittäminen oikeisiin asioihin
Nyt kun meillä on parempi käsitys ongelmista, joita haluamme ratkaista, voimme keskittyä oikeisiin asioihin:
- Mitkä ominaisuudet ovat käyttäjälle ensisijaisia
- Mitkä asiat on testattava ensin
Käyttäjäkeskeisten prioriteettien avulla voit keskittyä siihen, miten nämä ominaisuudet toteutetaan. Mitä tarvitaan, jotta käyttötapaus tai käyttäjävirta olisi sujuva ja intuitiivinen? Minkä on toimittava, jotta käyttäjävirta toimii tarkoitetulla tavalla? Mikä edellyttää käyttöliittymäelementtejä ja vuorovaikutusta ja mitä voi tapahtua konepellin alla? Näihin kysymyksiin vastaaminen johtaa yleensä monimutkaisempien teknisten ongelmien kartoittamiseen, jotka saattavat vaatia ratkaisua, ja antaa sinulle kehyksen, jonka varaan voit rakentaa mahdollisen tulevan kehityksen.
Yhteenveto
MLP:n toimittamisen alkuvaiheessa tehdään paljon työtä, jonka avulla saamme paremman käsityksen siitä, mitä asiakas haluaa rakentaa ja miksi. Tämä prosessi jatkuu koko kehitystyön ajan, ja työskentelemme usein iteraatioissa, jotka perustuvat parhaaseen ajan myötä kasvavaan ymmärrykseemme.
Tässä on lyhyt luettelo asioista, joita tarkastelemme tuotetoimituksen alussa:
- Asiakkaan ymmärtäminen: ymmärrämme asiakkaan taustan, hänen aiemmat pyrkimyksensä ja sen, miksi hän keskittyy ratkaisemaan ongelman ohjelmistotuotteella.
- Ongelman ymmärtäminen: ketä ongelma koskee, miksi se on korjattava ja mitä aiempaa työtä on tehty ongelman ratkaisemiseksi.
- Käyttäjien ymmärtäminen: miksi käyttäjät ovat huolissaan tästä ongelmasta, millaisia käyttäjäryhmiä ongelma koskee ja miten tuote sopii heidän nykyisiin työnkulkuihinsa.
- Prioriteettien ymmärtäminen: sen selvittäminen, mitkä tuotteen ominaisuudet ovat ratkaisevan tärkeitä ongelman ratkaisemiseksi, sen ymmärtäminen, mitkä ratkaisut ovat käyttäjille tärkeimpiä, ja niiden haasteiden löytäminen, joista meidän on huolehdittava alusta alkaen.
Seuraavaksi: tuotteen rakentaminen
Seuraavassa osassa menemme hieman syvemmälle Work in Progress -vaiheeseen, jossa alamme rakentaa ratkaisua ongelmaan: tuotetta. Kerromme, mitkä teknologiat toimivat mielestämme hyvin tämäntyyppisissä tuotetoimituksissa, ja annamme kuvan siitä, miltä kehitysprosessi näyttää.
Osa 2: Näin rakennamme Minimum Lovable Productin vuonna 2025 (julkaistaan myöhemmin).
Osa 3: näin rakennamme Minimum Lovable Productin vuonna 2025 (julkaistaan myöhemmin).
