In een wereld waarin een functie sneller dan ooit ontworpen, geprogrammeerd en uitgerold kan worden, is snelheid niet langer het grootste probleem. Het probleem is het maken van de keuze: wat is het eigenlijk waard om te bouwen.
Er komt een moment in het leven van bijna elk ontwikkeld systeem waarop de lijst met functies een eigen leven gaat leiden.
"De klant vroeg erom."
"De concurrent heeft het."
"Dat zal vast niet moeilijk zijn."
"Aangezien we die module al hebben, voegen we er nog even..."
"AI doet het snel."
En plots belandt weer een functie in de backlog. Daarna nog een. En nog een. Na een paar jaar heeft het bedrijf een app die bijna alles kan. Alleen wordt het voor de gebruiker steeds moeilijker om te vinden wat hij echt nodig heeft.
Dit is niet alleen een UX-probleem. Dit is een businessprobleem.
Wanneer meer functies geen beter product betekenen
Jarenlang was productontwikkeling vrij eenvoudig: als gebruikers nieuwe mogelijkheden nodig hebben, voegen we nieuwe functies toe. Klinkt logisch.
Het probleem ontstaat wanneer productontwikkeling gereduceerd wordt tot het aantal opgeleverde features. Dan gaat het team optimaliseren voor het aantal dingen dat ze "geleverd" hebben in plaats van voor de waarde voor de gebruiker.
Dan ontstaat de zogenaamde Feature Factory - een organisatie die functionaliteiten produceert, maar niet per se meet of ze daadwerkelijk klantproblemen oplossen.
Dit fenomeen is niet nieuw. Wat nieuw is, is het tempo waarin dit vandaag kan gebeuren.
AI verkort de weg van idee naar werkend prototype aanzienlijk. Atlassian beschrijft de verandering duidelijk: met ontwikkelingsagenten kan de route van "we weten wat we willen bouwen" naar een werkend prototype van weken naar uren krimpen.
Dat is een enorme kans. Maar ook een valkuil.
Want als bouwen goedkoper en sneller wordt, is het makkelijker om dingen te beginnen te bouwen die vroeger niemand durfde te bestellen.
"Als we het kunnen, laten we het doen"
Dat is een van de duurste zinnen in IT-projecten. Niet omdat elke extra functie een fortuin kost. Het probleem is dat een functie zijn leven niet beëindigt bij de lancering.
Elke nieuwe module moet later onderhouden worden. Je moet het testen. Je moet rekening houden met het bij toekomstige wijzigingen. Je moet de werking documenteren. Je moet bugs afhandelen. Je moet gebruikers trainen. Je moet het in de UX meenemen. Je moet de beveiliging bewaken. Je moet checken of latere systeemwijzigingen iets kapot maken.
Dus de kosten van een functie zijn niet alleen de creatiekosten. Het is ook de kost van het toekomstige bestaan.
En precies die kosten zie je vaak niet op het moment dat iemand zegt:
"Laten we er misschien nog één toevoegen..."
De duurste functie kan degene zijn die niemand gebruikt
Stel je een bedrijf voor dat een B2B-paneel ontwikkelt.
Klanten kunnen bestellingen plaatsen, aankoopgeschiedenis bekijken, documenten downloaden en contact opnemen met hun accountmanager.
Er komt het idee voor een uitgebreid rapportagesysteem. Het team ontwerpt het. Developers bouwen het. Er verschijnen grafieken, filters, exports, overzichten en tientallen extra parameters. De functie gaat live.
En dan blijkt dat de meeste klanten gewoon willen weten: wat heb ik gekocht, wat is onderweg en wat is de prijs.
De rest was een aanname. Ze hebben het niet nodig. Dat is een belangrijk verschil.
Een klant kan om een functie vragen. Dat betekent nog niet dat die functie zijn probleem oplost.
"De concurrent heeft het"
Dat is de andere klassieker.
Een bedrijf analyseert de concurrentie en ziet een nieuwe module.
En het begint: "Dat moeten wij ook hebben."
Maar de concurrent kan een compleet ander businessmodel hebben, een andere klantengroep, andere verkoopprocessen en een andere productstrategie.
Een functie die zinvol is in het ene systeem, kan volledig overbodig zijn in het andere.
Dit is vooral belangrijk bij maatwerkprojecten. Er bestaat geen universele set functies die van elke applicatie een goed product maakt.
Een systeem voor een industriële producent moet niet hetzelfde ontworpen worden als een platform voor een trainingsbedrijf.
Een CRM voor verkopers moet anders werken dan een B2B-paneel voor vaste klanten.
Een webshop die premium producten verkoopt heeft een totaal andere winkelervaring nodig dan een shop waar prijs de hoofdargument is.
Software moet voortkomen uit het businessmodel, niet uit het functiescatalogus van de concurrent.
AI verandert dit echt veel
En juist daarom is dit onderwerp nu bijzonder interessant.
Nog een paar jaar geleden moest een idee voor een nieuwe functie vele stappen doorlopen voordat een gebruiker het kon zien.
Analyse.
Ontwerp.
UX.
Development.
Tests.
Uitrol.
Vandaag kunnen veel van die stappen door AI aanzienlijk versneld worden. We kunnen sneller een prototype maken. Sneller een interface voorbereiden. Sneller code schrijven. Sneller tests genereren. Sneller data analyseren.
En daarom is snelheid van development op zichzelf geen voldoende voordeel meer.
Als iedereen iets sneller kan bouwen, krijgt degene die beter kiest wat te bouwen de voorsprong.
Atlassian wijst op dit paradox: AI verhoogt het tempo, maar meer tempo alleen betekent nog geen betere producten. Tegelijk gaf 89% van de door Atlassian ondervraagde managers aan dat hun werktempo toenam dankzij AI, terwijl slechts 6% zich zeker voelde over het bepalen van de ROI van AI op organisatieniveau.
Dat laat goed het verschil zien tussen sneller doen en een beter resultaat bereiken.
Eerst het probleem. Pas daarna de functie
Een goed productproces zou moeten beginnen met de vraag: Welk probleem proberen we op te lossen?
Niet: "Welke functie voegen we toe?"
Dat lijkt een klein verschil. In de praktijk verandert het alles.
Als een klant zegt: "We hebben een mobiele app nodig",
is het de moeite waard om te vragen: Waarom?
Misschien heeft hij inderdaad een app nodig. Maar misschien is het probleem dat er geen handige toegang tot het paneel op de telefoon is. Misschien volstaat een goed ontworpen responsive interface. Misschien een PWA. Misschien een mobiel module voor één proces. Of misschien is een app nodig, maar om heel andere redenen dan de klant aanvankelijk noemde.
Hetzelfde geldt voor functies.
"We hebben automatische rapporten nodig." — Waarom?
"Omdat verkopers tijd verliezen." — Waaraan?
"Aan het overtypen van data uit het systeem."
En dan blijkt dat het probleem geen gebrek aan rapporten is. Het probleem is het ontbreken van integratie.
Goede analyse kan maanden development besparen.
Soms is de beste functie: geen functie
Dat klinkt paradoxaal, maar dat zou de rol van een ervaren technologisch partner moeten zijn.
Niet alleen uitvoeren. Ook aannames bevragen wanneer daar reden voor is.
Als een klant met een lijst van twintig functies komt, zou een softwarehuis die niet automatisch als technische spec in steen moeten beschouwen.
Het zou moeten vragen: Welke van deze functies lossen een reëel probleem op? Welke zijn kritisch? Welke vergroten de verkoop? Welke besparen werk? Welke verbeteren klantservice? Welke zijn wettelijk of operationeel vereist? Welke zijn alleen maar "leuke toevoegingen"?
En vooral: waaraan zien we dat een functie geslaagd is?
Zonder dat laatste is het makkelijk een product te bouwen dat steeds groter wordt, maar je nooit weet of het daadwerkelijk beter wordt.
Een product moet "nee" kunnen zeggen
In goed product development is een lijst van dingen die we niet bouwen net zo belangrijk als de lijst van dingen die we wel bouwen. Dat vergt moed.
Want makkelijk is zeggen: "Ja, we doen het."
Moeilijker is zeggen: "Op basis van wat we nu weten, zien we nog geen reden om hiervoor te betalen."
En nog moeilijker is dat tegen een klant te zeggen die met een kant-en-klaar idee binnenkomt.
Maar precies dan begint partnership.
Een softwarehuis zou niet alleen een team moeten zijn dat opdrachten in code omzet. Het zou de klant moeten helpen technologische beslissingen te nemen.
Soms betekent dat het ontwerpen van een functie.
Soms het vereenvoudigen ervan.
Soms het vervangen door een andere oplossing.
En soms het volledig afzien van het idee.
Hoe herken je een functie die je waarschijnlijk niet nodig hebt?
Er is geen magische test, maar een paar vragen kunnen de euforie snel temperen.
Wie precies gaat dit gebruiken?
Als het antwoord "iedereen" is, is het goed om specifieker te worden.
Welk probleem lossen we op?
Als het antwoord is "het is handiger", dan verdient het probleem waarschijnlijk verdere analyse.
Hoe vaak zal de gebruiker dit gebruiken?
Eens per jaar? Eens per maand? Dagelijks?
Is er een eenvoudigere manier om hetzelfde probleem op te lossen?
Deze vraag is bijzonder belangrijk.
Hoe meten we het effect?
Meer omzet? Minder werk? Kortere processen? Minder fouten? Meer retentie?
Wat gebeurt er als we de functie niet bouwen?
Als het antwoord is "eigenlijk niets", hebben we misschien net een functie gevonden die niet gebouwd hoeft te worden.
Niet elk verzoek van een gebruiker hoort in de backlog
Dat is ook een belangrijke mindset-verandering.
Feedback van gebruikers is van onschatbare waarde. Maar feedback is geen automatische productspecificatie.
Een gebruiker vertelt over zijn probleem vanuit zijn eigen ervaring.
Hij kan zeggen: "Ik heb knop X nodig."
De rol van het productteam is niet het kritiekloos maken van knop X.
De rol is te begrijpen: waarom heeft de gebruiker die knop nodig?
Pas dan kun je beslissen of knop X echt de beste oplossing is.
Het kan automatisering zijn.
Een integratie.
Een procesverandering.
Een beter interface.
Gebruikerstraining.
En soms inderdaad een nieuwe functie.
Dat is precies het verschil tussen feature delivery en product development.
Data kan ook zeggen: "verwijder dit"
Productontwikkeling zou niet moeten eindigen bij toevoegen.
Je moet ook kijken naar wat er al is.
Welke functies worden gebruikt?
Welke worden genegeerd?
Waar haken gebruikers af?
Welke processen kosten de meeste tijd?
Welke onderdelen genereren de meeste supporttickets?
Welke features verhogen conversie?
En welke compliceren alleen de interface?
Soms is het beste ontwikkelproject niet het toevoegen van een nieuwe module. Het is het verwijderen van drie onnodige. Dat kan de UX meer verbeteren dan nog een maand development.
AI kan hier ook helpen
Interessant genoeg hoeft AI niet alleen te dienen om functies te creëren.
Het kan ook helpen analyseren of functies zinvol zijn.
Het kan gebruikersfeedback analyseren.
Tickets groeperen.
Terugkerende problemen detecteren.
Supportdata analyseren.
Gesprekken met klanten samenvatten.
Het team helpen hypotheses te vergelijken.
Variantoplossingen voorbereiden.
Gedragsanalyse ondersteunen.
Paradoxaal genoeg kan het beste gebruik van AI in productontwikkeling soms niet zijn dat we dankzij AI sneller een nieuwe functie bouwen.
Maar dat we sneller ontdekken dat we die functie niet zouden moeten bouwen.
Web24: eerst vragen we "waarom?"
Elk softwareproject begint met een behoefte.
Soms weet de klant precies wat hij nodig heeft.
Soms heeft hij al een specificatie.
Soms komt hij alleen met een probleem: "Dit proces kost ons drie uur per dag."
En dat is een heel goed vertrekpunt.
Want dan kunnen we nadenken niet over hoe we de voorgestelde oplossing coderen, maar over hoe we het probleem het beste oplossen.
Dat is precies wat maatwerksoftware onderscheidt van het samenstellen van een product uit kant-en-klare functies.
Bij Web24 gaat het niet om een applicatie met zoveel mogelijk mogelijkheden.
Het gaat om een applicatie met de mogelijkheden die echt nodig zijn voor die specifieke business.
Daarom kunnen twee vergelijkbare systemen er heel anders uitzien en anders werken.
Omdat processen verschillen.
Gebruikers verschillen.
Doelen verschillen.
Verkoopmethoden verschillen.
Klantenservice verschilt.
En het probleem dat de software moet oplossen verschilt.
De duurste backlog is die welke niemand in twijfel trekt
In een AI-wereld kunnen we in een erg interessante fase van softwareontwikkeling komen.
Technologie zal beter worden in het beantwoorden van de vraag: "Hoe bouwen we dit?"
En de mens zal steeds beter moeten antwoorden op de vraag: "Zouden we dit überhaupt moeten bouwen?"
Dat kan een van de belangrijkste veranderingen in softwarecreatie worden.
Want als kosten en tijd om een extra functie te realiseren dalen, neemt de verleiding om ze toe te voegen toe.
En daarmee groeit het belang van Product Discovery, UX, data-analyse, gesprekken met gebruikers en een strategische benadering van productontwikkeling. Gartner waarschuwt dat snelle productontwikkeling aangedreven door AI kan leiden tot uitdagingen in strategische alignment en een toename van technical debt als technologische snelheid niet gepaard gaat met productmanagement.
Dus de toekomst behoort niet alleen aan bedrijven die sneller kunnen bouwen. Het behoort ook aan diegenen die beter weten te kiezen wat ze bouwen.
Want soms is de beste technologische beslissing niet: "Laten we nog een functie maken."
Maar: "Laten we eerst controleren of we hem echt nodig hebben."
