De AI werkruimte voor productmanagers: specs, onderzoek en verhaal in één tool

Waar AI echt past in een PM-week

Productmanagement is vier verschillende banen die één agenda delen. Je leest veel (feedback, tickets, transcripten, analytics-exports), schrijft veel (specs, updates, briefings), analyseert een beetje (funnels, cohorten, enquêteresultaten), en overtuigt voortdurend. Elk van die dingen beloont een ander model, wat verklaart waarom één AI-abonnement ongeveer tweederde van het werk dekt en de rest aanvoelt als een gevecht.

PM-taak	Beste model	Waarom
PRD-verhaal, probleemstellingen, productupdates	Claude	Houdt een lang betoog vast, schrijft proza dat een engineer daadwerkelijk leest
Feedbackthematisering, ticketclustering, gestructureerde extractie	GPT	Betrouwbaar bij strikte outputformaten en consistente categorielabels
Discoveryonderzoek, concurrentiescans, marktcontext	Gemini	Beste bij recent webmateriaal, geeft bronnen die je kunt openen
Lange transcripten, onderzoeksrapporten, rapporten van 100 pagina's	Gemini	1M-token contextvenster, dus het hele corpus past in één keer
Spec-kritiek en het opsporen van edge cases	Elk model dat de spec niet heeft geschreven	Een onafhankelijke lezer ziet wat de auteur niet ziet

Niets hiervan vervangt het oordeel over wat je moet bouwen. Het verkleint de afstand tussen het hebben van de input en het hebben van iets op papier, en dat is waar de meeste PM-weken daadwerkelijk tijd verliezen. Ook het wisselen is goedkoop: op Whizi Pro kost een bericht van Claude Sonnet 5 10 credits van een maandelijks tegoed van 2,000 credits, kost een GPT-5.6 Luna-extractie 1 credit, en leest Gemini 3.7 Flash transcripten voor 2 credits per bericht.

Een PRD schrijven die een engineer niet terugstuurt

De meeste door AI geschreven specs falen op hetzelfde punt: ze beschrijven een functie in plaats van een beslissing. Engineering heeft geen paragraaf nodig over waarom de klant belangrijk is. Het heeft de statussen nodig, de edge cases, en wat er gebeurt als de aanroep mislukt. Vraag daar expliciet om en de output verandert van karakter.

Prompt: eerst de probleemstelling

Schrijf de probleemstellingsectie van een PRD. Bewijs dat ik heb: [plak supporttickets, analytics, interviewcitaten]. Stel geen oplossing voor. Geef terug: wie heeft het probleem, hoe vaak, wat doen ze nu in plaats daarvan, wat kost het hen, en wat zouden we verwachten dat verandert als het is opgelost. Markeer elke claim die niet wordt ondersteund door het bewijs dat ik heb geplakt als ASSUMPTION.

Prompt: het speclichaam

Zet dit om in een specificatie voor een engineeringteam. Functie: [beschrijving]. Te dekken gebruikersstatussen: [lijst]. Geef terug: user stories met acceptatiecriteria, elke status inclusief leeg, laden, fout en toegang geweigerd, het gedrag wanneer een afhankelijkheid niet beschikbaar is, analyticsgebeurtenissen met hun eigenschappen, en open vragen. Verzin geen vereisten die ik niet heb genoemd. Vermeld alles wat je hebt moeten aannemen in een apart gedeelte aan het einde.

Prompt: de kritiekronde

Handel als een staff engineer die deze spec beoordeelt vóór de schatting. Vermeld alleen de problemen: ongedefinieerd gedrag, ontbrekende statussen, tegenstrijdige vereisten, verborgen migratiewerk, en alles wat een vervolgvraag zal opleveren tijdens de refinement. Herschrijf de spec niet.

Voer die derde prompt uit in een model dat de spec niet heeft geschreven. Het brengt betrouwbaar de drie vragen naar boven die je team anders tijdens de refinement zou stellen, en die vooraf beantwoorden is het verschil tussen een groomingsessie van 20 minuten en een van 50 minuten.

Ruwe feedback omzetten in iets waarop je kunt prioriteren

De AI-taak met het hoogste rendement in productmanagement is niet schrijven. Het is het lezen van 400 stukjes feedback in een vorm waarop je kunt handelen. Handmatig gedaan is dit een halve dag. Goed gedaan met een model is het 20 minuten, en de kwaliteit hangt bijna volledig af van of je stabiele categorieën afdwingt.

Prompt: eerste ronde thematisering

Hier is ruwe klantfeedback. Cluster het in thema's. Geef voor elk thema terug: een label, het aantal items, de ernst die de taal impliceert, een representatief letterlijk citaat exact gekopieerd, en of het thema een bug is, een ontbrekende functionaliteit, een bruikbaarheidsprobleem of een verwachtingsmismatch. Voeg geen thema's samen die verschillende hoofdoorzaken hebben, zelfs als de bewoordingen vergelijkbaar zijn. Parafraseer geen citaten. Feedback: [plak].

Prompt: tweede ronde tegen een vaste taxonomie

Herclassificeer dezelfde feedback met alleen deze categorieën: [plak je bestaande taxonomie]. Alles wat niet past gaat naar UNCLASSIFIED met een uitleg. Geef een tabel terug met categorie, aantal en percentage.

