Welk probleem lossen we op? & 3 andere vragen vóór je weer een nieuwe tool bouwt

Ergens in Nederland zit op dit moment een stuurgroep bij elkaar. Weer geen meter verder gekomen sinds vorige maand. De roadmap loopt vast en teams leveren te weinig op. Niemand weet precies waarom. Na een uur discussie zegt iemand: ‘We hebben een betere tool nodig.’ De rest knikt. Eerste stap: demo’s plannen.

Dat is het moment waarop het helemaal de verkeerde kant opgaat. De tool kan best goed zijn. Dat is het punt niet. Het punt is dat niemand de vraag heeft gesteld die eraan vooraf hoort te gaan: welk probleem lossen we eigenlijk op?

Wat er daarna gebeurt, kennen we allemaal. Er komt een selectietraject, een implementatiepartner, een training, een adoptiecampagne van twee dagen. En zes maanden later is het oorspronkelijke probleem nog precies hetzelfde, maar nu met een duurder dashboard eromheen.

Tussen de 70 en 95 procent van alle digitale transformaties haalt niet het beoogde resultaat. De software werkt prima. De volgorde klopt alleen niet.

De product owner die het als eerste voelt

Stel: je bent ergens de manager en je hebt vorige maand een nieuwe roadmaptool laten uitrollen. Je product owner heeft een training gehad, het dashboard staat klaar en je verwacht dat de prioritering nu ‘scherper’ wordt.

Maar de vraag op basis waarvan de product owner prioriteert, is nooit beantwoord. Niet in de stuurgroep, niet in de training en ook niet in de tool. Dus doet ze wat ze altijd deed, maar nu in een ander systeem. Met meer velden, meer views en meer verwachtingen, maar niet met meer helderheid.

Uit het nationale product owner onderzoek 2026 blijkt dat bijna 40 procent van de developmentteams geen waarde meet. De tools om waarde te meten bestaan natuurlijk volop, maar de organisatie heeft niet bedacht, uitgesproken en opgeschreven wat waarde betekent.

Software implementeren boven op die onduidelijkheid maakt het probleem niet kleiner. Je geeft de onduidelijkheid alleen een dashboard.

En die 40 procent betreft niet de product owners die niet wíllen meten. Het zijn product owners in organisaties met wie niemand het gesprek heeft gevoerd over wat waarde eigenlijk is. Als leidinggevende is dat gesprek van jou, niet van je PO.

Vier vragen die je stelt voordat je begint te bouwen of te configureren

De organisaties waar het wél werkt, doen iets wat bijna teleurstellend simpel is: ze draaien de volgorde om. Geen tool als startpunt, maar vier vragen.

1. Welk probleem lossen we op? Voor wie?

Niet “we willen meer data-driven werken”, maar: “We nemen op dit moment beslissingen over onze roadmap zonder dat we weten wat gebruikers daadwerkelijk nodig hebben en dat kost ons kwartalen.” Hoe specifieker het probleem, hoe scherper de oplossing. Kun je het niet in één zin formuleren met de pijn voor een concreet team erin, dan ben je er nog niet.

2. Welk gedrag moet veranderen?

Een tool verandert geen gedrag. Als teamleads prioriteiten bepalen op basis van wie het hardst roept, dan verandert een nieuwe prioriteringstool daar niets aan. Je moet eerst het gesprek voeren over hoe beslissingen genomen worden. Pas daarna kun je kijken welk instrument dat ondersteunt.

3. Welke beslissingen moeten beter worden, en wie neemt ze?

Dit is de vraag die het vaakst wordt overgeslagen. In veel organisaties is het niet zo dat er te weinig data is. Er is te veel. Niemand weet welke data ertoe doet voor welke beslissing. Een dashboard dat alles laat zien, helpt niemand als onduidelijk is wat je ermee moet doen.

En hier wordt de belofte van AI heel concreet. Leidinggevenden scoren gemiddeld een 5,3 op AI-kennis en -strategie in datzelfde product owner onderzoek. Ze kopen Copilots en AI-assistenten, maar een AI-tool die backlogitems genereert voor een team dat niet weet waar het naartoe werkt, produceert meer output.

Meer herrie. Niet meer waarde. De volgorde geldt voor AI net zo hard als voor iedere andere technologie. Misschien harder, want de snelheid waarmee AI output produceert, maakt de illusie van vooruitgang alleen maar overtuigender.

4. Pas daarna: welke software ondersteunt dat?

En dan kan het antwoord soms zijn: geen nieuwe software. Soms is het antwoord een ander overleg. Een andere manier van rapporteren. Een duidelijkere rolverdeling. De eerlijkste en goedkoopste conclusie van een transformatietraject is soms dat je geen tool nodig hebt, maar een besluit.

Wat je als leidinggevende morgen anders kunt doen

Dit is geen pleidooi tegen software en ook niet tegen AI. Het is een pleidooi voor een andere volgorde.

Formuleer het probleem in één zin. De volgende keer dat iemand voorstelt om een nieuwe tool aan te schaffen, stel dan eerst de vraag: welk probleem lossen we hiermee op en voor wie? Niet als retorische oefening, maar als serieuze toets.

“Onze productteams besteden eenderde van hun tijd aan werk dat niet op de roadmap staat, omdat we geen mechanisme hebben om adhocverzoeken te wegen.” Dat is een startpunt. “We willen meer data-driven werken”,  is dat niet.

Stel de gedragsvraag vóór je een tool kiest. Vraag je af: als dit probleem morgen opgelost zou zijn, wat doen mensen dan anders dan vandaag? Als het antwoord is “ze gebruiken de nieuwe tool”, ben je er nog niet. Het gaat om hoe mensen besluiten nemen en hoe ze omgaan met druk van buiten het team.

Die gedragsverandering kun je ontwerpen, maar alleen als je hem eerst benoemt.

Meet waarde, niet adoptie. Stop met het meten van hoeveel mensen de tool gebruiken. Begin met meten of het probleem kleiner wordt. Als de waarde niet komt, is meer adoptie niet het antwoord. Dan is de vraag niet hoe je meer mensen in de tool krijgt, maar of de tool het juiste probleem oplost.

De verschuiving van software-first naar probleem-first is geen technologische keuze. Het is een management keuze. En het is de keuze die het verschil maakt tussen organisaties die digitaal transformeren en organisaties die alleen maar digitaal investeren.

Dit is het eerste artikel in de reeks ‘De staat van de digitale organisatie’.