Prompt engineering is product management

The teams shipping reliable AI features have not hired better prompt engineers. They have stopped separating the job of specifying what the product must do from the job of specifying what the model must produce.

The wrong person is writing your prompts.

In most companies building AI-powered products, the prompt is written by whoever last touched the codebase. An engineer integrating the API writes a quick system prompt, tests it against a few examples, decides it looks reasonable, and ships it. The product manager reviews the feature output in a demo, says it seems good, and signs off. Nobody specified exactly what the output should look like in the twenty-three edge cases that will appear in the first week of production.

This is how you end up with a customer-facing AI feature that works beautifully in demos and produces embarrassing outputs when real users arrive with inputs that the demo never included. The embarrassing outputs were predictable. Nobody predicted them because nobody's job was to predict them.

The best prompt engineers do not write better prompts in the sense of using cleverer language or more exotic techniques. They write better requirements. The prompt is the specification for a non-deterministic system that will encounter an enormous variety of inputs and must produce outputs that fall within acceptable bounds for all of them. Writing that specification well is a product management skill, not an engineering skill.

What product management and prompt engineering share.

Good product managers are obsessive about specifying the exact output required. They do not write user stories that say "the user should be able to see their order status." They write requirements that specify what information appears, in what order, with what formatting, with what error states, with what empty states, and with what edge cases handled how. Ambiguity in a product requirement produces disagreement and rework. Ambiguity in a prompt produces inconsistency and failure.

The prompt engineer who writes "you are a helpful customer service assistant, please help the user with their question" has produced approximately the same artefact as the product manager who writes "make it easy for users to get support." Both have specified the intent while leaving every consequential decision open. Both will generate enormous amounts of rework when the implementation turns out to not match what they actually wanted.

The prompt engineer who writes a system prompt that specifies: the exact persona and its limits, the output format down to punctuation conventions, the prohibited topics and how to handle them, the escalation language for cases outside scope, the handling of multiple questions in one message, the tone calibration for frustrated versus neutral users, and five examples of each response type — that person is writing a product requirements document that happens to execute at inference time.

Good product managers are also adversarial about failure modes. Before a feature ships, a good PM has asked: what happens when a user does the thing we did not design for? What is the worst case input? What does the error state look like? What happens if the user's intent is ambiguous or hostile? This adversarial discipline is identical to what separates reliable prompts from fragile ones.

The separation that kills reliability.

Most organisations that have separated prompt engineering from product management did so for understandable reasons. Prompt engineering sounds technical, so it goes to engineers. Product management handles requirements, so it sits upstream of implementation. The divide feels natural.

The problem is that a prompt is simultaneously a requirement and an implementation. It specifies what the output must be and it produces the output. When the requirement-writing and the implementation are done by different people in different conversations, you get prompts that technically function according to what the engineer understood the product manager wanted, rather than prompts that produce what the user actually needs.

Consider how this plays out on an AI triage feature for a healthcare-adjacent product. The PM writes a brief describing what the feature should do: categorise incoming patient messages, identify urgency, route to the appropriate team. The engineer translates this into a prompt asking the model to classify messages on those dimensions. The feature works. It can also consistently miscategorise a specific class of message — patients describing symptoms they are embarrassed about, who use hedging and indirect language — as low urgency, because the prompt never specified how to interpret indirect language in a medical context. The PM did not think to specify it. The engineer did not think to ask. The fix might be a single paragraph in the system prompt, but it only gets written after something goes wrong — unless the person who understands the product writes the prompt in the first place.

How to unify the functions.

The practical resolution is not to eliminate the distinction between PMs and engineers, but to change who owns the prompt and how it gets written.

The product manager should own the prompt specification — a document that defines the output with enough precision to be evaluated unambiguously. This is not a sentence or a paragraph. For a production customer-facing feature, it is typically a multi-page document that defines the output format, the tone requirements, the handling of edge cases, the prohibited behaviours, and the escalation paths. Writing this document well requires the PM to think adversarially about what could go wrong — which is a PM skill, not an engineering skill.

