Innlegg skrevet av Hallgeir Knutsen, produktansvarlig og partner i Reodor. 

Hvordan ignoranse og feilsteg bidro til et produkt som i dag hjelper noen av landets ledende merkevarer med å utvikle smartere og bedre løsninger.

Gjennom mitt tidligere selskap New York Digital Labs, ledet jeg blant annet design- og utviklingsarbeidet til den norske startupen vidFlow. vidFlow var en streamingtjeneste for musikkvideoer, med et radarpar av noen gründere i Nassir Achour og Shire Standnes. Sammen jobbet vi på startupen som høstet mye skryt i media, fikk massevis av brukere, startup-priser, hentet millioner fra investorer og satt rekord for equity crowdfunding i Norge i 2014.

Med andre ord var vi en lovende startup. For å følge med på utviklingen var også vi opptatt av metrics. Vi fulgte nøye med på antall besøk på siden, nye medlemmer, nye premium-brukere, og til en viss grad hvor mange videoer som ble sett hver dag.

Noen som skjønner problemet allerede her?

Jeg havnet i en veldig vanlig felle og lot meg lure av hva de over dammen kaller “vanity metrics” — metrics som ser bra ut i Google Analytics, men som faktisk ikke betyr noe for suksessen i produktet ditt. Dette er gjerne unike besøk, tid på siden, sidevisninger, og til og med nye registrerte brukere. Bra vekst på disse tallene er gull om du er VG, hvor mer besøk fortsatt betyr mer annonsepenger (en liten stund til). Men for alle som ønsker å bygge et digitalt produkt som skal leve av å gi en verdi til brukeren, så har ikke disse tallene reell verdi.

– Sykt å tenke tilbake på

Å forstå metrics er en rar ting. Før man har kommet inn i det, og kanskje brent seg på det, er dette en “verden” man ikke helt skjønner. Men først når man virkelig har fått følt det på kroppen, er det sykt å tenke tilbake på at man ikke forsto noe så grunnleggende. Sånn føles det å se tilbake på tiden i vidFlow.

Alle tallene vi målte var riktige å se på, men ingen av de viste oss om vi faktisk ga verdi til brukerene. Hvor mange brukere kom inn i tjenesten og så mer enn fem videoer? Hvor mange kom tilbake neste dag eller neste uke for å se på flere videoer? Av de som faktisk betalte for premium, hva hadde de gjort før de bestemte seg for å betale for tjenesten? Hvor mange var fornøyde med den neste videoen vi automatisk viste de?

Dette var helt essensiell innsikt for å spore om vi klarte å skape en tjeneste som betyr noe for brukerne våre, eller om vi måtte endre på deler av produktet for å komme dit. Vi manglet vissheten om at vi hadde en tjeneste som faktisk betydde noe for brukerene våre. Dette engasjementet er selve grunnlaget for å skape lojale brukere, som fører til premium-kunder og forhåpentligvis ambassadører som gjør at man får en viral anbefalingsmaskin som er så nødvendig i dagens verden.

Høy «burn rate»

Hadde vi hatt kontroll på disse tallene tidlig så hadde vi sett at vi hadde et stort problem med å få brukerne våre til å komme tilbake til tjenesten. Hadde vi hatt forståelsen for disse tallene kunne vi utviklet produktet sammen med brukerne, til å bli noe som brukerne faktisk anbefalte videre.

Long story short hadde vi alt for høy burn rate, og vi rant ut av tid og penger før vi skjønte det, og før vi virkelig fikk bevist det vi hadde drømt om å gjøre — “Change the way you love your music”.

At vidFlow fikk en sakte død var selvfølgelig mer sammensatt, og dette kommer nok min kollega Nassir til å skrive mer om en dag. Men for meg var dette en skikkelig lærepenge som gjorde at jeg fikk øynene opp for metrics som virkelig betyr noe.

Den store idéen

Etter denne opplevelsen «geeket» jeg ut på metrics en stund, lærte mine kunder om hva de burde følge med på, insisterte på å installere metrics-verktøy for å følge med på alt dette. Men både for meg og for kundene var dette et tidkrevende og vanskelig felt, så følelsen om at man må lage noe som kan gjøre dette enklere å følge med på vokste i meg. Jeg hadde lyst til å lage et verktøy som gjør det enklere for alle å følge med på hvordan produktet ditt faktisk blir brukt.

Dermed gikk jeg i gang. Det første jeg ville gjøre var å validere ideen gjennom å samle et team med kompetansen jeg trengte og med smarte folk jeg ser opp til. Fikk jeg ikke solgt inn dette til et kompetent, dedikert team som ville ofre fritid på dette, var ikke idéen liv laga.

