Presentations from tech-marketers: improve, recycle, learn

Last post I noted a few things to make presentations easier to follow. There is one additional area which could help technologists create better presentations, simply improve on what is out there. The first step is improve your own creation. If you are a programmer you know that all new programs can use improvement, testing, user feedback, benchmarking with competing programs... you get the point: I M P R O V E M E N T. That goes without saying for hardware designs. No hardware designer will ever say that the first version of a product is "perfect". The same goes for any communication and especially of the technical nature. The early life of a technical presentation needs exposure and feedback. This is specially important if you are going to introduce a new concept or claim something unique. The main reason for testing and feedback is to see what was understood. New concepts are specially difficult to explain unless they are very simple. Most of our technology is not that simple to others. We live and breath it all they long so we need to think in terms of people who do not. Even if you are trying to show an improvement in a known parameter like speed, power, or size or a program or a device. Just showing the "before" and "after" is not enough, because most people want to see the "how" and "why" and simply will not believe you if you say: "trust me". So you need to explain how the technology improved or changed the current way of doing things. This is where the questions pop out, but not to worry, here is where you can start diving into the technical details and make your point. This is where you need to create a good way to communicate; and improve, test, get feedback - and loop back!

---

Metcalf's patent flow chart for Ethernet

      The improvement of presentation is a good step for anyone and helps in getting you to present better. There are two areas which help a great deal in this area. The first is the use of other people's material. You may thing that this is a terrible piece of advice. For example, the flow chart I used here came from Robert Metcalf's original Ethernet patent (4,063,220). Patents are not read by many people, but by their very nature they are a good explanation of a technology or a basic technique. Trade publication papers, industry standard specifications, and academic publications are in a similar category. These are public domain documents, but more important they tend to become an industry reference. Even if most people don't read standard specs and patents, they are known and trusted as legitimate sources. The use of these "virtual standard" documents is not very popular and not always makes sense, but it does help when you want to build on top of a know concept.

---

Pentium Pro TAP processor, a small piece of technology in a big product. Intel (c) 1997
      Another useful source is industry standard documents. If you are writing about computer architecture there is nothing wrong with using Intel's specification or presentation on the Pentium. If you are a competitor you may thing that this may cause a problem, or that it shows that you are not original and that you need to "do your own work". Well, in our world most of the work is evolutionary. We improve, support, and integrate on top of what was done before. Even though most people are not familiar with the previous work you don't need to ignore it "at all cost". In each technology there are many old presentations, papers, and references. Again, even if you are the competing product you can still make use of this material. I do not advise you to copy every single presentation or manual from Cisco or Intel. But there is plenty of material that is considered industry standard by default. In the case of the figure I used from Intel, the TAP processor is a test function. You could find it in many places including the original standard specification (take a look at the IEEE resources). In this case the TAP processor is not a significant technology component in the Pentium product. But if you are going to talk about testing of integrated circuits it is useful. Make sure you ask for permission if you are using an important component of some one's publication. If you were to use Intel's main architecture drawings or flow diagrams you probably need to see if they will give you publication rights. In most cases if you are using the "core" technology they will probably not give you the rights, so be careful. As it is, you should probably do your own work when it comes to the "core" ideas.
      Well, this is another installment in our journey... stayed tuned to the giving of the presentation, or how not to put everyone to sleep on a fine sunny afternoon...