Writing for decision-makers: how busy executives actually read proposals
Most business cases are not read — they are skimmed. A senior decision-maker may give your document a few minutes between meetings, scanning the summary, glancing at the numbers, and looking for reasons to say yes or no. This is not disrespect; it is triage. Your job is to make that skim land correctly.
Lead with the answer, not the journey
The most important structural choice in a business case is putting the conclusion first. Your executive summary should answer four questions in order:
- What are you asking for?
- What problem does it solve, or what opportunity does it capture?
- What does it cost, and what is the expected return?
- What is your recommendation?
Chronological storytelling — "first we noticed X, then we investigated Y, then we considered Z" — buries the decision. Executives decide on the answer; the journey is evidence, and evidence belongs in the body.
Make every section scannable
Use short paragraphs, descriptive headings, and bullet points for anything list-like. Each section should open with its key point in the first sentence, so a reader who reads only the first lines still gets the argument. Long, dense paragraphs are where proposals go to die — they signal "this will take effort" and get skipped.
Know what your approver actually cares about
Different decision-makers weigh different things. A CFO cares about cost, payback period, and financial risk. An operations leader cares about disruption, capacity, and whether the team can actually deliver. A CEO cares about strategy, competitive position, and whether this is the right priority right now. If you can, tailor the emphasis — not the facts — to the reader. The same case can lead with financials for finance and with operational impact for operations, as long as both versions contain the full picture.
Be specific about the ask
Vague asks get vague answers — usually "let's revisit this later." State exactly what you need: the amount, the headcount, the timeline, and the decision. "We are requesting approval for a budget of $X and two team members for eight weeks, starting in Q2" is a decision. "We would like to explore upgrading our tooling" is a conversation. If there are conditional asks — approval now, with a checkpoint before phase two — say so explicitly.
Use plain language
Jargon, acronyms, and technical detail slow a reader down and create the suspicion that complexity is hiding something. Write as if explaining to a smart person outside your department — because that is often exactly who is reading. If a technical term is unavoidable, define it once in plain words. Save the deep technical detail for the appendix, where the specialists who want it can find it.
Anticipate the objections
Before submitting, list the three toughest questions your approver could ask: "Why now?", "What if it fails?", "Why not the cheaper option?" If your document already answers them, objections become confirmations. If it does not, the approver will ask them in the meeting — where you are on the spot. Addressing objections in writing also signals confidence: you are not hiding from the hard questions.
Respect the format they already use
Many organizations have a standard template, a preferred length, or an unwritten norm ("the CFO only reads the first page"). Find out what it is and follow it. A brilliant case in the wrong format creates friction; a good case in the expected format sails through. If no template exists, the section structure in our anatomy guide is a safe default.
The two-minute test
Before you send it, give your case to a colleague for two minutes — then take it back and ask: what am I asking for, what does it cost, and what do you recommend? If they can answer all three, the case is ready. If they cannot, the summary needs work. This test takes ten minutes and catches more problems than a week of polishing prose.