Prompt Design for PMs

A two-sentence prompt is a two-sentence spec

Here's the system prompt for a real AI feature that went to production:

That's it. The entire product spec for a feature that runs on every customer interaction. No role definition. No format rules. No constraints. No examples.

What happened? The bot wrote 500-word replies. Used the wrong tone. Occasionally recommended competitor products. The team spent three weeks debugging "the model" before someone looked at the prompt.

The lesson: A system prompt IS a product spec, written in plain English. A vague prompt causes the same downstream pain as a vague PRD — except a bad prompt reaches every user on every request until someone catches it.

The four ingredients (same as engineering — but you own the spec)

Engineers write the prompt. You write the requirements for the prompt. Same four ingredients, different ownership:

Think of it like a job posting. You wouldn't hire someone with just "be helpful and do work." You'd specify the role, the responsibilities, the standards, and the deal-breakers. A system prompt is a job posting for your AI.

PM insight: Constraints cause the most damage when missing. The model locks in its role, goal, and format first — and only then reaches the "what not to do" section. If that section is empty, the model will fill in the blanks with its own defaults. Those defaults are tuned for general helpfulness, not your product's specific needs.

Real example: Sofia fixes Loom's summary feature

Sofia is a PM at Loom (the screen recording tool). Her team's "draft summary" feature generates text summaries of video recordings. The v1 prompt? "Summarise this video transcript."

She iterated through four versions, running an eval (3 reviewers, 200 recordings, usefulness rated 1-5) after each:

Three things to notice:

1. The biggest quality jumps came from constraints and examples, not from elaborate descriptions. "Never mention timestamps" did more work than 50 words of positive instruction.

2. One example beat 100 words of instructions. V4 added a single example showing what a good summary looks like. That one example did more for quality than all three previous iterations combined.

   This technique — providing worked examples in the prompt — is called few-shot prompting. Zero examples = zero-shot; one = one-shot; two to five = few-shot. Few-shot examples are the fastest way to say "produce output exactly like this." The failure mode: if your examples share an accidental pattern (e.g., all are about software), the model may overgeneralise and apply that pattern to inputs where it doesn't fit.

3. The whole iteration took 4 hours. The team's alternative plan (fine-tuning the model) was estimated at 6 weeks.

Versioning: treat prompts like code, not drafts

This is the mistake that bites teams: an engineer edits the system prompt directly in production on a Friday afternoon. Nobody notices until Monday when quality drops.

The PM rule: system prompt changes follow the same process as code changes.

Back to that two-sentence system prompt. After three weeks of debugging "the model," the team rewrote the system prompt over a single afternoon. They added a role, a format constraint (max three sentences per reply), a constraint list (no competitor mentions, no unsolicited upsells), and one example of a good response. They ran an eval over 100 historical tickets. Quality went from consistently frustrating to consistently acceptable. The "model problem" turned out to be a prompt problem — which is almost always true.

Key takeaways

• A system prompt is a product spec in plain English. A vague prompt causes the same pain as a vague PRD — but it reaches every user on every request.
• You own the requirements, the engineer owns the implementation. Write acceptance criteria for role, goal, format, and constraints.
• Constraints do more work than positive instructions. "Never mention competitors" is clearer and more testable than "stay focused on our product."
• One example beats 100 words of instruction. If your prompt describes the format but doesn't show it, add an example.
• Treat prompt changes like code changes. Version, eval, test, log. Never edit production without measuring.