Er outcome ikke lig forandringen snarere end den værdi, der skal skabes?
Ja, outcome er selve forandringen, der kan føre til værdi. Eksempelvis kan et ønske om outcome være, at vi skal have flere signups til vores nyhedsbrev. Hvis vores tese er, at modtagere af vores nyhedsbrev vil have en hyppigere købsfrekvens, vil den øgede indtjening være den impact, der kommer ud af det.
En af de udfordringer, jeg tit oplever, er, at man ikke får illustreret/gjort opmærksom på, hvad fejlen lærte os.
Enig. Det er en typisk faldgruppe, vi ser hos mange. Ethvert loop skal der samles op på, i forhold til hvad vi lærte, og hvordan vi kan bruge det fremadrettet. Vi taler om strategiske feedback loops, da det er vigtigt, at vores læringer fra ekseveringen bliver afspejlet i strategien.
Det er derfor vigtigt, vi fra start er bevidste om, hvornår vi fejler og i hvilken periode, vi tester vores hypotese. Og at vi fra start lægger ind i planerne, hvornår og hvordan, vi samler op på det.
Har I indtryk af forskelle mellem private og offentlige organisationer?
Vi har heldigvis både en del offentlige og private kunder. Vi ser både ligheder og forskelle, men mange af tendenserne er de samme. Vi oplever, at der hos det offentlige i højere og højere grad er fokus på værdiskabelsen og mere agile processer. I det private er denne proces gået hurtigere nogle steder, da man fra start har haft et større fokus på, hvilken værdi, der skabes på den korte bane.
Der er dog en række udfordringer, der kan sammenlignes. Det offentlige har tunge kontrakter, der kan være en hæmsko for en tilgang, der baseres på at teste hypoteser for at komme frem til det bedste produkt. Omvendt er virkeligheden i store private virksomheder, at der ofte findes krav om, at man ved præcist, hvad man køber ind, hvilket selvsagt giver de samme udfordringer, hvis vi skal styre efter resultatet og ikke den givne leverance (output). Fælles er dog, at der er større og større fokus på, hvilken værdi projekterne skal skabe.
Vi er gået lidt i stå i vores udvikling på digital, efter vi fik ny løsning for et halvt år siden, og projektet er lukket med succes. Nu sker der ingenting. Hvordan vil du foreslå, vi skal komme igang med at fejle?
Det er en klassisk og paradoksal problemstilling. Paradoksal fordi det ofte er i tiden umiddelbart efter en lancering, at man har mulighed for at lave den største værdiskabende ændringer med ret beskeden indsats. En måde at komme videre på kunne være etablering af et cro-program (cro: conversation rate optimization). Her vil man løbende optimere, f.eks. i kvartalsvise sprints, på udvalgte områder og løbende teste hypoteser af.
Problem-orienteret roadmap: Hvordan ved man så, hvornår nye features lanceres?
Det er et super godt og helt centralt spørgsmål. Når vi afstemmer forventninger med organisation og ledelse, er vi vant til at gøre det ud fra et feature-perspektiv. Feature x kommer i Q1, Feature y og z i Q2 etc. Når vi ændrer arbejdsmåden, ændrer vi også forventningsafstemningen med organisationen. Vi lover ikke længere feature x, men at vi i Q1 løser et givent problem. Det problem kan have en række udfaldsrum, vi skal prøve af i løbet af den kommende periode. Så i stedet for at kommunikere features kommunikerer vi, hvilke problemer vi løser og afrapporterer på vores outcomes.
Man kan også argumentere for, at man bør udfordre, hvorvidt man bør frigøre sig af datoer helt. Ikke at løse et problem i et givet kvartal, men at tage næste skridt og sige: Vi arbejder på at løse dette problem nu. Vi arbejder på det, indtil vi har nået dette mål, eller indtil vi er blevet klogere. Derefter skal vi se på dette problem.
Skønt, at vi skal omfavne fejl. Det tror jeg, vi alle kan blive enige om, er en god ting. Men nogle gange har fejl alvorlige konsekvenser. Hvem står så med ansvaret? Mig som den, der har vovet pelsen og prøvet noget nyt, eller min chef, som helst ikke vil se dum ud over for sin chef?
Netop pointen om fejl og konsekvenser er central. Ved at teste og fejle i mindre skala, samt kontrolleret på baggrund af vores hypoteser, vil vi lave færre alvorlige fejl og have større fokus på læringer for succes. Det er tilsvarende vigtigt at have en klar governance om, hvem der træffer beslutninger, hvem der er informerede og hvem der bidrager med viden. Vi bruger ofte RACI frameworket til den del.
Hvad hed forfatterne/bogen?
Følgende tre bøger er et godt sted at starte:
- Product Roadmaps relaunched af Michael Connors, C. Todd Lombardo, Bruce McCarthy & Evan Ryan
- Sense and Respond af Jeff Gothelf og Josh Seiden
- Outcomes over output af Joshua Seiden
Løbende optimering bliver nemt en by i Rusland, når først en løsning er live?
Det er vigtigt, at der skabes et etaberet program for optimering med faste ressourcer, der arbejder med løsningen kontinuerligt udfra principperne om test af hypoteser. Det er essentielt, når vi arbejder med at få løsninger hurtigt i markedet, at det ikke bliver en måde bare at lave mindre løsninger, men at det netop baner vejen for, vi bygger videre på løsningen. Så allerede i version 1 skal der være en plan for, hvordan den løbende optimering vil foregå og med hvilke ressourcer.
Hvad er jeres største læringskurve i 2019 vedrørende fokus på outcome development?
Den er tosidet. På den ene side har vi lært rigtig meget positivt om, hvor hurtigt vi har kunne opnå resultater, selv i store organisationer, med hypotesesprint og eksekvering. På den anden side har det i lige så høj grad overrasket os, hvor svært det kan være at ændre en kultur i nogle organisationer til at have fokus på værdiskabelse fremfor output. Der har vi lært meget omkring, hvordan det er vigtigt at arbejde med hele kommunikationen omkring projekterne, fx ift digital forretningsudvikling.
