Welcome back. We're in lesson two. This lesson is called use drivers to explore characteristics. One of the things we don't want to do is settle into analysis paralysis where we are going over and hashing out the same details over and over again and not actually moving forward with product design. One of the ways we can stay focused is to take a minute and prioritize what's important. That's what we're going to do in this lesson specifically, we'll be covering these objectives. We'll be looking at drivers to benefits for design inputs. We're going to explore that concept a little more. Take it to the next step. We're going to construct three diagrams of benefits to be able to get to the level of technical design inputs that we need for design. And we're going to look at matrices to compare features with inputs and make sure that we're developing and engineering. The right thing. We've been talking a lot about concept development and benefits at concept and with this lesson, we're extending that to the design space a little more, we're getting more into technical design inputs. We're still relating what we've been learning and what we'll be learning through this process to the concepts and benefits. We still haven't started engineering solutions quite yet. In the last lesson, we talked about a benefit breakout model where we explored features and their impact and we applied a customer satisfaction rating that related to a model where we could prioritize our design features. In this lesson, we're going to be taking what we learned in the last lesson and continue to develop them into technical design inputs. Let's look at those drivers to our benefit and see how we can get design inputs from them. We've used the benefit breakout model to create opportunities and increase positive experiences. And we do that by looking at what can drive the feature to be available and what can drive the impact given that the feature is available. Both cases, we're looking for design inputs. Now, in our scenario, from last time, we came up with different drivers for features and different drivers for the impact. The drivers of the features we came up with were tools are included, assembly joints are visually matched, 10 or less screws and bolts for a user to tighten and a simple unpacking method. Some of these inputs are well on their way to being developed and some of them are not quite at the level of a technical design input, something we can use to help us get. There is a tree diagram. Tree diagrams are a pretty useful quality tool. There's a lot of different types of tree diagrams that you've seen before. There is the quality. Why why diagram fault tree analysis is a type of tree diagram and event tree analysis, a work breakdown structure. Even the organizational charts that your company uses is a type of a tree diagram. Really, it's a graphical representation of something that is great as a team tool. So yes, we use this with our cross functional team to explore the benefits to get two characteristics. We start with the benefit and we ask, what is it that we can do? What kind of characteristic could drive that benefit to occur? And then we go to the next level in order to have that driver occur, what else would we need to do? Now, we don't want to get too specific, too fast and we don't have to go to the same level for each branch. We just want to go far enough so that we can define a characteristic that's necessary and sufficient where we want to end the tree branch. And our tree diagram is at a characteristic. Again, we're doing this for information for ourselves, for design inputs, different industries and different products have different requirement, goals that they want to obtain. Your ending characteristic might be a requirement, a design requirement, it could be a metric in its value. It could be a property based requirement. An example of a property based requirement is reliability requirement. For example, when the relative humidity is 60%. The reliability of the switch to successfully close the circuit shall be 85% with 90% confidence after a dormant time period of 300 days. That's an example of a property based requirement. You can also be defining characteristics that are structural or behavioral or logical in nature or a mix of the two. And we could be talking about concrete objects or abstract objects. The level of detail is meaningful without really defining the features of the product. So now we have a list of benefits and different characteristics. We can further understand the relationship between the two by looking at matrix diagrams and really the matrices we're going to use. There are two different types of matrices. One is an L shape which compares two groups of different items and the other is a roof shape which compares one group of items against itself combined. It can really give us some important insights into our customers, their needs and what it is we're designing this matrix looks like the house of quality which is used with quality function deployment, but we're not going to take it that far. In this lesson. In this lesson, we're going to be setting up these matrices to look at the relationship between features and design inputs. Let's take a look first at the L shaped matrix in the rows. We're going to be listing our features with the priority. The priority could be the customer satisfaction rating that's associated with the model that we used in the last lesson. Then we're going to list in our columns, our design inputs, the, what we're going to do to implement this feature in the middle is our relationship matrix. This is where we can ensure our features are being duplicated or overlapped and we can ensure that we have design inputs that make sure that the features are available for our product design. And we can prioritize our list of design inputs associated with what level of customer satisfaction, the strength of that relationship to the feature. And if that input supports more than one feature in our examples, we're going to be using a strong medium and a weak relationship. Now, let's talk about the roof shaped matrix. We want to use the roof shape matrix to understand how design inputs are related if they're correlated or not or if they're competing for a trade off. If you're talking with quality professionals, they might also call this a correlation matrix. We can use the same relationship legend that we use for our other matrix. Sometimes teams decide to use a different legend, one that shows positive correlation or negative correlation. You can decide with your team what would work best for you. If you're just starting out with something like this, I recommend sticking with one legend, the L shaped matrix and the roof shaped matrix together can be used to help us understand relationships between the features and the customer satisfaction rating and the design inputs that we're developing. It will also help us refine the design inputs so that we can group similar inputs together or eliminate inputs that are unnecessary or maybe clarify them. There are more rows and columns of information we could add to these matrices, we could add the level of difficulty to implement a feature that could be a weight that we could apply. Some teams add the measurement unit or the target spec and adding that type of information could be useful to your team in order to make decisions. But let's start with the information that we have and explore how we can get started. We can ensure that our features aren't being duplicated. We can make sure our inputs are covering our features and we can prioritize our inputs with the customer satisfaction and understand the strength of that association. We can understand how inputs are linked. So we can see which ones are competing for trade offs or if there are certain inputs that support more than one feature that could be an indication of quality and cost concerns that we want to investigate more. These matrices can also help us refine the design inputs. Are there some that can be grouped if they're similar? Are there some that can be eliminated because they're just not necessary? And are there other ones that just need to be clarified or restated to be sufficient? These are all the things that we can talk about with our team using just the L shape matrix and the roof matrix together creating a matrix diagram is something that can be helpful to do with our team practices for matrices at concept development, 25 items is too big. You can imagine matrices getting big and unwieldy. We really want to focus on the high value benefits or the benefits that are confusing that we need to explore more. Another problem teams have with using these kind of matrices at concept is that they linger on the details past the point of learning for action, they have analysis paralysis to avoid this. We really want to focus on teamwork and learning for decisions, not perfection. We want to take something, understand the relationship, understand where we may need to do a little more research and then move on another problem that could be seen when using these matrices is conflicting customer bases, maybe you're developing one product, but you really have two types of customers that would use that one product that could lead to confusing outputs and results of using these matrices to address this. Just be consistent with how you're going to use your matrix. And some ideas is you could use a matrix for each of your customer bases or prioritize one type of customer or over another or you can average out the satisfaction level for a benefit. However, you choose to handle that situation just be consistent. Another best practice is to use paper or a worksheet or other online whiteboard. When doing these matrices at this level, don't try to fit it into an Excel sheet because doing so slows down the brainstorming and the team discussion when possible use a whiteboard. And I showed you an example of how you could do that in a whiteboard application online. So what have we talked about in this lesson? We talked about how we can use the drivers to benefits to start defining some design inputs for our product design and for the drivers that we needed to explore more. In order to get an input, we used a tree diagram with our team to get there. We also looked at matrices, a combination L and roof shaped matrix to compare features with inputs and really get closer to our finished design inputs. Thanks for joining me in this lesson and I will see you in the next.
