Phase 4: Writing AI Product Requirements · 40 min · Markdown · Python

Prompt Specs & Prompt-as-Interface

The prompt is the interface. Treat a silent prompt edit like you'd treat a silent API contract change.

Hiring signal: Interview loops test 'how you partner with data science across the model lifecycle,' and the prompt is the single highest-frequency handoff point between PM intent and engineering implementation in an LLM feature. A PM who can produce a versioned prompt spec — not just 'make it sound friendlier' feedback in Slack — demonstrates the same rigor traditional PMs bring to API contracts, applied to the interface that actually matters in a generative feature.

What you will learn

Explain why the prompt should be treated as a PM-owned product artifact, not an engineering implementation detail
Write a prompt spec that separates PM-owned intent (goals, constraints, tone, examples) from engineering-owned implementation (exact tokens, system message structure)
Design a prompt versioning scheme that ties each version to a specific eval result
Produce a versioned prompt spec and changelog for a real AI feature

The Problem

A PM tells an engineer in a Slack message: "Can you make the AI customer-support responses sound a bit more empathetic? Some users are saying it feels robotic." The engineer tweaks the system prompt, ships it the same afternoon, and moves to the next ticket. Two weeks later, refund approval rates have quietly dropped 15%, and nobody connects it to the prompt change — because there's no record that a change happened, what the exact wording change was, or what the prompt looked like before. It takes a data scientist three days of digging through deployment logs to even confirm the prompt was the variable that moved, let alone which specific line caused the effect. A one-line Slack message caused a measurable business outcome and left no auditable trail.

This is the failure mode of treating the prompt as an implementation detail instead of what it actually is: the interface between the product's intent and the model's behavior. Every other interface a PM cares about — an API contract, a UI copy string, a form field's validation rule — gets a spec, a review, and a version history, because everyone understands changing it changes behavior in ways that need to be tracked and testable. A system prompt changes behavior at least as much as any of those, often more, and yet it's routinely treated as a throwaway implementation detail that engineering can tweak informally. Treating the prompt as a first-class, PM-owned product artifact — with the same rigor as any other interface — is one of the concrete ways an AI PM's job differs from a traditional PM's, and it's a skill gap that shows up immediately in how a candidate talks about iterating on a generative feature.

What the PM Owns vs. What Engineering Owns

The PM doesn't write the literal token sequence the model receives — that's an engineering implementation concern, involving exact system-message formatting, few-shot example selection, and provider-specific syntax. What the PM does own is the prompt spec: the goal the prompt is meant to achieve, the constraints and tone it must respect, the specific behaviors it must produce or avoid (tying directly back to the acceptance criteria and guardrails from Lesson 2), and a small set of worked examples showing desired input/output pairs. Engineering translates that spec into the actual prompt implementation, and — critically — any translation choice that changes behavior in a way the spec didn't anticipate should trigger a conversation back to the PM, not a silent judgment call. This is the same division of labor as a traditional PRD and its engineering implementation: the PM specifies desired behavior, engineering decides how to achieve it technically, and anything that reinterprets the spec's intent gets flagged rather than assumed.

A prompt spec answers "what would I tell a new, very literal-minded employee on their first day," not "what exact words go in the system prompt"
If your prompt spec reads like a finished system prompt (full of exact phrasing, formatting instructions, and prompt-engineering idioms), you've written the implementation, not the spec — and you've taken over engineering's job while leaving out the actual PM job, which is being unambiguous about the goal, the tone, the hard constraints, and 3-5 worked examples of what right and wrong look like. A good test: could two different engineers, working independently from your spec, arrive at differently-worded but behaviorally equivalent prompts? If yes, you wrote a spec. If they'd have to guess your intent because you buried it in specific wording choices, you wrote an implementation and called it a spec.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Prompt Versioning as a Product Artifact, Handoff Without Losing the Thread, 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.

Key terms in this lesson

Prompt Engineering