Har du en digital beredskabsplan?

Hvis man skal pege på én ting, som de fleste, der arbejder med digitale projekter og aktiviteter er konsekvent dårlige til, er det at lære af deres egne fejltagelser.

For tænk over det: Hvis fejl var noget, vi virkelig lærte af, ville det ikke stadig være sådan, at langt hovedparten af alle digitale projekter fejler i den forstand, at de aldrig nogensinde kommer til at leve op til de ambitioner, der var hele grunden til at sætte dem i værk.

Fejlene kan skyldes mange forskellige faktorer. Men én ting er mere end nogen andet skyld i, at vi har så svært ved at lære: Vi har enormt svært ved at være skarpe på, hvornår et digitalt projekt er kørt i hegnet, få det lukket ned og lært af vores erfaringer til brug for næste gang. Men det kan man godt blive.

Læs videre “Har du en digital beredskabsplan?”

Overlev den brændende platform

Eksistentielle udfordringer er noget af det værste for enhver virksomhed. For mens det er en åbenlys trussel – deraf navnet – kan det være rigtig svært at få armene omkring disse og gøre noget ved dem.

Årsagen til dette er, at mens udfordringerne er reelle nok på den lange bane, er de lige præcis så langt væk, at de ikke virker, som noget, det er livet om at gøre at få gjort noget ved på den helt korte bane. Dermed risikerer man i dagligdagen at lulle sig selv ind i de faste opgaver og derigennem opnå en falsk tryghed, der i sidste ende kommer tilbage for at hjemsøge én selv på et senere tidspunkt.

Dette er ikke bare livsfarligt. Det er også unødvendigt. For der er faktisk ting, man kan gøre for at gøre det abstrakte, eksistentielle ude i horisonten både nærværende og håndgribeligt her og nu.

Læs videre “Overlev den brændende platform”

Skab en enkel handlingsplan

Hvor svært kan det egentlig være at skaffe sig overblik over en række målsætninger og de aktiviteter, der skal til, for at man kommer godt videre med dem? Svaret er, at det hurtigt kan vise sig sværere end langt de fleste forestiller sig.

Risikoen er derfor, at man hurtigt går i stå, og at det, der egentlig skulle have været en fokuseret workshop eller møde ender i den rene snak uden hoved og hale, og hvor ingen går derfra meget klogere. Det er ærgerligt. For dels får man følelsen af at have spildt sin tid. Og dels kan man forledes til at undgå øvelser som disse fremadrettet – hvilket bestemt ikke hjælper på noget som helst.

Læs videre “Skab en enkel handlingsplan”

Skyd rigtigt på din plan

Struktur er Guds gave til at analyse og vurdere potentialer, muligheder, udfordringer og trusler i forhold til de tanker, man gør sig om, hvor ens virksomhed eller organisation skal bevæge sig henad. Ikke desto mindre er det rigtig svært for mange at anvende en struktureret tilgang til virkelig at trykprøve, om den plan, man enten har lavet eller er på vej til at få lavet rent faktisk også giver mening.

Men det behøver faktisk ikke være så svært. Der findes en ret enkel metode, der som en anden Egon Olsen-plan kun kræver nogle gule lapper, en kuglepen og et stopur – og nogle andres plan.

Læs videre “Skyd rigtigt på din plan”

Design dig ud af udfordringerne

Hvad bruger du det meste af din tid på? Brandslukning her og nu eller arbejde, der peger fremad på den lange bane og skaber forudsætningen for, at du og din organisation også har succes i morgen og dagen efter?

Hvis du er som langt de fleste andre, anvender du hovedparten af din tid på brandslukning (“Haster & Vigtigt”) og en signifikant del af din øvrige tid på, hvad dem over dig ellers i øvrigt synes er vigtigt, men ikke nødvendigvis er det for dig (“Haster & Ikke Vigtigt”).

Når du så engang imellem får for meget og har brug for en pause, bruger du tiden på alt muligt andet – overspringshandlinger (“Haster ikke & Ikke Vigtigt”). Og så er den dag forlængst gået.

Læs videre “Design dig ud af udfordringerne”

2016 i tilbageblik – og fremad

Nu hvor nytåret står for døren, og 2016 nærmer sig sin afslutning, er det ved at være tid til at gøre status over året der gik fra et fagligt synspunkt. Hvad lærte vi – og jeg – undervejs i året, der gik om fænomener som digitalisering, digital transformation, disruption, business model innovation og mange andre fine buzzwords? Hvad betyder de? Og hvad kan vi bringe med os videre ind i 2017?

