Ofte vil de virkelig gode løsningene på et problem springe ut av en helt ny måte å definere selve problemet på. Når vi omformulerer et problem, så er det ikke nødvendigvis for å finne rotårsaken eller det ekte problemet, men snarere for å se om det er et bedre problem det går an å løse. Gjerne et problem som er enklere og billigere å løse.
Et eksempel brukt i en kjent Harvard Business Review artikkel illustrerer godt hvor viktig det kan være å omformulere problemet:
De ansatte på et kontor er frustrerte over den trege heisen på kontoret, og du har blitt bedt om å komme opp med en løsning. De fleste vil antakelig tenke at løsningene på problemet på en eller annen måte må gjøre heisen raskere. Man kan installere en helt ny heis, oppgradere motoren, eller forbedre algoritmen som fordeler heisturer mellom etasjer.
En omformulering av problemet, derimot, vil lede til helt andre løsninger. Istedenfor å si at heisen er for treg så kan man si at ventetiden er irriterende. Plutselig åpner man opp for at heisen ikke nødvendigvis trenger å bli raskere, men at løsningen man kommer opp med må få ventetiden til å føles kortere. Kanskje holder det å sette opp speil som folk kan se seg i, spille musikk, eller sette opp en håndsprit-maskin, og dermed gi de ansatte noe å holde på med mens de venter?
En alternativ problemformulering kunne også vært å si at istedenfor at heisen er for treig, så har man simpelthen et rushtid-problem som kan løses ved å justere noen avdelingers møtekalendere og lunsjtider.
Dersom vi setter denne modellen inn en hypotesedrevet prosess for produktutvikling ser det slik ut:
Vi har identifisert et problem som bør løses (basert på omfanget og verdien av å løse det), men tar oss tid til å se om problemet kan omformuleres. Deretter lager vi flere hypoteser som åpner opp for flere mulige løsninger per hypotese. Læring fra eksperimentering med hver av løsningene kan gå rett inn i en ny iterasjon på løsningen, eller den kan igjen bidra til at du ser at hele problemet kan omformuleres. Deretter kan vi på nytt utforske hypoteser basert på det nye problemet.
Den samme modellen kan brukes i nyhetsbransjen, der vi anser det som en del av samfunnsoppdraget å sørge for at alle lesere får med seg de største nyhetshendelsene hver dag. Problemet er at dagens nettaviser oppdateres i en frekvens som ikke samsvarer med hvordan de fleste leserne faktisk bruker produktet. En leser som er inne klokka 8 vil se en helt annen forside og andre saker enn en leser som er inne klokka 15. Med papiravisene var ikke dette et problem. Avisen var statisk i 24 timer, og alle leserne fikk tilgang til den samme informasjonen uansett når på døgnet de leste den. Når brukere av dagens nettaviser risikerer å sitte igjen med et helt ulikt bilde av hva som er dagens viktigste nyhetshendelser, har vi et problem. Kan omformulering av problemet, beriket med innsikten om brukernes ulike adferd, hjelpe oss å finne en løsning?
Den opprinnelige problembeskrivelsen (“sørge for at alle ser dagens viktigste saker”) er mangelfull fordi den ikke fanger opp den faktiske utfordringen knyttet til brukernes ulike digitale vaner. Løsningen til venstre blir derfor en tilnærming som ikke egentlig adresserer problemet vi prøver å løse. Dersom vi isteden omformulerer problemet til å fange opp det faktumet at brukere har ulik frekvens og besøkstidspunkt, så ser vi også at hypotesene blir forskjellige:
Hypotese 1: Vi kan klare få alle brukere til å besøke oss samtidig, litt som Dagsrevyen gjør.
Hypotese 2: Brukerne kommer til å lese en daglig oppsummering av dagens viktigste saker dersom vi begynner å produsere og distribuere denne.
Hypotese 3: Algoritmebaserte forsider som genererer ulike forsider for hver bruker kan sørge for at alle får med seg det viktigste.
I abonnementsavisene i Schibsted tror vi på den siste hypotesen, og har laget en algoritme som fanger opp den redaksjonelt vurderte “nyhetsverdien” på hver sak når den rangerer artiklene på forsiden. Vi kunne også ha gått for en logikk som er rekkeviddebasert, og sagt at “denne saken skal vises øverst på forsiden under alle brukeres første besøk, frem til den har nådd 80% av daglige brukere”. Poenget er at evnen til å omformulere problemet i dette tilfellet hjalp oss å forstå at mye av utfordringen ligger i brukernes radikalt ulike adferd og vaner.
Uansett hva slags produkt du jobber med, så vil evnen til å se problemet du skal løse fra nye perspektiv være en nøkkelferdighet. Av og til vil det hjelpe å bruke teknikker som the five whys, mens andre ganger vil du kanskje bare måtte sette deg ned i den lobbyen og tenke grundig gjennom hva problemet egentlig er med den heisen.
Ønsker du å lære mer om produktledelse finnes mitt kurs nå tilgjengelig hos Videocation her. I kurset vil du blant annet lære å:
• Forstå produktrollen og ansvaret du må ta for at selskapet bruker tid og ressurser på å løse problemer som er verdt å løse.
• Beskrive hvilket ansvar som ligger i rollen som produktsjef på ulike nivåer, og hvilke egenskaper og ferdigheter som kreves for å lykkes.
• Definere et produktteam og beskrive hvordan designere, utviklere, og produktsjefer bidrar med sin spisskompetanse i å løse problemer sammen.
• Lage en solid produktstrategi som tør å ta noen tydelige valg om hvordan du og teamet skal gå fram for å løse bedriftens viktigste problemer.
• Kombinere utforsking og leveranse i produktutviklingsprosessen, og hvordan du bruker passelig lang tid på begge deler.
• Starte med problemet, og bli god på å prioritere og omformulere problemer før du tester en konkret løsning.
• Unngå typiske feil det er lett å gjøre som produktsjef.