Geen glazen bol, wel een backlog: AI-producten bouwen voor nuchtere Product Owners

Live gaan is geen oplevermoment

Bij een klassiek softwareproject is de lijn helder: plan, build, test, live en dan gaat het in beheer. De scope ligt vooraf vast, het einde is bekend, en bugs fixen vormt het grootste deel van het werk daarna. Bij AI ziet die lijn er fundamenteel anders uit. Live gaan is geen eindstreep maar een startsignaal. Vanaf dat moment moet je continu meten of het model nog doet wat je ervan verwacht, bijsturen via prompts, regels en fallbacks, en periodiek hertrainen omdat data en gedrag in het echte gebruik veranderen.

Wat dat concreet betekent voor de PM: een begroting zonder einde en reserveer doorlopende capaciteit. Een team dat blijft draaien en geen “klaar en weg”-houding zoals bij een klassiek project. En een definition of done die uitbreidt: gemonitord, met fallback, met retrain-plan.

De richting zit niet meer in jouw hoofd

Het tweede grote verschil is misschien wel de belangrijkste en het meest onderschatte. Bij klassieke software wist je: dit framework, dit team, deze scope, ik kan zelf een redelijk plan maken. Bij AI is dat geen veilige aanname meer. Het modellandschap verandert per kwartaal, je technische team weet beter dan jij wat vandaag haalbaar is, en je concurrenten experimenteren met exact dezelfde modellen. Solo plannen vanuit je eigen hoofd loopt vast voordat je begint.

In plaats daarvan stuur je richting tússen drie buitenwerelden:

• Je technische team. Wat kan dit model nu wel en wat niet? Vraag het bij elke kickoff opnieuw, want modellen veranderen. Demo’s werken beter dan documentatie: laat zien wat eruit komt, zodat alle neuzen dezelfde kant op blijven.
• De markt. Wat is er deze maand veranderd in nieuwe modellen, prijzen en API’s? Wat zes maanden geleden onmogelijk was, kan vandaag standaard zijn. Plan expliciet ruimte in om te switchen want niets is voor altijd.
• De concurrent. Iedereen bouwt nu met dezelfde modellen, dus differentiatie zit elders: in jouw unieke data, workflow of context. Doe één keer per kwartaal een eerlijke feature-vergelijking: waar ben je beter, waar loop je achter, waar houd je jezelf voor de gek?

Drie concrete werkwijzen helpen om die drie buitenwerelden binnen te halen zonder erin te verzuipen. Start de functionele en technische roadmap apart: een functionele sessie met business, sales en klanten over wat we willen kunnen voor wie, alsook een technische sessie met engineers en data over wat haalbaar is met welke modellen en welke risico’s. Apart starten voorkomt dat de functionele kant meteen te conservatief wordt (“dat kan technisch niet”) of de technische kant te ambitieus (“want de business wil dit”). Pas in een derde sessie breng je ze samen daar maak je je echte roadmap, met scherpe keuzes in plaats van platte compromissen.

Stel daarnaast doelen en KPI’s op het niveau van outcomes, niet output. Niet “chatbot live in Q3”, maar “60% van level-1 vragen wordt zonder agent afgehandeld, met ≥ 80% tevredenheid”. Per use case één doel, één tot twee KPI’s, en één ondergrens (“zakken we daaronder, dan stoppen we”). Review die elke zes tot acht weken; KPI’s mogen kantelen, maar één voor één en met argumentatie. Bouw ook een outside-in ritme in: maandelijks dertig minuten met je tech-team over wat er nieuw is bij de grote modelleveranciers, elk kwartaal een feature-vergelijking met de top drie concurrenten, elk half jaar een reality check op je modelkeuze.

De kernboodschap van dit blok: je bent niet langer de PM die in haar eentje de richting bepaalt en het team laat uitvoeren. Je bent de PM die richting stuurt tussen drie buitenwerelden én die ze met elkaar laat praten.

Begin bij de use case, niet bij de feature

De zin waarmee een AI-traject begint, voorspelt vaak het succes ervan. “We willen een AI-chatbot” is geen probleem, dat is een technologie waar iemand over heeft gehoord. “Accountmanager Sophie verliest elke maandag twee uur aan het voorbereiden van haar klantgesprekken” is wél een vertrekpunt.

Het verschil zit in het onderwerp van de zin. Bij feature-denken staat het product centraal en groeit de lijst alleen maar; bij use-case-denken staat een persoon op een specifiek moment centraal en krimpt de lijst naar wat écht helpt. Pas als je de use case scherp hebt, weet je überhaupt welke AI-functie relevant is.

Een handige tool om dat scherp te krijgen is een use case canvas van zes velden: wie gebruikt het, welke taak proberen ze te doen, wat is de gewenste uitkomst, wat is de rol van AI, wat hebben we nodig om te starten, en de meest onderschatte vraag: wat is de grootste onzekerheid? Die laatste vertelt je waar je eerste experiment moet zitten.

Vier vragen die je altijd stelt

Vóór er één AI-story wordt geschreven, lopen deze vier vragen langs:

1. Welk probleem lossen we op en voor wie? Doorvragen tot je één mens kunt visualiseren op één moment in hun week, met één concrete frustratie. Geen naam, geen use case.
2. Hoe ziet succes eruit en hoe meten we dat? “Goed genoeg” is een getal, geen gevoel. Spreek vooraf af waar de ondergrens ligt, wat je meet, en wat er gebeurt met de gevallen die fout gaan.
3. Welke data hebben we en is die goed genoeg? Een goede test: leg de input die een model zou krijgen voor aan een ervaren collega. Als die zegt “met deze info kan ik geen goede beslissing nemen”, dan stopt het gesprek. Meer data, of een ander probleem.
4. Moet dit eigenlijk wel AI zijn? Drie tests helpen die vraag eerlijk te beantwoorden. De 80%-test: wat lost 80% van het probleem op zonder AI een if/else, een formulier, een zoekfunctie? De pasfactor: zijn de regels niet vooraf op te schrijven, gaat het om patronen in veel data, of verschilt de context per geval? De duct-tape-test: probeer je met AI iets te verbergen zoals slechte data, een vaag proces, onduidelijke regels, dat je eigenlijk eerst zou moeten oplossen?

Klein, oud en goedkoop wint vaak. AI is wat je toevoegt waar regels, formulieren en zoeken écht tekortschieten en niet waar je begint.

Bouwen zonder vangnet: drie vervangingen

Zodra AI in een product komt, vallen drie klassieke vangnetten weg. Bestaande klanten weten zelf niet wat ze van AI willen. Usage-data uit het verleden voorspelt AI-gedrag niet. En bewezen UX bestaat amper: hoe toon je “het model twijfelt”? Ook met duizend klanten sta je effectief op nul. Drie vervangingen werken in de praktijk:

• Founding customers als research-panel. Klein, betrokken, eerlijk. Behandel ze niet als opdrachtgevers, maar als mede-ontwerpers geef ze rauwe prototypes en vraag wat ze er kapot aan zouden trappen.
• Mens als bewijs én vangnet. Vóór de bouw bewijs je het concept eerst met de hand (Wizard-of-Oz). In productie houdt een mens-in-de-lus de twijfelgevallen vast: boven een confidence-drempel gaat het automatisch door, eronder kijkt iemand mee. Bij falen valt het systeem zacht terug naar een mens, een formulier of een telefoonnummer maar geen harde crash.
• Roadmap van vragen, niet van features. “Weten we in juni of het model accuraat genoeg is op onze data?” is een eerlijker doel dan “feature X live in juni”. Stuurgroep krijgt leerdoelen, geen toezeggingen.

Een backlog in drie soorten werk

Een AI-backlog bestaat uit drie soorten werk, bewust verdeeld. Discovery haalt onzekerheid weg: hypotheses, spikes, evaluaties. Capability is wat de gebruiker direct ervaart: klassieke user stories. Reliability zorgt dat het morgen ook werkt: drift-monitoring, fallback-paden, kosten in de hand houden. Die laatste sneeuwt in klassieke backlogs vaak onder; bij AI is het doorlopend productwerk.

De verhouding verschuift mee met de fase. Pre-product is je backlog 60% Discovery en 40% Reliability, met nul Capability dat is geen lege sprint, dat is een sprint die fundament oplevert. Met je eerste founding customers ligt het rond 50/25/25. Bij live en schalen kantelt het naar 15/60/25.

Scrum werkt met drie aanpassingen

Scrum is geen probleem voor AI-werk, mits je het bewust aanpast. Één-weekse sprints werken vaak beter dan twee-weekse, omdat spikes dagen duren en modellen wekelijks veranderen. Een sprint is geen leverritme meer maar een besluitvormings-ritme: aan het eind lever je niet per se een feature op, maar een antwoord op een leervraag. Wees daarnaast kritischer op ceremonies: ze kosten bij een team van vijf al snel vijf mensdagen per sprint. Drop, combineer of verkort wat geen waarde toevoegt. En verdeel je werk over Discovery, Capability en Reliability, niet alleen over user stories.

Drie regels voor stakeholders

Stakeholders zijn niet veranderd: ze willen weten wanneer iets klaar is, of het werkt, en wat het oplevert. Maar bij AI komen die zorgen er anders uit, en het verkeerd interpreteren van de vraag levert het verkeerde antwoord op.

Toon vroeg wat falen eruitziet: laat in de eerste demo expliciet een verkeerd antwoord zien, zodat falen vanaf dag één onderdeel van het product is en geen bug. Druk onzekerheid uit in cijfers, niet in woorden: “70–90% accuraat op 50 voorbeelden, eind juni go/no-go” geeft controle waar “het komt in juni” paniek veroorzaakt. En sta sterk: “we kijken het na” is een legitiem antwoord op “als ChatGPT dit kan, kan dit toch ook?”. Tijd kopen mag, gokken kost je later tien keer zoveel uitleg.

Drie vragen voor morgen

Wie morgen iets concreets wil doen, stelt drie vragen aan zijn eigen stakeholder. Wat is de ene gebruiker, het ene moment, het ene probleem dat we oplossen? Waar ligt onze ondergrens van kwaliteit en wat doen we met de rest? En wanneer is het go/no-go-moment, en wat moeten we dan weten?

Krijg je antwoord op die drie, dan heb je een project. Krijg je geen antwoord, dan weet je waar de onzekerheid zit en ook dát is voortgang. Begin bij use cases, stel de juiste vragen, vertrouw op je team en wees eerlijk over onzekerheid. Dan bouw je AI-producten, ook als het eindplaatje nog wazig is.