Build an Internal Decision Deck Around the Choice That Is Still Open
Build an Internal Decision Deck Around the Choice That Is Still Open
The deck is finished. Fourteen slides: a timeline of the discovery quarter, a summary of eleven interviews, photographs of a workshop wall, a list of what we learned. Then, near the end, someone asks the question the room has been circling for forty minutes.
So what are we deciding today?
Nobody is being difficult. The deck was built as a record of work, and a record of work is not a proposal. It answers what have you been doing when the meeting needed what can we still change, and who can change it.
The instinct behind the timeline is understandable. The work was real, it was expensive, and it would be strange to present a decision without showing how you arrived at it. But effort is not evidence about a choice. Eleven interviews can be genuine and still leave the room unable to say whether the next quarter should go one way or another. The chronology tells them you are serious. It does not tell them what to do.
So the deck's structure should come from the open choice. That sounds obvious written down and is surprisingly hard to hold once a project has thirty slides of accumulated material. The rest of this article works through a fictional example in enough detail to make the shape concrete.
Name the live choice and its decision owner
There are two sentences to complete before you build anything.
The room is being asked whether ___.
___ is the person who can decide it.
If you can only complete the first as "the room is being updated on," you have an update, and calling it a decision deck will make the meeting worse. If you cannot complete the second at all, you have found the real problem — and it is not a slide problem. A deck with an unidentified decision owner is a deck that will circulate, produce polite feedback, and change nothing.
It helps to sort the presentation you are actually writing into one of four kinds, because they need different structures:
- An update informs. Nothing is being asked.
- A decision request asks someone to choose between routes.
- An implementation review asks how to execute a choice already made.
- An endorsement request wants a room to bless something that is effectively settled.
Only the second is a decision deck. The fourth is common and rarely labeled honestly. If the choice has already been made elsewhere and the meeting is for the record, say so on the slide. Rooms forgive that. They do not forgive being walked through a comparison whose ending was fixed before the meeting started.
Authority is the part people skip. Name the person and name the boundary around what they can actually authorize — not the org chart in general, just the edge of this decision. Someone who owns a team can commit that team's time. Someone who owns a budget can commit money. Someone who owns neither can still recommend, and recommending is a real contribution, but it is not the same as deciding, and the deck should not blur the difference to make the ask feel bigger.
Here is the fictional example. A 250-person US software company, which I will call Wrenfield, receives customer requests through four routes: support, professional services, the sales team, and a form the product team runs for itself. Each route keeps its own list. People in the product team say the same request sometimes arrives twice, and that they cannot tell which requests are widespread.
Notice the verb. They say. Nobody has counted.
The decision owner for this exercise is the vice president of customer operations, who owns support and professional services. She can commit staff time in those two teams. She does not own sales or product, and she cannot authorize spending beyond the tool subscriptions her teams already hold.
The live choice: whether support and professional services run a single shared intake queue for one quarter.
Frame a recommendation against credible alternatives
A decision deck needs at least two routes the decision-maker could reasonably take. Not one route and a formality.
The test for whether your alternative is real: could a reasonable person in that room argue for it out loud, using your slide? If the alternative has no owner, no reason, and no consequences written down, it is a straw man, and the recommendation it flatters is weaker for it. A favored option that gets nine slides against two bullet points of vague doubt does not persuade anyone who was paying attention. It persuades the people who already agreed.
"Continue as we are" and "wait" are genuine options when they are genuine — when someone is currently doing the work, when waiting has a real trigger, when the status quo is tolerable. They are not genuine when they would quietly mean nobody does the work.
It is worth knowing that public options-comparison frameworks exist. The UK's HM Treasury publishes a route to guidance on developing business cases, at gov.uk. Only the landing page was seen, not the guidance behind it, so treat it as a pointer to the idea that routes get compared on stated criteria rather than as a template to import — and UK public-sector approval rules do not govern a fictional US software company anyway.
At Wrenfield, three routes are on the table.
Route A — a two-team pilot, one quarter. Support and professional services share one queue, one intake form with a common field set, and a weekly thirty-minute triage meeting. Each team supplies one triage owner for about two hours a week.
Assumptions: the two teams' request categories can be reconciled within the first two weeks; the shared queue runs inside a tool the company already licenses; the two hours a week comes out of existing work rather than added capacity, which means something else in those weeks gets less attention. The comparison baseline is last quarter's local records, which use each team's own categories — so the before-and-after comparison is approximate, and the deck should say so rather than let the numbers imply a precision they do not have.
What it would show: whether a shared queue changes how quickly a request gets an owner, and whether duplicates between those two teams become visible. What it would not show: anything about sales requests, anything about the product team's own intake, anything about customers' experience or the roadmap. Reversibility: high. It ends at the quarter boundary and no process change survives it.
Route B — shared fields, no shared queue. Both teams keep their own lists but adopt the same field set this quarter.
Assumptions: teams keep the fields consistent without a shared view to enforce it; the fields can be agreed in a week. What it would show: comparable records, which would make a later decision better informed. What it would not show: whether sharing a queue changes ownership or surfaces duplicates — the thing Route A is designed to test. Cost: lower. No new meeting, less disruption.
Route C — defer one quarter. Including sales in the queue would require sales request records to be visible outside the CRM, either as a weekly export or by manual re-entry. Sales operations has been asked whether the CRM can produce that export on the current plan. No answer yet. Deferral means waiting for it and then deciding on a three-team pilot.
Assumptions: the answer arrives in time; the next planning window is still open; and — the assumption that does the most work — sales-side visibility is material to the question. Cost: a quarter with no change, and the risk that the question loses its moment when the quarterly cycle turns over.
The interesting part is what the sales-ops answer would actually change, and there are two possibilities that look alike and are not.
If the answer only determines whether sales joins later, then it does not gate the two-team pilot at all. Start now; absorb a third team later if the answer is yes.
If the answer would change the field set or the routing rules — because sales request data has a different structure that would force different fields — then starting now means rebuilding the setup mid-quarter, and the case for waiting gets real teeth.
Which one it is depends on a schema question nobody has asked yet, which is a much narrower question than "can you export." That distinction is worth a slide of its own.
Select evidence that can change the choice
The organizing rule: attach each fact, assumption, and uncertainty to the option it affects. A general background section collects material and attaches it to nothing, which is why so many decks have a strong evidence section that moves nobody.
Label the status of every claim. Three labels are enough: observed (we counted it or read it), forecast (we expect it, and here is the basis), judgment (someone with relevant experience thinks so). Most decks blend the three into one confident voice and then wonder why the room argues about the wrong slide. The argument usually starts because a judgment was written in the grammar of a measurement.
Then there is the effort trap. At Wrenfield, the discovery quarter produced four workshops, eleven interviews, and three vendor demos. None of that answers whether to pilot a shared queue. It establishes that the problem was investigated. That is worth one line and an appendix, not a third of the deck.
The motivating claim deserves similar care. "The same request sometimes reaches two teams" is a report from the people closest to the work. It is not a count, and nobody has produced one. You have two honest choices. You can label it as a report and refuse to lean on it as a measurement. Or you can convert it into a count cheaply — in this case, a half day comparing last quarter's support and professional services lists for repeated customer names, with the limits stated: the two teams categorize differently, and matching on customer name will miss duplicates logged under different names.
That half-day check is worth naming because it does something a pilot cannot do quickly: it tests whether the problem exists at all. It is not a substitute for Route A, because it says nothing about ownership or timing. It is a cheaper answer to a narrower question, and offering the room a cheaper narrow question is often better than insisting the only options are a quarter-long pilot or nothing.
Finally, if a missing piece of information could reverse your recommendation, say so on the slide and say whether it is worth delaying for. Naming the thing that would change your mind is not weakness. It is the difference between a recommendation and a sales pitch, and it gives the room something to test you against.
Make the consequence of the decision explicit
For each route, the deck should state what it permits, what it does not permit, and what still needs a separate decision. That third clause is where decks get ambitious and lose their shape.
At Wrenfield, the vice president can authorize a support-and-services pilot. She cannot authorize sales participation. She cannot authorize new tool spending if the existing-licence assumption turns out to be false. If the deck asks the room to "approve a shared intake process," it has asked for something larger than anyone in the room can grant, and the meeting will either stall or produce a false yes that dissolves three weeks later.
Keep risks next to the option they belong to, with a name attached. A general risks slide at the end — five bullets, no owner, hedging everything and nothing — is a way of appearing thorough while making every route feel equally dangerous. The risk belongs in Route A's paragraph, where someone can respond to it.
Watch for scope creep through implementation detail. Which tool, which fields, who runs the triage meeting, what the escalation path looks like — these are real questions and they do not belong in the ask. The meeting decides whether to pilot. The pilot owner decides the fields within stated bounds. A deck that asks a room of executives to settle the meeting cadence has quietly expanded from one decision into six and will get a less useful answer to all of them.
Close with an answerable request
End with something a specific person can actually do. There are three shapes:
- A decision: proceed with Route A for one quarter.
- For a named piece of information first: the sales-ops schema answer, back within two weeks.
- For a bounded next investigation: the half-day duplicate check, before the next meeting.
All three are legitimate. What does not work is a request that needs the room to invent its own ending.
At Wrenfield, the exact scope of the proposed authorization is: the vice president decides whether support and professional services run a shared intake queue for one quarter, using the field set published before the pilot starts, with two named triage owners committing roughly two hours a week each. Not decided, and explicitly listed as not decided: whether sales joins; whether the shared queue becomes permanent; any tooling cost beyond existing subscriptions; anything about the product roadmap.
A "next steps" slide needs the same discipline. Do not assign work to people who have not accepted it. Distinguish proposed follow-through from a confirmed decision record, and write down what remains undecided rather than implying that a successful presentation settled every downstream question. If the room's answer is "circulate a plan," that is not a decision to proceed, and recording it as one will cost you credibility the next time you ask.
Deferral is a perfectly responsible recommendation — with a trigger. "Revisit when sales operations replies or at the next planning meeting, whichever comes first" is a real decision. A deferral with no date and no trigger is a quiet discard wearing a suit.
A decision deck is finished when a person with the authority to choose can read one sentence and say yes, say no, or say exactly what they need to know first. Everything else in the deck exists to make that one sentence fair — the alternatives honest, the evidence labeled, the consequences on the table, and the boundary of the ask drawn where the authority actually ends. Recommending, deciding, and authorizing dependent work are three different acts. A deck that keeps them apart on the title slide will still keep them apart on the last one.
Frequently asked questions
How do I tell whether I am building a decision deck or just an update?
Complete two sentences: the room is being asked whether something, and a named person can decide it. If the best you can say is that the room is being updated on something, you have an update. A deck with no identified decision owner will circulate, gather polite feedback, and change nothing.
Why not organise the deck around the discovery timeline?
Effort is not evidence about a choice. A timeline of interviews, workshops, and demos shows that the problem was investigated, but it does not tell the room what can still change, who can change it, or which route to take. That material usually belongs in one line and an appendix.
What makes an alternative route credible rather than a straw man?
A reasonable person in the room should be able to argue for it using your slide. It needs an owner, a reason, and consequences written down. Continue as we are and wait are genuine options only when they are real, not when they quietly mean nobody does the work.
How should evidence be labelled in a decision deck?
Use three labels: observed, forecast, and judgment. Attach each fact, assumption, and uncertainty to the option it affects. Most decks blend these into one confident voice, so the room argues about the wrong slide, often because a judgment was written in the grammar of a measurement.
What should the closing request look like?
End with something a specific person can actually do: a decision, a named piece of information, or a bounded next investigation. State the exact scope of the authorisation and list what is explicitly not decided. Do not assign work to people who have not accepted it, and make any deferral include a date or trigger.