Phase 6: Prompt Engineering & GenAI Feature Design · 45 min · System prompts · Few-shot prompting · Prompt versioning

Prompt Engineering Fundamentals for PMs

The first draft of a prompt tells you what you wanted. The fifth draft, written against real failures, tells you what the product actually needs to say.

Hiring signal: An AI PM who has never personally iterated a prompt against a real failure mode is asking data scientists to trust a prompt spec they didn't stress-test themselves. Interviewers testing product-sense and technical-fluency signals routinely ask candidates to walk through improving a bad AI output on the spot -- candidates who can name the specific failure mode and the specific prompt technique that fixes it stand out immediately from ones who only know to say 'iterate more.'

What you will learn

Structure a system prompt with role, task, constraints, and output format as distinct components
Use few-shot examples to correct a specific, observed failure mode rather than guessing at improvements
Diagnose common prompt failure modes (ambiguity, missing constraints, format drift, instruction conflict)
Treat prompt versions as a product artifact with a change log tied to eval deltas from Phase 5

The Problem

A PM specs a prompt for an AI feature that drafts customer-facing email replies: "You are a helpful customer support assistant. Write a reply to this customer email." It works on the three examples the PM tried in a playground. In production, it drifts: some replies are two sentences, some are four paragraphs; some open with "Dear Customer," others with "Hey!"; occasionally it invents a policy detail nobody confirmed. The PM's instinct is to ask engineering to "make it more consistent" — a request with no concrete action behind it. This is the same eval-first gap from Phase 5, but one level earlier: before you can evaluate a prompt's outputs, you have to know how to actually write and iterate one, or every improvement request stays vague forever.

Prompt engineering is not a one-shot writing exercise. It's an iterative loop: write a version, observe specific failures, apply a specific fix targeted at that failure, and re-test — the same before/after eval delta discipline from Phase 5, applied at the prompt-drafting stage instead of the launch-review stage.

Anatomy of a System Prompt

A system prompt that produces consistent behavior separates four things a single vague sentence conflates:

Role — who is the model acting as, and for whom. "You are a customer support assistant for [Product], writing on behalf of the support team" is more constraining, and more useful, than "you are helpful."
Task — the specific action, stated precisely. Not "write a reply" but "draft a reply that addresses the customer's specific question, in 2-4 sentences, matching the tone of the original message."
Constraints — the things the output must never do: never promise a refund or timeline not explicitly confirmed in the provided context, never invent a policy detail, never exceed a stated length.
Output format — the structural shape of the response: plain text, a specific greeting/sign-off convention, a JSON schema if the output feeds a downstream system (Lesson 2 goes deeper on this).

Most prompt drift traces back to one of these four being left implicit. "Make it more consistent" is not actionable; "the task doesn't specify a length constraint, so length varies" is.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Few-Shot Examples: Fixing a Specific Failure, Not Guessing, Common Failure Modes, Named, Prompt Versioning as a Product Artifact, Build It, What to Practice — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.