User, Buyer, Sponsor, and Affected Person Are Different Roles
User, Buyer, Sponsor, and Affected Person Are Different Roles
A presentation that describes one truthful change can be rebuilt into three different decks without altering a single fact. That sounds like spin. It isn't, as long as the differences track responsibility rather than flattery.
The distinction that matters is not between job titles but between relationships to this decision. Who does the work inside the tool? Who controls the money? Who has to defend the initiative when it's inconvenient? Who absorbs a changed routine without ever logging in? These are four different questions, and the answers decide which parts of the proposal each person is actually equipped to judge.
None of that guarantees agreement. It guarantees that a disagreement, when it comes, will be about the proposal rather than about two people who were shown different versions of it.
Define each role by the work of this decision
Four working questions are enough to start: who works with the change, who controls the purchase, who supports the initiative, whose work shifts. A person can answer more than one. A role can also be split across people, or sit for now with nobody.
Start with a fictional paper scenario, invented for this article and not drawn from any real organization. A regional facilities team of about twenty people, spread across four sites, currently handles shift swaps through a group chat and a shared spreadsheet. A scheduler named Dana reconciles the swaps each Friday. The team is considering a lightweight shift-request tool. Dana would use it daily. A finance manager controls a small annual software budget that is already spoken for. An operations director is the internal sponsor: she raised the idea and will have to defend it upward. Across the four sites, colleagues who cover the counter rotate among themselves whenever a swap is approved. Their cover arrangements change every time the schedule does, but those colleagues would never log into the tool.
Then take the ordinary way of planning the pitch: three slides, one per title. "For staff." "For finance." "For leadership." That mapping feels tidy and it collides with the scenario at once. The finance manager is not merely a budget holder here; she is also a weekend user of the app, because she takes shifts like everyone else. The scheduler and the sponsor are two different people but one argument, since the tool changes Dana's work and the director owns the decision. The covering colleagues amount to roughly a dozen people with no title on any of the three slides.
Put the two maps side by side.
Title-based map
- Staff → feature overview
- Finance → cost slide
- Leadership → benefits summary
Role-based map for this decision
- User (Dana, and the finance manager on weekends): the swap workflow
- Buyer (finance manager, budget authority): recurring cost and what would have to be reallocated
- Sponsor (operations director): the adoption argument she must carry upward
- Affected people (covering colleagues across the four sites): the changed cover routine
- Unconfirmed: who can authorize reallocation or additional funding, since the current budget is already committed
The second map contains the same people but assigns each a question rather than a label. It also names an open responsibility instead of distributing it by assumption. That unconfirmed signature is not a detail to smooth over at the back of a deck; it is the first thing to ask the sponsor.
Decide what each role actually needs to judge
The role tells you what a person is responsible for assessing. It does not tell you what will persuade them.
For the user, the judging question is whether the tool fits the actual swap routine: request, approval, cover confirmation, Friday reconciliation. The relevant evidence is a walkthrough of that sequence and an honest account of where it's clumsy. Dana's assessment will likely concern her Tuesday-afternoon workload, not the annual fee. That's a hypothesis about what Dana cares about, not a finding — nobody has spoken to her about this.
For the buyer, the question is narrower: does this fit the existing budget line, and if not, what would have to give? The evidence here is cost, term, and the boundary of the current envelope. The buyer does not need the interface tour, and the finance manager, who is also a weekend user, needs both views in one meeting rather than two decks that she has to reconcile herself.
For the sponsor, the question is what she can say when the proposal is challenged upstairs. That makes the limitations the most important slides, not the least. If the tool can't handle cross-site swaps in the first version, the operations director needs that sentence before someone else says it to her boss.
For affected people, the question isn't whether to adopt the tool at all. It's what their Wednesday looks like afterward: who asks whom for cover, how late a change can arrive, what happens when two people need the same favor. They judge the changed routine on its own terms, not the software's.
One caution about this list. It defines what each person must decide; it leaves open what they want. Where the proposal is presented as a case to win, every role tends to get the same confident summary in different fonts. The questions above resist that.
Trace the change past the login screen
The covering colleagues are the reason this article exists. They gain no account, take no training, and never appear in usage metrics. Their burden is real: every approved swap redistributes cover among them, and an opened-up scheduling tool could increase how often that redistribution happens. The proposal is honest only if the shared account says so.
Concretely, that means one line in every version of the proposal: swaps currently average a certain number per week per site[^1]; if adoption reduces the friction of requesting one, that number could rise, and every increase lands on the covering group first. Whether the number rises is unknown. That the covering group absorbs the first effect is not.
[^1]: The paper scenario deliberately does not fix this number; it would come from the team's own records, not from this article.
Three temptations follow the affected role around. The first is predicting their stance — "they'll probably welcome it" — when nobody has asked. The second is speaking for them: writing their concerns into the deck as a slide rather than bringing them to the table. The third is treating their concern as an objection to route around, which turns a scheduling change into a trust problem. The reliable move is to name the consequence, mark the unknown response, and let the sponsor decide who talks to them and when.
Affected people also sit elsewhere than the org chart suggests. Whoever maintains the spreadsheet Dana stops using, whoever fields the cover calls, whoever reconciles hours for payroll — none of them are users, and all of them may notice the change. Tracing the workflow end to end finds them faster than tracing the reporting lines.
Hold the facts still while the explanation changes
Adapting a proposal for different roles has one hard rule: the product state, the limitations, and the scope stay identical. Only order, emphasis, and the depth of detail may change. If the limitations vary between rooms, the proposal has stopped being one proposal, and the next meeting between two roles will discover it.
Here is the same paper scenario, same facts, expressed three ways.
User version — order: routine, then limits.
For same-site swaps, requests move from the group chat to the tool: one person requests, the other accepts, and the schedule updates after cover is confirmed. Friday review moves to a screen for those requests; no time saving or reduction in dropped requests has been established. Cross-site swaps keep the current process. Covering colleagues still arrange cover outside the tool, and easier requests could increase that work; their response is unknown. Purchase also remains unresolved: the existing budget is committed, and reallocation or added funding needs an approver.
Buyer version — order: cost, boundary, then limits.
The existing software budget is already committed. We need the recurring cost and an identified authority for reallocation or additional funding before calling this affordable. The tool would handle same-site requests and give Dana a Friday review screen; cross-site swaps retain the current process. No time saving or reduction in dropped requests has been established. Cover remains arranged outside the tool, and easier requests could increase that work for colleagues who will not log in. Their response is unknown.
Sponsor version — order: argument, exposure, then limits.
The proposed case to investigate is whether a review screen for same-site requests improves Dana's Friday work. Neither time savings nor fewer dropped requests has been demonstrated. Cross-site swaps keep the current process; future support is not promised. Covering colleagues still arrange cover outside the tool, and easier requests could increase their workload. Their response is unknown, so that conversation belongs before a recommendation to adopt. The budget is already committed; authority for reallocation or added funding also remains unconfirmed.
Read the three side by side and check for drift. The cross-site limitation appears in all three. The cover group appears in all three — briefly for the user, more fully for the buyer, front and center for the sponsor. No version contains a benefit the others lack. What changes is the first sentence each reader needs and how much room the limitation gets.
That's the whole technique, and it's harder than it sounds because the pressure at each meeting runs toward trimming the inconvenient line. The sponsor's version is the test case. A concise sponsor argument that hides the cover-group consequence would move the adoption forward and set up the person who has to explain it later. The honesty isn't an ethical garnish; it's the version that survives the second meeting.
Confirm the map before building the next artifact
The map retains a funding hole: who can authorize a reallocation or additional spend? A price could be known while permission to fund it remains unresolved. The spend slide needs to show both.
So the paper exercise ends where real work begins. Ask the sponsor who can authorize funding, how covering colleagues will be heard, and what those people already know. Ask the buyer what could be reallocated and which recurring costs would remain. Ask Dana whether the proposed Friday screen actually fits her work. No customer conversations, stakeholder opinions, or research findings back this scenario; these questions remain questions.
The map will change. The finance manager's dual role may split into two separate conversations if her time is short. The covering group may turn out to have a natural representative already. Someone who looked affected may say the change costs them nothing. Update the map when that happens, and update the proposal's facts at the same time, in every version, so the next reader isn't working from a stale sheet.
What the map still won't do is produce agreement. A buyer can accept the cost view and still say no. The covering colleagues can understand the consequence exactly as described and still object to it. The point of distinguishing roles is not to find the combination of evidence that closes every question; it's to make sure that when someone says yes or no, they're answering the question that was actually theirs.
Frequently asked questions
What defines the four roles in a decision?
They are defined by relationship to the decision, not by job title: who works with the change, who controls the purchase, who supports the initiative, and whose work shifts. One person can hold more than one role, a role can be split across people, or it can sit with nobody.
Why can the same facts support different versions of a proposal without that being spin?
Because differences can track responsibility rather than flattery. The product state, limitations, and scope stay identical; only order, emphasis, and depth of detail change. A limitation should not appear in one room and vanish in another.
What should be said about people affected who never log in?
Their burden is real even if they gain no account, take no training, and never appear in usage metrics. In the invented facilities scenario, every approved swap redistributes cover among covering colleagues, and easier requests could increase that redistribution. Whether the number rises is unknown; that the covering group absorbs the first effect is stated as not unknown. Name the consequence, mark the unknown response, and let the sponsor decide who talks to them and when.
What is unresolved in the funding part of the facilities scenario?
The finance manager controls a budget that is already committed, and who can authorize reallocation or additional funding is unconfirmed. A price could be known while permission to fund it remains unresolved, so the spend slide needs to show both.
Does a role-based map guarantee agreement?
No. A buyer can accept the cost view and still say no, and affected people can understand the consequence exactly as described and still object. The point is to make sure a yes or no answers the question that was actually theirs.