Who Should Own Prompts? How PMs and Engineers Collaborate on AI

Most teams don't fine-tune models anymore — 57% steer behavior through prompt engineering and RAG instead (LangChain, 2024). That makes the prompt the main control surface for your AI product. And here's the awkward part: a prompt is just English. The product manager who lives in customer calls often has sharper instincts for it than the engineer who owns the deploy pipeline.

So who edits it? This post is for AI product teams trying to answer that without turning every prompt tweak into a ticket — or every release into a gamble.

Key Takeaways

• Prompts are a shared control surface: 57% of teams steer behavior with prompts and RAG, not fine-tuning (LangChain, 2024).
• Quality, not cost, is the #1 barrier to shipping AI features (LangChain, 2024) — and quality is exactly what PMs are best at judging.
• Let product draft and iterate; let engineering own review, evals, and the deploy path. Guardrails are what let both move fast.

Why have prompts become a collaboration problem?

Prompts turned cross-functional the moment they became the product's behavior. Two-thirds of developers — 66% — name "AI solutions that are almost right, but not quite" as a top frustration (Stack Overflow, 2025). But "almost right" is a product judgment, not an engineering one. The person who knows what right looks like is usually the one closest to the user.

That's the tension. The prompt is written in plain language, so a PM or domain expert can read it, critique it, and often improve it faster than an engineer can. Yet it ships like code — one bad edit in production has real blast radius. When only engineers can touch it, product waits in a queue. When anyone can touch it, nobody can explain why output quality slid last Tuesday.

Neither extreme works. The fix isn't picking a side — it's splitting the work so the right person does each part.

Who should own prompts — product or engineering?

Both, but not the same parts. Quality ranked as the top barrier to shipping AI features in LangChain's survey — more than twice as significant as cost or safety (LangChain, 2024). Closing a quality gap is a product problem and an engineering problem at once, so ownership has to be shared along a clean seam.

Think of it as authorship versus operation. Product owns what the prompt should do — the intent, the tone, the quality bar, the iteration. Engineering owns how it ships — the registry, the eval suite, the deploy path, and the rollback. Draw the line there and you stop arguing about access.

The seam that works best in practice isn't "who's allowed to write English." It's "who's accountable for what reaches users." A PM can author the entire prompt; an engineer still signs off on the deploy. That single distinction dissolves most of the turf war.

How do you let non-engineers edit prompts safely?

Give them a sandbox, not the production switch. Reported AI incidents rose 56.4% year over year to 233 in 2024 (Stanford HAI, 2025), and a growing share of those trace back to changes that shipped without a second look. Letting a PM edit prompts is safe — letting an unreviewed edit hit production is not. The trick is to separate the two.

Four guardrails carry the weight:

1. Separate environments. A PM iterates freely in staging against real examples. Production is a deliberate promotion, never an autosave.
2. Review before promotion. Every production change gets a second set of eyes — usually an engineer, sometimes a senior PM. This is where regressions die.
3. Evals as the gate. Run each candidate prompt against a fixed test set before it ships. A change isn't done because it reads well; it's done because it passes the cases you care about.
4. One-click rollback. When something slips through at 2 a.m., anyone on call reverts to the last known-good version instead of waking an engineer to redeploy.

Our finding: the teams that give product real editing access and keep a review gate ship faster than teams that lock prompts behind engineering. The bottleneck was never the typing. It was the wait.

Notice what these guardrails do — they let you say yes to non-engineers without saying yes to chaos. The PM gets speed. The engineer keeps control of the surface that touches users.

What does a healthy PM–engineer prompt workflow look like?

It looks small and repeatable. DORA found AI adoption correlated with a ~7.2% drop in delivery stability unless teams kept changes small and tested (DORA, 2024). The same rule applies to prompts: tiny, tracked edits beat big batch rewrites every time.

A clean loop runs like this:

1. Product drafts a change in staging, using real inputs from recent tickets or transcripts.
2. Evals run automatically against the test set, flagging regressions before a human looks.
3. Engineering reviews the diff — what changed, why, and how it scored.
4. Promotion to production is one tracked action, with version, author, and timestamp recorded.
5. Monitoring and rollback stay live, so a bad result is a revert, not an incident.

Each handoff is fast because each role is doing the part it's best at. Product isn't waiting on a release train to fix a tone issue. Engineering isn't hand-editing strings a PM could have written. And every change leaves a trail, so "what changed?" has an answer in seconds.

The payoff compounds. McKinsey found 88% of organizations use AI, but only about 6% capture real value (McKinsey, 2025). The gap is rarely the model. It's whether teams can change prompts quickly and safely — which is exactly what a shared, guard-railed workflow buys you.

Frequently asked questions

Should product managers write prompts directly?

Yes — and increasingly they already do. With 57% of teams steering behavior through prompts rather than fine-tuning (LangChain, 2024), the prompt is a product artifact, not just code. PMs understand the intended behavior best; the guardrail is that an engineer reviews before production, not that PMs are kept out.

Doesn't letting non-engineers edit prompts create chaos?

Only without guardrails. The chaos comes from unreviewed edits hitting production — a real risk as AI incidents rose 56.4% in 2024 (Stanford HAI, 2025). Separate staging from production, require review, and gate on evals, and broad editing access becomes safe rather than risky.

How is this different from just managing prompts in Git?

Git handles history, but it couples every prompt change to the deploy cycle and assumes the editor is comfortable with pull requests. Most PMs aren't. A prompt workflow keeps the same rigor — versioning, review, rollback — while giving non-engineers an interface they'll actually use, which matters when 66% of teams fight "almost right" output (Stack Overflow, 2025).

Who's accountable when a prompt change breaks production?

Whoever approved the promotion — which is why the review gate matters. Product can author freely, but accountability sits with the engineer (or lead) who signed off on the deploy. A recorded audit trail of version, author, and timestamp turns "who broke this?" from a blame game into a two-second lookup.

Bringing it together

The old debate — should product or engineering own prompts — is the wrong question. Both own them, along a clean seam: product authors and iterates, engineering reviews and operates, and guardrails keep the handoff fast. That's how you let the person closest to the user shape behavior without betting production on an unreviewed edit.

That's the workflow we built PromptVault to support: a shared registry where product can draft and iterate while engineering keeps review, evals, and rollback. For the broader playbook, see our guide to prompt management for teams. For more engineering notes and guides, browse the PromptVault blog.