Prompting Is Only One Part of the Stack
When you build with LLMs, behavior usually depends on more than the user's message. It often depends on:
<ul>
<li>system instructions</li>
<li>app logic or developer rules</li>
<li>retrieved context</li>
<li>tool outputs</li>
<li>conversation history</li>
<li>the user's actual request</li>
</ul>
For PMs, prompt design is product design for model behavior.

Which of the following is clearly a user prompt?

A strong system instruction can improve consistency, but it does not guarantee correctness.

Instruction Hierarchy Matters
A useful mental model:
<ul>
<li>system instructions set behavior and boundaries</li>
<li>retrieved context brings in task-specific knowledge</li>
<li>tool outputs provide live or private data</li>
<li>user prompts express the immediate goal</li>
</ul>
Many quality problems come from missing context, not from weak wording alone.

An assistant over policy documents gives generic answers because it is not seeing the right handbook pages. What should the PM improve first?

Permanent product rules usually belong in system or application instructions, not repeated manually by end users every time.

Good Instructions Define Boundaries
Strong system instructions often specify:
<ul>
<li>the role the assistant should play</li>
<li>the audience and tone</li>
<li>when to ask clarifying questions</li>
<li>when to refuse or escalate</li>
<li>when to cite sources</li>
<li>what not to do</li>
</ul>
This makes the feature more predictable and safer.

Which system instruction is strongest for an enterprise knowledge assistant?

Telling the model when to abstain, escalate, or ask clarifying questions is part of good prompt design.

Prompt Changes Need Versioning
Prompts and instructions are part of product logic. Changing them can change outcomes just like code changes can.
That means teams should:
<ul>
<li>version important prompts</li>
<li>test them on representative tasks</li>
<li>compare outputs before rollout</li>
<li>monitor for regressions after launch</li>
</ul>

Why should a product team version prompts and system instructions?

Changing prompts in production without evaluation can silently change product behavior in harmful ways.

Prompting Is Not a Substitute for Architecture
If a feature needs live order status, private account data, or safe action-taking, prompting alone is not enough. The product may need retrieval, tool use, permissions, and fallback logic.
PMs should know when a better prompt helps and when the product needs a different system design.

If a user asks, "What is my current order status?", what should the product rely on for a trustworthy answer?