Kuinka välttää mielipidepohjaista tuotteiden priorisointia

Löydä oivalluksia, joiden avulla voit ohjata päätöksentekoa datan avulla ja hallita sidosryhmiä paremmin

Päätösten tekeminen on vaikeaa. Ja useat kilpailevat mielipiteet, sidosryhmät ja peliin liittyvät etunäkökohdat vaikeuttavat niitä useimmissa organisaatioissa. Joskus suurin este rationaalisen päätöksenteon tekemiselle voi olla toimitusjohtaja tai talousjohtaja, jonka erittäin vahvoille näkemyksille voi olla vaikea vastustaa.

Joten kuinka menestyvät sovelluskehittäjät välttävät tuoteominaisuuksia ja markkinointia koskevia päätöksiä, koska ne eivät ole parhaiten maksettujen tai pysyvimpien ääniä?

Minulla oli äskettäin tilaisuus tutkia tätä kysymystä. Haastattelin noin 20 parhainta kehittäjäämme, samoin kuin Googlen insinöörejä, Google-tuotepäälliköitä ja kasvujohtajaita. Näiden haastattelujen perusteella oli selvää, että haastatelluilla oli kolme avainkäyttäytymistä, jotka vastaavat tähän haasteeseen:

  • He kokeilevat mahdollisuuksiaan tutkiakseen.
  • He asettavat datan prosessin ytimeen.
  • He levittivät tätä tiedon ja tiedon jakamisen kulttuuria koko organisaatiossaan.

Tässä artikkelissa tarkastelen yksityiskohtaisesti kahta esimerkkiä näistä käytöksistä. Ensimmäisessä tapauksessa minulla oli tilaisuus valita tärkeysjärjestysmenetelmä, jota käytetään usein Googlessa sisäisesti, ja testata se Iso-Britannian sovelluskehittäjän 1tap avulla. Sitten olen ollut onnekas saamaan sisäisen radan prosessissa, jota vuoden 2017 voittaja Memrise-sovellus käyttää.

1tap ja North Star -menetelmä

Piilaaksosta lähtöisin oleva North Star -metriikan käsite on ollut olemassa jo jonkin aikaa. Googlessa muun muassa YouTuben ja Gmailin tiimit käyttävät suuntautumista pohjoisen tähden metrin ympärille rakennusominaisuuksien priorisoimiseksi. Haastatteluistani löysin kuinka hyödyllinen se on joukkueillemme ja pohdin, voisiko se auttaa myös sovelluskehittäjiä. Googlessa meillä on kasvutiimi, joka on toiminut prosessin johtajana, joten valjasin tämän tiimin työskentelemään 1tap: n kanssa.

Joten, mikä tämä menetelmä on? Käsitteellisesti se on todella yksinkertainen; komponentteja on vain neljä: North Star -metriikka, käyttäjän vuokaavio, kasvumalli ja laskentataulukko. Koska mitä tietopohjaista mallia on täydellinen ilman laskentataulukkoa, katsokaamme sitä?

Katsotaanpa tarkemmin kutakin näistä komponenteista ja kuinka ne soitettiin yhdellä painalluksella.

Aseta North Star -metriikka

Tämä on metriikka, joka yhdistää kaiken tekemäsi työn ja arvostat suorittamasi hankintaa, sitoutumista, muuntamista ja pidättämistä. Joten jos olisit hotellin varaussovellus, tämä tieto on varattu öisin, kun taas viestisovelluksessa se olisi lähetetty viesti.

1tapin tehtävänä on tehdä itsenäisestä ammatinharjoittamisesta helpompaa kuin palkata. Heillä on kaksi sovellusta: 1tapin kuitit, jotka tarjoavat automaattisen tiedonkeruun ja kirjanpidon, ja 1tap vero, joka arvioi veronmaksut automaattisella kuitilla ja laskujen skannauksella.

