How can I explain (technical) things more coherently/give better technical presentations?

In My Humble Opinion
1

I had an annoying time at work today because I gave a draft version of a technical presentation I have to give next week to a customer, and I did not do a good job. In fact, I generally do a worse job at presentations than most of the other people I work with, and I worry that it’s seriously starting to mess with my career, that I don’t get given as much responsibility because I can’t be trusted to do a good job communicating to the customers.

In particular, I can’t go in cold, without having practiced giving my slides multiple times, and talk about them. Of course this is exacerbated when I’m not very familiar with the material, but it happens even when I am familiar with it. It happens even when it’s about stuff I’ve worked on and thought about for years! Unlike pretty much all the other technically-oriented people I know, I just cannot seem to explain technical material in a nice logical progression without having practiced exactly what I’m going to say and what words I’m going to use. I tend to start in the middle, leave out important points, forget to put in important background information, and so on. This happens even informally – my husband points out a lot that when I’m telling him something I routinely start in the middle. (He explains things very well, in an extremely logical and elegant fashion, whether it’s on the Dope or at work or telling me about how the plumbing in our house works. I’m really jealous.) When people ask me stuff like, “What are you working on these days?” it’s really hard for me to put together two sentences that describe it coherently. Even this post required several drafts so that I wasn’t telling it in a cockeyed incoherent fashion (or at least, if you think this is incoherent, you should have seen what I started with).

Another, related problem I have, that plays into this as well, is that I tend to always overestimate how much the audience knows, when really I should underestimate and trust that the audience will tell me if I’m boring them. That’s something that is at least fixable in theory, although in practice it’s harder because I don’t always know/realize what the audience doesn’t know.

Is there a way to get better at this? Obviously one thing is that I apparently need to start practicing even for the draft versions (which is sometimes feasible, although not always, because sometimes there’s a time crunch and I don’t have time to practice before giving the draft). My husband has also valiantly volunteered to be the guinea pig for having me practice explaining things and/or telling stories in logical progression. (He obviously loves me very much, as I suspect this will be a little painful for him.) I guess practice must help? More than ten years of being asked what I’ve been working on at school/work doesn’t seem to have made that any easier for me, so I’m a little skeptical, but I suppose it can’t hurt. Any other tips? Does anyone else have this problem?

2

My approach would be to have someone else who is good at technical presentations give them. It’s not impossible to get better at them, but it is also one of those things that some people are good at, and some aren’t.

3

Do you understand the big picture of the things you’re working on? If not, there’s no way that you’re going to be able to explain them at all. It’s not necessarily a flaw if you don’t; the only problems are the ones you’ve encountered. But if you want to do this sort of thing, it’s a necessary condition?

4

As hard as it may be, try thinking back to when you first learned the material and what sort of mental gymnastics and connections had to be performed to understand it. What sort of misunderstandings did you initially have? What questions did you have? Your audience will probably have the same questions floating around in their head whether they ask them out loud or not. Try to give short, concise answers to these questions.

I had a calculus professor once tell us that the best way to reach most of his students was to teach the same material three different ways: using formulas (theory), using graphs (visuals), and using real world examples. I guess some students pick up things easier depending on the method used.

5

My main tip would actually be the one you’ve identified for yourself - the story is everything. You need to take the audience with you from point A to point Z. Do you read a lot of fiction? Think about how that is structured - at its most basic you could say that we begin by being introduced to the characters, then the current situation, the compelling next steps, then the resolution. This is hideously over-simplified, but you can take that same structure and apply it to this kind of presentation. I don’t know, maybe what I’m trying to describe is actually bad fiction!

This also fits with your idea about over-estimating your audience: again, you need to take them with you. Show them the connections between the points you’re making, don’t expect them to leap. Don’t over-complicate things, and don’t make too heavy use of jargon - even for a technical audience. One of the things inexperienced presenters do is try to fit in too many 10 dollar words, in the belief it will give the presentation more gravitas, but that isn’t necessarily true.

Keep the number of ideas you’re trying to include fairly low - perhaps you find explaining things generally quite hard because you try to include too much detail? That’s easy to do when it’s something you’re familiar with, and enthusiastic about. Along with trying to establish a narrative for your presentation, also focus on what it is you want your audience to get out of the session.

