--- name: executive-communication description: Create a compelling FDE engagement deck, solution walkthrough, executive decision memo or technical narrative. Turn substantive analysis into a clear point of view and an artifact the audience can use. license: MIT --- # Executive communication Make the opportunity, solution or decision intelligible to the people who must act on it. Start with the audience's working question and the substance of the analysis. A strong artifact lets them understand something they could not see before and make a better choice. ## Build a point of view Identify the finding or proposal that changes the conversation. Explain its mechanism: what constrains the current operation, what would change, why that creates value and what makes the proposed approach credible. For a deployment decision, connect observed behavior and operating economics to the scope worth committing to. For an opening conversation, give the audience a specific thesis and a useful way to challenge it. Resolve the consequential inference before improving its wording. A shorter preparation task does not establish lower total operating cost; a working prototype does not establish a supported service; an estimate does not establish a commitment. Trace the claim to the work and evidence that would make it true. Where that substance is missing, develop the analysis or narrow the claim while preserving a useful recommendation. For a worked example spanning a sponsor memo, exhibits and an opening conversation, see [from deployment evidence to a decision](references/evidence-to-decision.md). Develop the strongest reasonable objection. A sponsor may question whether the service creates demand; the technology leader may see an unsupported operating burden; the business team may see more review work. Address the objection through the design and evidence that matter, rather than appending a generic risk slide. If the objection changes the recommendation, change the recommendation. Show ambition and an executable path together. An enterprise vision without a first deployment is difficult to fund; a small pilot without a larger mechanism is easy to ignore. Explain how the first commitment tests or delivers the distinctive capability and what it makes possible next. For a continuing engagement, lead with what changed and the decision it creates. Reconcile the message with the current design, customer commitments and delivery forecast. Distinguish demonstrated behavior from planned capability, an implementer's estimate from an agreed date, and a recommendation from a customer commitment. Present a threatened outcome with feasible choices and a recommendation; a reassuring status label does not resolve the tradeoff. ## Choose exhibits that explain the work Use a real operating episode or a clearly introduced illustrative one to make the concept tangible. Show the decision that changes, the information needed, the action produced and what the receiving team does. A product walkthrough can make a new capability understandable faster than a page of benefits. Select visual forms for the argument. A current-to-target service flow can expose a disappearing handoff. An architecture view can show which existing systems retain authority and where the new intelligence operates. A sequence can reveal waiting, revision and asynchronous work. A comparison can make an investment tradeoff visible. A measured distribution or unit-economic model can explain when scaling becomes attractive. Choose the few exhibits that carry this particular story; do not repeat the same text-card layout for every idea. Keep technical depth available at the right level. Executives need to understand why the architecture and operating model are credible, not every endpoint. Engineers need enough precision to challenge and build the design. A technical appendix, linked design or speaker notes can serve that second audience without turning the main narrative into a specification. ## Write for the room Use natural, specific business language. State what you recommend and why. Explain the tradeoff being accepted, the commitment required and what could change the decision. Avoid generic claims about transformation, lists of AI benefits and headings that merely announce topics when a finding would be more useful. Keep bookkeeping out of the story. Internal source, evidence, requirement and decision identifiers belong in working records when needed; they are rarely useful slide text. Cite source names naturally and put detailed locators in notes or backup. State the status of a training scenario once where it is clear. Qualify material estimates and claims at the point of use, rather than covering the artifact in repeated caveats and labels. Do not flatten a proposal into uncertainty simply because it has not been approved. “We recommend starting with remote diagnosis and parts commitment for one equipment family” is a useful recommendation. The funding decision can remain open without adding “proposed” to every sentence. Preserve commitments already made and make the new decision explicit. ## Produce the artifact Follow the requested format and discover the relevant authoring capabilities available in the host. Use native editable objects for the work readers will change. Build the full presentation, memo, walkthrough or interactive explanation when tools permit; an outline is an intermediate step when the user asked for a finished artifact. Establish a visual direction suited to the customer and context. Use hierarchy, composition and explanatory graphics to make the argument clear. Restraint still needs deliberate design: changing a font and removing decoration does not make a weak exhibit sophisticated. Respect an existing client template while improving the story and analysis within it. Inspect the finished result in the form the audience will use. Look at the whole sequence as well as individual pages: whether each exhibit earns its place, the argument develops, the mechanism is understandable and the decision follows. Check substantive figures, legibility, overlap and editable behavior where supported. Rendering without errors establishes only that the file renders. Deliver the usable artifact with a short explanation of its purpose and any material delivery limitation. Keep authoring commentary and validation logs out of the customer-facing work.