Da jeg altid har været en stor fan af den amerikanske talkshow-vært David Letterman og hans “Top 10” lister, tænkte jeg, jeg ville forsøge at gentage det kunststykke her. Og i bedste Letterman-stil gøre det fra bunden og opad mod den vigtigste læring.

Læs videre “2016 i tilbageblik – og fremad”

Find kundens Jobs-to-be-done

En af de måder, man virkeligt kan gå galt i byen på, når man arbejder med innovation er ved at tage et indefra-ud perspektiv: Vi mener, markedet har brug for X, fordi…det ved vi bare. Det er den direkte vej hen imod en fiasko, for godt 90% af alle innovationsprojekter – store som små – der tager den tilgang, fejler. Nogle spektakulært. Andre siver bare stille og roligt uden det store postyr.

Når virksomheder tænker indefra-ud misser de én kritisk ting: Kundeperspektivet. De glemmer at sætte sig selv i kundens sted og se problematikken, virksomhedens produkt er sat i markedet for at kunne løse, fra synspunktet af den, der skal betale regningen. De glemmer ganske enkelt at sætte sig ind i, hvad det er for en opgave eller sæt af opgaver, kunden rent faktisk forsøger at finde løsninger de. De mangler at definere kundens job – Jobs-to-be-done (JTBD). Læs videre “Find kundens Jobs-to-be-done”

Sæt ild til innovationen

En af de helt store frustrationer omkring innovationsprojekter og -processer er, at mange oplever, det er for svært og går alt, alt for langsomt. Og mens det ofte er opportunt at bebrejde proces- og metodeapparat for alle de ting, der går galt, er det straks sværere at kigge indad i forsøget på at finde, hvad problemstillingen i sin kerne er.

Men det er faktisk ikke så svært at se. For udover at der kan være mange forskellige holdninger til innovation og det enkelte projekts levedygtighed, der afgør, om man vil bruge sin energi på det eller ej, er virkeligheden i alle virksomheder og organisationer, at der er noget, der altid tager forrang for fremtiden: Nutiden – den daglige drift.

Hyl som de andre ulve

Langt de fleste mennesker, der går på arbejde, deler hovedparten af deres tid op i to kasser: De ting, der er vigtige og haster – brandslukning – og de ting, der ikke som sådan er vigtigt, men haster – fordi chefen siger det. Bliver der lidt tid til overs, bliver den gerne brugt på ting, der hverken er vigtige eller haster – overspringshandlinger om man vil – og det eneste, der sjældent bliver tid til er ting, der er vigtigt, men ikke haster. Her befinder innovationsprojekterne sig.

For at løse op for den problemstilling, kan man vælge at anskue udfordringen fra to forskellige synsvinkler: Man kan enten forsøge at ændre kulturen og ad den vej få mere fokus på det lange perspektiv. Den vej er lang, trang, mørk – og måske endda i virkeligheden blokeret. Eller man kan forsøge at hyle som de ulve, man er iblandt og gøre innovationsprojekterne og -arbejdet til noget, der både er vigtigt og haster.

Og hvordan så det? Ikke ved at forsøge at italesætte det som sådan ved fine interne foredrag, memoer og andet godt, man kunne tænke sig. Men ganske enkelt ved et helt igennem banalt trick:

Stryg tændstikken

I stedet for at vise de store forkromede processer og modeller, handler det om at bryde innovationsarbejdet og -projekterne ned i så små enkeltbidder, at de – opgave for opgave – kommer til at ligne opgaver, der bare haster helt vildt meget.

Hvis vi skal holde fast på brandsluknings-analogien handler det kort fortalt om at sætte ild til sit projekt. På den – i denne sammenhæng – gode måde, forstås.

Banalt men effektivt

Ved at bryde opgaverne ned i noget, der er genkendeligt for den enkelte, kan der ske to meget væsentlige ting:

For det første stiger sandsynligheden for, at opgaverne rent faktisk bliver udført, fordi de kommer med i den almindelige slipstrøm af vigtige haste-sager, man alligevel behandler hver eneste dag.

For det andet involveres medarbejderne rundt omkring i organisationen nu på en meget direkte måde i innovationsarbejdet. Vel at mærke uden der forinden sker en fremmedgørelse via fremhævelse af innovation som noget mystisk og/eller særligt endsige terperi af metoder og processer. Det sker bare. Helt uden nogen for alvor opdager det. Og dermed også uden den organisatoriske, kulturelle modstand, der ellers er enhver innovations største fjende indenfor en etableret virksomhed.

