De AI MECE Probleem Structuur Coach skill voor Claude

Het probleem dat de skill oplost is een vergaderprobleem dat je waarschijnlijk herkent. Er is iets mis, iedereen heeft een theorie, en binnen tien minuten praat de kamer over oplossingen terwijl niemand het probleem heeft opgeschreven. Er wordt data opgehaald zonder dat iemand weet welke vraag die data moet beantwoorden. Twee mensen onderzoeken hetzelfde vanuit een andere hoek. En de tak waar het antwoord werkelijk in zit, staat op geen enkel bordje, want die is niemand opgevallen. Daar zet de skill een vaste volgorde tegenover: eerst structureren, dan pas oplossen.

Hij is geschreven voor iedereen die af en toe met een vraagstuk zit dat groter is dan een taak: ondernemers, managers, adviseurs, marketeers, projectleiders. De typische aanleidingen die de skill zelf noemt zijn strategische keuzes, omzetdalingen, klantretentie, productiviteitsvraagstukken, marktonderzoek en organisatorische problemen. Kortom: de momenten waarop mensen meteen in oplossingen schieten. Hij hoort thuis in de dienst AI en automatisatie, waar we dit soort werkwijzen ook echt inrichten voor bedrijven.

Eén ding moet je vooraf weten, en de skill zegt het zelf ook: hij structureert, hij lost niet op. Aan het eind van een sessie heb je geen antwoord op je vraag. Je hebt een boom, een set hypothesen en een plek om te beginnen. Dat klinkt minder dan een antwoord, maar het is precies wat ontbreekt op het moment dat een vraagstuk te groot voelt. Structuur maakt het onderzoek efficient, het vervangt het onderzoek niet.

De vraag is een oplossing in vermomming. Hoe verhogen we ons advertentiebudget is geen probleemvraag maar een besluit dat al genomen is. Wie zo begint, onderzoekt alleen nog of het besluit klopt. Wat de skill eist, is dat de resolutievraag begint met waarom, hoe of welke, dat hij met onderzoek te beantwoorden is, en dat er geen oplossing in zit. Waarom daalt onze maandomzet voldoet daaraan, en dat verschil bepaalt alles wat eronder hangt.

De takken overlappen elkaar. Zet je een vraagstuk uiteen in marketing, sales en klanttevredenheid, dan kan een oorzaak in alle drie tegelijk vallen. Het gevolg is dubbel werk en een discussie over wie waarvan is. De M van MECE staat precies daarvoor: mutually exclusive, de delen sluiten elkaar uit.

Er zit een gat in de indeling. Dit is de duurste fout, want je merkt hem niet. Als je omzetdaling uiteenvalt in minder klanten en lagere orderwaarde, maar niemand de vertrokken klanten als aparte tak opschrijft, dan onderzoekt de hele club maandenlang de verkeerde helft. De C van collectively exhaustive dekt dat af: samen honderd procent.

De hypothese kan niet fout zijn. Klanten zijn ontevreden is geen hypothese, want er is geen enkel onderzoek denkbaar dat die uitspraak onderuit haalt. Per tak moet er dus een falsifieerbare uitspraak liggen: klanten die in het eerste kwartaal instroomden zeggen bij opzegging vaker dat de levertijd tegenviel. Die kun je toetsen, en dus kun je hem ook verliezen.

Alles is even belangrijk. Zonder prioritering blijft een boom een mooi plaatje. Daarom markeert hij welke twintig procent van de takken naar verwachting tachtig procent van het antwoord oplevert, met de reden erbij, en sluit hij af met één actie. Niet drie, want wie met drie acties begint, begint met geen enkele.

In diff-vorm, met regels uit het voorbeeld van de skill: wat er als vraagstelling uit gaat, en wat ervoor terugkomt.

Niet alleen bij de vaktermen MECE, issue tree, probleemboom, Minto, Pyramid Principle, SCQA en McKinsey methode, maar juist ook bij hoe mensen het echt zeggen: waar begin ik, dit probleem is te groot, ik zie door de bomen het bos niet, help me dit opknippen, wat is de kernvraag, waarom daalt onze omzet, waarom lopen klanten weg, en ik weet niet welke data ik moet ophalen. In de frontmatter staat er meteen bij wanneer je hem juist niet moet gebruiken: bij pure feitenvragen met één antwoord, en bij taken van minder dan twee uur, want daar is structureren duurder dan gewoon doen.

