Understanding LLMs & Choosing Your AI Stack
Before you build anything with AI, you need to understand what you're actually working with. This module covers how large language models work (in plain English), how the major models compare, and the key concepts — projects, skills, MCPs, direct connections — that will shape every decision you make going forward.
Step 1 of 5 · Read the lesson
1. How LLMs actually work (plain English)
A large language model is not a search engine, a database, or a calculator. It's a pattern-completion system trained on an enormous amount of text. Given an input, it predicts the most statistically likely continuation — shaped by billions of parameters learned during training.
What this means practically for a PM:
- It has no memory between conversations unless you give it one
- It doesn't "know" things the way a database does — it has learned patterns and associations
- It can be confidently wrong (hallucination) because it optimises for plausible, not true
- The quality of its output is heavily shaped by the quality and structure of its input
- It reasons better when given time to think (chain-of-thought) vs asked for instant answers
- It has a context window — a limit on how much text it can hold in one conversation
Understanding these properties is what separates someone who gets frustrated with AI from someone who knows how to get consistent, high-quality output.
2. LLM Comparison: Claude vs ChatGPT vs Gemini
| Dimension | Claude (Anthropic) | ChatGPT / GPT-4o (OpenAI) | Gemini (Google) |
|---|---|---|---|
| Best known for | Long-form reasoning, nuanced writing, careful instruction-following | Breadth of capability, largest ecosystem, most integrations | Google Workspace integration, multimodal, search-connected |
| Strengths for PMs | Deep analysis, research synthesis, long documents, structured outputs | Versatility, code gen, image understanding, GPT Store, brainstorming | Real-time web access, native Google Docs/Sheets, data-heavy tasks |
| Weaknesses | No native real-time web in base mode, smaller plugin ecosystem | Can be verbose, over-hedges, cost at scale | Less nuanced on complex reasoning, enterprise privacy concerns |
| Context window | Up to 200K tokens — can process whole documents/codebases | 128K tokens (GPT-4o) | Up to 1M tokens (Gemini 1.5 Pro) |
| Best PM use case | Research synthesis, long briefs, structured analysis, automation prompts | Brainstorming, code, quick tasks, image analysis | Google Workspace workflows, real-time research, Sheets analysis |
| Pricing | Claude Pro $20/mo or API | ChatGPT Plus $20/mo or API | Gemini Advanced $20/mo or API |
Recommendation: For most growth PM workflows — research synthesis, experiment briefs, automation prompts, structured analysis — Claude is the strongest default. For brainstorming and quick tasks, ChatGPT is excellent. For anything living inside Google Workspace, Gemini wins on integration. Most power users have 2–3 and route by strength.
3. Projects vs Skills: What's the difference?
A Project (Claude Projects, ChatGPT Custom GPTs) is a persistent context container. It lets you give the AI a standing system prompt ("You are always working as a growth PM at Mentimeter…"), upload reference docs it can always access, and maintain a consistent role and tone across sessions. Think of a Project as a pre-briefed AI colleague dedicated to a specific area of your work.
Examples for a Growth PM: "Mentimeter Growth" (role, ICP, OKRs, experiment log) · "User Research" (framework, taxonomy) · "Content & Copy" (brand voice, tone examples).
A Skill means different things in different tools — in agent frameworks it's a reusable instruction set, in Microsoft Copilot it's a plugin capability, in general usage it's a saved prompt template. The mental model: Projects are about persistent context. Skills are about reusable actions.
| Project | Skill | |
|---|---|---|
| What it is | Persistent context container | Reusable action / prompt template |
| Sets up | Who AI is, what it knows, how it should behave | What AI should do when triggered |
| Analogy | Onboarding a colleague with full context | Giving that colleague a standard operating procedure |
| PM use case | "Always know I'm a growth PM at Mentimeter" | "When I say 'write a debrief', follow this structure" |
4. Why MCP instead of a direct connection?
Direct API: you call an external service's API directly in your code or n8n flow. Works for simple linear workflows, full control over the call — but every new AI tool needs custom integration code, and there's no standardised way for the AI to discover available tools.
MCP (Model Context Protocol): a standardised protocol (open-sourced by Anthropic, widely adopted) that sits between the AI and your tools. Write the integration once as an MCP server; any MCP-compatible AI client (Claude, Cursor, Windsurf, etc.) can use it. The AI dynamically discovers tools, tools self-describe, and switching models doesn't break integrations.
The key insight: Direct API = you decide when to call the tool. MCP = the AI decides when to call the tool. MCP shifts integration from "developer wiring things together manually" to "AI dynamically using tools as needed." That's the difference between an AI that answers questions and an AI that takes actions in your systems.
| Situation | Use |
|---|---|
| One-off automation, linear flow, existing n8n node | Direct connection / n8n |
| Want any AI to always be able to query your internal data | MCP |
| Building something other tools or teammates will use | MCP (standardised) |
| Prototyping quickly, complexity not justified | Direct API |
| Want AI to autonomously decide when to pull data | MCP |