Tätä harjoitusta varten tarkastelimme 1 tapauskuitit. Määritimme erittäin nopeasti North Star -metriikan 1tap-kuittien piti olla tapahtumista. Kuitenkin, kun Jon Butterfield, 1tapin kasvunjohtaja, toteaa, että täällä on hankala osa ja se asia, joka heitti meidät pois, oli mikä tärkeämpää, lisäämällä käyttäjiä paljon kuitteja vai paljon käyttötarkoituksia vain lisäämällä muutama kuitti? ”Tarkasteltaessa tarkkaan arvoa, jota 1tap-kuitit tarjoavat käyttäjille, oli selvää, että jos käyttäjät tallentavat enemmän tietoja, 1tap-kuitit voivat auttaa heitä paremmin veroissaan. Tuloksena on North Star -muuttuja, joka koskee kaikkia käyttäjiä koskevia tuloja ja mitä enemmän tuloja sitä parempi.

Määritä käyttäjän virtaukset

Tavoite tässä on kaksitahoinen. Ensinnäkin vahvistaaksesi, että sovelluksesi sisältää palautussilmukoita, jotka edelleen tuovat käyttäjän takaisin. Toiseksi, sinun on tutkittava mittarisi ja määritettävä, kuinka onnistut liikuttamaan käyttäjiä näiden piirien läpi. Prosessi on yksinkertainen, sinä:

  • Määritä sovelluksesi tärkeimmät tapahtumat.
  • Piirrä virtaukset tapahtumien välillä.
  • Käytä analyyttisiä tietoja käyttäjien prosentuaalisen osuuden määrittämiseksi kullakin virtauksella.

Löydät, että kaaviossa on 3 pääosaa: hankinta- ja säilytyspiirit, ja avain virtaa tuotteen sisällä.

Hankinta-lähteet ovat tärkeimmät tavat, joilla käyttäjät asentavat sovelluksesi. Voit hankkia nämä tiedot Play Console -sovelluksen kohdasta Käyttäjähankinta. Varmista vain, että olet lisännyt UTM-tunnisteet kaikkiin markkinointi-URL-osoitteisiisi ja yhdistä AdWords-tilisi täydelliseen näkyvyyteen.

Tuotekäyttäjät viittaavat yritykseesi, mutta todennäköisesti niihin sisältyy sisäänkirjautuminen, koneeseen kytkeminen ja muuntaminen (jos olet maksullinen sovellus). Todennäköisesti välittävään virtaukseen tulee maaginen hetki, josta välität todella, koska se on tärkeä sitoutumisen ja tuloksen osoitin, varmista, että sisällytät sen.

Viimeinkin tapahtuu uudelleen sitoutumista, joka saa käyttäjät palaamaan sovellukseen.

Kun kaavio on valmis, kaikki yrityksesi yritykset voivat puhua tuotteesta samalla tavalla ja ymmärtää, kuinka heidän toimintansa - hankinta, sitoutuminen, muuntaminen ja säilyttäminen - vaikuttavat North Star -mittareihin.

1 tapauskuitien tapauksessa tämä harjoitus tuotti seuraavan visualisoinnin.

Huomaat, että tässä käyttäjävirrassa ei ole mitään analytiikkaa. 1tap: n kannalta tärkein tulos oli tuotteen virtauksen ymmärtäminen ja keskittyminen tärkeimpiin komponentteihin, jotka “liikuttavat neulaa”. Yksi tärkeä tulos oli wow-hetken tunnistaminen. 1tap-kuiteissa osoittautui ”Aktivoi käyttäjä” -vaihe, jossa he lisäävät kuitin. "Sen saaminen, että käyttäjä näkee tietonsa automaattisesti, osoittaa tuotteen arvon heti, ja yllättää monia ihmisiä OCR-tekniikan tarkkuudella", Jon sanoo.