I understand your need to practice, but I’d be careful of over-doing it, you’ll suck all the life out of it. Similarly, I’d recommend notes rather than a script if you can bear it.

Practice does help, but this does come easier to some people than others, for sure. I ‘audition’ a lot of technical presenters as part of my job, and a lot of them find it hard to see that in actual fact, just because they know a lot doesn’t always help them. It’s a skillset in itself.

6

This reminds me of something that happened to me. I took a FOAF on a helicopter ride. When we got back one of the owners/instructors at the FBO asked how he liked it. FOAF said it was fun, but he kept worrying about falling out when I turned. (We flew with the doors off, of course.) I tried to explain why he was perfectly safe, describing centrifugal force (and not muddying the issue with centripetal force) and reminding him that the seat belt and shoulder strap would keep him from falling out anyway. He didn’t understand. So the owner/instructor says, ‘Did you ever take a bucket of water and swing it over your head, and the water didn’t come out?’ ‘Yes,’ said the FOAF. ‘Same thing.’ ‘Oh! OK.’

7

“I tend to always overestimate how much the audience knows” This is HUGE. And is very common among engineers. Though you may feel you’re “dumbing down” to your audience, it is FAR better to play it safe and assume they know little than the alternative (what you are already doing). Throwing out concepts and terms that the audience isn’t familiar with will derail them from the presentation, and they may never get on track.
Here’s a big tip, and the single most common mistake I see people make when giving presentations: acronyms. Presenters start throwing out ASIC-this and CPCI-that and acronyms of internal project subsystems, and the audience hasn’t got a clue. The problem is that since you and your co-workers use these acronyms day-in, day-out, they have become a part of your vocabulary…and you therefore start to assume they are part of EVERYONE’s vocabulary. So be aware of when you start to use acronyms (and no, they aren’t the same as “names”).

Being so familiar with the material, this is also a very difficult thing to do: but put yourself in the place of the audience as you review your material. It will take some self awareness to recognize how many “blanks” you fill in because you already know the stuff. But ask yourself that if you had never seen this material, would you really “get” it ? If not, what would you need to flesh out the full picture ?

Secondly, keeping in line with the “dumbing down” approach, I have had the most success with both simple pictures (diagrams) and using analogies to everyday things. This second part can be challenging, but you have to get creative in highlighting the similarities, even in concept/function or whatever, to something people “know”. This works wonders, and keeps them “into” the presentation because at a very fundamental level, they “get” that it is “like” (whatever). It’s this comfort level of understanding that will keep them with the presentation.

Rehearsing is great, but you need to 1) be flexible to be able to slow down (with analogies - it may take a couple before you see people getting it), and 2) be ready/able to answer questions (or have people wait because the answers are still to come in the presentation, BUT not get too off track with questions and be able to pick up where you left off.
When I hear you saying you rehearse and know “exactly” what you’re going to say, though you’re well prepared with what YOU want to say, but it may not leave much room when someone asks a question that may not be directly related to your material.

8

Could you take a speech class at a local community college? This is exactly the kind of thing they cover. I had speech in high school, then two speech-y classes in college (“Technical and Professional Communications”, which also covered things like memos, reports, etc., and a different dedicated Speech class). I regularly get complimented on my presentations and how at-ease I sound (though this obviously requires preparation first!).

A class should cover things like making a detailed and ORDERED outline (and how to start with a jumbled one and refine it), how to rehearse, good use of slides/visual aids*, topic organization, and more. You’ll cover a bunch of different speech types (instructional, informative, persuasive, etc) and even if you won’t personally do a certain type in your career, it still helps your overall presentation skills.

Since it’s directly connected to your career, you could ask the company to pay for the class, as well, assuming they do any tuition reimbursement.
My personal advice relates to your problem of starting in the middle. Practice giving some REALLY basic instructional speeches to your husband, who needs to pretend he has no clue how to do whatever the task is. I’m talking even “how to make a peanut butter and jelly sandwich” or “how to brush your teeth”. That way if you start the pbj with, “well, you want to put peanut butter on your bread”, he can interrupt with, “wait, what kind of bread? Is it sliced?” and so on. It helps you practice thinking of the steps you’ve internalized and think are “obvious” but really aren’t necessarily so.

  • FOR THE LOVE OF GOD, DON’T PUT A GODDAMN WALL OF TEXT ON A SLIDE. :mad: :mad: :mad:
9

If you’re talking about a real audience, it’s worth appreciating that there might be many different levels there, and you often cannot, and even should not, try to communicate to every single person. Or more specifically - you shouldn’t attempt to communicate to everyone at the same time - you can include everyone over the course of the talk.

I have to do this with research talks I give - there’s a difference between the professorial and graduate student level. I need to engage both, but they can demand different things. It helps me structure the talk when I know who I am talking to at any one time - A or B, or both.

If your audience is one person though, a customer, then it’s somewhat a different story - but you still need to know who your customer is, and what is their knowledge base. Seems like there’s a massive difference between a non-engineering customer who you might need to explain what the product is all about to, and a customer who’s very comfortable with the background and wants to hear the nitty-gritty. Obviously two very different talks required here.

10

I have a rep for writing about technical subjects that non-techies can understand. I used to write with my boss as the nominal target audience. I figured that if I wrote it so he (a lawyer, and about as non-tech as possible) could understand it, anyone could. It seemed to work.

11
  1. Think of your presentation as a funnel, taking your audience from the biggest picture to the final, take-home message. All presentations, even the most technical, have this type of outline. Present the problem, your company’s solution, details on why it’s different/special, how they can implement it to help them.

2a) Use the PowerPoint slides (or whatever visual) to your advantage. Add enough detail to act as your notes, but also keep the text to a minimum. It’s much preferable to pause for a second, review the slide to remind yourself of what you want to say, then continue. DO NOT READ COMPLETE SENTENCES OFF OF SLIDES! Your audience can read, too. Why are you even there if that’s what you do?