Som nævnt er det et relativt banalt trick. Dermed ikke være sagt, at det er let at skabe denne nedbrydning, delegere og gøre det konsekvent. Men sammenlignet med frustrationen over, at ens innovationsprojekter og -arbejde rammer muren igen og igen, er det bestemt et stort skridt fremad, som det er værd at tage.

(Foto: Flickr/Steven Bochniewicz)

Godt i gang med Lean Startup

Agil udvikling er over de senere år for mange blevet det helt store dyr i åbenbaringen. Drevet af startup-miljøet og nytænkende organisationer, er det blevet et fantastisk attraktivt alternativ til store, komplekse vandfalds-projekter.

Centralt i hele den agile tilgang står Lean Startup metodikken. Metodikken kom først på banen i 2008, da amerikaneren Eric Ries førte den på banen, og siden da har den gået sin sejrgang over hele verden. Bogen bag har solgt og solgt, og der findes ikke den konference rundt omkring, hvor man ikke snakker om metoden og dens tre elementer: Build, Measure, Learn.

Metodikken er også rigtig god og anvendelig, når man arbejder med udvikling af nye produkter og tjenester. Men lige som alle andre metoder og filosofier, fortjener den lige at få en kritisk gennemgang. Så det vil jeg forsøge at komme med her.

Udgangspunktet i Lean Startup er som nævnt den iterative proces Build, Measure, Learn. Man starter med at bygge noget ret simpelt. Så måler man, hvordan det virker. Man uddrager den lære, man kan af det. Og så tager man denne læring med videre i den næste iteration af ens produkt eller tjeneste. Og sådan kører det ellers rundt i ring og skaber i princippet en løbende forbedring af ens offering uden brug af store forkromede planer, GANT-diagrammer og hvad vi ellers har af gamle redskaber fra den klassiske projektverden.

Start med idéen

Lad mig gennemgå de enkelte skridt i modellen.

I starten har man en idé, og med udgangspunkt i den, bygger man sit Minimum Viable Product; det mindst muligt omfattende produkt eller tjeneste, man kan slippe afsted med for at få en rigtig test af, hvorvidt idéen holder eller ej. Man bygger sig produkt – Build – og releaser det til markedet.

Når produktet kommer ud, går næste del i gang – Measure. Her måler man kort fortalt på, hvordan produktet performer. Som minimum har man sørget for, der er rigtig god tracking på alt, hvad der foregår, og de fleste har også nogle KPI’er, som de følger. Disse kan være relativt generiske – antal besøg, antal salg m.m. – mens de mest avancerede opstiller specifikke KPI’er, der er designet til at definere præcis, hvilke svar det er, man gerne vil have ud af denne test.

Er man så avanceret, er man godt på vej mod sidste fase som er Learn. Det er her, hvor man bruger de opsamlede data på testen til at se på, hvordan det så egentlig gik og – vigtigst af alt – hvilke nye idéer og initiativer, det giver anledning til i forhold til at komme godt videre med næste iteration. Det er en super vigtig del af processen, for det er, man mere end på noget andet tidspunkt definerer, hvad det er, man hælder ind i sit produkt efterfølgende.

Pas på faldgruberne

Ovenstående er Lean Startup metodikken i meget korte træk. Og det ser jo ganske overskueligt ud. Men der er også nogle områder, hvor man med Lean Startup skal være opmærksom.

Det første opmærksomhedsprodukt handler om det input, man giver til modellen. Som med de fleste andre processer gælder princippet om ‘Shit in, shit out’. Og hvis man ikke passer rigtig meget på, er der en fare for, man kommer en halvbagt idé ind i processen til at starte med, og så kommer hele resten af forløbet til at handle om at optimere på noget, der egentlig er temmelig fejlbehæftet til at starte med – eller hvor der måske i virkeligheden bare havde været en bedre idé at starte ud med, hvis man havde gjort sig lidt mere umage.

Man kan naturligvis argumentere for, at metodikken vil fange en rigtig dårlig idé gennem processen og optimere på den. Og i princippet er det også korrekt. Men man skal ikke være blind for, at der kan indsnige sig en eller anden form for ‘confirmation bias’ undervejs, hvor man mere fokuserer på at få de målinger og den læring, der passer til ens ene forudfattede meninger end lytte til den feedback, markedet faktisk giver. Sker det bliver hele processen suboptimal for at sige det meget pænt.

Læring er altafgørende – og svær