Lopullinen käyttäjän vuokaavio syntyi noin 10 iteraatiosta. Ensimmäisessä oli Jonin sanoin ”tuhansia ja tuhansia erilaisia ​​asioita siinä ja se oli vain sotkua.” Sitten työskentelimme yhdessä yksinkertaistaaksesi esitystä keskittyäksesi käyttäjän matkojen keskeisiin hetkiin. Se auttoi myös 1tap-kysymystä kysymyksestä ominaisuuksista, jotka eivät päässeet kaavioon, ”jos sitä ei sisälly ydinvirtaan, tarvitaanko sitä jopa?” Kuten Jon huomauttaa, “sovelluksen siistiminen ominaisuuksilla voi tappaa käytettävyyden .”

Seurauksena 1tap havaitsi myös, että heillä oli tauko käyttäjän palautteen silmukoissa. Tämä tauko tapahtui toiminnoissa, jotka on esitetty kaaviossa oranssina ja jotka liittyvät tapahtumadatan vientiin. Seurauksena oli, että 1tap muutti tapaa, jolla käyttäjät vievät tietojaan ja missä he pääsevät vientiin. He kokeilevat edelleen, mutta pitämällä monia raportteja sovelluksessa ne ovat lisänneet säilyttämistä.

Luo kasvumalli

Seuraava askel on kasvumallin rakentaminen. Käytämme tietoja käyttäjävirroista ja ohjaamme North Star -metriikkaa kasvutekijöiden määrittämiseen. Nämä ovat ohjaimia, jotka parantavat heikkouksien alueita ja rakentavat vahvuuksia.

Kuten alkuperäisessä käyttäjien vuokaaviossa, rakennetun kasvumallin 1tap ensimmäinen versio oli melko monimutkainen, ja se ulottui noin 16 sivulle. Keskittymällä tärkeään kohtaan nousi pian selkeä ja toimiva kasvumalli. Tämä kasvumalli voidaan tiivistää seuraavasti:

Täällä otsikko on käyttäjää kohden lisätyt kuitit, jotka sinun tulisi tunnistaa: se on North Star -mittari. Tämä otsikko jakautuu kuittausten lähettämiseen jaettuna kuukausittain aktiivisten käyttäjien (MAU) kesken. Tämä puolestaan ​​jakautuu edelleen mekanismeihin, joita käyttäjät voivat käyttää kuittausten lisäämiseen - skannaukseen, sähköpostitse lähettämiseen ja manuaaliseen kirjoittamiseen - sekä uusien ja palauttavien käyttäjien käyttämiseen.

Kun he alkoivat ensimmäistä kertaa koodata tuotteitaan, 1tap keskittyi analytiikkaan. He seurasivat melkein kaikkea mitä käyttäjä tekee sovelluksessa. Kuten Jon toteaa, "tästä olemme todella ylpeitä", Jon sanoo. ”Ennen kuin tiesimme sen, kärsimme kuitenkin analyysihalvauksesta. Koska meillä oli niin paljon valintaa, emme tienneet, mistä aloittaa käyttäjien ja heidän käyttäytymisensä ymmärtäminen. Malli auttoi meitä keskittymään tarjoamaan arvoa ja helpotti meitä North Star -mittareiden toimittamisessa. ”

Mutta kuten Jon selittää, tämän kasvumallin kehittämisen tärkein etu oli, että sen avulla oli helpompaa selittää toimitusjohtajalle, mistä MAU tulee, ja sitten talousjohtaja näki, mistä tulot myös tulevat. Lisäksi tuote pystyi näkemään, mitkä vivut vedetään lisäämään eniten arvoa.

Luo laskentataulukko

Viimeinen vaihe on siirtää malli laskentataulukkoon ja arvioida mahdollisuutesi nähdäksesi, miten ne vaikuttavat kasvuun.

Et todennäköisesti ylläty, kun tiedät, että 1tapin kasvumalli on käännetty suureksi laskentataulukkoksi. Mutta tällä kertaa koko oli tärkeä. Tässä on katkelma siitä, mitä Jon ja 1tap-joukkue kutsuvat ”Laskimeksi”.

