Min MCP-stack
Tips og prompts, der får dine værktøjer til at tale sammen via AI.
TL;DR:
MCP’er er kraftfulde arbejdsværktøjer – især når man får dem til at tale sammen. Jeg bruger dem til at:
Udfordre mine roadmaps
Skabe overblik over bugs
Forstå ændringer i brugeradfærd
Forstå mine egne tanker
MCP (Model Context Protocol) var hypet i 2025. Med god grund.
MCP’er er en måde at connecte systemer via AI.
Tænk på det sådan her: Du giver AI’en adgang til alle mødereferater fra Zoom, Notion-filer, Mixpanel-data, osv. Og derefter kan du få AI til at analysere al dataen på tværs af dine systemer.
Det er vildt! Og det alene har gjort MCP’er til et uundværligt værktøj for mig.
Her er 3 MCP-use cases (og en lille joker)
(Ny til MCP? Her er en 2-minutters guide til at sætte en MCP op.)
Use case 1: Roadmapping
Roadmaps er til for at blive udfordret.
Roadmaps er kommunikationsværktøjer. Hele formålet er at starte en diskussion om prioriteter.
Her er MCP’er voldsomt effektive. For du kan let få AI’en til at trække data fra systemer og bruge det til at udfordre dit roadmap.
Jeg bruger fx følgende MCP’er:
Notion: Hvor roadmappet bor.
Dovetail: Hvor vi samler analyser og transskriptioner af vores user research.
Attention: Hvor vi samler transskriptioner af alle vores salg- og kundeservicekald.
Her er et eksempel på en prompt, hvor jeg bruger user interviews i Dovetail til at syreteste mit roadmap i Notion:
Du skal hjælpe mig med at finde på produktændringer, som ikke lige nu er på vores roadmap, men som vores kunder og markedet efterspørger.
Her er et link til vores roadmap i Notion [LINK]. Du kan tilgå det via Notion MCP’en.
Du skal:
1) Finde alle interviews i Dovetail fra de sidste 30 dage via Dovetail MCP’en
2) Identificere konkrete forslag til produktændringen, som vores kunder har nævnt i de interviews.
3) Identificere 10 forslag til produktændringen, som lige nu ikke figurerer på Notion-roadmappet. Prioriter de forslag der nævnes hyppigst.
4) Beskriv de 10 forslag udførligt samt lav en henvisning til hvilken kunde der efterspørger dem, og hvilket problem de forsøger at løse med produktændringen.Use case 2: Bughåndtering
De værste bugs er dem, du ikke kender.
Uanset hvor ofte du taler med brugere, vil der altid være blinde vinkler. Ting som dine kollegaer i Support kender til, men ikke får eskaleret.
For at fange de små issues bruger jeg typisk:
Intercom: Hvor vi håndterer alle support-henvendelser.
Linear: Hvor vi dokumenterer og planlægger udviklingsopgaver.
Forud for sprintplanlægning bruger jeg ofte en prompt i stil med:
Hjælp mig med at identificere små issues såsom bugs, UX issues eller dårlig copy, jeg lige nu har i mit produkt, men som ikke er på min radar.
Til dette skal du gøre følgende:
1) Lav en liste over alle åbne issues for følgende teams i Linear [INDSÆT TEAM NAMES]
2) Gennemgå alle kundesamtaler i Intercom fra de seneste 14 dage, og identificer eksempler på tekniske bugs og UX issues, der skaber friktion for brugere og eksempler på copy, der forvirrer kunder.
3) Lav en liste over alle issues fra step 2, som er nævnt af kunder, men som lige nu ikke figurerer i listen af åbne issues i Linear fra step 1
4) Prioriter listen du har genereret i step 3 så issues, der bliver nævnt ofte eller som er meget kritiske bliver nævnt først.Use case 3: Produktanalyse
Produktanalyse er ofte et detektivarbejde.
Metrik A falder. Men hvorfor? Hvorfor lige dér? Og hænger det sammen med den feature, du shippede samme uge?
Til den slags spørgsmål bruger jeg typisk:
Her er et eksempel på en prompt, jeg brugte for nyligt:
I Mixpanel kan jeg se at [METRIK] er begyndt at falde ret drastisk omkring [DATO]. Denne metrik måler [METRIKBESKRIVELSE I EN SÆTNING).
Jeg er usikker på, om der er en kausal forbindelse mellem den ændrede adfærd hos kunder og produktændringer vi shippede umiddelbart heromkring.
Du skal derfor:
1) Samle en liste fra GitHub over alle PR’er, der er merget i 7 dage før og 7 dage efter ovennævnte dato.
2) Gennemlæse alle Comments og Conversations på de PR’s du fandt i step 1, og udarbejd en ny liste over de PR’s der potentielt kan have påvirket ovennævnte metrik.
3) Tag derefter listen af PR’s fra step 2 og opsummer file changes i et simpelt, og kortfattet ordvalg.Jokeren: Anders Schäffner MCP
Den sidste er personlig. (Og ja: lidt selvoptaget.)
Jeg har bygget min egen MCP baseret på alle mine posts på Fejl 40. Det betyder, at den fx kan hjælpe med at give feedback på spørgsmål som “Har mit produkt product market-fit?” eller “Hvordan siger jeg nej til en vigtig stakeholder?”
Bevares: Den er nok mest relevant for mig. Men det er pointen.
Det er nemlig overraskende let at vibe code din egen MCP. Hvis du har en stor mængde data liggende, som du gerne vil kunne “sætte i spil” sammen med dine værktøjer, så overvej at bygge din egen.
Min ‘Anders Schäffner MCP’ er open source. Du kan downloade den, hvis du vil have min hjerne til at tale med dine systemer.
(Eller hvis du bare vil snuppe idéen og bygge din egen.)
Med andre ord
MCP’er er kraftfulde arbejdsværktøjer – især når man får dem til at tale sammen. Jeg bruger dem til at:
Udfordre mine roadmaps
Skabe overblik over bugs
Forstå ændringer i brugeradfærd
Forstå mine egne tanker