2b) Strongly resist the urge to stray from the info on your slides. You took the time to plan a presentation with a logical stream. Stick to it! In the moment, it’s easy to let your brain go off on a tangent. If it’s important, it’s in your presentation in the spot where it makes the most sense. Otherwise, it isn’t important enough to mention unless someone asks. I see a lot of presenters totally derail a nice talk by ignoring this rule. I think this is particularly hard for technical folks who get so into the minutiae of a project.

  1. Keep in mind that you are the expert in the room. That’s why you were asked to give the presentation. If you are comfortable and competent talking about the project with your colleagues, you’ll be fine to present it to customers. Just back off on the jargon and acronyms and add a bit more background (mostly of the “why we did this” variety).
12

Wow, thanks everyone! Lots of good advice.

Tripolar, thanks for the reminder that there are some things some people are better at than others. In fact I do get my boss to give the slides about the company, because he does a really good job with those.

Johnny L.A., great story! That’s how I feel a lot of the time.

cormac262, good point – I don’t necessarily use a whole lot of acronyms my customer won’t understand, but I have a very similar problem of assuming the customer will know, e.g., what that green dot on the screen means. Actually, that’s probably worse than using an acronym s/he doesn’t know :slight_smile:

zweisamkeit, huh, I didn’t realize that a speech class would help with those things. I thought it would be about getting over fear of speaking and gaining confidence, which I need relatively less help with. Your talking about it makes it sound like something I would benefit from. I also really like your advice about giving speeches about simple tasks.

I have learned, since I started work, not to use walls of text and that the more pictures and diagrams I have, the better. So I haven’t just been twiddling my thumbs in my presentation skill set! That was good to realize as well… that even though it feels like I haven’t improved, I actually am a lot better than when I left grad school. (Let’s not even compare when I entered grad school… ouch.)

13

I understand how you feel raspberry_hunter. Many of my clients have experienced similar frustrations to you. I’m a “techie” turned public speaking coach. The first piece of advice I can give you is look at the structure of your speech or presentation. Don’t be afraid to use the Tell Tell Tell method, where you constantly re-iterate the points that you want to distil to your audience. It may feel like you repeating yourself unnecessarily but it is required to ensure your audience absorbs the information you are presenting. Check out my blog if you want more tips: www.markkyte.com/blog/

14

I take the approach of putting in a few “background slides” when presenting. i.e. “This slide just goes over the architecture. You may remember that the hosting for this is offsite, but we will have a collection database here on site.”

The idea is to “remind” them of what they need to know. At the same time, DON’T fall into the other common technical person talking to non-technical person mistake of too MUCH detail. This is not a course in Intro to Electrical Engineering or whatever. This is an hour presentation where you have to get to the end of the story. Explain your technical concepts in 200 words or less, using analogies or examples or pictures where possible.

