Presenting Work That Is Not Finished

Most conference presentations are of work in progress. That is largely the point — a conference is where you find out what a room full of people who know your field think, at a stage where you can still act on it.

Two failure modes waste that. Presenting it as finished, which produces polite questions and no help. And apologising throughout, which makes the audience discount everything including the parts that are solid. For a concrete operational example of how a workplace tool approaches a related coordination problem, see this overview.

Say what stage it is at, once

Early, briefly, without apology. "This is work in progress — the design is settled, the results are preliminary, and I'd particularly like reactions to the identification."

That sentence does three things: it sets expectations, it prevents questions about missing pieces you already know are missing, and it directs the discussion.

Do not repeat it. A speaker who qualifies every slide teaches the audience to discount the whole talk.

Ask for what you actually need

The single most useful thing you can do, and it is rarely done.

Be specific. "I'd like reactions to the identification strategy" or "I'm unsure whether the outcome measure is the right one" gives the room a target.

Without it, you get comments on whatever is easiest to comment on — the framing, the presentation, the literature — rather than on the thing you are stuck on.

Say it at the start as well as the end. People form their questions during the talk.

And ask the question you are afraid of. If you suspect a problem and hope nobody raises it, the person who would have raised it in review is in the room now, and this is the cheapest time to hear it.

What to show

Show results, even preliminary ones. A talk that is entirely motivation and method with no findings frustrates an audience and wastes your slot. People cannot react to nothing.

Show the specification you actually ran, not a simplified version. The audience needs to see what you did to comment usefully.

Be honest about the sample. If it is a pilot with forty observations, say so on the slide.

Do not show results you do not believe. Preliminary is fine; unreliable presented as preliminary is not. If a number will change, say which direction and why.

Distinguish clearly between what is done and what is planned. A slide labelled "planned analysis" prevents the entire category of question about why something is missing.

What not to do

Do not claim more than you have. The room contains people who will check, and overclaiming at the work-in-progress stage damages you more than an incomplete result would.

Do not hide the weak part. It will be found, and finding it yourself is a much better position.

Do not apologise for the stage of the work. Presenting unfinished work is the normal use of a conference, not a favour the audience is doing you.

Do not present something so early that there is nothing to react to. An idea with no design and no data is a conversation over coffee, not a talk.

The particular case of a null or messy result

Common, and people avoid presenting it, which is why so much of it is never seen.

A well-designed study with a null result is a finding, and a room of specialists is exactly who can tell you whether the design was capable of detecting the effect.

Present it as a result, not as a failure. "We designed this to detect an effect of X and we do not find one" is a sentence with content.

Ask specifically about power and about the measure. Those are the two things that most often explain a null, and the audience can help with both.

Messy results are the same. If the pattern is inconsistent across specifications, showing that is more useful than showing the one that worked.

Handling the questions

Questions about unfinished work are the product, not an ordeal.

Write everything down. Every question is a referee comment arriving a year early. See handling questions.

"That's exactly what I'm stuck on" is a good answer, and it usually produces a better conversation than an improvised defence.

Defer detailed technical objections to afterwards, so the room gets other questions and you get a proper conversation.

Follow up. An email that week to the two people who asked the most useful questions is worth more than the talk.

Where you present matters

Small workshops and seminars are for early work. The audience is there to help, there is time for discussion, and the stakes are low.

Large conferences with parallel sessions are for work that has a result, even if provisional.

A job talk is not the place for work in progress. Different genre, different expectations. See the job market talk.

Match the stage to the venue and most of these problems do not arise.

For the audience

Since everyone is on both sides of this.

A speaker who says the work is preliminary has told you what kind of comment helps. Design and interpretation questions help; presentational polish does not.

Ask about the thing they said they were unsure about, if you have a view. That is what they asked for.

Be constructive in proportion to the stage. A first presentation of an early idea does not need the treatment a submitted paper gets.

And say what works. At the early stage, knowing which parts are convincing shapes what the researcher builds on.

The short version

Say the stage once, early, without apology, and then present normally.

Ask for the specific feedback you need, at the start and at the end.

Show results, including null and messy ones, and label what is planned.

Ask the question you are afraid of — that person is in the room, and this is the cheapest time to hear from them.

For an independent authoritative reference, consult the MIT Communication Lab for academic communication guidance.