Every CS team has a priority problem that is not really a priority problem. Ask five people what matters most this quarter and you will get five honest answers: the CSM drowning in renewals says save plays, the product manager says the roadmap, the sales leader says expansion, support says the bug backlog, and the exec sponsor says the strategic account that just went quiet. None of them are wrong. That is the problem.
Without a single place where those claims get weighed against each other, priorities get decided by whoever shouts loudest or escalated last. The result is familiar: a team pulled in six directions, a roadmap full of exceptions, and resentment every time one group's urgent item bumps another's planned work.
A prioritization council fixes that. It is one monthly meeting, 45 minutes, with one job: decide what the CS and revenue org will focus on next, in what order, and what will explicitly wait. It does not replace your frameworks โ the RICE scores, tier models, and cost-of-delay math from earlier in this series all feed into it. A score without a forum is just a spreadsheet. A forum without scores is just an argument.
What the council actually decides
Keep the mandate narrow or the meeting will balloon. The council decides three things, and only three things:
1. The ranked list. What are the top five to eight initiatives, plays, or asks the team will staff this month? Not twenty. Not "everything is P1." Five to eight forces real trade-offs, and trade-offs are the whole point.
2. The explicit deferrals. What are we choosing not to do, and until when? A deferral with a review date is a decision. A deferral with no date is a slow death by neglect, and it breeds exactly the shadow lobbying the council exists to kill. Write it down: "Deferred until the December council, pending the renewal data."
3. The owner and the deadline. Every ranked item leaves the room with one named owner and one date. Shared ownership is no ownership. If an item cannot get an owner in the room, it does not make the list.
Who sits at the table
Seven people is the sweet spot. Fewer and you miss a perspective that will ambush the decision later; more and the meeting becomes a presentation.
CS leadership (1โ2 seats). The CS director or VP chairs the meeting. They own the agenda and the final call when the room deadlocks, but they should not dominate the discussion โ a chair who always wins is running a briefing, not a council.
A frontline CSM. Not a manager speaking on behalf of CSMs โ a working CSM, rotating quarterly. They are the only person in the room who can say, in plain terms, what a proposed priority actually costs on a Tuesday afternoon. Rotate the seat so it does not become a second management voice.
Product (1 seat). Product brings the roadmap reality: what is actually buildable, what is already committed, and what customer asks are duplicates of work already planned. Without product in the room, the council produces a wish list.
Sales or revenue leadership (1 seat). Expansion and new-business priorities live here, and they need to be weighed in the open against retention work rather than negotiated in hallway conversations after the meeting.
Support or operations (1 seat). Support sees which issues actually cost renewals, versus which are just loud. Ops brings the data โ health scores, usage trends, renewal dates โ so the room argues about numbers, not anecdotes.
One rotating guest seat. Finance, marketing, an exec sponsor, whoever owns the month's thorniest item. It keeps the council from becoming a closed club, and gives other teams a legitimate way in, which stops them going around it.
The 45-minute agenda that actually works
Run the same agenda every month โ predictability lets people prepare, and preparation keeps the meeting short.
Minutes 0โ5: Review last month's list. What got done, what slipped, and why. No new discussion yet. If an item slipped twice, it gets a direct question: is it still a priority, or are we keeping it on the list out of guilt? Kill it or re-commit to it, in the room.
Minutes 5โ15: The data snapshot. Ops walks through five numbers, no more: renewals at risk this quarter, expansion pipeline, top support themes, health-score movers, and progress on the current top initiatives. Ten minutes, charts only, no storytelling. The point is a shared picture of reality before anyone advocates for anything.
Minutes 15โ35: The ranked debate. This is the core. Each proposed item gets two minutes: the proposer states the ask, the customer outcome, and the cost of delay, using the frameworks this series has covered. Then the room scores it โ openly, on the same criteria every month. A simple version works: customer outcome value, revenue at risk or opportunity, effort, and reversibility. Score it live, in a shared doc everyone can see. Visible scoring kills backroom deals because the reasoning is on the screen.
Minutes 35โ42: Decide and assign. The chair reads back the ranked list, the deferrals, and the owners. Anyone who disagrees says so now, not in a Slack message tomorrow. Disagreement in the room is productive; disagreement after the room has emptied is sabotage.
Minutes 42โ45: Publish it. The list goes out the same day, to the whole org, in one message: what we are doing, what we are deferring, who owns what. If the decision is not written down and shared, it did not happen โ it just becomes another meeting people vaguely remember differently.
The rules that keep it honest
A council without rules becomes a rubber stamp for whoever has the most political capital. Four rules prevent that.
Rule one: no item without data. Every proposal arrives with a one-paragraph brief: the customer outcome, the revenue at stake, the effort estimate, and the evidence. "A big customer asked for it" is not evidence. Which customer, how much ARR, what happens if we say no โ those are evidence. If the brief is missing, the item waits until next month. This sounds harsh. It is the rule that makes the meeting work, because it forces proposers to do the thinking before they take up the room's time.
Rule two: one escalation channel. Between meetings, urgent items go through the chair, not around the council. The chair can approve a genuine emergency swap โ a save play for a top-tier account at risk, for example โ but must report it at the next meeting, with the item it displaced. Emergencies happen. Unreported emergencies are just the old system with a new name.
Rule three: the deferral list is public. This is the hardest rule and the most important. Teams that only publish what they are doing, and quietly bury what they deferred, invite every deferred stakeholder to lobby privately. Publish the deferrals with their review dates, and lobbying drops, because there is a legitimate next date to wait for.
Rule four: review the council itself quarterly. Spend 15 minutes asking: are the right people in the room, is the scoring still honest, are decisions sticking? A council that never examines itself becomes the bureaucracy it replaced.
How to start: the first meeting
Do not announce a grand new governance body. Book the first meeting as a one-off: "Let's rank next month's CS priorities together, 45 minutes." Score openly. Publish the list the same day.
The test in the following two weeks is whether anyone tries to get an item done by going around it โ and whether the chair holds the line: "Great ask. Bring it to the council, with the brief." The first time that works, the council exists. By the third month, the priority fights do not disappear โ but they happen in the room, on the record, with data, and they end with a decision everyone saw.
That is the real payoff: an end to the invisible priority system, where work got assigned by volume, recency, and org politics. A council replaces it with a process, a date, and a list everyone can read โ something a team can trust even when they disagree with a specific call.
Book 45 minutes, bring the data, decide in the open.
Tomorrow: Measuring What Matters: New KPIs for AI-Augmented Revenue Teams โ beyond NRR, the metrics that actually capture leverage.
