Issues With The Tool-First Approach to Technical Presentations

If you scan the events calendar of your local Microsoft-related user groups and conventions there’s a pretty good chance that a large proportion of the presentations involve one of the following scenarios:

  • A rundown of all the cool features in a product or tool
  • A demonstration of a subset of a product or tool’s features, usually presented as a contrived example with no real world equivalent

No one seems to be complaining about this either, which could be a good indication that the “tool-first” approach to technical presentations is exactly what the public what they want.

I would argue, however, that it is not what they need.

We get enough of the sales spin and demo-ware from the companies that make these tools. There are plenty of resources out there on the Internet for us to learn about the specific features offered by a product, with companies often employing an army of evangelists to create articles, videos and sample applications for you to digest in your own time. I mean, why give up time that you could be spending with your family/loved ones/pet projects/gaming consoles/guitar collection to hear someone read out a feature list from a product’s website or run you through what amounts to a TechNet article that you could have read yourself in a fraction of the time? I just don’t see the logic in it.

When I attend a presentation I want to take full advantage of having a real live human being in front of me. I want debate. I want opinion. I want war stories. I want to interact and have a conversation with the person presenting to make the experience worth my time. Ideally I’d want to walk out of the presentation with an altered outlook on how I approach work, having just had my methods questioned, changed or reaffirmed.

You simply can’t get this from a straight “happy-days scenario” tool presentation where everything just works. There needs to be an underlying message and purpose of some sort; a purpose other than, for example, evangelising version 10.3 of IBM Pokemon WebSphere Black Sapphire Ruby Edition. Marketing material simply does not do this. Presenters shouldn’t be afraid to do things like:

  • Show the failings of a product as well as the happy scenario where everything works
  • Offer an informed opinion based on experience rather than marketing material
  • Discuss theory and process, either in relation to a product or tool or not
  • Present on a topic that is not tied specifically to a product
  • Use their technical example as a means to proving or stressing a point they wish to make, e.g. SharePoint + InfoPath + Reporting Services demonstration could be used to discuss how composite applications can provide a viable means to expand the scope of existing line of business applications to a new set of users without increasing training costs

If we don’t get away from this tool-first approach then the audience are going to leave presentations believing that downloading/purchasing a product or tool will solve all of their woes, which as we all know is never the case. We get enough of this junk from software vendors; we don’t need to be perpetuating this myth for them.

About Garry

I'm a Solution Architect living in Perth, Western Australia. I work primarily with Microsoft technologies, but I have an open mind and like to branch out into other areas in my spare time. I'm also a Microsoft Virtual Technology Solutions Professional (VTSP) in the Integration space and like to stay active in the local development community.

2 Responses to Issues With The Tool-First Approach to Technical Presentations

  1. Adam Grande May 6, 2011 at 8:42 am #

    Hmmm i know what you mean, but is it possible these sorts of issues come from the fact some people cant really talk about the applications they work on in any great detail?

  2. Dadang December 14, 2015 at 2:30 am #

    Cheers pal. I do apreacipte the writing.

Leave a Reply