Jeg hedder Toke, og er partner i THINK,

som er et digitalt designbureau.

Titlen p mit indlg er: Stop building og

begynd at eksperimentere.

ET INDLG OM BYGGEFEBER OG KUR

Toke Grfte
 Det seneste rs tid har jeg siddet i et
garage-setup hos Telia, og hjulpet med at
lancere Telias nye selvbetjeningsunivers:
Mit Telia.

Seneste tre kunder:

TOKE GRFTE

Digital strategi &

User Experience siden 1999
 Noget af det, jeg har lagt mrke til
gennem de sidste 18 r, er, at utroligt
mange projekter handler om at udkomme.

Byggefeber mindset Om at bygge feature p feature. Om at

bygge nyt. Vi sidder fast i et byggefeber
mindset.

Et mindset som gr, at man ikke fr fulgt

p, om de leverede features skaber vrdi
for forretningen og slutbrugeren.

Optimering imod leverancer

 I skarp kontrast, har vi det eksperimentelle
mindset.

Eksperimentelt
Byggefeber mindset Nr vi er i det eksperimentelle mindset,

mindset optimerer vi imod lring fremfor

leverancer.

Build
Det starter med at vi bygger et lille
eksperiment, som vi sender ud i hnderne
p brugerne

Measure
hvorefter vi mler, hvordan de
interagerer med det

Learn
s vi kan lre, om det er noget, vi skal
bygge videre p

Discard
eller smide vk.

Optimering imod leverancer Optimering imod lring Herefter starter den iterative proces forfra.
Og jo hurtigere vi kommer rundt i loopet,
jo hurtige lrer vi. Ved at lre hurtigt
undgr vi spild, s vi kan skabe strst mulig
forretningsvrdi p kortest tid.
 Et af de klassiske eksempler p denne
tankegang, taget helt ud i det ekstreme, er

Eksperimentelt Dropbox.

Byggefeber mindset
mindset Tilbage i 2007 da Dropbox lige var startet,
lavede founder Drew Houston en explainer-
video, som p overbevisende vis
demonstrede, hvad Dropbox kan.

Men der var et tvist - Dropbox softwaren

var p davrende tidspunkt slet ikke
bygget endnu.

Drew lavede videoen som et eksperiment,

der skulle teste, om der overhovedet var et
behov.

Video gik viralt, og folk styrtede til

getdropbox.com - hvorefter teamet fik
travlt med at bygge produktet alle ville ha.

Amazons CEO ynder at sige

Optimering imod leverancer Optimering imod lring

 For Amazon er det det eksperimenterende
mindset, alts ogs en fuldstndigt
integreret del af Amazons mde at drive
forretning p.

Our success at Amazon is Og mske den primre rsag til deres

succes.

a function of how many

experiments we do
per year, per month,
per week, per day.
Je Bezos
Amazon CEO
 S i mit indlg idag, vil jeg gerne
perspektivere konferencens overskrift og
Byg App fokus.

Jeg tror ikke p, at det at bygge i sig selv

Byg AR/VR Byg website giver vrdi.

Jeg vil gerne starte med et eksempel p,

hvor galt det kan g, nr man har
byggefeber.

BYGGE = VRDI

Byg omnichannel Byg CRM system

Byg chatbot
 Rejsekortet.

At fremhve et projekt, fra den oentlige

Reviews (1,269) Bad transportsektor, er selvflgelig at sparke til
en mand, som allerede ligger ned.

.. men da vi alle betaler for gildet, synes jeg

godt, at vi kan kritisere det lidt.

Og forhbentlig lre af deres fejl.

 Frst lidt kontekst

I 1993 startede de frste drmme om et

rejsekort, som en erstatning for
klippekortene.

Klipkortene var dyre i administration og

besvrlige for brugere.

Mske I husker, hvordan de altid blev

krllet og ikke ville stemple.

1993
 Fast forward til 2015, hvor Rejsekort
endeligt var bygget frdigt.

Basalt set et digitalt klippekort, hvor man

skal stemple ind og ud ved at stte kortet
op foran de fysiske standere.

22 milliarder kostede Rejsekortet. Det

svarer ca. til en halv Storebltsbro.

1993 2015
22 r - 22 milliarder kr.
 Hvorfor?!

Hvorfor dette kort, hvor brugeren selv skal

checke ind og ud via fysiske standere?

But

WHY?
 Mske de r 2010 skulle have tnkt:

