Var AI faktiskt passar in i en PM-vecka
Produktledning är fyra olika jobb som delar en kalender. Du läser mycket (feedback, ärenden, transkript, analysexporter), skriver mycket (specifikationer, uppdateringar, brev), analyserar en del (tratt-flöden, kohorter, undersökningsresultat) och övertygar konstant. Vart och ett av dessa gynnar en annan modell, vilket är varför en enda AI-prenumeration täcker ungefär två tredjedelar av arbetet och lämnar resten kämpigt.
| PM-uppgift | Bästa modell | Varför |
|---|---|---|
| PRD-berättelse, problemformuleringar, produktuppdateringar | Claude | Håller ett långt resonemang, skriver prosa en ingenjör faktiskt läser |
| Feedbacktematisering, ärendeklustring, strukturerad extraktion | GPT | Pålitlig med strikta utdataformat och konsekventa kategorietiketter |
| Discovery-research, konkurrentgenomgångar, marknadskontext | Gemini | Bäst på färskt webbmaterial, returnerar källor du kan öppna |
| Långa transkript, researchunderlag, 100-sidiga rapporter | Gemini | 1M tokens kontextfönster, så hela korpusen får plats i en genomgång |
| Specifikationskritik och jakt på specialfall | Vilken modell som helst som inte skrev specifikationen | En oberoende läsare fångar det författaren inte kan |
Inget av detta ersätter omdöme om vad som ska byggas. Det förkortar avståndet mellan att ha underlaget och att ha något skrivet, vilket är där de flesta PM-veckor faktiskt läcker tid. Bytet är billigt också: på Whizi Pro spenderar ett Claude Sonnet 5-meddelande 10 krediter av en månatlig kvot på 2 000 krediter, en GPT-5.6 Luna-extraktion spenderar 1, och Gemini 3.7 Flash läser transkript för 2 krediter per meddelande.
Skriv en PRD som ingenjören inte skickar tillbaka
De flesta AI-skrivna specifikationer misslyckas med samma sak: de beskriver en funktion istället för ett beslut. Ingenjörsteamet behöver inte ett stycke om varför kunden är viktig. Det behöver tillstånden, specialfallen och vad som händer när anropet misslyckas. Efterfråga det explicit och utdatan ändrar karaktär.
Prompt: problemformulering först
Skriv problemformuleringsdelen av en PRD. Bevis jag har: [klistra in supportärenden, analys, intervjucitat]. Föreslå ingen lösning. Returnera: vem har problemet, hur ofta, vad gör de istället idag, vad kostar det dem, och vad skulle vi förvänta oss förändras om det löstes. Markera varje påstående som inte stöds av bevisen jag klistrade in som ANTAGANDE.
Prompt: själva specifikationen
Gör detta till en specifikation för ett ingenjörsteam. Funktion: [beskrivning]. Användartillstånd att täcka: [lista]. Returnera: user stories med acceptanskriterier, varje tillstånd inklusive tomt, laddar, fel och behörighet nekad, beteendet när ett beroende inte är tillgängligt, analyshändelser med sina egenskaper, och öppna frågor. Uppfinn inga krav jag inte angav. Lista allt du fick anta i ett separat avsnitt i slutet.
Prompt: kritikgenomgången
Agera som en senior ingenjör som granskar den här specifikationen innan estimering. Lista bara problemen: odefinierat beteende, saknade tillstånd, krav som motsäger varandra, dolt migreringsarbete, och allt som kommer ge en följdfråga vid genomgång. Skriv inte om specifikationen.
Kör den tredje prompten i en modell som inte skrev specifikationen. Den framkallar konsekvent de tre frågor ditt team annars skulle ta upp vid genomgången, och att besvara dem i förväg är skillnaden mellan en 20 minuters genomgång och en 50 minuters.
Gör rå feedback till något du kan prioritera
Den mest lönsamma AI-uppgiften inom produktledning är inte att skriva. Det är att läsa 400 feedback-bitar i en form du kan agera på. Gjort manuellt är detta en halv dag. Gjort bra med en modell är det 20 minuter, och kvaliteten beror nästan helt på om du tvingar fram stabila kategorier.
Prompt: första genomgång, tematisering
Här är rå kundfeedback. Klustra den i teman. För varje tema returnera: en etikett, antalet poster, allvarlighetsgraden som antyds av språket, ett representativt ordagrant citat kopierat exakt, och om temat är en bugg, en saknad funktion, ett användbarhetsproblem, eller en förväntningsmissmatch. Slå inte ihop teman som har olika grundorsaker även om ordalydelsen liknar. Parafrasera inte citat. Feedback: [klistra in].
Prompt: andra genomgång mot en fast taxonomi
Klassificera samma feedback igen med bara dessa kategorier: [klistra in din befintliga taxonomi]. Allt som inte passar går till OKLASSIFICERAT med en förklaring. Returnera en tabell med kategori, antal och procent.
Strukturen med två genomgångar spelar roll. Den första genomgången visar vad som faktiskt finns i datan. Den andra gör resultatet jämförbart med förra kvartalet, vilket är det som gör det användbart i ett prioriteringssamtal snarare än bara intressant.
| Vad att efterfråga | Vad du får | Vad det är bra för |
|---|---|---|
| Teman med antal | En rangordnad lista över problemområden | Roadmap-underlag, kvartalsplanering |
| Endast ordagranta citat | Oredigerat kundspråk | Copy, positionering, övertygande ledningen |
| Uppdelning på allvarlighet och frekvens | En 2x2 av smärta mot volym | Bestämma vad som ska fixas först |
| Motsägelser | Var segment vill motsatta saker | Fånga en falsk konsensus tidigt |
Den sista raden är värd en stående prompt: Var i den här feedbacken vill olika användare oförenliga saker? Namnge segmenten och avvägningen. En temalista jämnar ut oenighet, och oenighet är oftast det mest användbara i datan.
Discovery, konkurrenter och den research du aldrig har tid för
Discovery är arbetet som skärs bort först när en release är sen, vilket är precis när ett dåligt beslut är dyrast. Modellassisterad genomsökning ersätter inte att prata med kunder, men den ersätter ursäkten för att gå in i ett beslut blint.
Prompt: konkurrentgenomlysning
Bygg en genomlysning av hur [konkurrent] hanterar [jobb som ska utföras]. Täck: deras uttalade positionering i deras egna ord, flödet som dokumenterat i deras hjälpcenter, prissättning där det är offentligt, vad som ändrades de senaste 12 månaderna med datum, och klagomålsteman synliga i offentliga recensioner. Ange en URL för varje påstående. Skilj vad företaget uttalar från vad tredje part observerar.
Prompt: intervjusyntes
Läs dessa intervjutranskript. Returnera: jobben användare försöker utföra, lösningarna de har byggt, ögonblicken där de uttryckte frustration med exakta citat, och alla platser där vad en användare sa motsäger vad de beskrev att de gjorde. Generalisera inte bortom transkripten. Om ett mönster förekommer i färre än tre intervjuer, markera det som en enstaka observation snarare än ett mönster.
Den sista begränsningen är den PM:er oftast glömmer. Modeller är ivriga att producera rena mönster, och ett rent mönster från två intervjuer är hur en roadmap slutar betjäna en kund som inte existerar. Efterfråga antal tillsammans med varje påstående.
Ledningsberättelse och lanseringskommunikation
Samma innehåll måste existera på fyra höjder: en specifikation för ingenjörer, en uppdatering för teamet, ett stycke för ledningsgenomgången, och en lanseringsnotis för kunder. Att skriva om mellan höjder är det mest mekaniska arbetet i jobbet och det lättaste att delegera.
Prompt: höjdändring
Skriv om detta för [målgrupp]. De bryr sig om [specifika farhågor]. De har [nivå] kontext på detta produktområde. Håll varje sakpåstående identiskt. Längd: [begränsning]. Börja med beslutet eller utfallet, inte bakgrunden. Utkast: [klistra in].
Prompt: ledningsstycket
Komprimera den här uppdateringen till 120 ord för en chef som kommer läsa den en gång. Struktur: vad ändrades, vad det betyder för måttet vi åtagit oss till, vad vi behöver från dem, och den enda risken värd deras uppmärksamhet. Inga adjektiv som inte är mätta.
Prompt: förhandsobduktionen
Antag att denna lansering misslyckades sex månader från nu. Skriv de tre mest troliga förklaringarna, rangordnade efter sannolikhet, med endast det som finns i planen nedan. För varje, ange den tidiga signalen vi kunde bevaka. Plan: [klistra in].
Håll alla fyra höjder i samma Whizi-tråd. Lanseringsnotisen ärver kontexten från specifikationen och feedbackanalysen, så du slutar förklara funktionen på nytt varje gång du byter målgrupp.
Var AI vilseleder produktchefer specifikt
Tre felmönster spelar större roll i detta jobb än i de flesta andra.
Fabricerade ordagranna citat. Om du ber om representativa citat utan att förankra modellen i källtexten får du ibland en trovärdig mening ingen kund sa. Instruera alltid kopiera citat exakt, parafrasera inte, och stickprovskontrollera tre av dem mot rådatan innan något citat når en bild.
Falsk trygghet från små urval. En modell kommer tematisera åtta supportärenden med exakt samma säkerhet den tematiserar åtta hundra. Efterfråga antal på varje tema, och behandla allt under en handfull instanser som en observation snarare än en signal.
Roadmap-teater. Att be en modell prioritera din backlog ger en säker rangordning härledd från inget annat än orden i dina ärenden. Den har ingen tillgång till din strategi, din kapacitet, din tekniska skuld, eller affären som stänger nästa kvartal. Använd den för att strukturera avvägningen, aldrig för att fatta beslutet.
- Spara en PRD-promptmall i Claude och en kritikprompt att köra i en annan modell
- Spara en feedbacktematiseringsmall i GPT med din befintliga taxonomi inklistrad
- Spara en konkurrentgenomgångsmall i Gemini som kräver en URL för varje påstående
- Efterfråga alltid antal tillsammans med teman, och behandla små antal som observationer
- Instruera modellen att kopiera ordagranna citat exakt, kontrollera sedan tre stickprov mot källan
- Kör en förhandsobduktion på varje lanseringsplan före lanseringsgenomgången, inte efter
- Håll specifikation, feedback och lanseringskommunikation i en tråd så kontexten följer med
Vanliga frågor
Kan jag klistra in kundintervjuer?
Ja. För långa transkript, använd Gemini: dess kontextfönster på 1M tokens rymmer ungefär 2 000 sidor text, så en hel uppsättning intervjuer får plats i en genomgång istället för att delas upp. Ta bort namn, e-post och företagsidentifierare först. Roller och segment är allt analysen behöver, och att ta bort resten håller dig utanför de flesta interna datapolicyer.
Integrerar Whizi med Jira eller Linear?
Inte inbyggt ännu. I praktiken är arbetsflödet att generera den strukturerade utdatan i Whizi (user stories med acceptanskriterier, en tabell över teman med antal) och klistra in den i ditt system, vilket tar sekunder eftersom formatet redan är vad systemet förväntar sig. Be om utdatan som en Markdown-tabell eller som ett ärende per block om du vill klistra in dem individuellt.
Vilken modell skriver den bästa PRD:n?
Claude för berättelsedelarna, det vill säga problemformuleringen, motiveringen, och allt en människa måste övertygas av. GPT för de strukturerade delarna, det vill säga user stories, acceptanskriterier, tillståndstabeller, och definitioner av analyshändelser. Att dela dokumentet mellan de två tar en extra modellbyte och minskar redigeringsgenomgången märkbart.
Är det säkert att klistra in intern roadmap- eller intäktsdata?
Whizi tränar inte på dina konversationer, och varje leverantörs datapolicy finns tillgänglig innan du aktiverar den modellen. Ditt företags policy är oftast den strängare begränsningen. En pålitlig vana är att indexera känsliga siffror istället för att klistra in absoluta tal, eftersom analys av relativ rörelse fungerar identiskt och siffrorna slutar vara känsliga.
Kan AI prioritera min backlog?
Den kan strukturera avvägningen, vilket är genuint användbart: poängsätta punkter mot kriterier du definierar, framhäva var två punkter är beroende av varandra, och visa vilka segment ett givet val betjänar. Den kan inte fatta beslutet, eftersom den saknar insyn i din strategi, din teamkapacitet, eller det kommersiella sammanhanget. Behandla varje rangordning den producerar som ett underlag för diskussion.