Virksomheter lever av å løse kundens problemer. Men det er ikke så enkelt som det høres ut som. Vi har sett storslåtte selskaper gå dukken som følge av at de har forelsket seg i sin løsning på kundens problemer og blitt forbigått av konkurrenter som har forelsket seg i selve problemet, og dermed i større grad evnet å innovere rundt løsningen. BlackBerry og deres «fulltastaturtelefon» er et ofte brukt eksempel på dette. For å drive med kontinuerlig forbedring og innovasjon rundt et problem, er det helt sentralt å forstå brukerens virkelige behov og problemer. Altså å jobbe brukersentrisk. Gjennom mine første måneder i Bekk har jeg gjort meg opp noen refleksjoner rundt brukersentrisk tilnærming, og hvorfor det er fånyttes dersom problem- og behovsdefinisjonene er feilformulert.

Å forstå problemet

Produkt- og tjenesteutvikling handler om å forstå kunden. Vi bør identifisere hvem de er, hvilke problemer de har og hvilke behov problemene er knyttet til. Basert på observasjoner og erfaring bygger vi noen hypoteser om dette, før vi tester det ut mot reelle kunder eller brukere. Ved å orientere oss rundt mennesket og innhente reell informasjon fra faktiske brukere kan vi tilegne oss essensiell innsikt inn mot produkt- og tjenesteutviklingsfasen. Dette fagfeltet er beskrevet i et lass av bøker og utallige rammeverk, men spesielt ett tema erfarte jeg at var krevende å sette fingeren på; Hva er egentlig forskjellen på et problem og et behov, og hvordan skal de formuleres?

En metode for å uttrykke at man skaper reell verdi og møter et behov er å lage brukerhistorier. I en brukerhistorie tar man et skritt tilbake og ser helheten i hvordan et produkt eller en tjeneste skaper verdi for kunden. Ved å ha et bevisst forhold til brukerhistorien sikrer vi at all funksjonalitet i det vi leverer er verdiskapende.

Et fint utgangspunkt for å lage brukerhistorier er setningen «Som en <'kunde/bruker'> ønsker jeg å <'løse et problem'> slik at <'behov tilfredsstilles'>». Ved å fylle ut de blanke områdene belyser vi hvem kunden er, hva de ønsker å løse (problemet), og hvilket behov vi tilfredsstiller. Denne måten å jobbe på synes jeg både er spennende og overførbar til problemløsning på alle nivå i en organisasjon. Tankesettet hjelper oss med å ha et bevisst forhold til problemet vi løser. Vet vi at problemet er knyttet til mange eller viktige behov hos en stor nok gruppe mennesker, så er det et problem verdt å løse. Klarer vi å ha selve problemet i fokus, og å skape produkter og tjenester som løser det, med kontinuerlig forbedring og innovasjon, da vil vi lykkes.

Så kommer utfordringen jeg har opplevd; hvordan sikre at man har forstått problemet? Jeg mener det kan gå ordentlig galt dersom problemet defineres feil. Jeg vil vise dette med et eksempel. La oss ta utgangspunkt i salg og distribusjon av musikk som et overordnet tema, skru tiden tilbake til 90-tallet da CD’er fortsatt gjaldt. Ha brukerhistorien som bakteppe («Som en <'kunde/bruker'> ønsker jeg å <'løse et problem'> slik at <'behov tilfredsstilles'>»), så skal jeg videre snakke om noen regler jeg har laget for meg selv for å bruke dette til å fremme innovasjon og nytenkning!

Som en kunde..

Hvem er det vi ønsker å treffe med våre produkter og tjenester, eller å danne hypoteser om? Jo mer datadrevet vi blir, jo bedre informasjon har vi om mennesker. Adferdsdata tilknyttet preferanser, ferdigheter, personlighet m.m. er tettere relatert til kunders behov enn demografiske faktorer. Hvem har likest behov tilknyttet musikk av to tilfeldige menn i 40-årsalderen og to personer som er musikkinteresserte? Mest sannsynlig de to personene som har musikkinteresse. Derfor er det helt nødvendig å danne kundegrupper basert på kundens adferd fremfor demografiske faktorer som alder og kjønn.

Ønsker jeg å løse et problem..

Hva er det kunden ønsker å gjøre noe med, hva er oppgaven som skal løses? I dette steget er det fort gjort å låse hodet fast i eksisterende løsninger. Hvis utgangspunktet er salg og distribusjon av musikk på 90-tallet, så er det vel naturlig å tenke at kundene ønsker CD’er? Her mener jeg at den største fallgruven ligger. Hvis jeg begrenser problemet til å dreie seg om CD’er, så er løsningen allerede skissert. Tar jeg i stedet et steg tilbake og gjør konseptet av CD’er abstrakt, så åpner det seg helt andre dører. Hva er det en CD eller en CD-samling er? La oss kalle det tilgang på musikk. Hvis vi heller snakker om at problemet er tilgang til musikk, så er vi ikke begrenset til konseptet av en CD som medium.

