The Council in My Head

Amy Westlake
Jul 11
5 min read

Situation

I had a status report Gem already. It followed a good format, pulled real data, avoided the fluff. I'd read it before sending, catch an awkward sentence here and there, clean it up, send it out. It worked. But it only ever had one opinion in it. Mine, filtered through one AI pass.

I started thinking about all the different people who actually read that report. My exec sponsor reads it one way. The chief of staff reads it a completely different way, prepping the exec to speak to it. A cross-functional partner skims it for exactly one thing: does this affect their team. None of them are reading it the same way I write it.

The AI Move

I already knew the trick of telling AI to "think as" a specific role. Most people use that one prompt at a time. I wanted all of them in the same room.

I added a step to my status report Gem called the Council Review Cycle. Five personas, each one built around a real reader of the report: the business partner, the executive, the chief of staff, a cross-functional stakeholder, the PMO. Each persona gets its own definition. What they actually care about. What they'd flag. What "good enough" looks like from their seat.

The instruction is simple in structure, even though the personas underneath it took real thought. Generate the draft. Have each persona review it independently and give a short take. Then have them debate the places where they disagree. Then synthesize a new draft that resolves what it can and makes the leftover tradeoffs explicit.

The Shift

The independent takes alone were useful. The debate is where it got interesting.

The business partner wants the report to explain why any of this matters to the business. The executive wants outcomes stated plainly, not just metrics. The PMO wants format and guardrails followed to the letter. Those aren't always compatible in the same three sentences. Watching the personas actually argue that out, instead of me trying to average five perspectives in my head, is where the report got better. Something a single pass would have missed just gets caught, because someone in the room is built specifically to catch it.

None of this required me to sit in the middle of it. I ran it, walked away, came back to a report that had already been fought over on my behalf.

The Pattern

The five personas I used are specific to status reporting. They're not the point. The point is the shape underneath them: generate, review independently, argue the disagreements, then synthesize. That structure doesn't care what the output is or who the reviewers are.

Most people using the "think as a specific role" trick run it one role at a time, one prompt at a time, then try to hold all those separate answers in their head and reconcile them themselves. This does that reconciliation as part of the process instead of leaving it for you to do after.

The Implication

Pick one output you produce on a recurring basis. Name the actual people who read it and judge it, not generic reviewer types. Define what each of them cares about and what they'd flag. Then ask AI to generate a draft, have each of those defined personas review it independently, debate where they disagree, and synthesize a revised version.

It doesn't need to be five. It could be two people who see the same document completely differently.

What I'm Testing Next

I built this for status reports because that's what I write regularly. I've started using this on other types of outputs such as an email to a wide audience, a plan I'm about to pitch, or a survey readout. I refining how the debate step works when the output isn't already following a strict format.

The Council Review Piece Prompt

This is the section I add into a broader status report prompt. Swap the personas for whoever actually reads and judges your own recurring output.

Council Review Cycle

Automatically run three rounds of review using the following personas. Each persona should evaluate the draft strictly from their own vantage point, not as a generic reviewer.

The Business Partner (Business Impact)
Cares about how this program affects the broader business, not the internal mechanics of the program itself. Reads for why this matters beyond the program: impact on strategy, customers, other teams, revenue, whatever the real stakes are. Flags any place where the report states a fact without connecting it to business impact. Standard for approval: someone with zero interest in the program's internals could still understand why any of it matters.

The Executive (Trust, Specificity, and Outcomes)
Wants numbers, dates, and owners, not characterizations. Distrusts hedge words like various, several, or in progress without a specific next milestone attached. Also wants outcomes named explicitly, not just metrics: what is this program actually producing, how do those outcomes move things forward, and how does it affect customers, other parts of the business, or whoever the real audience is. Flags any claim that isn't backed by a specific fact, and flags any point that reports activity without naming the outcome behind it. Standard for approval: every claim could be verified, and every major point connects to a stated outcome and its effect on the business.

The Chief of Staff (Executive's Lens, Prep Role)
Reads through the same lens as the Executive, outcomes, trust, specificity, but with the job of getting the exec ready to present it, not just consuming it. Flags anything unclear enough to generate a question the exec can't immediately answer, and anything where the outcome or business impact isn't stated plainly enough for the exec to repeat it without translating it first. Standard for approval: the exec could read this once and speak to it confidently, without notes.

The Cross-Functional Stakeholder (Dependencies)
Reads only for what affects their own team's work. Doesn't care about the program's internal health, cares whether a dependency, handoff, or blocker involving their group is clearly called out. Flags anything that implies cross-team work without naming which team, what's needed from them, or by when. Standard for approval: if their team's name should appear somewhere in this report, it does.

The PMO Lens (Format and Guardrails)
Checks the report against the standards the PMO has set. Verifies the format matches what's expected, the report is outcome-focused rather than activity-based, and any required sections or guidelines are actually followed. Also checks that health ratings match the empirical tolerances described in the data, and flags any place the roll-up logic breaks. Standard for approval: this report would pass a PMO audit on format and compliance, not just on the numbers.

Round 1, independent takes. Each persona reviews the draft in isolation and produces a short take, 100 to 150 words: what's working, what's missing, what concerns them, from their lens only.
Round 2, debate. Surface the points where personas disagree. Have them argue the tension directly, in character, until something resolves or the tradeoff is made explicit.
Round 3, synthesis. Produce a revised draft that incorporates the fixes the council agreed on, and explicitly resolves, or notes as an accepted tradeoff, anything still in tension.