Visiolakana on tuotteen tai digitaalisen palvelun hissipuhe

Visiolakana on Withmoren kehittämä tiivistys tuotteen tai palvelun tarkoituksesta ja toteutusideasta. Se palvelee tuoteomistajaa, tuotteen kehitystä ohjaavia ja kehitystyön tekijöitä tarjoamalla keskustelun pohjan tärkeimmistä tuotteen ydinkysymyksistä. Se sopii esim. tietojärjestelmän tai digitaalisen palvelun toteutusvision kuvaamiseen. Visiolakanan vahvuus on, että se pakottaa käymään tuotteen tärkeät keskustelut ja tekemään painotuksia eri tarpeiden ja näkökulmien välillä.

Visiolakanan täyttämisen fasilitointi

Vahva suositus on, että visiolakana täytetään keskustelemalla eri tahojen kanssa. Yleensä tuoteomistajan on sitä täyttäessään hyvä keskustella ainakin kehitystä ohjaavan ylemmän johdon ja eri intressitahojen, arkkitehtuurikysymyksistä vastaavien sekä toteutusta suunnittelevien kanssa (käytännössä esim. ohjausryhmä, organisaation oma IT, toteutusteknologian markkinatilannetta tuntevata asiantuntijat ja toteutustiimi).

Visiolakanan keskustelua katalysoiva voima saadaan parhaiten käyttöön, jos se täytetään työpajamuotoisesti postit-lapuilla esim. kokoushuoneen seinällä tai  digitaalisella yhteistyöskentelyalustalla. Tällöin kaikki keskusteluun osallistuvat kirjoittavat ensin esiin oman kantansa kuhunkin visiolakanan kysymykseen, jonka jälkeen päästään kiinni tärkeisiin kysymyksiin, kuten: Kolme teistä ajatteli että palvelun tärkein käyttäjä on sen kirjautumaton käyttäjä, mutta kaksi taas tuumasi että palvelun ylläpitäjä. Millaisia perusteluita teillä on? Voitaisiinko löytää yhteinen kanta?

Ajattelun erojen näkyväksi tekemisestä seuraava keskustelu on yleensä tuotteen kannalta erittäin hyödyllinen, ja sen käyminen mieluummin aikaisessa kuin myöhäisessä vaiheessa auttaa välttämään jatkossa monta hankausta tuotteen kehityksen ohjaamisessa.

Ketkä osallistuvat ja milloin?

On tyypillistä, että visiolakanan kaikkiin kysymyksiin ei pystytä vastaamaan samalla kertaa. 

Vastaajien kokoonpano vaihtelee kysymyksestä riippuen - esim. toteutusvisiokeskusteluun pystyvät kontribuoimaan lähinnä toteutustiimin edustajat, kun taas tuotteen liiketoimintamittareita pohtimaan tarvitaan tyypillisesti ohjausryhmä tai johto. 

On myös tavallista, että käyttäjän tarpeisiin ja liiketoimintamittareihin liittyviin kysymyksiin pystytään vastaamaan pian tuoteidean keksimisen jälkeen, kun taas rajausten tai toteutusvision hahmottuminen voi viedä esim. joitain kuukausia. Vastausten puute kertoo jatkoselvitysten tarpeesta.

Visiolakanan sisältö

Visiolakana koostuu yhdeksästä kentästä, jotka on numeroitu suositellun täyttöjärjestyksen mukaan:

1. Kenelle. Kuka on palvelun tärkein käyttäjä? Tähän tekee mieli yleensä luetella ainakin viisi ryhmää joista yhtään ei voi sulkea pois. Tarkoitus olisi kuitenkin päätyä vastaukseen siitä, ketä käyttäjistä suositaan jos on pakko tehdä valintoja ryhmien välillä. Usein on. Jos päädytään siihen että on kaksi ryhmää jotka ovat täysin elimellisiä (esimerkiksi kirjautumaton käyttäjä ja ylläpitäjä), näille voi täyttää molemmille omat kohdat 1-4 vaikka eri post-it-värillä.
   
   

2. Tarve. Millainen tarve pääasiallisella käyttäjällä on? Mitä hän haluaisi saada tehdyksi ja mikä nykyisissä ratkaisuissa on vikana? Lakanan kohdassa kysytään myös siitä, miten tämä käyttäjän tarve on todennettu. On parempi, että tarve on todennettu esim. käyttäjätutkimuksella tai haastatteluilla, kuin että palveluiden kehittäjinä luotamme peukalotuntumaan. Jälkimmäinen voi nimittäin välillä osua pieleen.
   
   

3. Ratkaisu. Millaisella perusidealla ajattelimme ratkaista käyttäjän tarpeen? Esim. Spotify voisi sanoa ratkaisevansa liikkuvan musiikinkuuntelijan tarpeen tarjoamalla kaiken maailman musiikin suoratoistona useampiin eri laitteisiin, tai lähiliikenteen mobiilisovellus voisi kertoa mahdollistavansa reitin suunnittelun ja lipun ostamisen samassa sovelluksessa.

