Tør å teste tidlig, de fleste innovasjoner blir aldri lansert
De fleste innovasjonsprosjekter blir aldri lansert. Fordi de stadig skal perfeksjoneres, bare litt til, et spørsmål til, en analyse til. Prosjektdeltakerne jobber stadig grundigere, henter inn mer data, kjører enda en runde, diskusjon og interne analyser . Det føles som det riktig å gjøre, oppleves som å være ansvarlig. Men mens prosjektet perfeksjoneres på detaljnivå, forsvinner momentet. Stille uten at noen egentlig merker det.Det vi tror vs. det som skjer
Vi tror vi er forsiktige. Vi samler mer data, diskuterer flere scenarier, kjører en ekstra justeringsrunde. Det føles ansvarlig. Ingen ønsker å gå videre for tidlig, og ingen vil være den som tok beslutningen som ikke holdt.
Men det som faktisk skjer, er noe annet.
To stille med livsfarlige “innovasjonsdrepere” tar over. Information overload fyller rommet med flere meninger enn klarhet. Jo mer data, jo flere måter å tolke den på. Analysis paralysis gjør hver beslutning så tung at den utsettes igjen. Møtene blir lengre. Beslutningene blir færre. Energien skifter umerkelig fra fremgang til beskyttelse.
Sluttresultatet er sjelden et dårligere produkt. Det er ingen produkt. Prosjektet mistet ikke kvalitet, det mistet bevegelse. Og blir dermed aldri lansert.
Innsikten ingen vil høre
Mer informasjon gir ikke mer klarhet. Den gir flere alternativer å holde levende, og flere hensyn å forhandle om.
Innovasjonstrygghet vokser ikke gjennom forberedelse. Den vokser gjennom kontakt med virkeligheten. Virkeligheten lærer deg mer på to uker enn analysen lærer dere på to måneder. En enkel test gir et reelt svar. En grundig utredning gir bare en bedre hypotese. Du må tørre å teste produktet ditt i markedet - og få de ærlige tilbakemeldinger. Selv om det er krevende.
Rådet vårt er tydelig: test tidlig fremfor å vente. Ikke fordi kvalitet er uviktig, men fordi kvalitet bygges gjennom læring i bevegelse. Ikke gjennom å etterstrebe perfeksjon. For du tester hos dem som er potensielle brukere eller kunder, og de vil si gi deg feedback og produktet er klart.
Målet er ikke fullstendig sikkerhet. Målet er nok selvtillit til å ta det neste meningsfulle steget. Med masse gode innspill i sekken.
Rammeverket: BLTF
Når team vil ut av analysen og inn i læring, bruker vi ett enkelt rammeverk. Fire steg, gjentatt om og om igjen til dere treffer. Det er godt utprøvd og gir klare resultater. Modellen heter BLT, ja, som sandwichen, men vi har lagt til en F, forstå, for å få med design thinking elementer inn i modellen.

B – Behov. Start med behovet. Ikke ideen, ikke teknologien, ikke løsningen dere allerede er forelsket i. Hvilket reelt problem løser dette, og for hvem? Kan dere ikke formulere behovet på én setning, er dere ikke klare til å løse det.
L – Løsning. Skissér det enkleste mulige svaret på behovet. Ikke det beste. Ikke det ferdige. Det enkleste. En prototype, en samtale, en mock-up, et tilbud. Noe som kan møte virkeligheten innen kort tid.
T – Test. Sett løsningen ut i verden. Mål, observer, snakk med dem som faktisk berøres. Bygg læring basert på forståelse og innsikt, ikke på antagelser.
F - Forstå (egen refleksjon). Tolk tilbakemeldigene fra kunder og marked slik at du kan justere hvordan dere treffer på behovet. Når endringer er gjort (tweeking) kjører dere en ny runde. Dette kaller vi en itterasjon.
Så gjentar dere. Behov · Løsning · Test · Forstå. Helt til dere treffer.

Et tydelig eksempel: I stedet for tre måneders forarbeid på en ny tjeneste eller produkt, gjør dere første test etter to uker. Tjenesten er kanskje halvferdig, men kundene møter den, tester den - og gir tilbakemelding. Funnet ett konkret friksjonspunkt? Da har den ene uken levert mer reell innsikt enn de første tre månedene noensinne ville gjort. I tillegg har grunnlag for å justere før dere har bygget hele veien feil.
Slik kommer dere i gang
Fire grep som flytter team fra utredning til læring:
1. Definer behovet på én setning. Klarer dere det ikke, har dere ikke et behov ennå. Dere har en hypotese. Bruk den første timen på å skjerpe formuleringen, ikke å diskutere løsningen. En presis behovsbeskrivelse sparer dere for uker med feil retning.
2. Sett en testdato før dere setter en løsningsspec. Bestem først når dere skal møte virkeligheten. La løsningen tilpasse seg datoen, ikke omvendt. En fast dato tvinger frem prioriteringer som ellers ville blitt utsatt.
3. Lukk avstemningsløyfene etter beslutning. Søk motstand før dere bestemmer dere. Når valget er gjort, slutt å forhandle. Forhandlede kompromisser oppstår når dere holder alle dører åpne hele tiden – og resultatet er sjelden bedre, bare senere.
4. Mål læring, ikke leveranser. Spør dere selv etter hver test: Hva forsto vi nå som vi ikke forsto før? Hvis svaret er «ingenting», var det ikke en test, det var en presentasjon. Bygg læring basert på forståelse og innsikt fra dem som faktisk berøres.

Slik jobber vi
BLTF er ikke en teori vi underviser i. Det er metoden vi selv bruker når vi hjelper norske ledere å gå fra strategi til gjennomføring.
I kursene, prosjekter, prosesser og work shops med oss får dere rammeverk, maler og veiledere som gjør BLTF til vane i hverdagen, ikke bare et begrep i en presentasjon.
Den ene avgjørelsen som teller
Innovasjon handler ikke om å eliminere risiko. Det handler om hvilken risiko dere velger.
Risikoen ved å gå for tidlig kan dere rette opp. Risikoen ved å vente for lenge er umulig å reversere.
Når sjekket dere sist om dere faktisk lærer noe nytt – eller om dere bare forbereder dere bedre?