Prompting For Pms

# Prompting for PMs

Not "10 magic prompts" — how to treat prompts as what they actually are: **product specs for a very literal, very fast contractor.** Everything you know about writing good requirements applies.

## The mental model

A prompt fails for the same reasons a spec fails:
- it assumes context the reader doesn't have,
- it says what to do but not what *not* to do,
- it doesn't define what "done" looks like.

If an offshore agency would misinterpret your spec, a model will misinterpret your prompt — just faster and with more confidence.

## The five-part prompt

Every production prompt should answer five questions. Order matters less than coverage.

### 1. Role — who is the model being?
> "You are a senior support agent for a B2B invoicing product. You are precise, warm, and never promise features or refunds."

Role sets the prior for tone, vocabulary, and judgment. One sentence is usually enough; a paragraph of personality is usually noise.

### 2. Context — what does it need to know?
The model knows nothing about your product, your user, or this conversation unless you tell it. Include: the product, the user's situation, relevant policy, and any retrieved documents. Label the sections (`<policy>`, `<ticket>`) so the model can tell instruction from data — this also blunts prompt injection from user-supplied content.

### 3. Task — what exactly should it do?
One prompt, one job. "Summarize this call *and* draft a follow-up *and* update the CRM fields" is three jobs; split them or expect the weakest one to suffer.

### 4. Constraints — what must never happen?
This is the part PMs are best at and most often skip. Be explicit:
> "If the answer is not in the provided policy, say you don't know and offer to escalate. Never invent policy. Never mention internal tooling."

Constraints are your safety requirements. Write them like you'd write the *non-goals* section of a PRD.

### 5. Output format — what shape is "done"?
Show, don't describe. One worked example of a perfect output beats three paragraphs describing it. If the output feeds another system, specify the schema and add "return only the JSON, no commentary."

## Techniques that actually move quality

- **Few-shot examples.** 2–3 input→output pairs, including one *hard* case. The single highest-leverage upgrade for most prompts.
- **Room to think.** For judgment tasks, ask the model to reason through the criteria before giving its verdict (or use a model with extended thinking). Accuracy on complex evaluation jumps noticeably.
- **Escape hatches.** Always define behavior for "input is garbage / question is out of scope / information is missing." Unhandled cases don't error — they hallucinate.
- **Positive instructions.** "Write in plain, direct sentences" beats "don't be verbose." Models follow *do* better than *don't*.

## Debugging: the failure ladder

When output disappoints, check in this order — cheapest fix first:

1. **Ambiguity** — could a smart intern misread the instruction? Rewrite it.
2. **Missing context** — did the model actually have the information? (Print what was really sent — retrieval failures masquerade as model failures constantly.)
3. **Contradictions** — does "be concise" fight "be thorough and detailed"? Prioritize explicitly.
4. **Format confusion** — is instruction separate from data? Wrap data in delimiters.
5. **Capability** — only after 1–4: try a stronger model or break the task into steps.

Most "the model is dumb" complaints die at rungs 1 and 2.

## Treat prompts like code

- **Version them.** A prompt change is a behavior change is a release. It goes through review.
- **Eval them.** Never ship a prompt edit on one good demo output — run the [eval set](writing-evals.md).
- **Own them.** Someone's name should be on every production prompt. Often the right name is yours.