Toen Open AI ChatGPT in november 2022 introduceerde, brak er aanvankelijk een periode aan van intense nieuwsgierigheid naar wat het kon.
Daarna ontstond er een ware wedloop om uit te zoeken hoe deze nieuwe, baanbrekende technologie kon worden gebruikt.
Het duurde niet lang voordat productmanagers zich in deze ontwikkeling mengden en de uitdaging vanuit twee verschillende invalshoeken konden bekijken:
- Waar kan ik AI in mijn product gebruiken?
- Hoe kan ik AI gebruiken om mijn leven als productmanager gemakkelijker te maken?
Als je aan een platform voor productmanagement werkt, zie je die twee invalshoeken misschien samenkomen door het automatisch maken van user stories in je tool in te bouwen.
Briljant!
Maar alleen omdat je iets kunt doen, betekent dat nog niet dat je het moet doen.
De argumenten voor het gebruik van AI om user stories te schrijven
Schijnbaar van de ene op de andere dag is er een geheel nieuwe categorie AI voor productmanagers ontstaan: generatoren voor user stories.
Sommige daarvan zijn zelfs gratis!
Vervolgens begonnen gevestigde platforms voor productmanagement AI-mogelijkheden aan hun tools toe te voegen, waaronder het genereren van user stories met één druk op de knop.
De voordelen die deze tools, en de artikelen waarin ze worden aangeprezen, beloofden, kwamen in grote lijnen neer op het volgende:
- Het genereren van user stories met AI is sneller en efficiënter dan ze handmatig maken.
- Het genereren van user stories met AI zorgt voor een consistente indeling en brengt daardoor duidelijkheid.
- Het genereren van user stories met AI zorgt voor nauwkeurigere user stories.
- Het genereren van user stories met AI stimuleert creativiteit.
- Het genereren van user stories met AI verbetert de samenwerking.
Ik ga elk van deze aannames bespreken, maar eerst vind ik het belangrijk om stil te staan bij het oorspronkelijke doel van user stories.
Waar user stories oorspronkelijk voor bedoeld waren
In zijn boek User Story Mapping beschreef Jeff Patton beknopt waarom user stories zo heten:
Stories ontlenen hun naam aan de manier waarop ze gebruikt moeten worden, niet aan wat er geschreven moet worden.
-JEFF PATTON, USER STORY MAPPING
Jeff bouwt vervolgens voort op die gedachte met een citaat van Kent Beck, die het concept van user stories ontwikkelde.
"Als we bij elkaar komen en praten over het probleem dat we met software oplossen, wie die software zal gebruiken en waarom, kunnen we samen tot een oplossing komen en onderweg een gedeeld begrip opbouwen."
User stories beschrijven wat iemand met je product wil bereiken en waarom.
Er zijn drie belangrijke zaken om te onthouden over user stories. Ze spelen een rol bij de beslissing hoe, of zelfs of, je AI-hulp moet gebruiken om ze te maken.
1. User stories zijn tijdelijke aanduidingen voor een gesprek
Ze moeten dienen als een herinnering die een diepgaandere discussie binnen je productteam op gang brengt over welk probleem je je gebruikers helpt oplossen.
Waarschijnlijk wil je noteren waarover jullie hebben gesproken, maar doe dat als herinnering en naslagwerk, niet als het enige middel om vereisten te communiceren. Hoewel je AI misschien niet gebruikt voor het schrijven van user stories, kan AI nuttig zijn bij het verzamelen van vereisten.
2. User stories zijn een planningshulpmiddel
Ze stellen je in staat het werk om je product te bouwen op te delen op basis van wat je gebruikers ermee kunnen bereiken, in plaats van de taken op te sommen die je moet uitvoeren.
Door je werk op deze manier op te delen, kom je pas bij de details wanneer dat nodig is—niet veel eerder.
User stories helpen je ook om gefocust te blijven op wat je wel en niet in je product zult opnemen, op een manier waarop een takenlijst je daar simpelweg niet bij helpt.
Daarom is het ook niet per se nuttig om een hele reeks user stories te brainstormen die je zou kunnen uitvoeren. Daarover zo meer.
3. Het schrijven zelf is niet belangrijk
Door die eerste twee punten blijkt dat hoe je user stories schrijft eigenlijk helemaal niet zo belangrijk is.
Zoals met veel dingen in het leven kunnen we Seinfeld erbij halen om dit punt te illustreren.
In de aflevering The Alternate Side reserveert Jerry een huurauto, om er vervolgens achter te komen dat ze zijn reservering hadden, maar niet zijn auto. Dit is wat er gebeurde.
Jerry Seinfeld over het reserveren van huurauto's:
"Kijk, je weet hoe je de reservering moet aannemen, maar je weet niet hoe je de reservering moet vasthouden. En dat is toch echt het belangrijkste onderdeel van de reservering: het vasthouden. Iedereen kan ze gewoon aannemen!"
Wanneer je dat parafraseert voor gebruikersverhalen:
Kijk, je weet hoe je het gebruikersverhaal moet schrijven, maar je weet niet hoe je met het gebruikersverhaal een gedeeld begrip opbouwt. En dat is toch echt het belangrijkste onderdeel van het gebruikersverhaal: het gedeelde begrip. Iedereen kan ze gewoon schrijven!
De gebruikersverhalen die je wel en niet schrijft, zijn veel belangrijker dan hoe je ze schrijft.
Zolang je gebruikersverhaal genoeg informatie bevat voor het productteam om zich hun gesprekken te herinneren over wat de gebruiker probeert te bereiken, zou dat voldoende moeten zijn.
Waarom je geen AI moet gebruiken om gebruikersverhalen te schrijven
Met die context over het beoogde gebruik van gebruikersverhalen in gedachten, kunnen we de argumenten voor het gebruik van AI om gebruikersverhalen te schrijven gebruiken om uit te leggen waarom je dat niet zou moeten doen.