Daarna volgt een hoofdstuk over de theorie waarop de skill rust, en pas daarna de werkwijze: vier fases in een vaste volgorde. Fase 1 is de probleemdefinitie via SCR, drie regels: de situatie in feiten, de complicatie die de situatie verstoort met sinds wanneer en hoe merkbaar, en de resolutievraag. Die vraag wordt de wortel van de boom, en de instructie is uitdrukkelijk om hem eerst ter bevestiging voor te leggen, want zit de wortel fout, dan is alles eronder verspilde moeite.

Fase 2 is de decompositie. De wortelvraag gaat in twee tot vijf deelvragen, en de skill moet bewust een structuur kiezen uit zes mogelijkheden: algebraisch, procesmatig, per stakeholder, per segment, volgens een bestaand model zoals 7S, of intern tegenover extern. Algebraisch heeft daarbij de voorkeur wanneer het kan, want dat is het meest waterdicht. Hij benoemt welke structuur hij kiest en waarom, splitst hooguit drie niveaus diep, en toetst elke splitsing hardop op de twee vragen uit FIG.02.

Fase 3 hangt aan elke tak vier dingen: een falsifieerbare hypothese, een impactinschatting van hoog, midden of laag met één zin waarom, het bewijs dat nodig is inclusief waar dat te halen valt, en een eigenaar die het uitzoekt. Ontbreekt de data om de impact in te schatten, dan komt er [ONBEKEND] te staan. Daar wordt nooit een zelfbedacht getal ingevuld.

Fase 4 sluit af: de MECE-toets nog eens expliciet en uitgeschreven als zin in plaats van als vinkje, de 80/20 markering met reden, en één concrete actie voor morgen van maximaal één werkdag, met daarbij de vraag die hij beantwoordt en wat je daarna weet. Daarnaast staat er een verplichte inputchecklist van zes punten, met de regel dat de skill alleen navraagt wat ontbreekt en maximaal twee vragen tegelijk stelt.

Er staat een vast outputformat in met de koppen Probleemdefinitie, Issue Tree, MECE check, 80/20 prioriteit en Actie voor morgen. Er staat een volledig uitgewerkt voorbeeld in, dat je in verkorte vorm in FIG.01 en FIG.02 terugziet. En het bestand sluit af met acht weigeringen, vijf grenzen van het framework en zes bronnen. Wil je zelf zo'n bestand leren schrijven, dan legt SKILL.md schrijven die opbouw stap voor stap uit.

MECE en de pyramide komen van Barbara Minto. Zij ontwikkelde het principe in de jaren zestig bij McKinsey en werkte het uit in The Pyramid Principle. Twee jaartallen zijn allebei juist en horen bij verschillende uitgaven: in 1973 gaf zij het zelf uit als een reeks boekjes, en in 1987 verscheen de brede editie bij Pearson die de rest van onze skillpagina's noemt.

MECE staat voor Mutually Exclusive, Collectively Exhaustive: onderdelen die elkaar niet overlappen en samen honderd procent van het probleem dekken. Het Pyramid Principle zelf gaat over iets anders, namelijk hoe je het antwoord communiceert: top down, met de governing thought vooraan en de onderbouwing eronder. MECE zit daaronder, want het bepaalt hoe je het probleem opknipt voordat je een antwoord formuleert. Wie vooral het communicatiedeel zoekt, is beter af bij de Pyramid Principle Schrijver skill, en voor de verhaalopening bestaat de SCQA communicatiecoach.

Het hypothesegedreven werken komt van Ethan Rasiel. The McKinsey Way uit 1999 beschrijft de praktijk erachter: je begint niet met data verzamelen maar met een hypothese, en de data die je daarna ophaalt heeft een doel. Dat vertaalt de skill naar de eis dat elke tak een falsifieerbare uitspraak draagt, met daarbij het bewijs dat nodig is en waar dat te halen valt. Rasiel schreef in 2001 met Paul Friga ook The McKinsey Mind, dat als tweede bron in het bestand staat.

De logic tree en de 80/20 komen van Conn en McLean. Bulletproof Problem Solving uit 2018 werkt de boom uit als werkplan: per tak weet je wie hem oppakt, welk bewijs nodig is en wanneer je klaar bent. Daar komt ook de eis vandaan dat je markeert welke twintig procent van de takken naar verwachting tachtig procent van het antwoord oplevert. Wie precies dat prioriteringsdeel zoekt, kan naast deze skill de Pareto Analist skill gebruiken.