Tämän laskentataulukon puitteissa 1tap aloitti tutkimuksen siitä, miten erilaiset toiminnot vaikuttavat käyttäjää kohti lisättyihin kuittauksiin 10 päivän aikana. Jon huomauttaa, että yksi varhaisista eduista oli, että he pystyivät näkemään pienten muutosten vaikutukset. Esimerkiksi parantamalla lataamista rekisteröintimuutokseen vain 2%, kokonaisvastausten lukumäärä parani 100%. Sitä vastoin rekisteröinnin parantaminen aktivointimuunnokseksi vaikuttaisi vain kuitumäärään 75%.

Seurauksena oli, että 1tap ryhtyi enemmän pyrkimyksiin saada wow-momentti (ja rekisteröinti) aikaisemmin käyttäjämatkoihin sen sijaan, että pumppaisi enemmän rahaa hankintaan.

Joten mitä tämä prosessi ja malli saavuttivat 1tap: lle?

"Ensimmäinen asia, jonka meille antoi, oli selvyys - kaikilla osastoilla - mitä teemme", Jon sanoo. Joten toimitusjohtajamme Nickin ei tarvinnut enää kysyä mistä MAU tuli ja miten voisimme lisätä sitä. Se on yhtä selkeää kuin päivä tässä mallissa. Samoin tuotteen ei tarvinnut kysyä, mitä aiomme tehdä seuraavaksi? Mikä on prioriteetti? Nämä päätökset perustuvat nyt kaikki laskimeen. Ja CFO tiesi, että lisäämällä tuloja kasvatimme pidätystä. Joten kasvumallista kaikki voivat nähdä, mitä tapahtuu seuraavaksi. ”

Toinen tärkeä vaikutus oli ymmärtäminen kuinka lisätä yritysostoja. ”Suuri asia, jonka tajusimme, on, että meidän pitäisi asettaa paljon etusija kirjanpitäjille. Emme ole oikeasti tehneet tätä aikaisemmin, joten se oli valtava herätys ”, Jon sanoo. "Tämä on iso vipu, ja oli selvää, että jos panostamme enemmän kumppanikanaviin, voisimme saada paljon enemmän käyttäjiä suhteellisen helposti ja meillä olisi sisäänrakennettu mekanismi, heidän kirjanpitäjänsä, auttaaksemme heitä säilyttämään."

Jon toteaa myös toisen tärkeän aloitusvaikutuksen, ja se tapahtui uusien vuokralaisten kanssa. ”Ilman laskimen tietoja voisimme helposti palkata väärät ihmiset väärään aikaan. Mutta nyt tiedämme, milloin ja ketä meidän pitäisi palkata maksimoidaksemme kasvumme. "

Memrise

Kielisovellus Memriseä käyttää 35 miljoonaa ihmistä oppimaan kielivalintansa yli 200 kieliparista. Memrisen kasvupäällikkö Kristina Narusk kuvaa yrityksen menneisyyden matkaa ainutlaatuiseksi osittain siksi, että ”meillä on ollut melko onnekas, että saamme toimitusjohtajaksi Ed Cooken, koska hän on yksi luovimmista ja kokeellisimmista ihmisistä siellä, Samanaikaisesti on hienoa johtaa kasvavaa joukkuetta ja kasvaa liiketoimintaa ”. Edin lähestymistapa injektoi paljon out-of-the-box-ajattelua yritykseen. Haittapuoli, jos pystyt kuvaamaan sitä sellaisenaan, on haaste hallita luovia ideoita löytää ideat, jotka kasvavat sovelluksesta.

Kristina kertoi minulle yhdestä sellaisesta esimerkistä, jossa eräänä sunnuntaiaamuna noin kolme vuotta sitten hän sai Ediltä tekstin sanoa olevansa Skotlannissa, ostanut kaksikerroksisen linja-autoa ja matkalla Eurooppaan kiertämällä videoita äidinkielenään puhuvista lauseita ja lauseita. "Se oli melko ainutlaatuinen kokemus saada tällainen viesti", Kristina sanoo. "Joten meidän piti keksiä keinoja käsitellä tällaista epäkunnioittavaa ideaa, ei vain Edin ideoita, vaan koko joukkuetta, ja muuttaa niistä onnistuneita sovellusominaisuuksia."

