From Stakeholder Ask to System Prompt: Translating Requirements Into Instructions

"Make it sound more professional" is not an instruction — it's a feeling a stakeholder wants the model to produce, with no way to check whether it happened. Translating requirements into instructions means converting that feeling into a rule with an observable trigger, a specific behavior, and a pass/fail test, using a three-column method: raw ask, clarified intent, prompt rule plus acceptance criterion.

Quick Answer: Run every stakeholder ask through three columns — what they said, what they actually mean (with assumptions named), and a testable prompt rule with a pass/fail criterion. If you can't write the criterion, you haven't finished clarifying the intent.

Why "Make It More Professional" Isn't an Instruction Yet

A raw stakeholder ask is a compressed signal, not a spec — it encodes an intent, a set of assumptions the stakeholder didn't think to state, and an implicit definition of success that lives only in their head. Handing that sentence to a model as a system prompt line just relocates the ambiguity into production, where it surfaces as inconsistent behavior instead of a clarifying question.

Language models are unusually good at following vague instructions in a vague way. A rule like "sound more professional" gets satisfied in a dozen incompatible ways: formal vocabulary, longer sentences, more hedging, fewer contractions, a different greeting. The model doesn't fail loudly — it picks an interpretation and commits, which means the gap between what the stakeholder wanted and what shipped is invisible until someone complains.

This is the same failure mode traditional requirements-gathering has always fought, just faster and less forgiving. In classical software, an ambiguous requirement produced a wrong feature that a QA pass or a demo caught before release. In a prompt-governed feature, the "wrong feature" is a live behavior interpreting every user message slightly differently, and there's often no QA step at all unless you built one.

Where the Ambiguity Actually Lives

Three things are usually missing from a raw ask, and naming them is most of the translation work:

1. A trigger — when should this behavior activate? Always, or only in some detectable condition?
2. A boundary — what does "more" or "less" mean in a way you could measure?
3. A failure mode — what does violating this rule look like, concretely, so someone could flag it?

Requirements literature has been circling this problem for decades. The IEEE 830 standard for software requirements specifications insists every requirement be verifiable — if you can't devise a test that determines whether the requirement was met, it isn't a requirement yet, it's a wish. That bar applies just as hard to a prompt rule as it did to a functional spec.

The Three-Column Method: Raw Ask, Clarified Intent, Prompt Rule

The method has three columns because collapsing straight from stakeholder language to prompt text skips the step where hidden assumptions get named and challenged. Each row starts as a sentence a stakeholder actually said, ends as a rule a QA process could grade pass or fail.

Column 1: Capture the Raw Ask Without Editing It

Write down what the stakeholder said, not your first-pass interpretation of it. This matters more than it sounds like it should — PMs habitually paraphrase-and-improve on the way into a doc, which quietly discards the exact word choice you'll need later to check whether you translated it faithfully.

• Log the ask in the stakeholder's own words, including hedges ("kind of," "a bit more").
• Note who said it and in what context — a sales lead's "more professional" after a lost enterprise deal means something different from a support lead's after a tone complaint.
• Resist the urge to fix it yet. Column 1 is a record, not a draft.

Column 2: Surface the Hidden Assumptions

This is where most of the actual thinking happens. Take the raw ask and list every assumption bundled inside it — audience, channel, tone register, what "more" is relative to, what would count as going too far.

For "make it more professional": does professional mean formal, concise, jargon-appropriate, or simply free of typos and slang? Is it about vocabulary, structure, or willingness to push back on a user's bad idea? Each of those is a different prompt rule, and stakeholders rarely distinguish between them unprompted — they're describing an outcome, not a mechanism.

Treat Column 2 as a running list of questions, not a finished paragraph. If you can't fill it in confidently, that's a signal to go back and ask, not to guess and move on.

Column 3: Write the Rule and Its Acceptance Criterion

A prompt rule earns its place in the system prompt only if it comes with a way to check it. Pair every instruction with a criterion phrased so a reviewer — human or automated — could grade a transcript against it without asking you what you meant.

• Weak rule: "Be professional in tone."
• Testable rule: "Do not use contractions or casual interjections (e.g., 'yeah,' 'no worries') in responses to messages tagged enterprise_account = true. Acceptance: 20 sampled transcripts from enterprise accounts, zero contraction/interjection violations."

That pairing is the same discipline behind treating the system prompt as the new PRD — a requirements document that isn't testable was never really a requirements document, and a prompt rule that isn't testable is just aspirational prose sitting in a context window.

Worked Example: "Be More Helpful to Enterprise Users"

This ask sounds actionable — it names a segment — but it's exactly as untestable as "more professional" until you push it through all three columns, because "helpful" hides at least four different mechanisms.

Raw ask (from a customer success lead, after a churn review): "The AI should be more helpful to enterprise users. They're paying more and they're not getting the white-glove experience they expect."

Running it through Column 2 turns up assumptions nobody had stated out loud:

That table is the moment the exercise stops being a wordsmithing exercise and starts being a scoping decision — because at least one row isn't a prompt problem.

Where This Revealed a Stakeholder Disagreement

