Teimme WEMASYssa säännön: ei julkaisua, ennen kuin tuote kestää meidät
Jo matkamme alussa teimme yhden säännön, joka ohjaa jokaisen WEMASY-tuotteen rakentamista. Kutsumme sitä nimellä ”Kestä meidät ensin”. Se on yksinkertainen. Jos ominaisuus ei tue sujuvasti omaa päivittäistä työtämme, se ei ole valmis kenellekään muulle.
Tämä sääntö pitää meidät käytännöllisinä. Se estää rakentamasta esityksiä varten ja ohjaa rakentamaan oikeaa käyttöä varten. Se muistuttaa, ettei tuote onnistu silloin, kun se julkaistaan. Se onnistuu, kun ihmiset voivat käyttää sitä mukavasti joka päivä ilman, että he eksyvät, hämmentyvät tai väsyvät.
Miksi useimmat tuotejulkaisut epäonnistuvat
Katsoimme julkaisuja, jotka lähtivät lentoon, ja julkaisuja, jotka hiipuivat hiljaa. Mukana oli myös muutama oma varhainen versiomme. Ero oli harvoin itse idea. Ratkaisevaa oli, miten tuote kesti oikeaa, sotkuista arkikäyttöä. Ominaisuudet, jotka näyttivät hienoilta demossa, hajosivat kiireisinä päivinä. Pienet kitkat kasautuivat, ja ihmiset palasivat vanhoihin tapoihinsa.
Tässä muutamia havaintojamme:
Tiimit tekevät tuotteen julkaisupäivää eivätkä työpäivää varten. Ominaisuus loistaa esityksessä, mutta ei ohjaa seuraavaan vaiheeseen, kun käyttäjällä on kiire.
Pienet kitkat kasautuvat, kunnes käyttäjä luovuttaa. Yksi ylimääräinen klikkaus täällä ja piilotettu valinta tuolla tekevät työkalusta vähitellen raskaan käyttää.
Tuote odottaa käyttäjän sopeutuvan siihen. Sen sijaan että se sopisi ihmisten tapaan tehdä työtä, se pakottaa uuteen polkuun, jossa on enemmän vaiheita ja enemmän ajattelemista.
Todellinen konteksti on työkalun ulkopuolella. Tiedostot, palaute ja päätökset jäävät chatteihin ja sähköpostiin, joten tuotteesta ei tule koskaan ainoaa totuuden lähdettä.
Vastuut ja tavoitteet ovat epäselviä. Kukaan ei tiedä, kuka tekee seuraavan siirron tai mitä ”valmis” tarkoittaa, joten tehtävät pomppivat ja aikataulut venyvät.
Tuotetta ei käytetä sisäisesti päivittäin ennen julkaisua. Kun tiimi ei elä tuotteen kanssa, se ei huomaa arjen kipukohtia, jotka näkyvät vasta päivien oikean työn jälkeen.
Opimme myös omista virheistämme
Parhaat opit tulevat virheistä. Huomasimme, ettemme olleet immuuneja näille virheille. WEMASYn alkuaikoina mekin teimme ominaisuuksia, jotka olivat täysin järkeviä suunnittelupalavereissa. Kaikki olivat samaa mieltä, että idea oli hyvä. Mutta heti kun yritimme käyttää niitä päivittäisessä työssämme, tunsimme saman kitkan, jonka olimme nähneet muissa tuotteissa.
Se, mikä näytti näytöllä yksinkertaiselta, tuntui hitaalta, kun yritimme oikeasti saada tehtävän valmiiksi.
Polku, joka kuulosti keskustelussa selvältä, muuttui sekavaksi, kun kokeilimme sitä ilman taustatietoja.
Vaiheet, joita pidimme ”pikkujuttuina”, kävivät raskaiksi, kun ne toistuivat monta kertaa päivässä.
Huomasimme käyttävämme kiertoteitä työkalun ulkopuolella. Se oli selvä merkki siitä, ettei ominaisuus tukenut oikeaa työtä.
Tämä oli käännekohtamme. Ymmärsimme, että jos me emme pystyneet käyttämään ominaisuutta sujuvasti, vaikka tiesimme miten se on rakennettu, tavalliset käyttäjät kamppailisivat vielä enemmän. Mikään lanseerauksen markkinointisuunnitelma ei korjaa tuotetta, joka ei toimi arjessa. Silloin päätimme muuttaa tapaamme rakentaa ja julkaista tuotteita ja teimme siitä sisäisen säännön.
Näin julkaisemme tuotteen WEMASYssa
Oppiemme jälkeen julkaisuprosessimme muuttui yksinkertaiseksi. Jos haluamme käyttäjien tuntevan, että WEMASYn tuotteet toimivat heille, WEMASYn on ensin toimittava meille vaivatta. Siirryimme oletuksiin perustuvasta rakentamisesta kokemukseen perustuvaan rakentamiseen. Nyt jokainen tuote kulkee kolmen vaiheen läpi ennen kuin se tulee sinulle.
Kolme tärkeää vaihetta:
Vaihe 1. Rakennamme toimivan version ja käytämme sitä ensin itse
Heti kun ominaisuus toimii, siirrämme oman päivittäisen työmme siihen. Silloin totuus paljastuu. Näemme heti, mikä katkaisee työn kulun, mikä tuntuu raskaalta ja minkä pitäisi olla luontevampaa. Jos jokin hidastaa meitä, korjaamme sen. Jos joudumme miettimään liikaa tai käyttö tuntuu vaikealta, yksinkertaistamme sitä. Hiomme sitä, kunnes emme enää huomaa työkalua vaan vain sen, että työ tulee tehdyksi.
Vaihe 2. Jaamme sen pienelle joukolle nykyisiä WEMASY-käyttäjiä
Kun voimme käyttää sitä mukavasti, avaamme sen pienelle ryhmälle nykyisiä käyttäjiä, jotka antavat mielellään rehellistä palautetta. He näyttävät, miten ominaisuus toimii erilaisissa työtavoissa, aloilla ja tiimikoissa. Heidän palautteensa auttaa hiomaan kohtia, jotka ehkä ohitimme, koska meidän tapamme käyttää tuotetta ei ole ainoa tapa.
Vaihe 3. Julkaisemme sen kaikille vasta, kun molemmat osapuolet käyttävät sitä sujuvasti
Vasta kun ominaisuus toimii hyvin meille ja tälle ensimmäiselle ryhmälle, tuomme sen kaikkien saataville. Kun se tulee kaikille käyttäjille, se on vakaa, selkeä ja valmis käyttöön ilman koulutuspuheluita tai monimutkaista käyttöönottoa.
Rakensimme WEMASYn näin, koska olemme itse kokeneet työkalut, jotka näyttävät hyviltä mutta eivät auta kiireisenä päivänä. Kun käytämme omia tuotteitamme ensin, pysymme uskottavina, luotettavina ja rehellisinä. Jos uskot, että tuotejulkaisun strategiamme auttaa sinua, kokeile sitä ja kerro, miten se toimi brändillesi. Lisää verkkoon pääsemisestä luet blogistamme näin pääset alkuun verkkosivustosi kanssa. Katso myös verkkosivuston julkaisun tarkistuslista. Kokonaiskuvan saat pilariartikkelistamme mikä verkkosivusto on ja miksi tarvitset sellaisen.
Usein kysytyt kysymykset
Mikä tekee tuotejulkaisun strategiasta hyvän?
WEMASYssa opimme, että paras tuotejulkaisun strategia on sellainen, jossa tiimi käyttää tuotetta päivittäin ennen kuin kukaan muu näkee sen. Kun tunnet kitkan itse, korjaat oikeat ongelmat etkä niitä, jotka kuvittelit suunnitteluvaiheessa. Varhainen palaute 10-30 oikealta käyttäjältä tuo ulkopuolisen näkökulman, jota tiimilläsi ei voi olla. Kun julkaiset tuotteen kaikille, se toimii jo sotkuisissa, todellisissa oloissa.
Kuinka kauan sisäisen testauksen pitäisi kestää ennen tuotejulkaisua?
Vähintään kahdesta neljään viikkoa aitoa päivittäistä käyttöä. Nopea testaus viikonlopun aikana ei paljasta kitkaa, joka näkyy vasta toistuvassa käytössä. Tavoite on löytää pienet ongelmat, jotka kasautuvat päivien aikana, kuten ylimääräiset klikkaukset, sekavat polut tai puuttuva konteksti. Käyttäjät huomaavat nämä heti, mutta tiimit ohittavat ne usein.
Pitäisikö lanseerauksen markkinointisuunnitelma tehdä ennen kuin tuote on valmis?
Aloita suunnittelu ajoissa, mutta älä lukitse viestejä ennen kuin tuote on testattu. Lanseerauksen markkinointisuunnitelman pitää perustua oikeaan käyttäjäpalautteeseen eikä oletuksiin. Jos testaus paljastaa, että käyttäjät arvostavat eri hyötyä kuin odotit, markkinoinnin kulmaa pitää muuttaa. Tee suunnitelma rinnakkain, mutta pysy joustavana.
Mikä on tiimien suurin virhe tuotejulkaisussa?
Tuote tehdään julkaisupäivää eikä työpäivää varten. Monet tiimit kiirehtivät ehtiäkseen määräaikaan ja ohittavat oikean testauksen. Tuote näyttää hienolta esityksessä, mutta turhauttaa käyttäjiä kolmantena päivänä. Ylimääräinen viikko kunnollista testausta säästää kuukausia julkaisun jälkeisiä korjauksia ja kielteistä palautetta.
Kuinka monella varhaisella käyttäjällä pitäisi testata ennen julkista julkaisua?
Aloita 10-30 käyttäjällä, jotka edustavat todellista kohderyhmääsi. Heidän pitää olla ihmisiä, jotka käyttävät tuotetta säännöllisesti, eivät vain ystäviä, jotka klikkailevat kerran. Heidän palautteensa on arvokkaampaa kuin satoja kyselyvastauksia, koska he kokevat oikean kitkan, jonka satunnaiset testaajat ohittavat.
Miten WEMASY testaa omat tuotteensa ennen julkaisua?
Jokainen WEMASYn ominaisuus kulkee kolmen vaiheen läpi: tiimin oma päivittäinen käyttö, testaus pienellä joukolla nykyisiä käyttäjiä ja vasta sitten julkinen julkaisu. Jos ominaisuus ei toimi sujuvasti tiimille ja varhaisille käyttäjille, sitä ei julkaista. Näin jokainen työkalu on vakaa, selkeä ja valmis oikeaan työhön ensimmäisestä päivästä alkaen.
