Waarom in oplossingen denken niet altijd handig is

Wie kinderen heeft, kent het wel. Nee je mag geen snoep! Waarom? Nou, omdat dat slecht voor je is, Waarom dan? Omdat er veel suiker in zit, Waarom zit er dan veel suiker in? Net zo lang tot je het zelf ook niet meer weet en je je beroept op je senioriteit. Nou gewoon! Omdat ik het zeg, en nu hup naar bed! Kinderen ladderen automatisch. We worden geboren met de waarom-vraag en dat is waarschijnlijk ook meteen de reden dat we de hele wereld, inclusief onszelf, naar onze hand hebben weten te zetten (ik laat even in het midden of we daar goed aan doen). Het lijkt er op dat we die gave (ik noem het ‘waarommen’) verliezen naarmate we ouder worden.

Wellicht hebben we in onze jeugd net wat te vaak een draai om onze oren gekregen door het waarommen en associëren we het met gezeur of zelfs recalcitrant gedrag. Natuurlijk zijn er momenten waarop waarommen niet handig is. ‘Pas op, een boom! Remmen!’ Is bijvoorbeeld een goed moment om de waarom-vraag even te laten voor wat het is. Maar als je een team van gemotiveerde designers en developers vraagt om een product of service te ontwerpen, kan het verdraaid handig zijn om te begrijpen welk probleem je voor wie probeert op te lossen.

Waarommers en oplossers

Naast waarommers zijn we ook ‘oplossers’ en in tegenstelling tot het waarommen groeit dit vermogen naarmate we ouder worden. Zien we een probleem, dan schieten we direct in de oplossing-stand. Een beetje te vergelijken met niezen. Daar denken we tenslotte ook niet over na. Dat komt gewoon vanzelf. Daniel Kahneman noemt dit in zijn boek Ons feilbare denken (aff.) het systeem 1-denken. Snel, reflexmatig, intuïtief en evolutionair oud. Niks mis mee als er een tijger op je af rent, maar zeer risicovol als je aan de slag gaat met een experiment voor je hypothese.

Wacht: we denken toch na als we met een oplossing komen? Dat klopt, maar ik heb het hier niet over de oplossing zelf. De kans is zelfs groot dat je eerste ingeving meteen een fantastische oplossing oplevert. Ik heb het hier over het feit dat we geneigd zijn alles uit de kast te trekken om bewijsvoering te vinden voor dat eerste idee. In de Cognitive Bias Codex is deze te vinden onder het kopje confirmation bias. In het Nederlands wordt dit ‘de voorkeur voor bevestiging’ genoemd. Het verwijst naar de neiging van mensen om meer aandacht en waarde te hechten aan informatie die de eigen ideeën of hypotheses bevestigt. Tegelijkertijd is er de neiging om minder aandacht te besteden aan informatie die je eigen ideeën tegenspreekt.

Nadelige gevolgen

Dit alles maakt ons geen beste onderzoekers en kan naast gefrustreerde teamleden grote financiële gevolgen hebben (het één is vaak een gevolg van het ander). Alleen door onszelf bewust te maken van onze voorkeur voor bevestiging is er hoop. Tijd dus om die waarommer in onszelf wakker te maken!

Hoe doen we dat, die waarommer in ons wakker maken (of houden) en tegelijkertijd bewust worden van onze bias? Jezelf dwingen om niet meteen in oplossingen te denken, noemt Steve Peters in zijn boek The Chimp Paradox (aff.) “to arm wrestle your chimp” (armpje drukken met je inner chimp). Kun je proberen, maar ik verzeker je dat je dat verliest. Als bij het zien van een probleem de ideeën ongevraagd op je deur bonzen, schrijf ze dan op een post-it en hang ze net buiten je onderzoek. Ze komen aan de beurt, maar moeten nog even geduld hebben. Dit houdt je chimp rustig, waardoor je lekker ongestoord het probleem in kunt duiken. Hieronder vind je een van mijn favoriete problem framing-methodes die ik zelf bijna dagelijks gebruik.

Problem framing

Pak een probleem. Bijvoorbeeld: verpleegkundigen zijn een groot deel van hun dag kwijt aan administratie. Doe vervolgens de volgende invuloefening:

1. Onze (Wie? Gebruiker)
2. Heeft het probleem dat (Wat? Probleem, taak, wens)
3. Wanneer (Waar? Context, situatie)
4. In de ideale situatie (Waarom? Voordeel voor de gebruiker)
5. Voordeel voor de business (Ze betalen immers je salaris)

Let op bij het invullen van de volgende zaken:

1. Houd het kort: dit dwingt je om tot de essentie te komen.
2. Let op bij het gebruik van symptomen (koorts is bijvoorbeeld geen ziekte, het is jouw lichaam dat je laat weten dat er iets mis is). Zo voorkom je symptoombestrijding.
3. Beschrijf het probleem niet vanuit het ontbreken van de (of jouw) oplossing (omdat we geen livechat hebben op de site…) Zo voorkom je confirmation bias.
4. Vermijd het gebruik van containerbegrippen (inspiratie, duurzaam, authenticiteit, et cetera), anders wordt het veel te vaag.
5. Zakelijke doelstellingen zijn geen designproblemen (Als we geen 10 procent groei halen, dan…).

Verpleegkundigen-voorbeeld

De probleemstelling voor de verpleegkundigen zou je als volgt kunnen omschrijven:

1. Verpleegkundigen
2. Hebben het probleem dat ze, door de hoge werkdruk, eigen tijd moeten inzetten
3. Om de werkzaamheden van de dag te administreren
4. In de ideale situatie gebruiken ze eigen tijd om tot rust te komen
5. Waardoor de kwaliteit van de zorg zal toenemen

Persoonlijk blijf ik het uiterst lastig vinden een probleem te ‘framen’. Het is niet voor niets dat Charles Kettering (uitvinder van onder anderen de startmotor en de airconditioning) een mooi citaat de wereld in heeft geslingerd:

A problem well stated is a problem half solved.

Neem van mij aan dat het leven er een stuk eenvoudiger uitziet als al je teamleden het probleem begrijpen en delen. Ik heb het hier nadrukkelijk over ‘begrijpen’ want we hoeven het natuurlijk niet altijd met elkaar eens te zijn.

Wat voor de één een probleem is, is voor de ander gesneden koek. Zolang we het maar begrijpen vanuit de context van onze geliefde eindgebruiker. En deze gebruiker is bij voorkeur niet de belangrijkste investeerder van het bedrijf, maar een heus persoon dat graag wil betalen voor jouw service omdat je, jawel, ermee een probleem voor ze oplost.