You can read about role prompting for an hour and still not know what a good one looks like in practice. Abstractions like "specify priorities" and "describe behavior" only click when you see them applied to a real task with a real output on the line. This article walks through five concrete scenarios, each with the actual persona, the reasoning behind it, and an honest note on what worked and what did not.
These are deliberately varied: a marketing draft, a code review, a difficult email, a research summary, and a multi-persona critique. The variety is the point. Role prompting behaves differently across task types, and seeing that range is more instructive than ten examples of the same kind. Some of these worked cleanly; one needed a second pass; one taught a lesson about where personas help least.
Adapt them freely. The exact wording matters less than the structure underneath each one.
Scenario One: Conversion Copy That Stays On-Brand
A team needed product-page copy that matched an established brand voice without sounding like generic AI output.
The Persona
"You are a conversion copywriter for a premium outdoor gear brand. You write in plain, confident sentences, favor concrete sensory detail over adjectives, and never use exclamation marks. Optimize for one clear benefit and one call to action. Keep it under 90 words."
What Worked
The behavioral specifics β "concrete sensory detail over adjectives," "no exclamation marks" β did the heavy lifting. Removing them and leaving just "expert copywriter" produced generic, punchy, exclamation-heavy copy that missed the brand entirely. This is the behavior-over-status principle from our best practices that actually work in action.
Scenario Two: A Code Review That Surfaces Risk
A developer wanted a review that flagged security and edge-case issues, not just style.
The Persona
"You are a security-minded senior reviewer. For the code below, prioritize input validation, error handling, and edge cases over style nits. List issues by severity, and for each, name the risk and a concrete fix."
What Worked
Naming the priorities β validation, error handling, edge cases β pulled the review toward substance. Without the security framing, the model defaulted to formatting and naming comments. The persona conditioned it to look where it mattered.
Scenario Three: A Hard Email That Lands Right
A manager needed to decline a vendor's proposal firmly but without burning the relationship.
The Persona
"You are an experienced operations lead known for direct but respectful communication. Write a short email declining this proposal. Be clear that the answer is no, give one honest reason, leave the door open for the future, and keep it warm without being apologetic. Under 120 words."
What Worked and What Did Not
The first draft over-apologized. Adding "without being apologetic" fixed it on the second pass. This is a small reminder from our step-by-step approach to role prompting: test, spot the drift, add the missing constraint.
Scenario Four: A Research Summary for the Wrong Audience
A researcher needed a dense paper summarized for non-technical executives.
The Persona
"You are a strategy consultant who translates technical research for executives. Summarize the paper below in five bullets. Focus on the business implication of each finding, skip methodology, and use no technical jargon."
What Worked
The audience framing ("for executives") plus the explicit "skip methodology" produced a summary leadership could actually use. The persona's value here was entirely about emphasis and register β exactly the subjective dimensions where roles are strongest.
Scenario Five: Multi-Persona Critique
A founder wanted a business plan stress-tested from several angles at once.
The Approach
Rather than one persona, three sequential ones:
- The skeptical investor: "Name the three biggest risks this plan ignores."
- The target customer: "Read this as someone being sold to. What would make you not buy?"
- The operator: "What in this plan is hardest to actually execute?"
What Worked
Each narrow persona surfaced blind spots a single "business expert" voice blurred together. This per-step pattern is core to our framework for role prompting, and it consistently beats one persona trying to cover everything.
A Counterexample: Where the Persona Did Nothing
It is worth showing a case where role prompting added no value, because knowing the limits is as useful as knowing the wins.
The Task
A team needed to extract structured data β dates, amounts, and reference numbers β from a batch of invoices into a clean table.
The Persona That Did Not Help
"You are a meticulous accounts-payable clerk. Extract the date, total, and invoice number from each document below into a table."
Removing the persona entirely and keeping only "Extract the date, total, and invoice number from each document into a table" produced identical results. The task was objective and fully specified; the model's accuracy depended on its parsing ability, not on any disposition. The "meticulous clerk" framing was pure decoration. This is the line our best practices that actually work draw between subjective and objective work β and a reminder that not every prompt wants a persona.
Patterns Across the Examples
Looking at all six scenarios together, a few reliable patterns emerge that you can apply to your own work.
Behavior Carries the Signal
In every example that worked, the win came from specifying observable behavior β "concrete sensory detail," "no exclamation marks," "name the risk and a fix." The job title alone never did the work. When you adapt these, keep the behavioral specifics and feel free to change the title.
Constraints Shape More Than Tone
Word limits, banned phrases, and explicit "skip this" instructions did as much heavy lifting as the personas themselves. The copywriting, email, and research examples all leaned on constraints to hit their target. Pair every persona with the boundaries that define a good output.
Test Before You Trust
Two of the examples needed a second pass once real input exposed a gap. Assume your first draft will too. Running a persona on a few real inputs and adjusting is normal, not a sign you did it wrong.
Frequently Asked Questions
Why did the copywriting example need behavioral details instead of just "expert copywriter"?
Because "expert" carries no instruction the model can act on. The output defaulted to generic punchy copy. Specifying observable behavior β concrete sensory detail, no exclamation marks, one benefit and one CTA β gave the model something to actually execute, and the brand voice emerged. Behavior steers; status does not.
How did the code review persona avoid the usual style-nit output?
By naming the priorities explicitly: input validation, error handling, and edge cases, ranked above style. Without that framing, the model defaults to the easiest comments, which are usually formatting and naming. Telling it where to look conditioned the review toward substantive risk instead of surface polish.
What lesson came out of the difficult-email example?
That you should test and refine, not trust the first draft. The initial output over-apologized despite the persona. Adding one constraint β "without being apologetic" β corrected it. Real personas usually need a second pass once you see how the model interprets them against an actual input.
When is a single persona worse than multiple personas?
When you need a task examined from several angles, like stress-testing a plan. One "business expert" voice blends perspectives into mush. Three narrow personas β investor, customer, operator β each surface distinct blind spots. For evaluation and critique work especially, sequential single-angle personas outperform one broad one.
Why was the research summary a good fit for role prompting?
Because its value was entirely subjective: audience, register, and emphasis. The persona's job was to translate for executives, skip methodology, and drop jargon β all framing decisions, not factual ones. That is exactly the territory where role prompting is strongest, as opposed to objective tasks where it adds little.
Key Takeaways
- Behavioral specifics ("no exclamation marks," "concrete detail") outperform titles like "expert copywriter."
- Naming explicit priorities steers a code review toward substance instead of style nits.
- Expect to refine after the first draft β adding one missing constraint often fixes the output.
- Role prompting shines on subjective tasks like audience translation, where emphasis and register matter.
- For critique and stress-testing, several narrow personas beat one broad "expert" voice.