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?”

3 misforståelser om Business Model Canvas

Business Model Canvas er en af de mest brugte modeller verden over i forhold til at visualisere sin forretningsmodel. Men det er en misforståelse at se det som et simpelt redskab. Alene fordi denne overdrevne simple forståelse af modellen gør, at langt de fleste ikke formår at bruge modellen rigtigt.

I det følgende vil jeg prøve at beskrive tre almindelige misforståelser i forbindelse med brugen af Business Model Canvas, og hvad man kan gøre for at rette op på dem.

Læs videre “3 misforståelser om Business Model Canvas”

Test med Pretotyping

En af de helt store fordele ved at arbejde agilt og lean er, at man hurtigt kan få noget fra hånden, indhente nogle resultater fra marken og blive klogere, før man bygger videre på det, man nu er i gang med at ville bygge op. Men forudsætningen for, at man kan dette, er, at man har nogle effektive metoder til hurtigt at få nogle forskellige tests i markedet.

Her kommer Pretotyping ind i billedet som en både hurtig, effektiv og ikke mindst billig måde at indsamle data omkring en idé’s holdbarhed på. Metoden er som så mange andre udviklet hos Google, og manden bag hedder Alberto Savoia. Han har skrevet en gratis bog om metoden, og det følgende er en gennemgang af, hvad Pretotyping egentlig går ud på. Samtidig kigger jeg på nogle af de forskellige test typer, der findes i metoden, som man med fordel kan anvende, når man gerne vil teste, om man med sin idé har fat i noget, der kunne blive stort.

Grundidéen

Grundkonceptet i Pretotyping ligger i konstruktionen af selve ordet: ‘To pretend’ sammen med ‘prototyping’. Man skaber kort sagt illusionen om, man har et produkt i markedet via en prototype i mindre skala, og så samler man dybest set de reaktioner fra mulige kunder ind, som man får og bruger disse resultater til at vurdere, om man skal gå videre eller ej. Som en tommelfingerregel siger man, at man kan få 80% af den samme viden som fra andre dyrere typer af tests med 20% af omkostningerne. Det sammen med hastigheden gør Pretotyping super interessant som testmetode.

Er du interesseret?

Én af de ting, vi rigtig gerne vil måle via Pretotyping, er interessen hos de kunder, vi gerne vil have fat i, for det produkt eller den service, vi gerne vil tilbyde dem. Dette gør vi ved at måle ILI – Initial Level of Interest – og OLI – Ongoing Level of Interest.

ILI handler om at se, hvad der umiddelbart sker, når vi placerer et ‘fake’ produkt foran en mulig kunde? Hvordan registrerer kunden det? Hvad er første respons? Ansporer denne respons til en handling i form af et ønske om f.eks. at købe produktet? O.s.v. o.s.v. Vores interesse her er at få den tidligst mulige og hurtigst mulige idé om, hvorvidt der overhovedet er nogen som helst form for interesse for det, vi har gang i.

Rammer vi et behov?

OLI handler mere om det lange seje træk. Det handler i virkeligheden om at gentage det første eksperiment og se, hvad der sker, når vi igen udsætter de mulige kunder for vores produkt. Det vi gerne vil se er, hvilken faktor nyhedens interesse spiller. Var det interessant første gang, bare fordi det var nyt? Eller bliver kunderne ved med at interessere sig for vores produkt eller tjeneste? Er vi i virkeligheden slået ind på en vej, hvor vi kan opfylde nogle reelle behov og løse nogle helt konkrete problemstillinger, som kunderne har?

Det sidste er interessant, fordi det er det, der i sidste ende vejer tungt i vores overvejelser om, hvorvidt vi skal bevæge os videre fra test stadiet og mod et decideret udviklingsforløb.

I gang med tests

For overhovedet at komme til ILI og OLI har vi brug for at designe en relevant test. Og her byder Pretotyping på en række forskellige metoder, man kan bringe i anvendelse alt efter case, pengepung og tidshorisont. De spænder lige fra de helt enkle og hurtige til de lidt større udstyrsstykker.

Den umiddelbart mest enkle at gå i gang med er den, der hedder ‘Fake Door’. Her handler det om at lade som om, man har et produkt til salg, selvom man ikke har det. Det kan man f.eks. teste på en webshop, hvor man lægger et produktbillede op, skriver en tekst og så ser, hvor mange der klikker. Længere er den sådan set ikke – bortset fra man selvfølgelig skal fortælle de, der klikker, at det er en test og så tilbyde dem et eller andet til gengæld for ulejligheden med at klikke forgæves.

En sådan test kan sættes op på ganske få minutter, så der er i virkeligheden slet ikke nogen undskyldning for ikke at teste.

Mand eller maskine

En anden testform er ‘Mechanical Turk’. Her lader man som om, man har et virkelig avanceret produkt rent teknisk, mens det i virkeligheden er almindelige mennesker, der bag skærmen sørger for at tingene hænger sammen. Her er man virkelig ude og fake den, men kombinationen af en fin front end og en håndbåren proces for at løse en eller anden problemstilling for kunden er god til at teste, om man rent faktisk rammer et behov, inden man går i gang med den store tekniske løsning.

‘Pinocchio’ er en tredje metode, hvor man bygger en non-funktionel prototype af produktet. Det kan f.eks. være for at teste et designforslag i forhold til form. Det kan også være for at teste navigation i en app, hvor man gør det via en ‘papir prototype’ resident i en app skal på mobilen. Eller det kan være noget helt tredje.

Udstyrsstykker

Udover disse metoder er der også de rene udstyrsstykker som f.eks. ‘One Night Stand’, hvor man i forbindelse med eksempelvis en retail lancering bygger hele løsningen ét sted og så tester den der, før man ruller den ud til andre lokationer. Det er ‘the full monty’, men grundet begrænsningen til én lokation, man kan bruge gode statistiske metoder til at identificere rigtigt, er det stadig en mindre og overskuelig investering at gennemføre en test af denne skala.

Endelig findes der andre test typer som f.eks. at leje sig til en løsning bestående af forskellige eksisterende komponenter, man kan tage fat i eller simpel ‘relabeling’, hvor man bare sætter en anden etiket på et eksisterende produkt. Og så kan man ellers ekstrapolere derfra ud i alle mulige nye typer af tests. Og så kan man jo altid følge den traditionelle metode fra Lean Startup og lave et Minimum Viable Product (MVP) og teste derfra.

Hurtig og billig viden

Pointen omkring Pretotyping er, at man meget hurtigt og meget billigt kan komme i gang med at teste, om en idé holder vand. Man slipper i princippet for at gøre sig en masse spekulationer og beregninger i forretningsplaner m.m., fordi man bare kan gå ud i virkeligheden og se, om det man påtænker, rent faktisk fungerer i praksis.

Det er en ny måde at arbejde på for de fleste. Men netop fordi det går hurtigt, er simpelt og ikke koster det store, er det også en af de metoder, hvor barrieren for bare at prøve det af og gøre sig sine egne erfaringer med, hvilke typer af tests, der virker bedst for ens egen virksomhed, er meget, meget lav.

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.