Many presentation books and guides seem to focus on presentations that we see at conferences, for sales pitches, or for executive meetings about business topics.
They don't seem applicable to the technical design reviews that engineers host.
But they do relate.
We talk about just 3 ways that we can change how we can plan technical design reviews, using some of the principles of presentations.
Visit the podcast blog for extra links and resources.
Give us a Rating & Review
**NEW COURSE**
FMEA in Practice: from Plan to Risk-Based Decision Making is enrolling students now. Visit the course page for more information and to sign up today! Click Here
**FREE RESOURCES**
Quality during Design engineering and new product development is actionable. It's also a mindset. Subscribe for consistency, inspiration, and ideas at www.qualityduringdesign.com.
About me
Dianna Deeney helps product designers work with their cross-functional team to reduce concept design time and increase product success, using quality and reliability methods.
She consults with businesses to incorporate quality within their product development processes. She also coaches individuals in using Quality during Design for their projects.
She founded Quality during Design through her company Deeney Enterprises, LLC. Her vision is a world of products that are easy to use, dependable, and safe – possible by using Quality during Design engineering and product development.
Many presentation books and guides seem to focus on presentations that we see at conferences, for sales pitches, or for executive meetings about business topics.
They don't seem applicable to the technical design reviews that engineers host.
But they do relate.
We talk about just 3 ways that we can change how we can plan technical design reviews, using some of the principles of presentations.
Visit the podcast blog for extra links and resources.
Give us a Rating & Review
**NEW COURSE**
FMEA in Practice: from Plan to Risk-Based Decision Making is enrolling students now. Visit the course page for more information and to sign up today! Click Here
**FREE RESOURCES**
Quality during Design engineering and new product development is actionable. It's also a mindset. Subscribe for consistency, inspiration, and ideas at www.qualityduringdesign.com.
About me
Dianna Deeney helps product designers work with their cross-functional team to reduce concept design time and increase product success, using quality and reliability methods.
She consults with businesses to incorporate quality within their product development processes. She also coaches individuals in using Quality during Design for their projects.
She founded Quality during Design through her company Deeney Enterprises, LLC. Her vision is a world of products that are easy to use, dependable, and safe – possible by using Quality during Design engineering and product development.
As a product design engineer, you're likely going to have to present at some point where you may have to present every day. If you really think about it, you're presenting technical information to people to make decisions or to understand something so they can help you with the design or maybe even with your customers so they can give you feedback on your concept. What are some things you might be able to do to improve the way you present your information? Listen in after this brief introduction, Hello, and welcome to quality during design the place to use quality thinking to create products others love for less. My name is Diana. I'm a senior level quality professional and engineer with over 20 years of experience in manufacturing and design. Listen in and then join the conversation@qualityduringdesign.com. Today, I'm coming off of a four month coaching experience about public speaking and developing speeches and the different kind of speeches, which is making me think about presentations in general. And when I think about product development, engineers and design engineers, we have to do a lot of presentations. Now, the speeches that we need to do in work, we may not even really think of them as speeches or formal presentations, but aren't, they now they're not the same as a keynote speech, which is the kind of speech where you would go to a conference and someone's on a stage and everybody that's attending the conference is watching them. Those are inspirational and are trying to make a bigger impact with your ideas and how you do things. And we're usually not trying to convince somebody of anything. Uh, you're not trying to sell somebody something or convince them to do something different. Our engineering presentations are usually about showing the facts, talking with people about it, and then coming to a consensus at the end of what to do next, or what decision to make, what part to choose. We don't necessarily wanna think of our engineering presentations as salesy, because that doesn't seem true to the scientific method and the principles that we adopt for design. But I can tell you that from doing design reviews, hosting them participating in lots of design reviews and also presenting at conferences and hosting workshops. There is an overlap between the technical design reviews or the design reviews and those keynote speeches. Some of the books that are popular and out there about presentations and using PowerPoint and how information is transmitted to people. Well, they're focused on those keynote presentation styles or those influential and sales and marketing type of presentations. The two books I'm thinking about most are data story from Nancy dote and beyond bullet points by cliff Atkinson, we can take these lessons that these authors are giving us about speaker and audience and presentation and delivery and apply it to technical design review. Let's do just that today. Let's take these general presentation principles and figure out how we can apply it to a technical design review for our purposes. And that it makes us feel good about transferring the information that we want. I'm going to give you three guidelines. So let's start with number one. First of all, we need to recognize that a technical design review is not for us. It's for the attendees to review data, assess choices and our recommendations and make a decision based on data. We need to make our technical design reviews about the audience. First step toward that is knowing your audience. There might be standard operating procedures at your business that dictate which functional groups need to be part of the technical design review or design reviews. In general, you may need to have a representative from marketing, from manufacturing, from field or commercial operations and an independent reviewer to provide feedback on your recommendations. Once you know your audience, you need to allow them to prepare, to help them to prepare for the meeting at least 24 hours in advance, give them a technical report and an agenda for the meeting. We definitely don't want to water down or dumb down our reports for anybody on our team. You know, as engineers, we do get hung up in all the technical stuff, but we also have a responsibility to make it accessible to those that need to make a decision. And that includes giving them and allowing them to see our full technical report and synopsis, give them the information and let them study it and develop questions about it. So they can prepare for the design review meeting. The rest of the people on your team have a different viewpoint, a different way of looking at things. And that's the beauty of a cross-functional team. These design reviews are a way for you to communicate what, you know, bring them up to speed so that you can all make a decision together to summarize trick number one for awesome design reviews. It's not about you. It's about them. Trick number two, I'll tell you another thing that it's not about is it's not about the methodology and design reviews. We tend to rehash the journey that we took to get to the data now for a posterity sake. And for thoroughness, we do wanna create a technical report, something with a executive summary and an introduction and background, a type of document that would allow somebody else five years from now to recreate the same results that we got presenting this information to someone else, or another group of people is not to place to start from the top of the technical report and take them on that same journey. We need to start somewhere else. We start with our overall problem and topic. Why are we meeting today? What are we here to discuss? Then we discuss the relevance of this meeting to the rest of the project and to other decisions that were made. We describe the challenge that we had and what it is that we want to solve. Then we consider our options. We lead with our recommendation, then we explain it. And then we describe the methodology of how we came to our recommendation, giving your audience the problem and topic, the relevance, the challenge, and what it is you want to accomplish in the design review that gets the audience warmed up to the topics and for the discussion, even if they've studied and prepared for the meeting, they're likely coming from somewhere else where they've just had a discussion about a completely different topic. So warm them up, get everybody on the same page and aligned with thinking about the topic of your design review, making the recommendations, then explaining it, and then getting into the methodology helps people to evaluate the recommendations as you're discussing them and talking about them. If we start with a methodology, first, it leads to overwhelm and we lose focus on what it is we're trying to evaluate and choose between to recap, tip number two for awesome design reviews, realize that it's not about the methodology. It's about the recommendations and being able to choose between the different recommendations to make a decision tip. Number three, for up in your game in design reviews, use your technical report to communicate the technical data, refer to the report in the meeting, within your report, your data is within the context of everything else, the methodology, the results, and other facts that you've uncovered. Give them a copy of your full report. The whole Ang. Now you would've emailed this 24 hours in advance for them to look at, but make sure they have a copy of it. At the top of the meeting, you can provide paper copies or you can email them just before the meeting starts so that a copy of your report is in the top of their email and they can access it easily. Consider mapping out the recommendations all together. You're going to be mapping out your recommendations during the presentation verbally. You could also choose to map it out on paper or on an electric file that you send with your report. Keep it brief and high level because you're going to be talking about the details and all the details should be in your technical report, giving your audience all the technical information early and together in their natural formats helps do two things for your design review. Most importantly, because it's about them and not you, our principle, number one, it's making sure that we're able to communicate this technical information adequately for discussion. It not only helps our communication to our teammates. It also helps us because now we know that everyone has the technical information and we don't have to cram it on a PowerPoint slide. The kind of slide with a big graph and tiny print that nobody can read. Anyway, if we're using slides at all, we can use them to feature big graphics, maybe a photograph of a failure that we saw during tests or visual aids and graphics to help our team better understand the information that we're sharing, but we're not using the slides to share the information that's already been done by sharing our reports, psychologists and sociologists study the information transfer between a presenter and their audience. And there are limits of working memory. A policy that we have is that if we put it on the screen and talk about it, that all the information on that screen is going to be transmitted to our audience. And that's just not the case. Our audience is getting just bits and pieces of what it is that we're presenting and talking about from a slide with our audience, there is also visual and verbal synchronizing going on in their minds, which also makes it difficult to assimilate and understand information, especially technical information. You can think of it as sort of guiding the attention of your audience through the information so they can assimilate it and make a decision. So tip number three, for stepping up your game for design reviews, share the technical results separately in their natural format altogether, and maybe include the recommendations with it and significantly pair down the content on the PowerPoint slides so that you can best communicate with your audience. And those are my recommendations for your design reviews. For today. We reviewed three things today, but really there is one overarching theme over all of them. And that is, is that these design reviews aren't for you, therefore the audience. So decisions about how you're presenting the data in what order, what you're showing on the slide versus what you're handing out. It's all about having your audience in mind. I'd love. If you would visit this blog post@qualityduringdesign.com and leave a comment for me and the other readers. What is one thing that you do during your technical design reviews that you think would benefit other engineers? Please go to my website@qualityduringdesign.com, you can visit me there. And it also has a catalog of resources, including all the podcasts and their transcripts. Use the subscribe forms to join the weekly newsletter, where I share more insights and links in your podcast app. Make sure you subscribe or follow quality during design to get all the episodes and get notified when new ones are posted. This has been a production of Dean enterprises. Thanks for listening.