The hardest part of writing a conference proposal is rarely the writing. It is deciding which part of a large, complicated project is actually useful to somebody who was not there.
A project contains months of context. A talk has one promise and a limited amount of time. The job is to find the smallest honest story that carries a reusable lesson.
Start with the changed belief
Before you write a title, finish this sentence:
We used to believe X. After operating the system, we now believe Y, because Z.
If the sentence is specific, you probably have the centre of a talk. If it still sounds like “AI is changing quickly,” keep digging.
Good changed beliefs often hide in a decision the team would make differently now:
- a metric that looked healthy but missed user harm
- an architecture that was elegant but difficult to operate
- a manual step that turned out to be a feature, not a temporary flaw
- a cost model that changed when real usage arrived
Draw the evidence line
A production claim needs an evidence line. It does not require publishing sensitive numbers, but it should show how the team knew something had changed.
claim
├─ signal we observed
├─ decision we made
├─ result we could verify
└─ limitation that remainsThis small structure makes a proposal easier to trust. It also protects the eventual talk from drifting into a broad survey.
Keep the scope narrow enough to be useful
“Everything we learned building our platform” is too large. “Why our offline evaluation stopped predicting support tickets” creates a useful boundary.
Try this proposal shape:
| Part | Question to answer |
|---|---|
| Context | What system and constraint are we dealing with? |
| Tension | Which signal or failure challenged the original plan? |
| Decision | What changed, and why was that option chosen? |
| Evidence | What became measurably or observably different? |
| Transfer | What can another engineer reuse? |
Your audience does not need every branch of the decision tree. It needs enough context to understand why the chosen branch mattered.
Write the abstract last
Once the evidence line and scope are clear, write three plain sentences:
- the production problem
- the unexpected lesson
- what the audience will be able to do with it
Then remove any claim the talk cannot support. Specificity will make the proposal sound more ambitious, not less, because it shows there is a real experience underneath it.
If you have shipped something that changed how your team thinks, you already have the raw material. The proposal is simply the first act of making that lesson useful to someone else.