Memrise keksi tapa suodattaa nämä ideat kuuden kriteerin avulla:

  1. Täytyy olla toistettavissa. Sen on oltava mahdollista aloittaa pienellä MVP: llä ja sitten iteroida, jos se onnistuu.
  2. Vaikuttaa välittömästi. Heti kun ominaisuus otetaan käyttöön käyttäjille, sen tulisi tuottaa käyttäytymismuutos, joka on havaittavissa metrissä.
  3. Vaikuttaa pysyvästi. Sen on hyödyttävä käyttäjiä pitkään, ei vain viiden ensimmäisen minuutin tai ensimmäisen päivän aikana.
  4. On oltava mitattavissa. On oltava tapa mitata sen vaikutus käyttäjiin ja sovelluksen menestykseen.
  5. Hänellä on lokalisoinnin voima. Sen on oltava jotain, joka voidaan toimittaa useimmille, ellei kaikille, sovelluksen markkinoille.
  6. Täytyy sopia johdonmukaisesti sovellukseen. Idean on sovittava sovellukseen ja järkevä.

Ominaisuuden löytämisvaiheessa joukkue pelataan sitten ennustuspeliä arvioidaksesi kuinka ominaisuuden idea on linjassa kriteerien kanssa. Vain kaikki ehdot täyttävät ideat kulkevat arviointisuodattimen läpi ja kulkevat Memrisen kehitysprosessiin.

Kuten Kristina selittää, Memrise jakoi tämän luovan ja kokeellisen ajattelutavan jokaisessa yrityksen joukkueessa tuotekehityksen elinkaaren neljään vaiheeseen: löydä, määrittele, kehitä ja seuraa.

Löytövaiheessa tuoteryhmä luonnostelee, piirtää, suunnittelee, prototyyppejä ja käyttäjä testaa ideaa. Kokeita suoritetaan malleille, UI-prototyypeille ja sisältöprototyypeille. He voisivat esimerkiksi rakentaa jotain, jonka avulla he voivat saada satunnaisia ​​ihmisiä kadulta testaamaan. Muut kokeilut saattavat käyttää online-resursseja (kopioiden, painikkeiden ja värien testaamiseen) tai Memrise-käyttäjiä pitkittäiskurssin sisältökokeisiin. Koko tuote- ja suunnittelutiimi on mukana tässä vaiheessa, ja tutkijat, kieliasiantuntijat ja kehittäjät istuvat testisessioissa. Yksi haaste, jonka Kristina on löytänyt tällä prosessilla, on tarkkailijoiden hiljaisuus. "Kehittäjät ovat erittäin hiljaisia ​​koodaamisessa," sanoo Kristina, "mutta heistä tulee yleensä äänekäs, kun he näkevät ihmisten käyttävän tuotetta" väärin "."

Memrise Membus -tapauksessa (Ed: n skotlantilainen hankinta) löytövaiheen aikana linja-auto meni Oxfordiin kuvaamaan joitain englanninkielisiä videoita nähdäkseen, onko idealla järkeä ennen kiertää muualla Euroopassa. Videoiden lisääminen Memrise English -kursseille oli vähimmäiskykyinen tuote (MVP), ja sen varmistaminen, että linja-auto pysyi yhtenä kappaleena pidempiä matkoja kuin ajomatka Memrisen toimistosta Itä-Lontoosta Oxford Circusiin, oli enemmän haaste. Tärkeintä on kuitenkin, että testi osoitti, että videoilla oli positiivinen vaikutus tilaustuloksiin ja videoiden tuotantokustannukset olivat riittävän alhaiset perustelemaan siirtymistä muille kielille. Joten kävi ilmi, että oli hyvä idea ostaa linja-auto Skotlannista ja muuttaa siitä sitten video-ominaisuus.