4. Käyttäjäpalaute. Miten palvelun tai tuotteen kehittämisen varrella aiotaan varmistaa, että todella onnistutaan käyttäjän ongelman ratkaisemisessa? Yleensä vastauksena on aikaisessa vaiheessa tehtävä prototyyppi ja sen käyttäjätestaus, joilla varmistetaan että toteutusidea toimii. Näillä varmistetaan että iso investointi kehitystyöhön oikeasti kannattaa. Myöhemmin palautteen saaminen voidaan varmistaa mm. pilottikäytöllä, jota laajennetaan kehityksen edistyessä.
   
   

5. Ainutlaatuinen arvo. Tuotteella on aina kilpailijoita - myös silloin kun ei siltä ensi katsomalta tunnu. Käyttäjät voivat aina valita olla käyttämättä tuotetta, tehdä vanhalla tavalla tai soittaa asiakaspalveluun. Mikä valitsemassamme ratkaisussa varmistaa, että käyttäjät haluavat käyttää meidän tuotettamme kilpailevien vaihtoehtojen sijaan? Monesti vastaukset löytyvät esim. helppokäyttöisyydestä tai kilpailevia ratkaisuja edistyneemmistä ominaisuuksista.
   
   

6. Toiminnan mittarit. Siinä missä käyttäjäpalautteessa halutaan saada nopeasti signaalia onnistuneesta suuntavalinnasta, toiminnan mittareilla halutaan varmistaa että tuotteesta saadaan pitkällä tähtäimellä irti siltä toivottu hyöty. Haetaanko tällä tuotteella uudenlaista myyntiä, parempaa asiakastyytyväisyyttä, tehokkaampaa toimintaa vai kaikkia näistä? Millä mittareilla saamme nämä käytännössä todennettua?
   
   

7. Avainresurssit ja kyvykkyydet. Millaista osaamista erityisesti tarvitsemme, että saamme suunnittelemamme ratkaisun toteutettua? Yleensä kyse on teknisestä osaamisesta, mutta millaisia referenssihankkeita pitää löytyä juuri meidän tuotteemme teknisten toteuttajien taustalta? Missä asioissa heidän pitää olla erityisen kyvykkäitä?
   
   

8. Rajoitukset. Yleensä tuotteen toteutusta rajoittavat monet asiat: tavoiteaikataulu jolla voi olla pakottavia syitä, toteutus- ja ylläpitobudjetti, säännöksiä jotka vaikuttavat toteutukseen, teknisiä rajoituksia, arkkitehtuurivaatimuksia tai integrointitarpeita, tietoturva-, tietosuoja- ja saavutettavuusvaatimuksia jne. Ne on hyvä tiedostaa jo ennen kuin lähdemme varsinaisesti suunnittelemaan toteutusta.
   
   

9. Toteutusvisio. Viimeisenä mutta ei vähäisempänä, kaiken edellisen valossa: millainen toteutusideamme on lyhyesti? Olemmeko korvaamassa jotakin olemassa olevaa? Millä teknologialla toteutamme ja miten huolehdimme, että toteutus on kustannustehokas ja aikaa kestävä? Onko valmisratkaisuja joille voimme nojata? Esimerkiksi CRM-hankkeen toteutustiimi voisi kertoa korvaavansa olemassa olevan järjestelmän SaaS-ratkaisulla, mikä vaatii organisaation käytäntöjen sopeuttamista valittuun järjestelmään.
   
   

Visiolakanan esityöt

Jotta visiolakanan pystyy täyttämään, on monesti pitänyt tehdä kohtuullisen paljon esityötä. Monesti käyttäjän tarpeita on selvitettävä käyttäjäkyselyillä ja -haastatteluilla sekä edellisen järjestelmän analytiikasta, tulevan järjestelmän taustaprosessi on hahmoteltava organisaation asiantuntijoiden kanssa arvovirtakartoituksella ja erilaiset toteutusvaihtoehdot on selvitettävä markkinakartoituksella.

Vaikka visiolakana on näennäisesti esitystavaltaan yksinkertainen, sillä on taipumuksena paljastaa aukot ja ristiriitaisuudet ajattelussa tuotteen ympärillä. Se on hyvä asia: mitä aikaisemmin saamme tuotteen avoimet kysymykset keskustelun alle eri osapuolien kesken, sitä paremmat onnistumisen mahdollisuudet meillä on.

Ota käyttöön: Lataa visiolakana tiedostona 

Visiolakana on Withmore Oy:n Karoliina Luodon ja Miika Kuhan edelleen kehittelemä versio Alex Osterwalderin / Business Model Foundryn Business Model Canvasista sekä Ash Mauryan / Lean Foundryn Lean Canvasista. Se on käytettävissä ja jatkojalostettavissa Creative Commons 3.0 -lisenssillä Nimeä - JaaSamoin.

Visiolakana on tuotu kehittäjiensä toimesta osaksi usean organisaation ketterän kehittämisen menetelmää, mm. Helsingin kaupungin kehittämismenetelmäohjeistoa (Kehmet).