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.