De structuur met twee rondes is belangrijk. De eerste ronde vertelt je wat er daadwerkelijk in de data zit. De tweede maakt het resultaat vergelijkbaar met vorig kwartaal, en dat is wat het bruikbaar maakt in een prioriteringsgesprek in plaats van alleen interessant.

Wat je moet vragen	Wat je krijgt	Waar het goed voor is
Thema's met aantallen	Een gerangschikte lijst met probleemgebieden	Roadmapinput, kwartaalplanning
Alleen letterlijke citaten	Onbewerkte klanttaal	Copy, positionering, overtuiging van de directie
Verdeling van ernst en frequentie	Een 2x2 van pijn tegenover volume	Bepalen wat je eerst oplost
Tegenstrijdigheden	Waar segmenten tegengestelde dingen willen	Vroeg een vals consensus opsporen

Die laatste rij is een vaste prompt waard: Waar in deze feedback willen verschillende gebruikers onverenigbare dingen? Benoem de segmenten en de afweging. Een themalijst vlakt onenigheid af, en onenigheid is meestal het nuttigste in de data.

Discovery, concurrenten en het onderzoek waar je nooit tijd voor hebt

Discovery is het werk dat als eerste wordt geschrapt wanneer een release te laat is, en dat is precies wanneer een slechte beslissing het duurst is. Door modellen ondersteunde scans vervangen geen gesprekken met klanten, maar ze vervangen wel het excuus om blind een beslissing in te gaan.

Prompt: concurrentieanalyse

Bouw een analyse van hoe [concurrent] omgaat met [taak die moet worden uitgevoerd]. Behandel: hun eigen positionering in hun eigen woorden, de flow zoals gedocumenteerd in hun helpcentrum, prijzen waar die openbaar zijn, wat er in de afgelopen 12 maanden is veranderd met data, en de klachtthema's die zichtbaar zijn in openbare reviews. Citeer elke claim met een URL. Scheid wat het bedrijf stelt van wat derden waarnemen.

Prompt: interviewsynthese

Lees deze interviewtranscripten. Geef terug: de taken die gebruikers proberen te volbrengen, de workarounds die ze hebben bedacht, de momenten waarop ze frustratie uitten met exacte citaten, en elke plek waar wat een gebruiker zei tegenspreekt wat ze beschreven te doen. Generaliseer niet verder dan de transcripten. Als een patroon in minder dan drie interviews voorkomt, label het dan als een enkele observatie in plaats van een patroon.

Die laatste beperking is degene die PM's het vaakst vergeten. Modellen produceren graag nette patronen, en een net patroon uit twee interviews is hoe een roadmap uiteindelijk een klant bedient die niet bestaat. Vraag om aantallen naast elke claim.

Directieverhaal en launchcommunicatie

Dezelfde inhoud moet op vier hoogtes bestaan: een spec voor engineering, een update voor het team, een paragraaf voor de directiereview, en een launchbericht voor klanten. Herschrijven tussen hoogtes is het meest mechanische werk in de baan en het makkelijkst om uit te besteden.

Prompt: hoogteverandering

Herschrijf dit voor [doelgroep]. Ze geven om [specifieke zorgen]. Ze hebben [niveau] context over dit productgebied. Houd elke feitelijke claim identiek. Lengte: [beperking]. Begin met de beslissing of uitkomst, niet met de achtergrond. Concept: [plak].

Prompt: de directieparagraaf

Comprimeer deze update tot 120 woorden voor een leidinggevende die het één keer zal lezen. Structuur: wat er is veranderd, wat het betekent voor de metric waar we ons aan hebben verbonden, wat we van hen nodig hebben, en het ene risico dat hun aandacht waard is. Geen bijvoeglijke naamwoorden die niet gemeten zijn.

Prompt: de pre mortem

Ga ervan uit dat deze launch over zes maanden is mislukt. Schrijf de drie meest aannemelijke verklaringen, gerangschikt op waarschijnlijkheid, met gebruik van alleen wat in het onderstaande plan staat. Geef voor elk het vroege signaal aan dat we in de gaten zouden kunnen houden. Plan: [plak].

Houd alle vier hoogtes in dezelfde Whizi-thread. Het launchbericht erft de context van de spec en de feedbackanalyse, zodat je stopt met het steeds opnieuw uitleggen van de functie telkens als je van doelgroep wisselt.

Waar AI productmanagers specifiek misleidt

Drie faalpatronen doen er in deze baan meer toe dan in de meeste andere.

Verzonnen letterlijke citaten. Als je om representatieve citaten vraagt zonder het model aan de brontekst te binden, krijg je soms een aannemelijke zin die geen enkele klant heeft gezegd. Geef altijd de instructie kopieer citaten exact, parafraseer niet, en controleer steekproefsgewijs drie ervan tegen de ruwe data voordat een citaat een slide bereikt.

Vals vertrouwen door kleine steekproeven. Een model themiseert acht supporttickets met exact hetzelfde vertrouwen als achthonderd. Vraag om aantallen bij elk thema, en behandel alles onder een handvol instanties als een observatie in plaats van een signaal.

Roadmaptheater. Als je een model vraagt om je backlog te prioriteren, levert dat een zelfverzekerde rangschikking op die nergens anders vandaan komt dan de woorden in je tickets. Het heeft geen toegang tot je strategie, je capaciteit, je technische schuld, of de deal die volgend kwartaal sluit. Gebruik het om de afweging te structureren, nooit om de beslissing te nemen.