Digging into "proactive suggestions" versus "escalation awareness" surfaced a real conflict: the customer success lead wanted the model to try harder to resolve issues itself before looping in a human, to reduce ticket volume. The support lead, in the same review, wanted enterprise accounts to reach a human faster, on the theory that white-glove means human contact, not a better bot.

Those two intents produce opposite prompt rules. One says "escalate less for this segment"; the other says "escalate sooner." Neither stakeholder had noticed they disagreed until the clarified-intent column forced both interpretations onto the same page. This is the actual value of the method — it's not primarily a formatting exercise, it's a forcing function that makes disagreements visible before they become inconsistent production behavior that nobody can trace back to a decision.

The resolution, once surfaced, was a scoped rule rather than either extreme:

• Prompt rule: "For messages from accounts tagged enterprise_account = true, if the user expresses frustration (negation, repeated rephrasing of the same request, explicit mention of 'still not working') after 2 unsuccessful resolution attempts within the conversation, offer human escalation immediately rather than attempting a third automated fix."
• Acceptance criterion: In a set of 15 scripted enterprise conversations with a scripted third-failure turn, the model offers escalation in all 15 by the third failed attempt, and does not offer escalation before the second attempt in any of them.

That's a rule a QA reviewer can run against transcripts and mark pass or fail — the same rigor you'd want before shipping any structured output a downstream system depends on, just applied to a behavioral rule instead of a JSON schema.

Where This Method Breaks Down (and What to Do Instead)

The three-column method works well for behavioral, tone, and process rules — anything expressible as "in situation X, do Y, and here's how we'd check." It breaks down when the ask isn't really about the prompt at all, and forcing it into a prompt rule produces something that looks precise but can't actually be satisfied.

Watch for these tells that you're past the prompt's jurisdiction:

1. The clarified intent requires information the model doesn't have access to (account history, prior tickets) — that's a retrieval or context problem, not a wording problem.
2. The acceptance criterion keeps needing "usually" or "in most cases" — vague thresholds at Column 3 usually mean Column 2 wasn't actually finished.
3. Two stakeholders' clarified intents are flatly incompatible, as in the escalation example — that needs a decision, not a cleverer prompt.
4. The ask is really about latency, cost, or a UI affordance — no system prompt line fixes a feature the interface doesn't support.

When you hit one of these, say so explicitly rather than writing a prompt rule that reads well and does nothing. A documented "this requires X, not a prompt change" is more useful to the team than a rule that will quietly fail acceptance testing three weeks later.

Testing the Rule Before It Ships

A prompt rule's acceptance criterion isn't just documentation — it's the test suite. Once you have a rule and a criterion, run it against a sampled set of real or scripted transcripts before it goes live, and re-run the same set whenever the prompt changes, the same way you'd regression-test code. That discipline is exactly the argument behind versioning prompts like code and testing them like features — a rule that passed once and was never checked again is a rule you're only assuming still holds.

It also pays to trace each rule back to the situation that motivated it. Requirements engineering has long used traceability — linking a requirement back to its origin — to catch rules that outlived their reason for existing. A prompt rule written for a churn review eight months ago, with the underlying complaint since resolved a different way, is dead weight cluttering the context window and possibly fighting a newer rule that supersedes it.

Tracking Whose Asks Made It Into the Prompt

Once you're running several stakeholders' asks through this method, a second problem appears: keeping track of whose behavioral requests actually got translated into rules, and whose are still sitting in a meeting note somewhere unaddressed. That gap is easy to lose track of across a handful of stakeholders and near-impossible to track by memory once you're managing a dozen.

This is the honest use case for Prodinja's Stakeholders CRM, which computes an alignment-debt score per stakeholder — a way to see at a glance whose behavioral asks are represented in the current prompt and whose have gone stale without a resolution. It's a bookkeeping layer for exactly the traceability problem above: not a replacement for doing the three-column translation work, but a way to make sure nobody's "be more helpful to enterprise users" gets nodded at in a meeting and then silently dropped from the actual system prompt.

Pairing that tracking with the earlier steps in the process — the kind of grounding Jobs to Be Done thinking provides when you're not sure what a stakeholder's ask is really in service of, or mapping the ask against a customer journey to see where in the experience it actually bites — keeps the translation honest instead of just fast.

Key Takeaways

• A stakeholder ask is a compressed signal, not a spec — treat "make it more professional" as a starting point requiring decomposition, not text ready for the system prompt.
• Use three columns: raw ask (verbatim), clarified intent (with named assumptions), and prompt rule plus acceptance criterion (testable pass/fail).
• If you can't write the acceptance criterion, the clarified intent isn't finished — vague thresholds at Column 3 are a symptom of skipped work at Column 2.
• Translating requirements into instructions often surfaces disagreements between stakeholders that a single vague ask was hiding — that's the method working, not a side effect to route around.
• Not every ask is a prompt problem — retrieval gaps, latency, and UI limitations need to be named as such rather than forced into a rule that looks precise but can't be satisfied.
• Test the rule like you'd test code: run the acceptance criterion against sampled transcripts before shipping and again after any prompt change.
• Track whose asks are represented and whose aren't — alignment debt accumulates quietly across stakeholders and is worth monitoring deliberately, not from memory.