The engineer translates the specification into the actual prompt text and tests it against the evaluation set. When the prompt fails — when it produces output that does not meet the specification — the failure is surfaced to the PM as a requirements question: is the specification wrong, or does the prompt need to be rewritten to meet the specification? This question routes correctly. The PM holds the authority about what the product must do. The engineer holds the authority about what is technically achievable within the model's capabilities.

This collaboration requires something else: genuine humility on both sides about what the model can and cannot do. Product managers who have not worked closely with LLMs tend to write specifications that presuppose capabilities the model does not reliably have. Engineers who have worked closely with LLMs tend to narrow specifications to what they know the model handles well, missing edge cases the PM would care about. Both failure modes are addressable when the two functions are in the same room, reading the same evaluation results, looking at the same failure cases together.

Prompts as versioned product artefacts.

One of the clearest signals that an organisation has not internalised this principle is how they manage prompt changes. In most organisations, prompt changes happen in a Notion doc or a hard-coded string in the codebase, without version history, without documented rationale, and without evaluation against a regression set before deployment.

This is the equivalent of shipping code changes without tests or version control. The prompt is the most consequential specification in an AI product — it is what determines the product's behaviour for every user. Changing it without systematic evaluation is accepting unknown risk. Undocumented prompt changes are one of the most common and most avoidable sources of failure in AI features.

Prompts should be version controlled with explicit commit messages explaining why the change was made. Every change to a production prompt should be evaluated against the regression set before deployment. There should be a rollback path for prompt changes with the same urgency as a rollback path for code. None of this is technically complicated. All of it requires treating the prompt as the product artefact it actually is.

What model limitations require product decisions, not prompt solutions.

Part of the value of unifying prompt engineering with product management is that it surfaces the cases where no prompt can solve the problem — where the limitation requires a product decision about what not to try to do with AI.

There are classes of task that current foundation models handle unreliably regardless of how the prompt is written: precise arithmetic with large numbers, reliable recall of specific facts without retrieval augmentation, consistent formatting in complex nested structures, and sustained coherence over very long outputs. A PM who understands this will design features that route around these limitations. A PM who does not understand this will write requirements that the model cannot reliably meet, and the engineer will ship something that fails in ways the PM considers unacceptable but did not anticipate.

The teams shipping the most reliable AI features have PMs who have spent significant time reading model outputs, understanding failure patterns, and designing features that exploit what the model does well while building workflow guardrails around what it does poorly. This knowledge cannot be fully delegated to the engineering team. It must live in the product function.

• 01
  The PM should own the prompt specification, not just the brief. A brief that says "summarise the document helpfully" is not a specification. The specification defines format, length, required elements, prohibited elements, edge case handling, and examples. If you are handing a brief to engineering and expecting a reliable prompt to emerge, you will be disappointed.
• 02
  Write the adversarial cases into the specification before the prompt is written. What happens when the input is ambiguous? Too short? In the wrong language? Hostile? These cases are product decisions, not engineering decisions. They must be in the specification, not discovered in production.
• 03
  Version control prompts with the same discipline as code. Every prompt change should have a commit message explaining why. Every production prompt change should be evaluated against a regression set before deployment. Treat undocumented prompt changes as the production risk they are.
• 04
  PMs must read model outputs, not just approve demo screenshots. Understanding what the model does when given ambiguous inputs requires reading output, not slides. PMs who have never read raw model output from their own product will continue to write specifications that cannot be reliably implemented.
• 05
  When the prompt cannot solve it, that is a product decision. If a class of input reliably produces bad outputs regardless of prompting, the product must decide how to handle it: block the input, disclose the limitation, route to a human, or not support the use case. This decision belongs to the PM, not the engineer.
• 06
  Measure prompt quality, not just feature usage. Usage metrics tell you if users are engaging. Quality metrics tell you if the model is producing what the product requires. You need both, and the PM should own the quality metrics with the same rigour they apply to user satisfaction scores.

Frequently asked questions.