Technical Presentation
What it is
A technical presentation puts work or a decision in front of a room so that they can follow it and decide. It is not a tour of everything that was done; it is the shortest path from the audience’s context to the decision you want from them.
Why it matters
Presentations go wrong in two predictable ways. The first is the chronology — what we tried, what we found, what we tried next — which leaves the room forming an opinion before they know what they are being asked. The second is the depth that interests the presenter and exceeds what the audience can evaluate, so the discussion drifts to a detail and the decision does not happen. Both are fixed by deciding the decision first and building the slides backwards from it.
Core ideas
Name the decision before the first slide
One sentence at the top: what you want the room to decide or approve. If you cannot write it, the presentation is an update and should be an email.
Decision wanted: approve the schema change and a two-week migration
window, accepting a read-only period of about 20 minutes.
Five slides, in this order
Context, the options, the evidence, the recommendation, the ask. Anything else goes in an appendix you can be dragged into.
1 Context what problem, whose, what it costs (1 slide)
2 Options two or three, with their real costs (1 slide)
3 Evidence the measurement or test behind them (1-2 slides)
4 Recommendation what you propose and why
5 The ask the decision, the cost, the date
One idea per slide, as a sentence in the title
The title states the finding; the body supports it. “Latency doubled after the queue change” is a slide; “Performance” is a chapter heading.
Show the artefact, not the process
The room needs to see the thing and its consequences, not the four weeks of exploration. Keep one slide of alternatives considered for the question someone will ask.
Rehearse the first ninety seconds out loud
That is where the room decides whether to listen. Say the decision, the recommendation and the ask in that order before anything else.
Practice
Build the five-slide outline for a real decision
Take a decision you need from a real audience and build the five slides, with the decision written above slide one.
Done when each slide title is a sentence stating a finding, and someone reading only the titles can follow the argument.
Present it and record the questions
Deliver the outline to a colleague, and write down every question they ask.
Done when: each question has either been answered in a slide or listed as material for the actual appendix.
Common mistakes
- Chronological structure — the audience forms a position before hearing the ask; fix: start with the decision and the recommendation.
- No stated ask — the meeting ends without anything decided; fix: name the decision, the cost and the date at the top and the end.
- Topic titles instead of findings — the slides describe areas, not conclusions; fix: write each title as the sentence the slide proves.
- Showing the exploration — the audience cannot evaluate the work and drifts to detail; fix: keep the process in an appendix.
- Not rehearsing the opening — the first minute is rambling and attention is lost; fix: say the first ninety seconds out loud beforehand.
Go deeper
- Communication (08-soft-skills/01-communication) — read this first; presenting is the one-to-many case of the same skill.
- Explaining to any audience (08-soft-skills/01-communication/01-explaining-to-any-audience) — calibrating detail to a mixed room.
- The decision role (04-product-process/03-product-management/01-the-decision-role) — the decisions these presentations usually ask for.
- Technical Writing (04-product-process/08-technical-writing) — the same structure applied to a document.