Den næste ting, man skal være opmærksom på er selve læringsdelen. Talrige praktiske erfaringer viser, at mens man generelt er ret gode til at bygge ting, og de fleste også kan finde ud af at måle på det, de bygger, står det sløjt til med evnen til at lære. Dette kan skyldes, vi bare ikke er særligt gode til at lære af vores fejl. Men det kan også skyldes, vi nægter at se virkeligheden i øjnene og dermed discounter den negative feedback, der egentlig var livsnødvendig for os at få ind i den næste iteration af produktet.

For at imødegå dette sidste problem findes der de praktikere, der mener, man skal anskue hele processen anderledes. I stedet for at sige Build, Measure, Learn bør man i stedet sige Learn, Measure, Build. Dette er ud fra tanken om, at man først sætter sig ned og definerer, hvad det er, man gerne vil have ud af sin test i den pågældende version af produktet, hvordan man har tænkt sig at måle på det og først til sidst bygger produktet.

De praktikere, der advokerer for denne version, gør det, fordi de kan se, at rigtig mange i praksis har enormt svært ved læringsdelen, som er den centrale i hele processen. Alle kan bygge, de fleste kan måle – men de færreste formår for alvor at indfri det potentiale, der ligger i læringsdelen. Hvis det at kunne gøre det kræver, at der rettes lidt ind i rækkefølgen, må det være et lille offer at bringe for en metodik, som ellers er super effektiv.

(Foto: Flickr/Rebeca Zuñiga)

Kom hurtigt i gang med et Design Sprint

I jagten på at skabe hurtige resultater af ens innovationsindsats, er der efterhånden en del virksomheder, der har set sig lune på Design Sprint processen, som Google Ventures har udviklet. Og man forstår hvorfor. For hvis Google kan bruge den og har succes med den, må den alt anden lige også være god nok til at skabe resultater for rigtig mange andre.

Og det gør den givetvis også. Der findes mange eksempler på virksomheder, som har taget processen til sig – i første omgang på forsøgsstadiet – og som har fået resultater ud af det. De fleste resultater har dog ikke så meget med selve produktet af processen at gøre som processen selv; følelsen af at man rent faktisk på fem dage kan rykke fra idé til at have et eller andet ude til test hos nogle kunder.

Men hvad går Googles Design Sprint ud på? Og hvordan adskiller den sig fra den proces, jeg er fortaler for – Innovation Sprint?

Godt i gang

Design Sprint er som nævnt ovenfor en proces, der tager fem dage. Man starter mandag morgen og er færdig fredag sen eftermiddag. Det er til at forstå for de fleste. Og det gør det relativt enkelt at prøve processen: Det er nemt at overskue for en virksomhed, hvad det vil koste i indsats af ressourcer, tid, penge m.m. at prøve af.

Mandagen bruges på at identificere og indramme den problemstilling, man gerne vil arbejde med resten af ugen. Der findes flere konkrete måder at gøre det på, men pointen er, at man kommer ud af dagen med en fælles forståelse for, hvad det er for en udfordring, det er vigtigst at bruge ugen på at forsøge at løse. Dette er både godt og skidt. Det er godt, fordi det giver entydigt fokus for ugens arbejde. Det er skidt, fordi processen foregår indefra-ud, og resten af ugen således kommer til at handle om at få verificeret virksomhedens egen opfattelse af en problemstilling. Men mere om det senere.

Om tirsdagen bliver man mere konkret og går i skitsemodus. Man tegner og fortæller hver for sig med pen og papir og kommer op med en lang række forskellige forslag til, hvordan en løsning kunne tage sig ud. Det væsentlige er her, at vi er på skitsestadiet – det handler om kvantitet i antallet af vinkler og tilgange fremfor kvalitet i design af de enkelte skitser – og at det er hver enkelt projektdeltager for sig selv. Dermed undgår man at falde i fælden med kollektiv brainstorm og én enkelt stakkel, der skal forsøge at ramme det hele ind efterfølgende. Hvilket i sig selv er en god ting.

Prototype tager form

Onsdag går med at snævre løsningen ind fra de mange forslag i skitseform, der blev genereret dagen før. Dette gøres bl.a. ved at udarbejde et story-board, der forklarer forslaget til en løsning i enkelte skærmbilleder. Hvad sker der, når jeg trykker på den versus hvis jeg trykker på den i stedet for o.s.v.? Det er her, der i gruppen skabes konsensus om den samlede løsning, der skal blive til en prototype. Og det er her, man begynder at tænke mere i, hvordan denne prototype rent designmæssigt kommer til at tage sig ud.