Aanname #1: Het is sneller en efficiënter
Tegenwerping: Nou, niet per se.
De meeste artikelen waarin het gebruik van AI bij productontdekking voor het schrijven van gebruikersverhalen wordt geïntroduceerd, impliceren of stellen expliciet dat gebruikersverhalen een noodzakelijk kwaad zijn.
Er wordt geklaagd over hoe lang het duurt om al die gebruikersverhalen te schrijven en ze precies goed te krijgen. Verlangende gedachten zoals: "Konden we die taak maar sneller en efficiënter maken!" Sommigen spreken zelfs de wens uit om het brainstormen over verschillende gebruikersverhalen achterwege te laten.
Wanneer ik deze klachten zie, vraag ik me af of mensen het punt missen. Het noteren van het eerste gebruikersverhaal zou geen zware opgave moeten zijn. Het is een snelle herinnering om meer details uit te werken en de relevante informatie uit dat gesprek te noteren. Het hoeft in het begin niet perfect te zijn.
Een heleboel gebruikersverhalen brainstormen en ze in de productbacklog zetten om ze later af te handelen, is een slechte gewoonte die veel productteams in de loop der jaren hebben aangeleerd.
Een betere aanpak is om te beginnen met een specifieke uitkomst en vervolgens de specifieke verhalen te identificeren die je helpen die uitkomst te bereiken.
Samenwerkingstechnieken zoals impactkaarten en bomen voor kansen en oplossingen helpen je die gebruikersverhalen te identificeren.
Aanname #2: Het is consistent qua opmaak en duidelijkheid
Tegenwerping: Consistentie in de opmaak is in een vroeg stadium niet cruciaal.
Op het eerste gezicht zijn consistente en duidelijke gebruikersverhalen een goede zaak. De vraag die je moet stellen is: is het belangrijk dat gebruikersverhalen een consistente opmaak hebben wanneer je ze voor het eerst maakt, of nadat je productteam de kans heeft gehad ze te bespreken?
Ik stel dat het bewerken op consistentie vlak voordat het team ontwikkelwerk gaat doen belangrijker is dan consistent blijven wanneer je ze voor het eerst opschrijft.
Je gaat het gebruikersverhaal toch bespreken, dus schrijf genoeg om het gesprek op gang te brengen en laat het daarbij.
Als je bang bent dat je niet meer weet wat een kleine zinsnede betekende, is dat waarschijnlijk een teken dat je het gebruikersverhaal te lang van tevoren maakt voordat je ermee aan de slag gaat.
Aanname #3: Het stimuleert creativiteit
Tegenwerping: Het kan je ook verder van het punt af brengen.
Hulpmiddelen op basis van AI beloven je uit een schrijversblok te halen met een reeks vooraf gedefinieerde sjablonen en aanwijzingen voor gebruikersverhalen. Dat is geweldig als je een hele reeks bizarre ideeën wilt genereren.
Maar zoals ik eerder al aangaf, wil je je backlog niet vullen met allerlei ruis in de vorm van gebruikersverhalen. In plaats daarvan wil je je richten op de zaken die je helpen vooruitgang te boeken bij het bereiken van uitkomsten.
De technieken die ik eerder noemde, bieden een geweldige manier om betekenisvolle gebruikersverhalen te identificeren die gericht zijn op het bereiken van resultaten. En vergeet niet dat beperkingen geweldig zijn om creativiteit te stimuleren.
Aanname #4: Het is nauwkeuriger
Tegenwerping: Dit is alleen waar als je AI-tool een zeer uitgebreid inzicht heeft in je product en gebruikers.
Het argument voor nauwkeurigheid stelt dat het genereren van verhalen op basis van grote hoeveelheden gegevens en feedback van klanten leidt tot nauwkeurigere verhalen. De redenering is dat die verhalen meer “accuraat” zijn omdat ze aansluiten bij de behoeften van klanten.
Dit is misschien wel het beste argument om AI te gebruiken, maar het berust op een paar grote “als-en”.
- Je traint je AI-tool met gegevens over je specifieke product.
- Je beschikt over voldoende productgegevens om een effectieve analyse uit te voeren.
De eerste “als” sluit al die “gratis” tools uit die zijn gebouwd op GPT 3, 4, enzovoort.
De tweede als helpt niet echt als je een nieuwe tool bouwt of net begint om op een zinvolle manier feedback van klanten vast te leggen.
Aanname #5: Verbeterde samenwerking
Tegenwerping: Sorry—wat?!
Ja… ik keek twee keer toen ik dit argument zag.
Wil je me vertellen dat het laten genereren van gebruikersverhalen door AI—waarbij wordt gesuggereerd dat ze klaar zijn om naar ontwikkelaars over de muur te worden gegooid zodra ze uit de tool komen—de samenwerking verbetert?
Toen bekeek ik de toelichtingen opnieuw. Daarin worden vooral de samenwerkingsvoordelen van gebruikersverhalen in het algemeen aangeprezen, niet van verhalen die specifiek door AI zijn gemaakt.
Leuke poging, maar ik ben niet overtuigd.
Suggereer je dat ik AI helemaal niet moet gebruiken?
Ik ben geen luddiet.
AI heeft een plaats, zelfs in tools voor productmanagement. Het proberen te automatiseren van activiteiten die samenwerking met je productteam vereisen, is niet die plaats.
Het is logisch om AI te gebruiken om alle feedback van klanten die je hopelijk verzamelt, samen te vatten. Het kan ook nuttig zijn om verschillende testgevallen te genereren, zodat je zeker weet dat je alles volledig afdekt.
Doug Steele behandelde ditzelfde onderwerp op LinkedIn en stelde dat je AI niet moet gebruiken om het schrijven van gebruikersverhalen over te nemen, maar dat je de hulp ervan wel kunt gebruiken om je inspanningen aan te vullen.
Omdat je iets kunt doen, betekent dat nog niet dat je het ook moet doen.
Als het gaat om het schrijven van gebruikersverhalen, of welk mogelijk AI-bedrijfsidee dan ook, moet je AI niet gebruiken om AI te gebruiken. Bepaal waar het gebruik van AI daadwerkelijk waarde toevoegt.
Een goede plek om te beginnen is door de vragen die ik hierboven stelde, aan te passen.
- Waar zou AI zinvol kunnen zijn in je product?
- Waar is het zinvol om AI te gebruiken ter ondersteuning van je productmanagementactiviteiten?
Door de vragen op die manier te stellen, zorg je ervoor dat je AI op verantwoorde wijze gebruikt—om je product te verbeteren en je PM-werk gemakkelijker te maken.
Vergeet niet je te abonneren op onze nieuwsbrief voor meer bronnen en handleidingen over productmanagement, plus de nieuwste podcasts, interviews en andere inzichten van leiders en experts uit de sector.