Testatun idean kanssa joukkue siirtyy määrittelemään, missä he luovat yksityiskohtaisen erittelyn kaikilla kuvatuilla toiminnoilla ja piirretyillä käyttöliittymillä. Se määrittelee myös ominaisuuden suorittamat kokeilut, mukaan lukien yksityiskohdat, kuten:

  • Kohdealusta
  • Kohdenna oppijoille
  • Kohdekieli
  • Kokeen pituus
  • Mitä tarvitaan seurantaa
  • Mitä analytiikan hallintapaneelissa tulisi olla

Myös datatiimi osallistuu. Ne auttavat varmistamaan, että ominaisuus on rakennettu oikeiden datapisteiden sieppaamiseksi, jotta tuoteryhmä voi arvioida ominaisuuden vaikutuksia. Videot käytettiin premium-oppimismoodin luomiseen, ja niitä tarjottiin osana Pro-tilausta. Siksi oli tärkeää ymmärtää, kuinka suuri vaikutus muuntamisprosenttiin Prossa on tämän moodin lisäämisellä englannin kielelle. Vaiheen lopussa koko joukkue toimii tuomaristona antaa palautetta tuoteideoista ja haastattelutuloksista.

Kun kaikki on valmis ja valmis, kehitysryhmä alkaa kehittää ominaisuutta. Koska kehitystiimi on ollut mukana etsinnässä ja vaiheiden määrittelyssä, kehitys on yleensä suoraviivaista, koska monet oletukset on testattu ja ominaisuuden rakentamisen liiketoiminnallisista syistä on enemmän varmuutta.

Kun kehitys on valmis, tuotepäällikkö voi kytkeä ominaisuuden päälle, jotta käyttäjät näkevät, mitä on rakennettu, ja aloittavat kokeilut.

Sovelluksen uuden version ulkopuolella joukkue voi siirtyä seurantavaiheeseen. Tässä vaiheessa ryhmä etsii vastauksia kysymyksiin, kuten: Kuinka ominaisuuden KPI-arvot suoriutuvat? Mikä on käyttäjän alkuperäinen palaute? Kuinka uusi julkaisu vaikuttaa sovellusten arvosteluihin? Toivottavasti, kuten Kristina kuvaa, se on ”iloinen hetki katsellen, milloin ja miten tulokset tulevat”.

Memrise-palvelussa heillä on vakio mittari ja kuvaajat jokaisesta kokeesta, joka menee ulos. "Päivänä julkaisun jälkeen löydät meidät päivittämään tätä sivua koko ajan", kertoo Kristina, "nähdäksesi, kuinka ominaisuus ja uusi idea toimivat. Tiimimme tapauksessa se osoittaa sinulle iloa ja hauskaa nähdä tulokset ja oppia, rakensimmeko jotain erittäin menestyvää, josta ihmiset nauttivat, vai onko meidän palattava takaisin taululle ja aloitettava uudelleen ajattelu. ”Memrise Membus-matka päättyi päätökseen lisätä videoita ja erityinen Opi paikallisten kanssa -tila kaikille kielille.

johtopäätös

Sanoin tämän artikkelin alussa, että päätöksenteko on vaikeaa. Vältä mielipideperusteisia päätöksiä, ehkä, entistä vaikeammin. Jakamalla kuitenkin kaksi hyvin erilaista lähestymistapaa tuotepäätöksentekoon, toivon, että olen antanut sinulle ideoita prosessin tehostamiseksi ja rationalisoimiseksi yrityksessäsi. Huolimatta valitsemastasi tai luomassasi prosessista on tärkeätä, että prosessi kattaa kaikki organisaatiosi ja tuoteryhmän jäsenet. Viime kädessä etsimme tietoja, jotka auttavat tunnistamaan oikeat muutokset tai harjoitettavat toimet.

Mitä mieltä sinä olet?

Onko sinulla ajatuksia päätöksenteosta ja priorisoinnista? Kerro meille alla olevissa kommenteissa tai twiittiä käyttämällä #AskPlayDev ja vastaamme @GooglePlayDeviltä, ​​jossa jaamme säännöllisesti uutisia ja neuvoja siitä, kuinka menestyä Google Playssa.