Dette giver et rigtig godt udgangspunkt for torsdagens arbejde, som ene og alene handler om at omsætte idé og storyboard til en prototype, man kan vise for et antal kunder, man har rekrutteret til samme formål. På mange måder er dette den mest konkrete af dagene og måske nok i virkeligheden den, der kalder på den mindste grad af facilitering. Der kommer en masse indestængt energi ud, som gruppen har fået lov til at gå og oparbejde over de forudgående dage, og hvor det lige præcis er blevet holdt tilbage kort tid nok til, at den ikke er begyndt at sive ud mellem sprækkerne endnu. Det giver gode muligheder for en rigtig effektiv proces og en god oplevelse for alle parter af, at man rent faktisk skaber noget og gør det hurtigt efter, man kom på den allerførste idé.

Mød kundernes dom

Slutteligt bruger man fredagen på at teste og evaluere. Man viser sin prototype for et antal kunder – ikke ret meget mere end en håndfuld – og tager en snak med dem om, hvad de tænker, når de får den i hænderne. Dette giver en idé om, hvorvidt man er på rette spor, men det giver ikke det endelige facit på noget som helst. Dertil skal der en hel del mere arbejde og reel udvikling til, før man kan sige, man har noget, der minder om et reelt produkt, der adresserer det issue, man om mandagen satte sig for at løse. Men om ikke andet, har man fået et fingerpeg.

Dermed minder et Design Sprint meget om et Innovation Sprint, som er den – noget længere (12 uger) – metode, jeg selv prædiker: Man får en eller anden form for validering. Men der er også en række faldgruber, man skal tage under overvejelse. Lad mig prøve at komme ind på dem her.

Faldgruber

Valideringen, man får med et Design Sprint, er ikke særlig omfattende. Det siger sig selv, at snakker man kun med f.eks. 5-6 kunder, bygger man relativt meget på ganske få mennesker. Dette kan imødekommes ved, at man ikke umiddelbart efter et Design Sprint træffer en beslutning om at igangsætte et større projekt men i stedet vælger at teste mere. Og det er helt fint. Man skal blot være opmærksom på, hvad man gør.

Udover at valideringen ikke er specielt omfattende, dækker den heller ikke ret mange dimensioner. Når man har én dag til at teste på få mennesker, er det svært at finde bag om argumenterne, de kommer med. Skal man tage testpersonerne på deres ord om, hvad de kan lide eller ikke kan lide? Eller skal man forsøge at afdække, hvad der i virkeligheden ligger bag deres udsagn for at trykprøve dem lidt mere? Det sidste kan man ganske enkelt ikke nå på den korte tid.

Der er heller ikke på én dag tid til andet og mere end en funktionel test. Det vil i praksis sige, at mens man godt kan teste lidt for de funktionelle behov hos kunderne, er det udenfor scope at teste for f.eks. sociale, emotionelle eller understøttende behov. Så der er en masse granularitet i testfasen, man ganske enkelt ikke får med.

Husk forretningen

Derudover indeholder Design Sprint heller ingen forretningsdimension. Der er ingen vurdering af værdi i forhold til prissætning, og der er ingen vurdering af, om det overhovedet forretningsmæssigt giver mening at forfølge idéen; kan en eventuel fremtidig forretning overhovedet hænge sammen. Idéen kan for så vidt være fin og interessant nok, men hvis ikke økonomien kan komme til at hænge sammen, kan det hele i langt de fleste tilfælde være lidt ligemeget.

Endelig – og det synes jeg er den største ulempe ved et Design Sprint – tager den udgangspunkt i, at man selv ved, hvad der reelt er behov for ude i markedet. Det ved man sjældent. Det er altid kunderne, der bedst ved, hvor skoen trykker, og ved at starte med en mulig forkert hypotese, kan man reelt set hurtigt ende med at spilde en uges arbejde på en test, der ikke giver noget rigtig godt endsige brugbart resultat. Dette er også sket for rigtig mange af dem, jeg har snakket med omkring brugen af Design Sprint, og jeg har dem mistænkt for, de har overset lige præcis denne lille ting.

Når alt det er sagt, er et Design Sprint en rigtig fin ting at gøre. Metoden er ganske velbeskrevet i den bog, der hører til, og der findes masser af gode videoer og case studies på nettet. Og så skal man altså ikke kimse af, at alene oplevelsen af, der sker noget her og nu kan være succes nok for mange – i starten. Når man så skal videre med sine innovationsprocesser skal man være bevidst om Design Sprintets begrænsninger. Og her giver det mening at snakke om Innovation Sprints i stedet.