Hvad med en app?

Kan det ikke bare have vret en app, hvor

brugeren automatisk stemples ind og ud
via GPS?

S er der mske nogen som siger:

Jamen rejsekortet har lavet en app
r 2010

Hva med en
app?
 De har en app: Check udvej appen.

En app hvor du udelukkende kan checke

ud, hvis du har glemt at gre det via de
fysiske standere.

Check Udvej Men du m maks bruge den tre gange pr.

mned.

Af Rejsekort A/S Men det er jo ikke kun de gode folk hos

Rejsekortet, som elsker at bygge nyt.

Jeg skal da indrmme, at jeg selv har

vret ramt af byggefeber massere af
gange.
 Kuren mod Heldigvis har jeg en kur, som jeg vil dele
med jer, og som I kan tage med hjem og
bruge allerede idag.

byggefeber
 KUREN MOD BYGGEFEBER

Det starter med noget s simpelt som

Giv projektet projektets navn.

det rigtige navn

1
 Vi navngiver projekterne med fokus p
midlet frem for mlet.

Rejsekort projektet. App projektet. Nyt

website projektet. Chatbot projektet.

Det har den uheldige konsekvens, at alle i

bde team og organisation, fokuserer p

Vi navngiver projekterne med outputtet, frem for resultatet.

Projektnavnet stter hele rammen, og

fokus p midlet frem for forventningsafstemmer med CEOen,

bestyrelsen og andre vigtige stakeholders.

mlet. Hvis projektet er et app projekt, er det

svrt ikke at levere en app, selv hvis man
finder en bedre vej til mlet senere i
projektet.

Og tnk hvis ens bonus eller fremtidige

karrieremuligheder er hngt op p, om
man leverer en app - er man s villige til at
udfordre?
 Tnk hvis Rejsekort projekt fx havde
heddet 'Rejse betaling.

Derved havde man muligvis ikke fastlst

sig p et fysisk kort, og fundet tilbage til,
hvorfor det var man lavede projektet i
frste omgang: For at gre det billigere og
nemmere for rejsende at betale for deres
rejse, og slipper for det gammeldags
klippekort.

Rejsekort vs Rejsebetaling
Vi har for nylig hjulpet Telia med at bygge
deres nye selvbetjeningsunivers: Mit Telia.
 Men fra start af, var projektet ikke
navngivet Projekt Selvbetjening eller Mit
Telia

Ikke Projekt Selvbetjening eller

Mit Telia, i stedet
Istedet hed projektet Switchr.

Fordi projektet grundlggende handlede

om at switche kundeoplevelsen fra
kedelig selvbetjening til en engagerede
dialogplatform.
 Fordele
Ml fremfor middel
Lser ikke lsning prematurt
Mere motiverende for teamet
 KUREN MOD BYGGEFEBER

Kom ud af
Featurefabrikken

2
 Dem af jer, der har arbejdet lngere tid p

Processen p strre digitale projekter, kender mske til

flelsen af at arbejde p en featurefabrik.

Featurefabrikken John Cutler, som er en kendt amerikansk

product management guru, beskriver
processen p featurefabrikken sledes

John Cutler
Forretningen holder mder - et utal af
stakeholders, skal hres og tages i ed -
markerting, jura, kundeservice, produkt, it,..

Alle fr lov til at komme med nsker til de

ting, de mener, kunderne har brug.

nskerne er mere baseret p

mavefornemmelse og intuition end data og
indsigt.

Det kan vre CEOen har set en ting

konkurrenterne har. Eller salg, som lige
mangler den sidste feature for at lukke en
stor kunde.

Alle har et say!

Product owner og resten af
udviklingsteamet fr en lang liste med ting,
der skal bygges.

Bevares, de kan estimere og trkke

backlog kortet, til de mest hblse bygge
forslag.

Men der er stadig en kmpe bunke

features, som skal estimeres, designes,
specificeres.
Til undstning, komme User Experience
Designeren, og kaster sit magiske stv
udover udover den endelse liste af
features.

Hvis de er heldige, fr de mske lov til at

lave en enkelt brugertest.
S kommer udviklerne kommer p banen,
og de klar til at bygge. Og der er meget,
som skal bygges.

Helst lanceret i gr.

Jubiii, s har vi lanceret produktet!

Et kmpe rod af usammenhngende

features, som kunderne slet ikke forstr.
Et feature-monster!

Fordi der er blevet lagt feature, p feature,

