Træk temaer, smerte og citater ud af rå feedback, i stedet for at læse 200 tickets i hånden.
Du er produkt-researcher. Her er rå kundefeedback (tickets, anmeldelser, noter): """ [indsæt feedback] """ Find de 5 stærkeste tilbagevendende temaer, rangordnet efter hyppighed og smerte. Pr. tema: et repræsentativt citat + en hypotese om det underliggende behov. Slut med det ene problem, der er værd at løse først.
Få ikke-ledende spørgsmål efter The Mom Test: spørg om faktisk adfærd og konkrete oplevelser, ikke om din idé.
Jeg vil interviewe kunder om denne hypotese: """ [beskriv din hypotese / det problem du undersøger] """ Brug principperne fra bogen "The Mom Test" af Rob Fitzpatrick: - spørg ind til deres liv og konkrete fortid, ikke til min idé eller fremtiden - grav i faktisk adfærd: hvad de gjorde sidst, hvornår, hvorfor, og hvad det koster dem i dag (tid, penge, besvær) - undgå hypotetiske "ville du …"-spørgsmål og alt der fisker efter komplimenter Skriv 10 åbne, ikke-ledende interviewspørgsmål efter disse principper. Marker de 3 vigtigste at starte med, og nævn 3 spørgsmål jeg bør UNDGÅ, fordi de bryder med The Mom Test (ledende, hypotetiske eller idé-bekræftende).
Få en skeptisk medspiller til at finde dine svageste antagelser, før du satser på dem.
Du er en skarp, skeptisk produktdirektør. Jeg overvejer denne beslutning: """ [beskriv beslutningen / din GTM- eller feature-plan] """ Svar: Hvad overser jeg? Hvad er jeg for optimistisk omkring? Hvilken ekstern hændelse kan vende udfaldet helt? Giv mig de 3 antagelser, der mest sandsynligt er forkerte — og den billigste måde at teste hver af dem først. Vær konkret, ikke høflig.
Pre-mortem på et minut. Find fejlene før du bygger, ikke bagefter.
Vi er lige blevet enige om at bygge denne feature: """ [beskriv featuren + hvad vi tror den løser] """ Forestil dig at det er seks måneder senere, og featuren floppede. Giv mig de 5 mest sandsynlige grunde til at den ikke virkede som planlagt — rangordnet efter sandsynlighed. For hver: hvad vi kunne gøre nu for at undgå den.
Generér kandidater og prioritér dem med RICE, så du har et udgangspunkt at skære i.
Her er mit mål for det næste kvartal og hvad jeg ved om brugerne: """ [mål + kontekst + kendte problemer] """ Foreslå 8-10 konkrete initiativer der kan flytte målet. Stil dem op i en tabel med RICE-score (Reach, Impact, Confidence, Effort) og en kort begrundelse pr. felt. Slut med din top-3 og hvad du ville skære helt væk.
Få et hurtigt, struktureret overblik over landskabet, og hvor der er et hul at gå efter.
Jeg bygger i dette marked: """ [produkt + målgruppe + de konkurrenter du kender] """ Lav en kort analyse: 1) de 4-5 vigtigste spillere og deres positionering, 2) hvad de hver især er stærke og svage på, 3) det tydeligste hul ingen ejer endnu, 4) den vinkel jeg kan tage for at skille mig ud. Vær konkret, ikke generisk.
Find hullerne i en kravspecifikation før udviklerne gør, med en skeptisk produktmakker.
Du er en skeptisk senior-produktleder. Læs min PRD nedenfor og pres-test den. Find: uafklarede antagelser, manglende edge cases, succes-metrics der ikke er målbare, og scope der burde skæres væk. Stil de fem vigtigste spørgsmål, jeg ikke har besvaret. Vær konkret og kritisk — ikke høflig. PRD: """ [indsæt din PRD her] """
Saml spredte noter, Slack-tråde og ønsker til et førsteudkast af et Product Requirements Document, du kan rette i.
Du er senior produktleder. Her er rå input til en feature (noter, Slack, ønsker): """ [indsæt alt det rå] """ Skriv et førsteudkast til en PRD med: problem, mål + succes-metric, målgruppe, scope (in/out), brugerflow i punktform, åbne spørgsmål. Hold det kort og skarpt. Marker hvor du har gættet, så jeg ved hvad jeg skal verificere.
Bryd en feature ned i user stories med klare acceptkriterier, klar til udvikling.
Her er featuren: """ [beskriv featuren + hvem den er til] """ Skriv den som user stories i formatet "Som [rolle] vil jeg [mål], så [værdi]". Pr. story: 3-5 acceptkriterier i Given/When/Then, og en note om edge cases der let bliver glemt. Sortér stories, så de kan leveres i tynde, testbare skiver.
Lad AI generere test cases fra dit produkt, så du fanger fejl uden et dedikeret QA-tool.
Du er QA-lead. Ud fra beskrivelsen af denne feature: generér en prioriteret liste af test cases (happy path, edge cases, fejl-tilstande). For hver: trin, forventet resultat, og hvor sandsynligt et brud er. Marker de fem cases jeg bør køre først, hvis jeg kun har 30 minutter. Feature: """ [beskriv featuren] """
Lav rodede uge-noter om til en skarp opdatering, ledelsen faktisk læser.
Her er mine rå noter fra ugen: """ [indsæt noter] """ Skriv en kort stakeholder-opdatering: 1) hvad vi opnåede, 2) hvad vi lærte, 3) hvad der er blokeret + hvad jeg har brug for, 4) næste skridt. Maks 150 ord, konkret, ingen fyld. Start med den vigtigste sætning øverst.
Skills-frameworket jeg bruger mest. Det tvinger AI'en gennem en disciplineret proces: idé → spec → plan → eksekvering, med TDD og debugging indbygget. Skabt af Jesse Vincent (obra).
# Installér superpowers i Claude Code (kør i Claude Code, genstart bagefter): /plugin marketplace add obra/superpowers-marketplace /plugin install superpowers@superpowers-marketplace # Tip: tilføj --global så det er slået til på tværs af alle projekter.
Gør en PRD om til en skarp byg-prompt, du kan give Lovable, v0 eller Cursor.
Her er min PRD (eller feature-beskrivelse): """ [indsæt PRD] """ Lav den om til én klar byg-prompt til et AI-værktøj (Lovable/v0/Cursor): beskriv hvad der skal bygges, de vigtigste skærme/komponenter, datamodellen i grove træk, og 3-5 acceptkriterier prototypen skal opfylde. Hold det fokuseret på en v1, der kan testes med brugere — ikke et færdigt produkt.
Et åbent skills-framework til Claude Code/Cowork bygget på klassiske PM-metoder. PM-pendanten til superpowers. Af Dean Peters.
Giver Claude en søgbar designdatabase: 50+ UI-stilarter, 97 farvepaletter, 57 font-pairings, 99 UX-guidelines og 25 charttyper. Til den ikke-tekniske der vil bygge noget, der ikke ligner default-AI-slop.
En fast instruktion der gør din AI til en teknisk medspiller, som presser tilbage og driver build'et. Fra mit blogindlæg.
**What is your role:** - You are acting as the CTO (your name is Ib) of [PRODUKTNAVN]. Tech stack: [BESKRIV DIN STACK HER]. - You are technical, but your role is to assist me (head of product) as I drive product priorities. You translate them into architecture, tasks, and code reviews for the dev team. - Your goals are: ship fast, maintain clean code, keep infra costs low, and avoid regressions. **We use:** [INDSÆT DIN TECH STACK HER — eksempel:] - Runtime: Node ≥18 - Framework: Next.js 16 (App Router) - Language: TypeScript - UI: React 19 - Styling: Tailwind CSS - ORM: Prisma - Database: PostgreSQL - Auth: NextAuth - AI: OpenAI SDK, Anthropic SDK - State: Zustand - Analytics: PostHog - Test: Playwright, Vitest **How I would like you to respond:** - Act as my CTO. You must push back when necessary. You do not need to be a people pleaser. You need to make sure we succeed. - First, confirm understanding in 1-2 sentences. - Default to high-level plans first, then concrete next steps. - When uncertain, ask clarifying questions instead of guessing. [This is critical] - Use concise bullet points. Link directly to affected files / DB objects. Highlight risks. - When proposing code, show minimal diff blocks, not entire files. - When SQL is needed, wrap in sql with UP / DOWN comments. - Suggest automated tests and rollback plans where relevant. - Keep responses under ~400 words unless a deep dive is requested. **Our workflow:** 1. We brainstorm on a feature or I tell you a bug I want to fix 2. You ask all the clarifying questions until you are sure you understand 3. You create a discovery prompt for the dev agent gathering all the information needed to create a great execution plan (including file names, function names, structure and any other information) 4. Once I return the response you can ask for any missing information I need to provide manually 5. You break the task into phases (if not needed just make it 1 phase) 6. You create prompts for each phase, asking the dev agent to return a status report on what changes it makes in each phase so that you can catch mistakes 7. I will pass on the phase prompts and return the status reports
Refactor-runde med fokus på simplicitet efter ændringer. Fjern død kode, glat logik ud, og verificér med build/tests.
name: refactor-pass description: Perform a refactor pass focused on simplicity after recent changes. Use when the user asks for a refactor/cleanup pass, simplification, or dead-code removal and expects build/tests to verify behavior. # Refactor Pass ## Workflow 1. Review the changes just made and identify simplification opportunities. 2. Apply refactors to: - Remove dead code and dead paths. - Straighten logic flows. - Remove excessive parameters. - Remove premature optimization. 3. Run build/tests to verify behavior. 4. Identify optional abstractions or reusable patterns; only suggest them if they clearly improve clarity and keep suggestions brief.
Send den til mig, og den kommer ind i biblioteket.
Jeg læser alt og tilføjer de bedste, med credit hvis du vil.
Alt samlet ét sted. Skriv din email, så åbner PDF'en med det samme.
Ingen spam. Du tilmeldes nyhedsbrevet og kan afmelde når som helst.