In this article
- Build persuasive presentations around a fair comparison
- Describe the current problem precisely
- Make the future observable
- Put the transition in the middle
- Compare alternatives honestly
- Use contrast without manufacturing emotion
- Use scenarios without presenting them as forecasts
- Close with the smallest useful decision
The contrast should help people judge a proposal. It should not exaggerate today's difficulties or paint tomorrow as effortless. A realistic transition can be more convincing than an idealised destination.
Build persuasive presentations around a fair comparison
Duarte describes using contrast between the current state and a possible future. The workplace challenge is making both sides accurate enough for a decision.
Define the current state using evidence the audience can inspect. Then describe the proposed state in terms of observable changes, not adjectives such as seamless or world-class.
Use the same criteria on both sides. Comparing today's actual problems with tomorrow's best imaginable outcomes creates a misleading contrast.
Include a credible no-change option. Sometimes improving the existing approach is more sensible than introducing a new one.
Describe the current problem precisely
Name who experiences the problem, when it occurs and what it prevents. Distinguish an occasional inconvenience from a recurring constraint.
A proposal about reporting might concern inconsistent category definitions, not “a broken reporting culture.” Narrow wording makes the solution easier to evaluate.
If the evidence is incomplete, say what is known and what still needs checking. A request to investigate can be persuasive without pretending the diagnosis is finished.
Avoid attaching blame unless individual conduct is genuinely relevant and appropriately established. Most process proposals benefit from explaining the mechanism rather than identifying a villain.
Make the future observable
Hypothetical example: A team wants one shared intake form for requests arriving through several channels.
The current state: requests arrive without a consistent owner, required date or description of the problem. The proposed state: each request contains those fields before it enters the review queue.
The benefit is not automatically “higher productivity.” The immediate intended improvement is that reviewers can identify incomplete requests and assign responsibility consistently.
A good presentation distinguishes that direct change from later outcomes that need testing. Faster completion, fewer escalations or better customer satisfaction may be hypotheses rather than established benefits.
Put the transition in the middle
The transition is where many persuasive presentations become vague. Explain what people must stop, start or learn.
Include who will maintain the new form, how old channels will be handled, what happens to urgent exceptions and when the approach will be reviewed.
Show the effort required during the change. A system may be worthwhile while still creating temporary duplication or training needs.
| Transition question | Why it matters |
|---|---|
| Who owns the change? | Prevents shared responsibility from becoming nobody's task |
| What will be trialled? | Keeps the proposal proportionate |
| What support is required? | Makes hidden work visible |
| What would stop the trial? | Protects against continuing a poor approach |
| How will feedback be used? | Gives users a meaningful role |
Compare alternatives honestly
Present the strongest reasonable alternative to your preferred option. It might be a revised checklist, clearer ownership or a smaller pilot.
Use common criteria: effort, risk, usability, reversibility and relevance to the problem. Avoid selecting criteria only after choosing a winner.
If a competing approach performs better on an important criterion, acknowledge it. Explain why you still prefer your recommendation or revise the recommendation.
A fair comparison signals that the audience is being asked to judge, not simply endorse.
Use contrast without manufacturing emotion
You can make consequences concrete by describing the work a person currently repeats or the decision they cannot make. You do not need to invent frustration, fear or relief.
Keep examples representative. One difficult case can illustrate a problem but cannot establish its frequency.
If the proposed future depends on assumptions, place those assumptions near the benefit claim. Do not hide them in a final disclaimer.
For numerical scenarios, label estimates and show the basis. A forecast should remain distinguishable from a measured result.
Use scenarios without presenting them as forecasts
A possible future can be illustrated through a scenario, but label it clearly. Explain the assumptions and avoid suggesting that the scenario is the expected result unless you have a defensible basis.
Prepare a less favourable version as well. Ask what happens if uptake is slower, implementation takes longer or the benefit is smaller than hoped.
This does not require a complicated model for every proposal. A short explanation of the main dependency may be sufficient.
If the recommendation is sensible only under the most optimistic scenario, reconsider its scope or propose a smaller test.
Keep the scenario separate from measured results in both wording and visuals. A reader should not have to inspect a footnote to discover that tomorrow's improvement is hypothetical rather than observed.
Close with the smallest useful decision
Ask for the commitment needed at this stage. That may be permission to investigate, a limited trial or agreement on evaluation criteria.
A broad transformation request can overwhelm an audience when a reversible test would answer the main uncertainty.
Explore Storify and storytelling in presentations for more presentation guidance. Storytelling in meetings can help you frame a shorter approval discussion.
Before your next presentation, make a three-column outline: current condition, proposed condition and transition. If the middle is empty, the proposal is not ready for persuasive delivery yet.
AI-assisted researched guidance from PeakBelt. Hypothetical examples are labelled in the text. See our editorial approach.