Dersom vi prøver å løse problemet at kundene ønsker mange CD’er, så kommer vi til å prøve å lage verdens beste CD-produkt og løsninger for å distribuere disse. Tar man steget tilbake til konseptet om tilgang til musikk, så kan løsningen på problemet også inkludere det man gjorde før CD’en; vinyl, kassett m.m., og samtidig la dørene stå åpne for fremtidens løsning; mp3, Spotify osv.

Slik at behov tilfredsstilles..

Jeg opplever at vi har forskjellige oppfatninger av hva behov er, og hvordan vi snakker om det. Samtidig ser jeg at vi er ofte enige hvis vi graver dypt nok. Man kan spille «Hvorfor det?»-spillet til man blir grønn, og det er ofte en nyttig øvelse! Hvorfor ønsker den musikkinteresserte personen tilgang til musikk? Dette høres banalt ut, men det er viktig. Et svar på dette kan være behovet for å dyrke sin musikkinteresse, eller det kan være at man ønsker å bygge identitet. I begge disse eksemplene på behov er vi kommet svært langt ned i «Hvorfor det?»-spillet. Å fortsette med å spørre hvorfor man ønsker å dyrke en interesse eller å bygge identitet begynner å bli lite hensiktsmessig. Derfor mener jeg at eksemplene over er gode behovsdefinisjoner på et riktig nivå. I noen tilfeller ender man helt nederst i Mazlows behovspyramide, men det er ikke målet med øvelsen. Forsøk å tenke ut den sanne effekten på personen som får problemet løst, rettet mot underliggende behov og følelser.

Svake behovsdefinisjoner er typisk formulert som et problem eller inneholder antakelser om løsninger. At kunden for eksempel skulle ha behov for «å bytte CD ofte» er både mer et problem enn det er et behov, og det inneholder en antakelse om at CD er mediet. Det kan skape problemer fordi vi trolig kunne fått innsikt om at mange kunder ønsker å «bytte CD ofte». Og da hadde vi etablert denne sannheten, jobbet ut ifra det, og forsterket utfordringen med å ikke låse seg til konseptet CD som en del av løsningen. Vi må huske at kunden ofte ikke vet hvilken løsning de ønsker før de plutselig får den presentert.

Å knytte problem til behov anser jeg som en virkelighetssjekk; er det viktige behov vi knytter til problemet? Og i hvor stor grad vil vi kunne tilfredsstille behovene til brukeren gjennom å tilby vår løsning til deres problem? Hvis vi ikke vet hvilke behov vi forsøker å tilfredsstille, så er det veldig vanskelig å måle effekten. Er vi i et team enige om hvilke behov kunden har, som vi søker etter å tilfredsstille, vil vi ha en tydeligere felles vei mot målet og snakke samme språk. Vi kan innhente kundeinnsikt, og i neste fase designe produkter og tjenester, målrettet.

Hvordan dette kan hjelpe oss på veien videre

Når vi har gjort øvelsen gjennom stegene, gjerne for flere kundegrupper og identifisert mange potensielle behov, så må vi teste usikkerheter mot bruker. Jeg har opplevd at testing er uendelig mye lettere dersom vi har gode problem- og behovsdefinisjoner. Er det viktigst for brukeren å kunne dyrke musikkinteresse generelt? Da er det kanskje hensiktsmessig å fokusere på en løsning som lar brukeren utforske. Er det å bygge identitet som er viktigst? Da bør vi kanskje legge til rette for at brukeren kan vise andre mennesker hva man lytter til. Dette var tilfeldige eksempler på hvordan vi kan ta i bruk tankesettet. Finner vi ut hvilke behov som er viktigst for kunden, kan vi prioritere funksjonalitet som løser problemet inn i produkt- og tjenestedesign.

Problemer forblir problemer

Bedrifter som «forelsker seg i problemet, og ikke løsningen» sies å være vinnerne. Jeg håper denne artikkelen bidrar til å se viktigheten av å forstå og definere problemet man jobber med, samt hvordan man knytter dette opp mot underliggende behov hos brukeren.

Behov og problemer er ofte vedvarende, mens brukernes krav til løsninger endrer seg kontinuerlig. Definerer man problemer rundt abstrakte konsepter tilknyttet dype behov, har man et utgangspunkt som er åpent for innovasjon, og først da mener jeg at man kan «forelske seg i problemet».