This is how most talks held at computer science conferences start:

First, I will give you an introduction. I will present the problem and then I will introduce our approach. I will then show the case study we performed. In the end I will finish a discussion and with concluding remarks.

People do that because it is a known fact that any talk should start with a roadmap so that the audience is informed about how the next minutes will be spent.

The problem is that the typical roadmap, like the one presented above, is so generic that it tells nothing. It can be about anything, from solving the software crisis to solving the climate crisis.

Instead of such a roadmap, better none at all. In fact, I argue that many time you actually do not need a roadmap at all, and that it is only rarely that you would want to start with one.

Roadmaps are good when the journey is long and complicated. When your journey is short and straight, you do not need a roadmap, you merely need a direction. Thus, when your talk is short and is about one main point, you do not need a roadmap.

When your talk is longer and hits several bases, it can be beneficial to have one. Even then, it’s rarely useful to present it as the first thing because the audience does not have the necessary background to understand it. In most cases, it is much better to introduce the topic, and only afterwards to talk about the roadmap.

If you do use a roadmap, make it useful. After all, a roadmap is useful only when it provides the map of the road.