De 5 Whys komt van Taiichi Ohno. Toyota Production System uit 1978 staat in de bronnenlijst als aanvullende techniek voor één enkele tak. Dat is een nuttige afbakening: MECE ordent het geheel, de 5 Whys graaft binnen één tak door naar de oorzaak. Die twee bijten elkaar niet, ze werken achter elkaar. De 5 Waarom Analist skill is de logische volgende stap zodra je weet welke tak je wilt uitgraven.

De waarschuwing tegen bevestigingsdrang komt van Richards Heuer. Psychology of Intelligence Analysis uit 1999 gaat over het toetsen van concurrerende hypotheses in plaats van het bevestigen van één. Dat is de scherpste zelfkritiek in het hele bestand: hypothesegedreven werken maakt je sneller en vergroot tegelijk de kans dat je vindt wat je al dacht. Actief bewijs zoeken dat je eigen hypothese onderuit haalt, is daarom een harde opdracht in het bestand. Wie die reflex breder wil trainen, kan terecht bij de Eerste Principes Denker skill, die aannames afpelt tot wat er echt vaststaat.

Ook zonder de skill te installeren kun je met deze principes je eigen vraagstuk beter aanpakken: schrijf de vraag op voordat je oplossingen bedenkt, toets je indeling op overlap en gaten, en zoek bewijs dat je ongelijk geeft.

Daarna is het gebruik simpel: beschrijf je vraagstuk in normale taal, inclusief wat er precies gebeurt, sinds wanneer, en welke cijfers je wel en niet hebt. Hoe rauwer de beschrijving, hoe beter, zolang er maar feiten in zitten. Wat ontbreekt vraagt hij zelf na, maximaal twee dingen tegelijk. Werkt de indeling voor jouw branche niet goed genoeg, open dan de SKILL.md en voeg je eigen decompositiestructuren toe: het is een tekstbestand, geen black box. In de kennisbank staat de bredere uitleg over werken met AI.

Er zijn ook situaties waarin je hem beter laat liggen, en het bestand is daar zelf duidelijk over. Bij pure feitenvragen met één antwoord is een boom onzin. Bij taken van minder dan twee uur is structureren duurder dan gewoon doen. En bij vraagstukken waar het probleem zelf nog niet vaststaat, of bij creatieve en ontwerpvragen, werkt divergeren beter dan opknippen: je moet dan eerst meer mogelijkheden zien, niet minder.

Daarnaast staan er vijf grenzen van het framework zelf in benoemd, en die zijn eerlijker dan je van een instructiebestand zou verwachten. MECE is een ideaal, geen garantie. In sociale en organisatorische vraagstukken overlappen oorzaken vrijwel altijd een beetje. Het doel is bruikbaar scheiden, niet perfect scheiden.

De boom is zo goed als de wortelvraag. Een keurige structuur onder een verkeerde vraag is verspilde precisie met een geruststellend uiterlijk. Hypothesegedreven werken vergroot de kans op bevestigingsdrang, dus zoek actief bewijs dat je hypothese onderuit haalt. Het model past slecht bij vraagstukken zonder vastomlijnd probleem, zoals hierboven al genoemd. En bij sterke terugkoppeling tussen takken is een boom een vereenvoudiging: als de prijs het verloop aanjaagt en het verloop weer op de prijs drukt, dan benoem je die lus in plaats van hem weg te knippen. In FIG.02 staat die waarschuwing letterlijk bij tak 3.

Wat de skill ook niet doet, is je vertellen of het probleem dat je aandraagt het juiste probleem is om nu aan te werken. Een perfect gestructureerde analyse van een randverschijnsel blijft een analyse van een randverschijnsel. Wie eerst wil bepalen of het vraagstuk uberhaupt urgent is, kan beter beginnen bij een risicoblik zoals de Pre-Mortem Analist skill, die een plan vooraf laat mislukken om te zien waar het breekt.

Een goede boom bespaart je weken verkeerd onderzoek, maar hij levert het onderzoek niet. Zit jouw vraagstuk in de hoek van vindbaarheid, dan is de eerste tak vaak sneller te toetsen dan je denkt: de gratis SEO scan laat in enkele seconden zien waar je site staat. En wil je doorpraten over wat AI verder voor je bedrijf kan doen, van losse skills tot volledige automatisering, dan doen we dat gewoon in een gesprek.