Before You Start Engineering Solutions, Do This

We're given information about an opportunity for a new product. 

We talk about what can happen when we start solution-building just with what we're given. And we talk about an alternative start to a new engineering project.

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.

Transcript

Speaker 1: 0:00

In product design engineering, do you solve problems or do you find problems? The answer is yes to both. Let's talk more about what happens when we skip the finding problems. Step after this brief introduction. Hello and welcome to Quality During Design, the place to use quality thinking to create products, others love for less. Each week we talk about ways to use quality during design, engineering, and product development. My name is Diana Dini . I'm a senior level , quality, professional, and engineer with over 20 years of experience in manufacturing and design. Listen in and then join us. Visit quality during design.com. Engineering things is a lot of fun. I mean, you have to love it in order to be working in engineering, tinkering, figuring things out, and solving problems as a cornerstone of an engineering career. When in new product design or when we're first starting to design anything, we are given a problem or a task to solve. Sometimes it's a simple ask and new product development. It might be an opportunity that's been identified by the company. Someone has talked with customers, vetted an idea, came up with some customer needs, and then we're given that information to design against to be able to solve that problem. So we take that information, we go off to our corner and we design the most spectacular product design ever. It's intricate, it's complicated. It's an engineering marvel. We even worked with and coordinated with some other engineering disciplines in order to make it happen. And then we presented to the people that created the customer needs and identified the opportunity and they say, what is this? This isn't what we asked for. This isn't going to solve our customer's need. And then we say, but we spend so much time developing this product already. We've got it mostly done. You have a prototype. We've have preliminary manufacturing and production processes. It's nearly done. And this is what I call the ta-da flop because we had gone off into our own corner and said, TA-da , here's the design. And then when we presented it with our cross-functional team, it went flop. It really wasn't what they needed. So what went wrong in this situation? Or how can we prevent this kind of scenario from happening in the first place? It happened way back in the beginning. We jumped too soon into engineering a solution to a problem that somebody else already defined. We made an assumption. We assumed that they told us everything that we needed to know to be able to design a solution. But here's the thing. We are different people and different people have different experiences and baseline knowledge about things, and especially when we're working with different functional groups within a company, we have different perspectives of the same problem with all good intentions. The other functional groups in the company gave you information to be able to design against, and they felt like it was complete, but it really wasn't, not from an engineering point of view. It's not so much that it's lacking, it's just that different life experience and different perspectives that are coming into play. They don't know exactly what to tell you or they assume that you know the same kind of things that they know. And on the flip side of that, you don't really know what specific questions to ask them, so they kind of give you the information and then we just accept it and take it and move on with it. And that's what can lead to the [inaudible] flop. There are things we can do to avoid this situation. Instead of just accepting the information and moving on, we need to stop ourselves from doing the fun problem solving engineering stuff and be a little proactive and ensure that we found all the problems that it is that we're really being asked to solve. We need to take off our problem solving hat and put on our problem finding hat before we even know anything specific about our product, what we're designing with, just given an opportunity and some customer needs, we can start taking a closer look at the use space of our product. You're probably familiar with P diagrams where you have an input, a black box system, and then an output, and you might have intended outputs and unintended outputs. We can have that same kind of viewpoint with the concept space where our customers are at point A , they use our product to be able to do something, and they end up with an output that they want. Within this use space, we can take a closer look at the benefits that our product is going to be giving our customers, and we can look at this with our team and be able to prioritize and start teasing out some design inputs from just the benefits. We can also look at the unintended outputs and look at symptoms, things that the customers might experience if things go wrong, and that can lead into some risk analyses . And we can look at the use process, the things that customers do to be able to use our product, and we can review those steps with our team and do analyses and get even more design inputs. When we're looking at the concept space like this with our cross-functional team, we sort of need to be facilitating the meetings because we are the ones that are on fact finding missions. We're on problem finding missions. Our goal is to ensure that we properly understand the use space, that we get all the design inputs that we can, and that we give our cross-functional team opportunity to be able to give us those design inputs. We arrange meetings and get togethers. We ask the critical questions, and we develop these ideas with our team, and that's how we can avoid the ta-da fob. And this is what I teach in quality during design, quality and reliability tools and structures and techniques can be used to be able to facilitate those kinds of conversations. I'll talk a little bit more about this next week, and I'm also going to be following up this month with an invitation. Until then, please visit the website quality during design.com . We have a library of resources we've been collecting there. And while you're there, subscribe, it's an easy way to stay on top of all the things I'm doing with quality during design. This has been a production of D Enterprises. Thanks for listening.