Del 3. Hypoteser - [Sida - Länk]
När vi skivat elefanten och börjat jobba med mindre delar --- en i taget --- jämfört med tidigare och dessutom hittat problem som våra kunder eller användare har, då är det gissningsvis dags att hitta lösningar på de problemen? Nej, det är det inte! Varför? Lösa problem är väl just vad vi gör på jobbet, hela dagarna? Ibland släcker vi till och med bränder. Ju snabbare vi hittar en lösning, desto bättre?
Sluta hitta lösningar - [Sida - Länk]
Här har vi ytterligare en stor skillnad mellan de nya arbetssätten och de gamla. I traditionella projekt spenderar du mycket tid och resurser i början på att inte bara hitta en lösning, utan den rätta lösningen. Och den handlar resten av projektet om att producera vad den lösningen innebär. Vem bestämmer vad som är rätt lösning? Den med mest erfarenhet eller mest lön i rummet. (Vilket oftast påstås vara samma sak.) Eller den som är chef av något slag. Men vi har ju redan visat hur de ändrade arbetssätten som digitaliseringen bygger på uppstått likt en ny upplysningsera på grund av att vi sett hur inte ens de vassaste experterna kan säga vad som är den bästa lösningen.
Alltså måste vi ta oss ur vår tradition av att försöka ta fram bra idéer, eller den bästa idén, och istället likt upplysningens pionjärer formulera hypoteser.
I det här avsnittet går vi igenom skillnaden mellan en lösning och en hypotes och hur hypotesformlerande i förlängningen leder till mycket bättre idéer.
Fler än en hypotes - [Sida - Länk]
Även om vi tidigare pratat om vikten att ta tag i ett problem i sänder, så kan du absolut formulera fler än en hypotes kring ett och samma problem. Det är en av grunderna i att förstå att det kan finnas flera lösningar och att vi inte vet svaret på vilken som är rätt förrän vi testat våra hypoteser.
Om vi sen ska vara riktigt noggranna kanske olika hypoteser är olika sidor av ett problem, men det spelar ingen roll. Precis som när vi nominerade vilka problem vi skulle ta tag i först, formulerar vi också fler hypoteser. Och först när vi har flera väljer vi ut vilka vi ska testa.
Hur förkastar du din hypotes? - [Sida - Länk]
Det här är inte raketvetenskap, men det är vetenskap. Att arbeta evidensbaserat istället för att förlita sig på den som pratar högst och mest i mötet, har finast titel eller säger sig vara någon typ av expert. Även om detta har varit självklart sedan Upplysningen så har traditionellt organiserade företag på något sätt lyckats missa den lektionen. Kanske skolkade de? För att öka farten på digitaliseringen behöver vi alltså gå ifrån vanan att försöka hitta på den “bästa idén” till beteendet att försöka hitta sätt att visa varför vi har fel.
Fail fast är ett begrepp du säkert hört vid det här laget och många tror att det påminner oss att lära av misstagen. Det kan man säga, men att det blivit ett mantra för digitalisering beror mer på att uttrycket vill få oss att ha ett strukturerat angreppssätt till att ta reda på varför något inte funkar. För ju snabbare vi vet det, desto mindre resurser behöver vi lägga på att utveckla funktionen i fråga.
Därför är en av de viktigaste momenten i hypotesarbetet --- och i hela den digitala utvecklingen --- att fundera ut hur du ska visa att din hypotes inte stämmer.
Det är inte bara Upplysningen och vetenskapstraditionen som är anledningen till att vi jobbar så. Här finns också ett stort mått av effektiv psykologi. Den som tror sig har en bra idé och får i uppgift att ta reda på om den kommer att fungera, kommer också att bli offer för det som kallas confirmation bias. Att vi ser det vi vill se. Och när det gäller våra egna idéer vill vi vara dubbelt duktiga: Vi vill både att vår idé ska bara bra och vi vill lösa testuppgiften på ett bra sätt. Det är ett mer positivt resultat om ett test visar positiva resultat.
Om din uppgift istället är att hitta sätt på vilka din hypotes bör förkastas, då försöker du vara duktig på det. Vilket då gynnar hela processen att misslyckas så fort som möjligt.