(We HAVE to put walls of goddamn text on the slide, its how we work. Drives me crazy. If I were the boss, I’d have all presentations be PRESENTATIONS and backed up with a whitepaper…I’m not the boss so we get walls of text. Lesson here, prepare your slides to meet the audience needs - our presentations are whitepapers in powerpoint.)

Take a one day seminar from Edward Tufte.

15

A lot of the points I would offer have already been made, but I’ll provide my advice in toto for the o.p. to take away what she wants. In my job I produce and review a lot of presentations on highly technical topics that are intended for a non-technical or marginally technical audience. There is certainly a knack to being able to take technical discussions and distill them down to the fundamental elements that are comprehensible by an average person. Just as with storytelling, some people have a natural talent for this and others have to work very hard at it, but everyone can learn to do it to some degree. It may be necessary to collaborate with someone to help vet out a presentation, but there is nothing wrong with this; many writers (both technical and non-technical) work best in collaboration.

A few points to consider for improving presentation are below:
[ul]
[li]Give context: always start telling the story at the beginning. Don’t just jump into your research or experiment; explain the basic problem and what led you into the research you are presenting. This gives a framework for the audience to interpret your work, and the reasons that they should be interested in your results.[/li][li]Give a précis of your results or conclusions up front: this isn’t a mystery story you are presenting; the audience should be focused on how you came to your conclusion, not what it is. Technical research should always be presented (in terms of cinematic jargon) in flashback. “This is what we set out to do, this is the result that we got, and now I’m going to show you the path to how we got there,” should be your introduction.[/li][li]Present the logical flow, not the chronological one: that you had to go back and redo some work, or you discovered an effect before a cause is not generally germane to your audience’s understanding of your work. This is not a peer review and you don’t need to provide every detail to justify your work; you simply need enough to explain what your results were and how you achieved them. In fiction, a writer will often skip superfluous details that do not contribute to the story; for instance, a writer may have a character jump from a scene in New York to one in Los Angeles merely by opening up a new chapter or even paragraph with something like, “Hammer landed on the 10:20 to LAX, and the heat which blistered the macadam struck him in waves as he hailed a taxi.” Similarly, you can skip over pedantic details that are only of interest to other scientists or engineers.[/li][li]Give definitions: as you are providing technical information to a non-technical audience, you will likely be using jargon that is not familiar to the general public, or worse yet, terms that are used in a colloquial sense that is not consonant with the use of it in your work. It helps the audience to define terms, either up front (if the presentation will be reviewed by the audience later) or parenthetically (if this is one time exposure). If you find yourself defining more than six or seven terms–about as many new ideas that most people can hold in their mind at one time–then you probably need to reduce the complexity of the presentation for this audience.[/li][li]One idea per slide (at most): don’t try to cover too much information in a single slide. Doing so will confuse your audience and leave them not understanding your logical flow. Each slide is like a chapter in a novel, and should have a start, a body, and a conclusion. You are better off with more slides with less content per slide than one slide with three or four points crammed on it. If you have to stretch a single discussion across multiple slides, clearly indicate that the slides are connected, e.g. use the same title with “continued” or “(n of 4)”. For many presentations, it also helps to summarize a slide or progression of slides with a clearly defined “takeaway” box at the bottom of the slide. [/li][li]A picture is a story: use images, diagrams, and graphs to illustrate your point. Even non-technical audiences are generally pretty savvy about graphs and can grasp your point more easily in visual form. It is also important to select a perspective or scale that suitably illustrates your point; if you have a graph with a small jump, put a telebox on top of the graph that magnifies the area of interest. Annotate pictures so that the audience understands what they are looking at.[/li][li]Use analogy to explain: unlike in other areas of study such as history or literature, where comparison and contrast are useful methods in analysis, in the hard sciences we shy away from similitude as a method of comprehension, insofar as it often draws one to make the wrong conclusion; by definition, analogy is a comparison of the similarities between two essentially unlike things. As scientists and engineers, we deal with hard data and objective falsification rather than the approach of “This seems like that, thus they are the same.” (See every crackpot theory on gravitation and quantum mechanics for an example of misuse of analogy.) However, analogy is very useful for the purpose of illustration, allowing someone uneducated in theory to bridge between what they know, and concepts that are new and not intuitive. The use of analogy in an appropriate context can be extremely useful, although you need to be clear with your audience on where the analogy breaks down. Of modern science writers, Brian Greene is one of the best at crafting useful analogies that make complex concepts accessible. [/li][li]No eye charts: putting up a giant table of numbers that are too small to be read is a pointless waste of space. Make a table that presents or summarizes the data particular to you conclusion. Use color coding and highlighting to make the data you present readable and comprehensible to your audience.[/li][li]Use humor to keep you audience in engaged, but apply is sparingly: notice that the best comics don’t try to press one gag after another; they tell a seemingly serious story and then break the tension with an unexpected joke. Keep the audience engaged on your work, and gauge the point where they’ll start to lose interest, then offer a joke.[/li][li]Conclusion: summarize your work and the points that you want the audience to take away on your last slide. Limit your points to five or six at most. When reviewing, ask yourself what the audience needs to be able to say to summarize your work. You don’t need to cram everything onto this slide; just the verbiage they need to know.[/li][li]If you have more content that you think may be necessary to answer questions but seems to involved for the basic slides, put it in backup slides beyond the conclusion. You can reference it as you need without destroying the flow of the basic presentation. Similarly, if someone wants to vent their particular hobbyhorse or ask a protracted and tangential issue, offer to address it in a sidebar or provide separate information to prevent the presentation from being sidetracked. [/li][li]Executive summary: if someone else is going to take your presentation and present it to their management, you should provide an executive summary up front that condenses all of the absolutely critical information in the presentation into one single slide. This differs from the conclusion in that it has to contain all of the assumptions, work, and conclusions in one slide. This can be the hardest slide in the presentation to draft, and will take a disproportionate amount of effort compared to the other slides.[/li][/ul]
Stranger

