How to write a decision update for your VP
Make an executive update useful in one read: say what decision is needed, show the trade-off, and make the requested action unmistakable.
A senior leader rarely needs every discussion that led to a product decision. They do need enough context to understand what is being recommended, what could go wrong, and whether the choice fits the goals they own. A good update makes that judgment possible without asking the reader to excavate a long thread or a crowded slide deck.
This structure works for an approval request, a decision already made, or an escalation where your team is blocked. It keeps the reasoning visible while leaving implementation detail available for follow-up. The central discipline is to state the decision and the action you need before explaining the history.
What decision does the VP need to make?
Write the decision as a direct question with a boundary. “Can we proceed with the enterprise launch if audit export ships in the next release?” is easier to answer than “We have been discussing the launch.” Include the decision owner and the date it is needed. If no approval is required, say whether you are informing the VP or asking them to resolve a conflict.
Do not bundle several unrelated approvals into one request. If the VP needs to choose a launch date and a staffing plan, present the questions separately and explain how they depend on one another. An executive can make a faster, more accountable choice when it is clear which options are open and which constraints the team is not proposing to revisit.
What is your recommendation?
State your preferred option near the beginning and give the reason in a sentence. A recommendation is not a promise that every risk has disappeared; it is the best-supported next step given the goal, evidence, and constraints. If you are not ready to recommend one, say what evidence or authority is missing and when you expect to have it.
Put the strongest alternative beside your recommendation. Explain why it remains plausible and what the team gives up by not choosing it. This shows that you considered the real trade-off rather than arranging the options so your preferred one looks inevitable. It also gives the VP a useful route to disagree: they can challenge the assumption or the value you prioritized.
Which evidence changes the choice?
Choose evidence that helps distinguish the alternatives. A customer interview may reveal whether a workaround is acceptable; a reliability test may show whether an incremental release is safe; a delivery estimate may expose a dependency hidden by the original plan. Name the source and date, and be honest about sample size or confidence when the evidence is thin.
Separate evidence from interpretation. “Three of five pilot teams could not complete the setup unaided” is an observation; “all enterprise customers will be blocked” is a broader conclusion. Tell the VP what you infer from the evidence and what could change that interpretation. A short explanation of uncertainty is more credible than decorating an estimate with precise-looking numbers.
Decision needed by Thursday: approve a staged enterprise launch without custom audit export, or hold the launch until export is ready. I recommend the staged option for the five pilot accounts; all can complete setup, while two need a manual export from our team. This protects the target date but adds about one support hour per account. We have not validated the workflow at higher volume. Please confirm the pilot boundary by 3 p.m. Thursday; if you prefer the hold, I will reset the customer plan and bring a revised date.
What risk and impact matter most?
Describe the downside in business and customer terms. Translate a technical dependency into its likely effect on adoption, support workload, revenue timing, or trust. Include the cost of waiting where it changes the choice. If the risk is limited to a particular segment, say so rather than implying every customer has the same exposure.
Show the mitigation and what it does not solve. A staged rollout may limit the number of affected accounts but will not remove an underlying data issue. A manual fallback may help a small pilot while increasing support effort. Leaders can set an appropriate risk boundary when they see both the failure mode and the limits of the proposed safeguard.
What action should the VP take next?
End with one observable request: approve an option, choose between two dates, connect you with an owner, or confirm that the team should proceed within a stated boundary. Add the deadline and the consequence of no decision only when they are real. If the VP needs a pre-read or another participant, make that explicit so the next step does not become another round of clarification.
If you are sharing a decision rather than requesting one, say what has already been decided, who owns delivery, and when you will report the next signal. This prevents an FYI from quietly becoming an approval request after the fact. It also gives a leader a clean way to raise a concern before teams have made further commitments.
How can you keep the update concise?
Use a short opening, a small comparison of options, and a final action line. Move technical detail, alternative scenarios, and raw research into an appendix or link, but leave enough evidence in the update to support the recommendation. If the reader must open five links to discover your point of view, the summary has not done its job.
Ask someone outside the project to read the note in under a minute and repeat the decision, recommendation, risk, and request. Revise whatever they miss. Save the final version with the evidence and assumptions that were available at the time. Lumo can help you preserve that reasoning and draft audience-specific updates without transferring responsibility for the judgment itself.