Etter å ha vært grunder i mange år vet jeg veldig godt at idéer er billig, gjennomføring er 99 prosent.

Jeg trengte en designer, en utvikler, og en til å holde orden på papir og økonomi. Heldigvis for meg visste jeg akkurat hvem jeg ville ha til hver av de rollene. Til min store glede fikk jeg etter noen raske samtaler “ja” og “fett” fra alle mine førstevalg, og første milepæl var nådd.

Utforme identitet

Den første idéen var å lage et enkelt dashboard med nøkkeltall, kombinert med en funksjon hvor man satt konkrete mål og fikk dynamisk oppdatering på hvordan man lå an i forhold til disse. Tallene skulle vi hente via data fra Google Analytics og Intercom (Intercom er et CRM verktøy som sporer hver bruker og dens aktivitet, og kan sende ut meldinger til de basert på deres aktivitet i tjenesten din). Google Analytics er utrolig keitete å bruke, og Intercom tilbyr ikke statistikk, så da kunne vi ha et bra produkt til en veldig spesifikk målgruppe, og vi hadde til og med bra ideer for hvordan vi skulle nå de. Boom boom boom.

Designeren vår Kristian satt i gang med å utforme identitet, og tech-leaden vår Ario satt i gang med å sjekke API til Analytics og Intercom. Og der strandet den første ideen. Intercom sitt API var for begrenset til å hente den dataen vi trengte, så ideen med å kombinere disse ville ikke gå. Bummer.

Men vi ga ikke opp, for problemet var ikke løst. Tilfeldigvis hadde jeg akkurat flyttet tilbake til Norge og startet i min første faste jobb noensinne i kommunikasjonselskapet Trigger. De skulle i gang med en kampanje for en app som hadde et helt konkret nedlastingsmål — caset var perfekt for vår løsning.

Vår første validering

Idéen var å lage et felles dashboard mellom kunde og Trigger, hvor alle involvert i kampanjen kunne se hvordan man lå an i forhold til målet og hvilke kanaler som faktisk konverterte, og legge til en faktor av målsporing dag for dag. Til vår store glede var både kunden og Trigger interessert i dette og vi hadde fått vår første validering. Vi leverte dashboardet, feiret og sendte vår aller første faktura.

Nedturen kom like etter produktet var tatt i bruk. Selvfølgelig spiste vi vår egen medisin, og sporet derfor bruken fra både kunde og Trigger for å forstå om vi hadde løst problemet vi ønsket å løse for kunden. Til vår store skuffelse viste det seg at til tross for at produktet leverte på akkurat det det ble solgt inn som, ble det ikke brukt. I det hele tatt. Vi hadde enda ikke helt forstått kundens behov. For for kunden ble verktøyet bare glemt bort i en hektisk arbeidshverdag. Et verktøy uten engasjement fra kundene har ingen fremtid, så slukøret hadde vi igjen krigsråd for å snakke om veien videre.

Et veiskille — fra pull til push

Vi visste at problemet var reelt siden vi hadde fått en kunde til å betale for produktet. Men derimot var ikke løsningen riktig. Vi forstod at vanen ble for vond å vende om kunden måtte gå og finne dataen selv. Vi måtte finne en løsning for å “pushe” dataen på dem. Hvordan kunne vi gjøre dataen lettere tilgjengelig? Vi testet med daglige emailer med oppsummeringer, men det kjentes spammete og gav lite effekt. Derimot innså vi at Slack kunne vært en god kanal.

Ansatte som bruker Slack er i programmet hele tiden. I tillegg kunne teams faktisk kommunisere rundt tallene på samme sted som oppdateringen kommer. Så vi gikk i gang med ny produktutvikling. Budskapet måtte tilpasses mediumet, og i Slack er det uformelt, kort og gøy med emojis og giffer. Derfor måtte vi sørge for at vårt produkt også var i “samme ånd”.

Så ideen pivoterte til en chatbot som pusher data i setninger som er enkle å forstå, toppet med emojier som indikerer hvor bra 🚀eller dårlig ☹️ tallet er i forhold til historikken. Igjen prøvde vi prøve å selge løsningen for å validere om behovet var der. Vi valgte en potensiell kunde som vi kjente godt og som vi kjente behovene til. Vi viste dem et skjermbilde fra hvordan daglig rapport kunne se ut i Slack, og spurte om de ville betale 1000 kroner måneden for å holde den gående. Svaret var en rungende “ja”, og dermed var vi i gang igjen! Yay!