p feature.
 Featurefabrikken gr ingen glade.

Brugerne kan ikke finde ud af produktet,

da de mange features, gr, at det tager for
evigt at lre at bruge.

Udviklerne vedligeholder en kmpe bunke

kode og forst ikke ,hvorfor de sidder og
laver alle disse features, som ingen brugere

Featurefabrikken gr ingen glade, vil ha.

CEOen nr ikke sine ml, og river sig i

hret, over time to market bliver

hverken brugere, medarbejdere eller CEO. langsommere og langsomere.

Det starter her!
S hvordan kommer man ud af
featurefabrikken? Et godt sted at starte er
her.

Listen med ting der skal bygges:

Roadmappet.

For langt de fleste virksomheder centerer

deres digitale initiativer omkring
roadmappet.

Men der er noget galt, med langt de fleste

roadmaps
 Selvom langt de fleste virksomheder har
taget den agile tilgang til sig og lbende

Feature roadmap releaser forbedringer i hver version,

arbejder de fleste stadig med, hvad jeg vil
kalde et featurebaseret roadmap.

Version 1.0 Version 2.0 Version 3.0 Version 4.0

Feature Feature Feature Feature Feature Feature Feature Feature

Feature Feature Feature Feature Feature Feature Feature Feature

Feature Feature Feature Feature Feature Feature Feature Feature

Fremtid
 Fx: I version 1.0 skal brugeren kunne
oprette profil og logge ind. I version 4.0

Feature roadmap skal de kunne lave kbe via et checkout

flow.

Men hvordan kan man gtte hvilke

features, der skal i version 4.0, nr man
ikke engang har lanceret version 1.0 og set,
hvordan kunderne tager imod den frste
Version 1.0 Version 2.0 Version 3.0 Version 4.0 version? Hvordan undgr vi at blive
prematurt fastlst til en specifik lsning?
Opret Check
Feature Feature Feature Feature Feature Feature Feature Feature
profil out Det har har en fyr, der hedder Bruce
McCarthy en interessant id til. Og det er
Feature
Login Feature Feature Feature Feature Feature Feature Feature faktisk en super enkel id

Feature Feature Feature Feature Feature Feature Feature Feature

Fremtid
 Bruce McCarthy foreslr, at erstatte
features med kundeproblemer, der skal

Kundeproblemer der skal lses roadmap lses.

Version 1.0 Version 2.0 Version 3.0 Version 4.0

Problem Problem Problem Problem

Problem Problem Problem Problem

Problem Problem Problem Problem

Fremtid
 I takt med at vi lancerer produktet, bliver
problemerne selvflgelig omdannet til

Kundeproblemer der skal lses roadmap konkrete features.

Men ved at lade lsningsmulighedere st

bne til vi er blevet klogere, undgr vi at
tre forkerte beslutninger fordi, vi har
lst os fast p en specifik lsning for tidligt.

Version 1.0 Version 2.0 Version 3.0 Version 4.0 Mske vi endda opdager, at der slet ikke er
brug for seks features, men faktisk kun tre,

Feature Feature Problem Problem Problem som illustrationen viser.

Hvad er s et kundeproblem, der skal

Feature Feature Problem Problem Problem lses?

Feature Problem Problem Problem Og hvordan finder man et stort juicy

Feature
kundeproblem, som giver en masse
forretningsvrdi, hvis man lser det?

Lanceret Fremtid
 Som mange andre virksomheder har Telia,
en god del kald fra kunder, som ikke-
skaber vrdi for hverken Telia eller kunden.

Mange af disse opkald er relateret til

kundernes regning.

Ved at se p kaldsstatiskstik fra

kundeservice, og tale med
domneeksperter fra finans, marketing, it
m.fl. fandt vi ud af, at mange af disse
regningskald var relateret til en intern
Telia problem proces i Telia kaldet Carry over

Ikke-vrdiskabende opkald vedr. regning

 Carry over er et levn fra en tid, hvor
kunderne fik deres regning via brev.

Carry over For at spare porto og undigt papirspild,

fik kunderne, der havde et forbrug p
under 150 kr, skubbet regningen til nste

Hvis kundens forbrug er under 150 kr, mned, hvor de modtager regning for to
forbrugsperioder.
skubbes regningen til nste mned