16

Stranger On A Train and others have given excellent advice, but part of that advice was to hammer down the point several times. So here I go :slight_smile:

It is surprising how many technical people receive no training on technical writing.

There are some basic characteristics of technical writing that are different from writing a novel:

  • Start off with a concise, clear statement of what you are trying to convey. “I am proposing a change to Accounts Receivable processing. This change will improve efficiency and reduce errors, thus reducing costs.”

A bad way to start is “Our Accounts Receivable system was originally a mainframe system written in COBOL. It was ported to client/server in the 90’s at the same time regional offices were given more autonomy. We ended up with different practices in different regions. This ended up…” At this point nobody know why you are talking to them.

  • Proceed in orderly, logical steps: for example,
    [ul]what is the problem or opportunity
    [li]what are the alternatives[/li][li]why is one alternative the best[/li][li]how it will be implemented[/li][li]what resourcing is required[/li][li]what are the timelines[/li][li]what is the estimate of cost.[/li][li]what are the overall benefits to proceeding. What are the risks of not proceeding.[/li][/ul]

  • Parallel construction is desirable. Again, you are not writing a novel where repetition is amateurish. For example:

Good: “Stage one will start in the second week of January and will end April 30. Stage two will start September 1st and will end October 31. Stage three will start January 1, 2012 and will end March 31 2012.”

Bad: “The first stage will start right in the New Year, the second week of January to be exact. It will end April 30. Then, we have a hiatus of a few months followed by the second phase. This portion of the project will run from September 1 to October 31. Then we take a break until next year, resuming on the first of January again, but this time completing it on the last day of March.”

17

No one has covered the most important point of a technical presentation, which is fulfilling some goal. Is the goal of your presentation to help a sales person sell more stuff, or is it to introduce a new product or concept, or is it to build the credibility of your company? Each goal will lead to a different presentation. The first might concentrate on technical features the customer needs, the last might lead you to go just enough over their heads to make them think you and your company are brilliant.

Are you visual or verbal? Pictures are better, but some of us have a hard time with pictures only. If you are more verbal, bullets might work better for you. No more then 5 -7 words a bullet, and no more than 5 - 7 lines per slide. Don’t use complete sentences. It is actually a good idea if the bullets are just jogs to your memory, since then the audience won’t read them and snooze while waiting for you to catch up. It will also keep you from the sin of reading your slides. If you have the right bullets, you won’t skip over things.

When I practice, I often go to a subject different from the next bullet or next slide, which means I don’t have things in the right order. Practice telling the story along with your slides - if they get out of synch, change the slides. And do practice.

