Prompting

Chapter 2 · Phase 1 · practice in Week 2 and Week 3

1. Anatomy of a prompt

Modern LLMs use a chat format with three distinct message roles. Understanding them is the foundation of everything else.

2. Core prompting patterns

Pattern 1 — Role + constraint

Give the model a specific role and explicit boundaries. This is the minimum viable system prompt.

You are a senior TPM reviewing engineering estimates.
Your job: identify unstated assumptions and missing dependencies.
DO NOT provide your own estimate. Ask clarifying questions only.
Respond in bullet points, max 5.

Pattern 2 — Few-shot examples

Show 2–5 examples of input → desired output in the prompt. The model learns the pattern without training.

Classify each support ticket as: billing / technical / feature-request

Ticket: "My invoice shows double charge this month"
Category: billing

Ticket: "The API returns 500 when I POST with a null field"
Category: technical

Ticket: "Can you add dark mode?"
Category: feature-request

Ticket: "I was charged twice for the Pro plan"
Category:

Pattern 3 — Chain-of-thought (CoT)

Ask the model to reason step by step before giving an answer. This dramatically improves accuracy on complex or multi-step tasks.

Analyze this incident and identify the root cause.
Think step by step:
1. What symptoms are described?
2. What is the likely proximate cause?
3. What is the systemic cause?
4. What mitigations would prevent recurrence?

Incident: [paste incident report]

Pattern 4 — Self-critique

After an initial response, ask the model to review its own output for errors, gaps, or risky claims.

# Step 1 — Generate
Generate a go-to-market plan for [product].

# Step 2 — Critique (new message)
Review the plan above. List:
- Any assumptions that need validation
- Any claims that might be factually wrong
- Any risks not mentioned
Be specific.

Pattern 5 — Decomposition

Break a complex task into explicit sub-tasks and ask the model to complete each step before moving to the next.

Task: Write a technical spec for a rate-limiting feature.

Step 1: List all user stories this feature must satisfy.
Step 2: Define the data model needed.
Step 3: Define the API contract.
Step 4: Identify failure modes and mitigations.

Complete Step 1 first, then wait for my confirmation before Step 2.

Pattern 6 — Constrained output format

Specify the exact output structure (JSON, YAML, a table, specific headings). This is essential for production systems that parse the response programmatically.

Return your analysis as JSON with this schema:
{
  "severity": "P0" | "P1" | "P2" | "P3",
  "category": string,
  "summary": string (max 50 chars),
  "recommended_action": string,
  "confidence": 0.0–1.0
}
Return only the JSON. No explanation text.

3. Evaluations (evals) — design before you write prompts

An eval is a test suite for a prompt. Before writing a single line of prompt text, define what "good" looks like and how you will measure it. This is the PM's highest-leverage contribution to an AI feature.

Types of evals

4. Function calling (tool use)

Modern LLMs can decide to call external functions and use their results before generating a response. This is how you ground a model in live data without RAG.

Functions are defined as JSON schemas passed to the API. The model does not execute code — it generates a structured call that your application executes.

tools = [{
  "type": "function",
  "function": {
    "name": "get_incident",
    "description": "Fetch live incident status from PagerDuty",
    "parameters": {
      "type": "object",
      "properties": {
        "id": {"type": "string", "description": "Incident ID, e.g. INC-4821"}
      },
      "required": ["id"]
    }
  }
}]

5. Prompt versioning and governance

Production prompts are code. A prompt change can break features just as badly as a code change.