Mned 1 Mned 2
Telia kundeproblem: Carry over I praksis ser regningen sdan ud. I
eksemplet her, har kunden et abonnement
p 129 kr, men fordi belbet er under 150
Regning med to forbrugsperioder kr, fr han alts nu en regning p 258 kr.

Kunden har naturligvis ikke lagt mrke til,

at der ikke kom en regning i forrige mned,
s nu er han frustreret og ringer ind for at
hre, hvorfor regningen er s hj.

S Telia fik en masse ikke-vrdiskabende

kald, som kostede penge at hndtere via
kundeservice og desuden med en masse
frustrerede kunder, som var forvirrede over
deres regning.
 Vi lste kundeproblemet ved at lgge
processen i graven i stedet for at bygge
features ovenp en forldet proces
 Vi (teamet) fik simpelthen afskaet
processen, s alle kunder nu, altid fr en
regning hver mned.

Havde vi fulgt et traditionelt featurebaseret

roadmap, fremfor at fokusere p kundens
problemer, kunne man frygte, at vi havde
bygget en forst carry over feature,
istedet for angribe selve kilden til
problemet.

Alle Telia kunder fr nu Ikke alene sparede vi vrdifulde ressourcer

og gav en bedre kundeoplevelse.

en regning hver mned Vi hjnede ogs moralen i teamet

uanset forbrugets strrelse

Her en mail fra projektlederen, der
deklarerer at Carry over endeligt er dd.
Og en af udviklere, som har arbejdet i Telia
i mange r, skriver RIP Carry, 1990-2017, A
pain in the bip til the end
Carry over problemlsning der giver forretningvrdi

Recucere kald vedr. regning

Hurtigere time to market (vi byggede ikke
noget!)
Mindre frustreret kunder

Gladere team
KUREN MOD BYGGEFEBER

Navigr
med KPIer

3
Vi har lige set, hvordan det at bygge
mindre kan give stor vrdi.

Men hvordan mler man vrdi?

Hvis ikke vi kan mle vrdi, ved vi ikke, om

vi bygger det rigtige. Og vi kan ikke
generere nye ideer og hypoteser, som vi
kan teste af.
BTW: Er der nogen som har prvet at
foresl, at man fjerner en bestemt feature?

Hvordan var reaktionen?

Det er som regel corporate harakiri at
foresl, at en feature skal fjernes.

Nr frst en feature er rget ind i et

produkt, s skal den blive
- no matter what.

Rationalet synes at vre: Nu har vi jo brugt

tid p at udvikle?!!

Derfor
 Skal vi kunne koble digitale KPIer direkte
til forretningens ml.

Lser vi kundens problem?

Bygger vi de rigtige features?

Giver de features vi lige har releaset

vrdi eller skal smides vk igen?

Vi skal kunne koble digitale KPIer

direkte med forretningens ml.
 Typisk kunne en virksomhed have tre
overordnede forretningsml: get salg,
get loyalitet og Frre omkostninger.
Virksomhed
Nr vi laver et digital produkt, skal KPIerne
tappe direkte ind i en eller flere af disse
ml.

Men hvordan materialiserer disse KPIer sig

helt konkret?

La os vende tilbage til Telia casen

get salg get loyalitet Frre omkostninger

KPI KPI KPI KPI KPI KPI

 Mit Telia skal bde ge salget, ge loyalitet
og reducere omkostningerne.

Virksomhed Men i og med, at det er en

selvbetjeningslsning, er frre
omkostninger til manuel hndtering af
kunder via fx kundeservice, et klart
erklret forretningsml.

get loyalitet Frre omkostninger

Mit Telia ml:

Frre omkostninger til kundeservice
fordi kunderne betjener sig selv

KPI KPI KPI KPI

 Men hvad er s Mit Telias KPIer?

Hvordan kobler vi Mit Telias KPI med det

overordnede ml om at reducere
omkostningerne?

Men hvad er Mit Telias KPIer?

# opkald til kundeservice?

# sidevisninger p Mit Telia?
# sign ups p Mit Telia?
 Forstil jer fx at antallet af sign ups, var den
styrende KPI.

Har det en vrdi for Telia, om der kommer

en masse brugere p Mit Telia? Det
kommer jo helt an p, hvad de laver efter
sign up.

Hvis bare de laver en sign up, og vi aldrig

ser dem igen, er det helt vrdilst.

Derfor er antallet af sign ups ikke en

indikator p, om Mit Telia skaber vrdi
# sign ups eller ej.

En KPI skal

tid
 F teamet og organisation til at afprve
