Hvor AI faktisk passer inn i en produktleders uke
Produktledelse er fire forskjellige jobber som deler én kalender. Du leser mye (tilbakemeldinger, saker, transkripsjoner, analyseeksporter), skriver mye (spesifikasjoner, statusoppdateringer, brief), analyserer litt (traktanalyser, kohorter, undersøkelsesresultater), og overtaler hele tiden. Hver av disse belønner en annen modell, som er grunnen til at et enkelt AI-abonnement dekker rundt to tredjedeler av arbeidet og lar resten kjennes som en kamp.
| Oppgave | Beste modell | Hvorfor |
|---|---|---|
| PRD-narrativ, problembeskrivelser, produktoppdateringer | Claude | Holder en lang argumentasjon, skriver tekst en utvikler faktisk vil lese |
| Temaanalyse av tilbakemeldinger, klynging av saker, strukturert ekstraksjon | GPT | Pålitelig på strenge outputformater og konsistente kategorietiketter |
| Discovery-research, konkurrentskanning, markedskontekst | Gemini | Best på nyere webmateriale, returnerer kilder du kan åpne |
| Lange transkripsjoner, researchpresentasjoner, 100-siders rapporter | Gemini | 1M tokens kontekstvindu, så hele korpuset passer i én omgang |
| Kritikk av spesifikasjon og jakt på grensetilfeller | Hvilken som helst modell som ikke skrev spesifikasjonen | En uavhengig leser fanger det forfatteren ikke kan |
Ingenting av dette erstatter vurderingen av hva som skal bygges. Det komprimerer avstanden mellom å ha innspillene og å ha noe skrevet ned, som er der de fleste produktleder-uker faktisk lekker tid. Byttet er billig også: på Whizi Pro bruker en melding til Claude Sonnet 5 10 kreditter av en månedlig kvote på 2000, en ekstraksjon med GPT-5.6 Luna bruker 1, og Gemini 3.7 Flash leser transkripsjoner for 2 kreditter per melding.
Å skrive en PRD en utvikler ikke sender tilbake
De fleste AI-skrevne spesifikasjoner mislykkes på samme ting: de beskriver en funksjon i stedet for en beslutning. Utviklingsteamet trenger ikke et avsnitt om hvorfor kunden er viktig. Det trenger tilstandene, grensetilfellene og hva som skjer når kallet mislykkes. Be om det eksplisitt, og resultatet endrer karakter.
Prompt: problembeskrivelsen først
Skriv problembeskrivelsesdelen av en PRD. Bevis jeg har: [lim inn supportsaker, analyser, intervjusitater]. Foreslå ingen løsning. Returner: hvem har problemet, hvor ofte, hva de gjør i stedet i dag, hva det koster dem, og hva vi ville forventet å endres hvis det ble løst. Marker enhver påstand som ikke er støttet av bevisene jeg limte inn, som ANTAKELSE.
Prompt: selve spesifikasjonen
Gjør dette til en spesifikasjon for et utviklingsteam. Funksjon: [beskrivelse]. Brukertilstander å dekke: [liste]. Returner: brukerhistorier med akseptansekriterier, alle tilstander inkludert tom, lasting, feil og avvist tillatelse, oppførselen når en avhengighet er utilgjengelig, analytics-hendelser med egenskapene deres, og åpne spørsmål. Finn ikke opp krav jeg ikke har oppgitt. List opp alt du måtte anta i en egen del til slutt.
Prompt: kritikkrunden
Opptre som en senior utvikler som gjennomgår denne spesifikasjonen før estimering. List bare problemene: udefinert oppførsel, manglende tilstander, krav som er i konflikt, skjult migreringsarbeid, og alt som vil skape et oppfølgingsspørsmål i finpussingen. Skriv ikke om spesifikasjonen.
Kjør den tredje prompten i en modell som ikke skrev spesifikasjonen. Den avdekker konsekvent de tre spørsmålene teamet ditt ellers ville tatt opp i finpussingen, og å svare på dem i forkant er forskjellen mellom et 20-minutters og et 50-minutters gjennomgangsmøte.
Å gjøre rå tilbakemeldinger til noe du kan prioritere
Den AI-oppgaven med høyest gevinst i produktledelse er ikke skriving. Det er å lese 400 tilbakemeldinger i en form du kan handle på. Gjort manuelt er dette en halv dag. Gjort godt med en modell er det 20 minutter, og kvaliteten avhenger nesten helt av om du tvinger stabile kategorier.
Prompt: første temarunde
Her er rå kundetilbakemeldinger. Klynge dem i temaer. For hvert tema, returner: en etikett, antall elementer, alvorlighetsgraden underforstått av språket, et representativt sitat kopiert ordrett, og om temaet er en feil, en mangel på funksjonalitet, et brukervennlighetsproblem, eller et forventningsmisforhold. Slå ikke sammen temaer som har forskjellige grunnårsaker selv om ordlyden er lik. Omskriv ikke sitater. Tilbakemeldinger: [lim inn].
Prompt: andre runde mot en fastsatt taksonomi
Klassifiser samme tilbakemeldinger på nytt med bare disse kategoriene: [lim inn din eksisterende taksonomi]. Alt som ikke passer, går inn i UKLASSIFISERT med en forklaring. Returner en tabell med kategori, antall og prosentandel.
Den to-trinns strukturen er viktig. Den første runden viser deg hva som faktisk er i dataene. Den andre gjør resultatet sammenlignbart med forrige kvartal, som er det som gjør det brukbart i en prioriteringssamtale i stedet for bare interessant.
| Hva du skal be om | Hva du får | Hva det er godt for |
|---|---|---|
| Temaer med antall | En rangert liste over problemområder | Innspill til veikart, kvartalsplanlegging |
| Kun ordrette sitater | Uredigert kundespråk | Tekst, posisjonering, ledelsesovertalelse |
| Fordeling av alvorlighet og frekvens | En 2x2 av smerte mot volum | Å avgjøre hva som skal fikses først |
| Motsetninger | Hvor segmenter vil ha motsatte ting | Å fange en falsk konsensus tidlig |
Den siste raden er verdt en fast prompt: Hvor i disse tilbakemeldingene vil forskjellige brukere ha uforenlige ting? Navngi segmentene og avveiningen. En temaliste flater ut uenighet, og uenighet er ofte det mest nyttige i dataene.
Discovery, konkurrenter og researchen du aldri har tid til
Discovery er arbeidet som kuttes først når en lansering er sent ute, som er nøyaktig når en dårlig beslutning er dyrest. Modellassistert skanning erstatter ikke å snakke med kunder, men den fjerner unnskyldningen for å gå inn i en beslutning blind.
Prompt: konkurrentgjennomgang
Bygg en gjennomgang av hvordan [konkurrent] håndterer [jobb som skal utføres]. Dekk: deres uttalte posisjonering i egne ord, flyten som dokumentert i hjelpesenteret deres, priser der de er offentlige, hva som endret seg de siste 12 månedene med datoer, og klagetemaene synlige i offentlige anmeldelser. Referer hver påstand med en URL. Skill hva bedriften uttaler fra hva tredjeparter observerer.
Prompt: intervjusyntese
Les disse intervjutranskripsjonene. Returner: jobbene brukerne forsøker å utføre, løsningene de har bygget, øyeblikkene der de uttrykte frustrasjon med eksakte sitater, og steder hvor det en bruker sa er i konflikt med det de beskrev at de gjorde. Generaliser ikke utover transkripsjonene. Hvis et mønster forekommer i færre enn tre intervjuer, merk det som en enkeltobservasjon snarere enn et mønster.
Den siste begrensningen er den produktledere oftest glemmer. Modeller er ivrige etter å produsere rene mønstre, og et rent mønster fra to intervjuer er hvordan et veikart ender opp med å betjene en kunde som ikke eksisterer. Be om antall sammen med hver påstand.
Lederkommunikasjon og lanseringskommunikasjon
Det samme innholdet må finnes på fire høyder: en spesifikasjon for utviklingsteamet, en statusoppdatering for teamet, et avsnitt for ledelsesgjennomgangen, og en lanseringsmelding for kunder. Å skrive om mellom høyder er det mest mekaniske arbeidet i jobben og det enkleste å delegere.
Prompt: høydeendring
Skriv dette om for [målgruppe]. De bryr seg om [spesifikke bekymringer]. De har [nivå] kontekst på dette produktområdet. Hold hver faktapåstand identisk. Lengde: [begrensning]. Start med beslutningen eller utfallet, ikke bakgrunnen. Utkast: [lim inn].
Prompt: ledelsesavsnittet
Komprimer denne statusoppdateringen til 120 ord for en leder som vil lese den én gang. Struktur: hva som endret seg, hva det betyr for målet vi har forpliktet oss til, hva vi trenger fra dem, og den ene risikoen som er verdt deres oppmerksomhet. Ingen adjektiver som ikke er målt.
Prompt: forhåndsobduksjonen
Anta at denne lanseringen mislyktes seks måneder fra nå. Skriv de tre mest sannsynlige forklaringene, rangert etter sannsynlighet, ved å bruke bare det som er i planen under. For hver, angi det tidlige signalet vi kunne se etter. Plan: [lim inn].
Hold alle fire høyder i samme Whizi-tråd. Lanseringsmeldingen arver konteksten fra spesifikasjonen og tilbakemeldingsanalysen, så du slutter å forklare funksjonen på nytt hver gang du endrer målgruppe.
Hvor AI vilseleder produktledere spesifikt
Tre feilmoduser betyr mer i denne jobben enn i de fleste andre.
Oppspinnede ordrette sitater. Hvis du ber om representative sitater uten å binde modellen til kildeteksten, vil du noen ganger få en plausibel setning ingen kunde faktisk sa. Instruer alltid kopier sitater ordrett, omskriv ikke, og stikkontroller tre av dem mot rådataene før noe sitat kommer på en lysbilde.
Falsk trygghet fra små utvalg. En modell vil tematisere åtte supportsaker med nøyaktig samme sikkerhet som den tematiserer åtte hundre. Be om antall på hvert tema, og behandle alt under et titall forekomster som en observasjon snarere enn et signal.
Veikart-teater. Å be en modell prioritere backloggen din produserer en trygg rangering utledet av ingenting annet enn ordene i sakene dine. Den har ingen tilgang til strategien din, kapasiteten din, den tekniske skulden din, eller avtalen som lukkes neste kvartal. Bruk den til å strukturere avveiningen, aldri til å ta beslutningen.
- Lagre en PRD-promptmal i Claude og en kritikkprompt å kjøre i en annen modell
- Lagre en mal for temaanalyse av tilbakemeldinger i GPT med din eksisterende taksonomi limt inn
- Lagre en mal for konkurrentskanning i Gemini som krever en URL for hver påstand
- Be alltid om antall sammen med temaer, og behandle lave antall som observasjoner
- Instruer modellen til å kopiere ordrette sitater eksakt, deretter stikkontroller tre mot kilden
- Kjør en forhåndsobduksjon på hver lanseringsplan før lanseringsgjennomgangen, ikke etter
- Hold spesifikasjon, tilbakemeldinger og lanseringskommunikasjon i én tråd så konteksten følger med
Vanlige spørsmål
Kan jeg lime inn kundeintervjuer?
Ja. For lange transkripsjoner, bruk Gemini: kontekstvinduet på 1M tokens holder rundt 2000 sider tekst, så et fullt sett med intervjuer passer i én omgang i stedet for å bli delt opp. Fjern navn, e-poster og bedriftsidentifikatorer først. Roller og segmenter er alt analysen trenger, og å fjerne resten holder deg klar av de fleste interne dataregler.
Integrerer Whizi med Jira eller Linear?
Ikke direkte ennå. I praksis er arbeidsflyten å generere den strukturerte outputen i Whizi (brukerhistorier med akseptansekriterier, en tabell med temaer og antall) og lime det inn i sporingsverktøyet ditt, noe som tar sekunder fordi formatet allerede er det sporingsverktøyet forventer. Be om outputen som en Markdown-tabell eller som én sak per blokk hvis du vil lime dem inn individuelt.
Hvilken modell skriver den beste PRD-en?
Claude for narrative deler, det vil si problembeskrivelsen, resonnementet, og alt et menneske må overbevises om. GPT for strukturerte deler, det vil si brukerhistorier, akseptansekriterier, tilstandstabeller og definisjoner av analytics-hendelser. Å dele dokumentet mellom de to tar én ekstra modellbytte og reduserer redigeringsrunden merkbart.
Er det trygt å lime inn interne veikart- eller omsetningsdata?
Whizi trener ikke på samtalene dine, og hver leverandørs datapolicy er tilgjengelig før du aktiverer den modellen. Bedriftens policy er vanligvis den strengeste begrensningen. En pålitelig vane er å indeksere sensitive tall i stedet for å lime inn absolutter, siden analyse av relativ bevegelse fungerer identisk, og tallene stopper å være sensitive.
Kan AI prioritere backloggen min?
Den kan strukturere avveiningen, som er genuint nyttig: score elementer mot kriterier du definerer, synliggjøre hvor to elementer er avhengige av hverandre, og vise hvilke segmenter et gitt valg betjener. Den kan ikke ta beslutningen, fordi den ikke har innsyn i strategien din, teamets kapasitet, eller den kommersielle konteksten. Behandle enhver rangering den produserer som et utgangspunkt for diskusjon.