It is great if you can structure your presentation as a story. I did one as a kind of mystery, and I got perfect speaker feedback scores. But you can’t always do this - the structure of the talk needs to fit the subject matter.
If you have a small audience, try to get feedback from them during the talk in the form of questions from them or questions from you to them. It is especially good if the question is a choice for them. But be careful with customers.

Finally, how energetic are you. Some people have fine slides but put people to sleep, and some energize their audience. Speaking is like acting. Actors turn on when the camera rolls, and speakers need to turn on also.

18

Whenever a write a presentation or story, I try to start with the audience’s point of view. The very first question I ask is “what’s in it for them?” What do I want them to take away from the presentation – a way to solve a problem, an understanding of an issue, enthusiasm about a new product, etc.

The second question I ask is “what do I want them to go away with?” Then I figure out what I need to say to get to the answer for both those questions.

Decide your objective first, then write toward it.

19

It’s interesting that many people seem to have interpreted the OP as “I need help making slides.” I didn’t actually mean that at all (it’s more the verbal delivery of the slides I was concerned with in the OP), but I am definitely interested in all the responses, as I figure it’s not like I don’t need help with making the slides as well.

Stranger, your point about presenting the logical flow is well taken. I think my main question is, how do you figure out what the logical flow is on-the-fly while you’re giving the presentation, after making the slide? Maybe the answer is just that people like my husband and my program manager happen to be awesome at it, and I do not, so I just have to be more conscientious about practicing and trying to develop that skill, as zweisamkeit suggested.

K364, heh; I don’t do well with parallel construction (I’d be much more likely to say something like the “bad” examples you gave, so that’s something I have to keep in mind. I blame an education overly-heavy in the liberal arts :wink: (I majored in a science, of course, but I went to the sort of liberal-arts school where we had to take a lot of non-science classes, where I felt very much like your “bad” examples were what they were asking for.)

20

I’m another technical communicator, although I left the field some years ago in order to pursue another career. Still, I did have over 20 years in the industry, and there are some things you can never forget. I may be reiterating points given by others, but if I am, then you can tell how important they are.

Audience: Know it. Are they non-technical, technical, or somewhere in between? Note that in this case, “non-technical” can include users who are comfortable with home and work PCs, but they have no idea what (for example) your industrial software application running on proprietary hardware in the workplace is or does. Adjust your presentation accordingly.

Analogies: Excellent. Likening technical concepts to common, everyday things will help your audience understand the concepts. A Token Ring network is nothing more than a train running on a circular track, where mail is put on the train at a station, and thrown off the train when it gets to the station where it is addressed. Now, before techies jump on me–yes, I am aware that a Token Ring network is a lot more complicated; but IME, for the non-technical user, this explanation worked just fine.

Objectives: Have them. “By the time I finish this presentation, you will be able to _____.” This helps your audience members understand why they are there; and if you repeat it often enough (yes, it’s hokey, but do it), it will help you focus your presentation during its construction so you do not lose sight of the goal.

Diagrams and figures: Keep them simple. A square or rectangular box can be labelled “Host,” while another box can be labelled “Client.” Other boxes can carry labels too: “Router,” “Hub,” “Server,” or whatever, and so on. A straight line with shorter straight lines to named boxes can be labelled “Network.” Avoid the temptation to try to reconstruct what a piece of technology actually looks like–you can show photos and/or display the actual hardware later, if necessary.

Consistency: Be consistent, as it avoids confusion. Years ago–1985, maybe?–I attended a presentation where the computer screen was described by the same presenter as a “display,” a “screen,” a “VDT,” and a “CRT.” And this was not the only things the presenter used different terms to refer to. Needless to say, we attendees left there more confused than ever. Which reminds me…

Acronyms: Explain them, and reiterate the explanations any time you start to see your audience looking confused.

And finally … don’t reinvent the wheel. I well remember being assigned to create training sessions that were the same as those offered at the local tech school, college, or university. (A training session called “Understanding TCP/IP” would be a good example.) There was no need for us to replicate what was offered elsewhere; we needed the time lost in creating such presentations to deal with creating training for our proprietary hardware and software. It may be a bit of a tough sell, but if you can convince management that you don’t need to create something if there is a perfectly good offering elsewhere, you’ll have more time to address the creation of presentations that better deal with your company’s particular needs.