Een nuttig probleem is groot of vaak genoeg om aandacht te verdienen

Het dashboard ziet er prachtig uit in de demo. In dit denkbeeldige geval ontdekt het een opmaakfout in een maandelijkse export. De fout herstellen duurt twee minuten en komt tweemaal per jaar voor. Iedereen vindt de demo goed; na de proefperiode opent niemand het dashboard nog.

Het probleem is echt genoeg om te beschrijven, maar ermee leven kost misschien minder dan een extra tool invoeren. Mooi ontwerp creëert op zichzelf geen urgentie.

Een opgenomen gesprek over producten geeft een bruikbare test met twee assen: wees voorzichtig met een probleem dat zowel klein als zeldzaam is. Een groot probleem kan aandacht verdienen als het zelden gebeurt; een kleine terugkerende taak kan zich tot dagelijks werk ophopen. Kijk naar het werk achter de pitch.

Tel hoe vaak iets gebeurt en wat het kost apart

‘Hoeveel mensen hebben dit probleem?’ is als eerste vraag te breed. Vraag één team wanneer het voor het laatst gebeurde en wat daarop volgde. Kostte het iemand minuten, ging een verkoop verloren, liep een bestelling vertraging op, werden privégegevens blootgesteld of was het alleen hinderlijk? Die gevolgen zijn niet uitwisselbaar.

Vraag vervolgens hoe vaak hetzelfde soort gebeurtenis optreedt. Een correctie van vijf minuten per week kan in een groot team veel tijd kosten. Een fout eens per jaar kan zwaar wegen als die een belangrijke overdracht blokkeert. Een hinder van twee minuten die tweemaal per jaar voorkomt, is moeilijker als zelfstandig product te verkopen.

Een denkbeeldige keuze langs beide assen:

De vakken geven aan wat je moet onderzoeken, geen marktbeslissing. ‘Hoog’ hangt af van wiens kosten je meet. Een fout die een beheerder nauwelijks raakt, kan voor een klant ernstig zijn. Een fout die in een kort gesprek nooit voorkwam, kan tijdens een seizoenspiek centraal staan.

Een probleem kan klein zijn in een demo en groot in een systeem

Integratiewerk maakt het verschil concreet. Een verkeerde veldwaarde lijkt klein op één contactrecord. Als dezelfde toewijzing op duizenden contacten wordt toegepast, ontstaat terugkerend handwerk. Omgekeerd kan een ingewikkelde waarschuwing voor een eenmalig cosmetisch verschil meer beheer toevoegen dan ze wegneemt.

De gids voor het integreren van bedrijfstools begint bij workflow en gezaghebbende bron, omdat de werkelijke kosten ontstaan wanneer records bewegen en worden gebruikt. Een team dat overstapt van gratis tools moet ook omwegen en gemiste handelingen tellen, niet alleen functies vergelijken.

Vraag naar de laatste drie echte keren. Noteer telkens wie het ontdekte, wie het herstelde, welk ander werk stopte en wat er zonder ingreep was gebeurd. De laatste vraag maakt onderscheid tussen een ergernis en een onzichtbaar risico. Ze voorkomt ook dat een oprichter of koper een pakkend denkbeeldig geval als gemeten patroon presenteert.

Vraag daarna wat de huidige omweg kost. Een spreadsheet en een controle van vijf minuten kunnen goed genoeg zijn. Een handmatig proces waarvoor elke ochtend een specialist records moet vergelijken misschien niet. Het alternatief hoort bij de waarde van het product en mag niet worden genegeerd.

Test adoptiekosten naast probleemkosten

Zelfs een betekenisvol probleem vraagt niet altijd om een nieuwe applicatie. Iemand moet die koppelen, leren gebruiken, de uitkomsten bekijken en de toegang onderhouden. Kost het product meer aandacht dan de taak, dan kunnen kopers verstandig bij de huidige omweg blijven.

Het brongesprek waarschuwt ook dat veel hulp bij de installatie vroege belangstelling groter kan laten lijken dan ze is. Een team lijkt software te kopen maar leunt in feite op advieswerk zonder prijskaartje. Een klein probleem met dure onboarding is extra lastig duurzaam te bedienen. Dienstverlening mag best; tel haar alleen mee.

Er zijn uitzonderingen op de twee assen. Regelgeving kan handelen verplichten terwijl incidenten zelden worden gezien. Een nieuwe markt heeft misschien weinig geschiedenis om te meten. Een kleine doelgroep kan een pijnlijk probleem hebben dat de brede bevolking niet kent. Het bewijs moet dan komen uit verplichtingen, geloofwaardige foutpaden of toegezegde budgetten, niet alleen uit een schatting van de frequentie.

De assen helpen ook beslissen of een behoefte een eigen product of een kleine functie verdient in iets dat mensen al gebruiken. Een zeldzame opmaakfout kan een handige knop in de export rechtvaardigen, ook als niemand voor een aparte dienst wil betalen. Een klein veelvoorkomend probleem los je misschien beter op met een andere standaardinstelling dan met nog een dashboard. De productomvang moet passen bij de aandacht die de taak nu al krijgt. De vraag is niet of het probleem bestaat, maar hoeveel nieuw gedrag de oplossing redelijkerwijs mag vragen.

De nuttige onderzoeksvraag is niet ‘Zou je dit gebruiken?’, maar ‘Vertel over de laatste keer dat dit gebeurde, wat het kostte en wat je in plaats daarvan deed.’ Een product verdient zijn plek als het antwoord wijst naar werk dat mensen al proberen te veranderen.