If it wont change nye initativer, som de kan lre af.

how you behave En KPI skal motivere til, at forblive i det

eksperimenterende mindset, hvor vi

its a kontinuerligt bliver klogere.

Klogere p, om de features vi ligger live

rent faktisk lser et kundeproblem, der
skaber forretningsvrdi.

BAD
METRIC.
 Derfor er alle Mit Telias KPIer centreret
omkring antallet af interaktioner.

Dvs. de kundeinteraktioner p Mit Telia,

som skaber mlbar vrdi for Telias
forretning.

# interaktioner
Aktivering af service i selvbetjening Som et del af kundernes abonnement, fr
de en rkke services med - i dette
eksempel har kunden Spotify, HBO Nordic
..

For at kunden kan tage servicen i brug skal

den aktiveres. Det gres ved at klikke ind
p servicen, og gennemg et
aktiveringsflow, hvor Telia reelt gr ind og
overtager regning fra Spotify, hvis du
allerede er Spotify Premium bruger.
Aktivering af service i selvbetjening Nr kunden gennemfrer denne handling,
skaber det mlbar vrdi for Telia - de
bliver lngere, fordi de fr mere ud af
deres abonnement,

Og ved at klare aktiveringen selv, fremfor

at ringe ind til kundeservice for at f hjlp,
sparer Telia kald = penge.
# serviceaktiveringer i selvbetjening vs. kundeservice
Tager vi herefter antallet af
serviceaktiveringer via selvbetjening og

68% sammenligner med kald til kundeservice,

fr vi et reelt billede af, om
21% 71% selvbetjeningen, bliver bedre til at afvrge
25% 15% 22%
24% 57% 57% 66% kald.

60% Dermed kan vi mle eekten p tvrs af

kanaler og fx se, om en feature er
37% vrdifuld eller ej.
15%
24% 17%
20%

w27 w28 w29 w30 w31 w32 w33 w34 w35 w36 w37 w38 w39 40 w41 w42

Selvbetjening Kundeservice
# serviceaktiveringer i selvbetjening vs. kundeservice
I uge 36 blev Mit Telia lanceret kommercielt
til alle privat kunder, og som I kan se, sker

68% der et kraftigt skift i fordeling fra

kundeservice til selvbetjening.
21% 71%
25% 15% 22%
24% 57% 57% 66% Men det stopper naturligvis ikke her for
Telia. At lancere er bare frste skridt p
60% rejsen - herefter fortstter det hrde
arbejde med kontinuerligt at bygge > mle
37% > lre.
15%
24% 17%
20%

Mit Telia launch

w27 w28 w29 w30 w31 w32 w33 w34 w35 w36 w37 w38 w39 40 w41 w42

Selvbetjening Kundeservice

Most companies manage projects in terms of
outputs, not outcomes. This means that most
companies are settling for done rather than
doing the hard work of targeting success.
Je Gothelf & Josh Seiden
Je Gothelf og Josh Seiden har skrevet
bogen Sense & Respond, som jeg varmt vil
anbefale - de har flgende formulering,
som jeg synes, er helt central:
Most companies manage projects in terms
of outputs, not outcomes. This means that
most companies are settling for done
rather than doing the hard work of
targeting success.
Hvis vi vil skabe forretningsvrdi med
digital initiativer, er vi ndt til at redefinere
mden, vi styrer dem p.
Her er KPIer, som er bundet direkte p
forretningsmlene, det vigtigste vrktj til
kontinuerligt at skabe gte vrdi, for
brugerne og virksomheden.
Giv projektet det Kom ud af
rigtige navn featurefabrikken Navigr med KPI'er
Lav roadmaps med
Fokusr p mlet fremfor Udpeg og ml interaktioner
kundeproblemer der skal
midlet fx Telia Switchr som giver forretningsvrdi
lses
 At vre agil er, at hele organisation
omfavner et eksperimentelt mindset, hvor
vi bruger langt mindre tid i Byggefasen, og
hurtigt kommer over i measure og learn.
Og bliver ved med at iterere.

Design sprints, demoer, backlog, design

thinking, marketing automation og alle de
andre fine ord og metoder er ligegyldige,
hvis ikke vi grundlggende ndrer vores
mindset.

At vre agil er at hele organisationen

omfavner et eksperimentelt mindset
Tak for opmrksomheden!

tokeg@thinkdigital.dk
www.linkedin.com/in/tokegrofte