Guide · Dubai · MENA

Prompt engineering for product managers: treat prompts like product specs

On more than one client build I have watched a founder open the system prompt, add three sentences to fix a support complaint, and ship it straight to production. No review, no test, no record of what the prompt said an hour earlier. Across engagements in Dubai and MENA I keep seeing the same gap: teams that require review before an engineer merges a schema change let anyone touch the prompt that decides what the product says to each user. A prompt is a product spec, and it deserves the same discipline as any other spec that ships to users.

Prompt engineering for product managers, the two meanings

The phrase carries two different jobs, and mixing them up causes most of the confusion I see in early product teams.

The first meaning is personal: using ChatGPT, Claude, or another assistant well in your own work. Writing a sharper research prompt, getting better meeting summaries, drafting a spec faster. Useful, but it is a personal productivity skill, not product work.

The second meaning is the one this guide covers: writing the prompts that live inside your product and shape what it says to real users. That system prompt sets tone, encodes business rules, defines what the product refuses to do, and handles edge cases your support team will hear about within a week if you get them wrong. Writing that prompt well, and maintaining it as the product changes, is product management. Treat it as a side task and whoever last opened the file ends up owning it by default.

A system prompt is a spec, not a suggestion

A good system prompt does the same job a good product spec does. It states the intended behaviour, the tone, the constraints, and the cases where the product should say no. The difference is that a spec sits in a document engineers read once and build from. A prompt runs on each incoming request, so an unreviewed edit changes production behaviour the moment someone saves the file.

I have reviewed client prompts that ran 40 lines of accumulated patches with no version history and no owner who could explain why line 22 existed. No one on the team remembered which support ticket triggered it. Treat the prompt the way you treat any other spec that ships to users:

• Keep it in version control, not a shared doc or a chat thread.
• Require a review before a change reaches production, the same bar you apply to a pricing change or an onboarding flow.
• Write a one-line comment or commit message for each rule you add, naming the case it handles.
• Read it end to end once a quarter. Prompts accumulate exceptions the way codebases accumulate technical debt, and no one notices until a new hire asks why a paragraph contradicts the one above it.

Ship a prompt change like a feature

The riskiest prompt edits are the small ones. A single added sentence can shift tone across many responses, break a refusal case that used to work, or raise the token count on each call. Ship a prompt change the way you would ship any feature that touches your entire user base.

Run your eval suite before the change goes out, not after a complaint comes in. If you do not have one yet, our LLM evals guide covers how to build a first set from real transcripts rather than guessed test cases. An eval suite catches the regression a demo will not, because a demo only tests the inputs you thought to try.

Roll the change out to a slice of traffic before it reaches the rest of your users, and watch the same product metrics you would watch for any other release: acceptance rate, regeneration rate, and any support tag tied to the feature. Keep the previous prompt version tagged and ready to restore, because the fastest fix for a bad prompt change is reverting it while you diagnose, not patching forward under pressure.

Write prompts from evidence, not vibes

The weakest prompts I have read were written from what the team assumed users would ask. The strongest ones came from reading real transcripts.

Pull 20 to 30 recent conversations or generations, tag where the output missed, and group the misses into patterns rather than one-off fixes. A support ticket that says "it gave a weird answer" is not a prompt instruction. The transcript underneath it is: the user asked something ambiguous, or asked in a way your examples did not cover, or hit an edge case your refusal rules do not mention.

Turn each pattern into a specific rule with an example, not a vague instruction. "Be more careful with edge cases" tells the model nothing it can act on. "When a user asks for a refund outside the stated policy, explain the policy and offer to escalate to a human" gives it a rule and a fallback. Write the rule, add a test case to your eval set that exercises it, and only then ship it.

Who owns prompts on a small team

On a team without a dedicated prompt engineer, someone still has to own this, and the ownership works best split by what each role already does well.

The founder or PM owns the intent: what the product should and should not say, which cases matter, and what tone fits the brand. That is product judgement, not a technical skill, and it belongs with whoever owns the roadmap.

The engineer owns the mechanics: how the prompt is versioned, how it gets tested against the eval suite, and how a change gets deployed and rolled back. That is infrastructure work, and it belongs with whoever already owns deploys.

Both sign off before a change ships. A PM who writes a rule without an engineer wiring it into the eval suite ships untested. An engineer who ships a prompt change without a PM reviewing the intent ships a tone the product did not mean to have. Write the split down where both roles can see it, and neither gap happens alone.

Prompt anti-patterns I keep finding in client codebases

A few patterns show up often enough across engagements that they are worth naming before you inherit them.

Prompt sprawl: a single system prompt that has grown to handle each edge case anyone has raised, until no one can predict what one more sentence will change. Split it into sections with clear ownership, or move stable rules into structured examples the model can reference instead of prose it has to parse each time.

Magic incantations: a line in the prompt no one wants to remove because the team is not sure what it fixes. If a rule exists, someone should be able to name the case it handles and point to the eval that covers it. If they cannot, that is the signal to test whether removing it changes anything.

Untested hotfixes: a prompt edited live to answer one complaint, with no eval run and no record kept. It fixes the ticket in front of you and often breaks a case no one is watching. The five minutes an eval run costs is cheaper than the support thread the untested fix creates next week.

FAQ

Is prompt engineering a real product management skill? Yes, when it means writing and maintaining the prompts inside your product. It is spec writing for a system that runs on each incoming request, which makes review, versioning, and testing part of the job, not optional extras.

Who should own the system prompt on a startup team? Split it. The founder or PM owns what the product should say and to whom. The engineer owns how changes are tested, versioned, and rolled back. Both review before a change ships.

How do I test a prompt change before shipping it? Run it against an eval suite built from real transcripts, not guessed cases, then roll it out to a slice of traffic and watch acceptance rate and regeneration rate before opening it to the rest of your users.

How often should a system prompt be reviewed? Read it end to end at least once a quarter, and any time you notice two rules that contradict each other. Prompts accumulate exceptions the same way codebases accumulate patches, one small change at a time.

Book a call

If your product's prompts have grown past what anyone can explain line by line, book an intro call to bring spec discipline to how your team writes and ships them. For weekly writing on AI and product from zero, read the Scalable newsletter.