Hallgeirs fem konkrete råd om du ruger på en digital startup-idé:

Denne reisen har lært meg masse om hvordan man jobber best med produkter og som team, noe jeg nå bruker i både veien videre for Butter Metrics, og i mitt daglige virke som produktansvarlig i Reodor. Her prøver jeg å sammenfatte 5 helt konkrete råd som jeg håper kan være til nytte.

1. Finn ut hva som er den absolutt minste innsatsen du kan gjøre for å validere produktet ditt. Dette er noe av det viktigste jeg har lært igjennom 20 år som gründer (shit, det tok meg altfor lang tid altså). Vi fikk den første kunden i Butter basert på et designet screenshot som tok 20 minutter å lage. Vi har fått de neste fem betalende kundene kun basert på at jeg skriver inn hva jeg tenker deres daglige rapport bør være i Slack, og tar et screenshot av det. Så enkelt kan det være; ingen programmering og definitivt ikke noe investering eller pengejag. Før Kanye gikk helt loco, sa han det veldig bra i remixen av låten “Power”: “Now we all ain’t gonna be American Idols, But you can least grab a camera, shoot a viral,”. Hva er det minste du kan gjøre for å sjekke om det er et marked for produktet ditt? Det koster så godt som ingenting å bygge en enkel lead generator i form av en landingsside i Squarespace, kjøre opp noen Facebook ads, og se om noen faktisk klikker og melder interesse. Kjør, kjør!

2. Finn team som kan ta produktet fra a til å. Om du er i situasjonen som mange andre at du har en god idé, men ikke penger til å gjennomføre det, så bruk nettverk, sosiale medier, skoler eller hvor som helst, for å finne et team som sammen med deg kan bygge idéen fra serviett-stadiet til at noen faktisk ønsker å betale for det. Hadde vi feks ikke hatt en utvikler på teamet hadde vi aldri hatt råd til å bare snu helt på retningen selskapet gikk i etter å ha brukt masse ressurser på å lage dashboard først, for så å lage en Slackbot etterpå.

3. Build-measure-learn. Dette er “lean startup” i et nøtteskall og det er mye hype der ute rundt dette. Men etter at du har tatt rådet over, altså build, starter jobben med å faktisk lære av tilbakemeldingene. Både om du lykkes og om du ikke gjør det, sørg for at du virkelig vet hvorfor, snakk med kundene, mål alt som kan måles, og bruk det for å bygge, iterere og teste videre. Uber leide ut sorte limousiner i San Fransisco før de ble en taxi-gigant, AirBnb leide ut luftmadrasser på egne stuegulv i første versjon, Instagram startet som en tjeneste hvor man sjekket inn på ulike steder, og kunne legge ut bilder av det (haha, noen som husker at man faktisk drev med det for noen år siden?). Denne prosessen er så essensiell endring i hvordan man jobber i den nye verden at om du ikke allerede kan disse grunnleggende prinsippene, google litt mer om “lean startup” — det er ikke hokus pokus, men det er en smart trinnvis måte å bygge selskaper på.

4. Ta betalt fra start. Dette er er råd spesifikt til dere som ønsker å bygge et SAAS (software-as-a-service)-produkt, altså en B2B tjeneste som hjelper kunder med en helt spesifikk ting mot betaling. Det viktigste argumentet for å ta betalt fra dag én er at du validerer produktet gjennom at kundene tar en avgjørelse som faktisk koster noe. Om ikke du klarer å overbevise om dette fra start, har du kanskje ikke et bra nok verdiforslag. Når vi kom frem til at det var en Slackbot vi ville lage, kunne vi helt sikkert fått masse startups til å teste det gratis som “betakunder”, men det hadde ikke bevist noen ting. Vi har valgt å heller ha få betalende kunder, hvor vi både får bevist både verdiforslag og prismodell, samtidig som vi får litt midler å bruke til videreutvikling av produktet vårt.

5. Sørg for å tracke alle funksjoner du har! Om du har en digital tjeneste, sørg for å sette opp sporing på alt, både før og etter registrering, hele veien fra oppdagelse til brukeren er en trofast ambassadør (se illustrasjon lenger opp). Når du har orden på alle disse tallene bør de deles med alle som er involvert i produktet. Når hele teamet vet hvordan produktet oppfattes, kan alle komme med ideer til hva som bør gjøres bedre. I vidFlow kjente jeg på ønsket om at både jeg og min designer umiddelbart kunne se hvordan endringene vi gjorde i grensesnittet påvirket hvor mye funksjonen ble brukt.