Thanks for joining me for lesson one where we're going to explore benefits as drivers to design. An easy and fun thing for engineers to do is to jump into engineering solutions. Oh, you want something that does this? Let me work it up for you quick and create a prototype. We've gone too far in the direction of engineering before we've really explored and had an opportunity to talk to our cross functional team about the supposed benefits of this product concept.

How do we even do something like this? Well, I have a model for you. We're going to break out the benefits into different parts so we can get drivers not only for the product design itself, but it would also affect other parts of the product offering.

Here's what we're going to cover in this lesson.

• We're going to explain the difference between needs benefits, features and design inputs. What we really want to do is get on the same page when we're talking about these things and to identify where in the design process we're going to be working with our team.
• In this particular lesson, we're also going to be developing features into potential design inputs, which are those things that we really want to engineer against.
• And we're going to do that with a team using a benefits model. You'll see how a benefits model can help us and our team chunk out information and start to create ideas and how it will be helpful.
• Also to prioritize we can prioritize potential design features against a level of customer satisfaction and then determine how much of that feature we want to implement in our design that's using a model.

Now, let's talk about needs benefits and features. What specifically we're talking about in relation to product development. We are working at the concept phase of product development where we still don't know particulars about how we're going to do or implement a design. We're still exploring the use space and the users and the use environment. And in this lesson, we want to focus on the benefits for some design inputs within the concepts of this lesson. Our team has already identified needs, that's what prompted the whole project needs could be something that's known by our customers and it also might be something that they really haven't even considered or thought about. We've identified these gaps in between what the user can do now or has now to what they want to do or have needs identify and characterize the problem space. Our project goal is all about developing a product that our customers will use to be able to fill a need. We're not only providing a device, we're also enabling our customers to use it and benefits our outcomes of using a product that will fill the gaps that people have. They can be real outcomes or perceived outcomes. A benefit statement links products and users together. If we start developing our product from benefits, we're keeping the user in mind in both how they'll use our product and the positive outcomes that they'll experience because they used our product, a benefit statement could be worded like this. Our customers can use product capabilities or have characteristics so they can experience this value. Our product features are the product capabilities or characteristics that we've designed for our customers to use.

Let's review how this benefits model can be used with our teams for design inputs. We can take our benefits statement and reorganize it into something like an equation. We can describe benefits as a product feature that gets used and the impact that feature or use combination has on our user. With that impact. We can associate that with a customer satisfaction rating. Ultimately, what we want to do is we want design inputs which are the physical and performance requirements of a device. We can start engineering solutions with design inputs, but we can't take too big of a jump from the user's experience to design inputs because chances are we'll be missing some important information. We'll end up in a situation where we don't have buy in on our design because we've missed some crucial talks with our team benefits is that stepping point between our customer needs and the technical design inputs that we're going to be engineering against. Another problem is that design inputs are the language of engineers, not the cross functional team or our user. We want to develop design ideas with our cross functional team. Before we start doing engineering activities, they're going to help us to bridge the user's experience to design inputs and they'll give us additional perspectives about the use space to develop solutions that are going to make a difference. We can break out benefits and explore their drivers as that step between customer needs and design inputs. We'll be identifying the actual features and their impact themselves, but we can also drill down a little bit into the drivers of each of those. The feature drivers are the reasons. The product provides the capabilities and characteristics and this is where we're going to look to create design inputs. We'll be developing options with our team in order to be creating this feature as part of our product design impact drivers are those reasons that affect the impact. Given the features are provided, we can really look to impact drivers to increase value and increase positive experiences. It will help us to develop offerings to increase satisfaction. Sometimes these are design inputs into the actual product. Sometimes they are service related and support function related. If our benefit is going to be providing a lot of customer satisfaction. Then we want to look at these impact drivers to increase that satisfaction. These are all drivers to a benefit. Don't worry too much about what goes where the main reason to use. This type of model is getting our team to think about the product its use and then also the customer's experience with it, given that our product has a particular feature, it breaks down a big chunk of information to be able to come up with different ideas. Ultimately, we're going to take the results of this conversation and start developing our design inputs.

This model is also going to help us with prioritizing what is it that really matters for this product because we can prioritize our features with the impact that they provide using a satisfaction rating. Not unlike other team exercises where we break out an effect of an unintended output into its parts to analyze risk and prioritize risk factors including developing design inputs. It's just from that point of view, we're controlling bad things from happening through our design choices with a benefit breakdown. We're boosting good things to happen through our design choices.

I've introduced the benefits statement and the breakout model for us to be able to get design inputs. And I've also talked about a satisfaction rating and let's get more into that how we're going to use a satisfaction rating for design priorities. Really, we want to relate our impact to satisfaction rating to a two by two chart called a Kano model. Now, just to back up a little bit, we use two by two charts to prioritize lots of different ideas. We can do this within our brainstorming sessions to help us prioritize ideas to develop actions. We can use them for our own project management and task management. I'm sure you've heard of urgent and important charts or time versus impact or value versus effort or risk versus reward. These are all ways that we can evaluate ideas and concepts with two different criteria. A Kano model is a special kind of two by two chart. It's evaluating ideas against the level of customer satisfaction that it would provide and how well it's implemented in our product design. It's not just a two by two chart, but it also has arrows that represent how product characteristics when they're implemented can affect customer satisfaction. It's a snapshot in time and time does have an effect on whether a characteristic stays on one area of the graph or it shifts to another. But really a kind of model we can look at to help a team discuss what customers really expect. What would really increase customer satisfaction? How can our product differentiate itself from the other competitive products in the field? And how is it possible to excite customers as well as non customers? And on the opposite side of that, what are the kind of things that could be neglected or that we don't want to have in our product because it's not providing customer satisfaction out of these two ideas, the benefit equals the outcome and the impact we're developing customer needs. And out of the model, we're developing design priorities. Let's take a closer look at the model. The overarching idea of the model is that not all design inputs are equal, not all customer statements have the same weight as the other ones or not, all of the characteristics that we decide to develop to meet this user need should be implemented equally. Let's look at the three main areas of the model. First, let's look at the middle or the one dimensional area of our model. This is represented by a line that goes from negative to positive through the center of our model through the center of the axes. And it's almost a direct relationship between customer satisfaction and how well something is really done. These one dimensional factors are really wants, they lead to customer satisfaction when they're met and dissatisfaction when they're not met. In fact, the better they're implemented, the higher the customer satisfaction. Now, let's look at another factor of the model above our one dimensional line. There is another line and it does extend into not done at all and then it quickly escalates to a high customer satisfaction. These are called attractive factors. They're really delight, those kind of characteristics that are unexpected if we don't have these kind of characteristics in our product. It doesn't really cause customer satisfaction. But if they're there, they cause a high satisfaction with very little implementation. Almost opposite of that line on the model is our must be factors. Our must be factors extend from a low customer satisfaction area into something that's neutral. If they're not included, they create customer dissatisfaction and when they are included, if they're done well, they lead to something that's more neutral, doesn't really increase the customer satisfaction, but they expect it. It's a must be keeping those factors. We can add two more. There is also a neutral factor and a reverse factor. The neutral factors are really indifferent. Our customers don't really care if they're there or not. They don't make sense to implement because they don't have an effect on customer satisfaction. But there might be a reason that they're there and we'll talk a little bit more about that in a bit reverse qualities. Well, we want to avoid those reverse factors are really a rejection of our product design. They really dissatisfy the customer. And in fact, the more we have of it, the more dissatisfied that they are, and it can also lead to a bad brand image. So neutral and reverse factors are really not value added for customer satisfaction, not value added or worse given the two by two nature of the model and its different factors or categories, we can create a satisfaction rating that corresponds with these different areas of the cono model. Our satisfaction rating could go from 1 to 51 being the reverse the thing we want to avoid to neutral. Three, the must be four, the one dimensional where the more we have of it, the better and five the attractive they. Wow, this is really special. We're not really assigning a satisfaction rating number to be able to do any kind of mathematics with it. But it is an easier way for us to prioritize our features, the intended outputs of our product design. And we're going to apply that satisfaction rating to the impact in order to prioritize these features within our satisfaction rating to further enhance our understanding of these different rating scales. We can also correlate that with a voice of the customer's statement. For example, for a satisfaction rating of five for an attractive mode on our model, we could think that our customers would say I'm delighted or excited. I didn't even know I wanted this or that this was possible and our one dimensional could be I want this the more of it or the better I get it, the more satisfied I am. This can also help us with our teamwork in deciding what rating would really apply to the impact that we're looking at. Now as far as what to do with this information, we're assessing our features versus the implementation. Remember those are the axis of our cono model, customer satisfaction and level of implementation. We're really asking how much do we want to implement this feature into the design? If we have a characteristic that we think is attractive, we could think of that as critical to motivation because that's going to motivate our users to buy and use our product. If our characteristic is one dimensional, we could think of that as critical to satisfaction because the more we have of it, the more satisfied our customers are going to be, if we have a must be factor, we can think of that as critical to quality. Because if we don't have that, our customers are not going to think that our product is of a quality nature, neutral factors are not critical, but they might be necessary. And the reverse factor, we want to intentionally avoid the result of this teamwork on breaking out the benefits and assigning a severity rating using the cono model. It's really one input into project management and defining design priorities. If we discuss the benefits of our particular design and we don't have any attractive benefits, then we may need to research to add some attractive benefits because remember those are critical to motivation for our customers to buy and use our product. So we would like to identify some attractive characteristics. If we have many one dimensional factors, then we may need to further research again to identify which one takes priority. We're going to have limited time resources, money in order to be able to develop this new product. So is there a characteristic that takes priority of the others? And which one would that be identifying? This could help us ask further questions to be able to find out the answers from our customers with the must be characteristics. What steps can we take to ensure that it's implemented? We can also think of these characteristics as critical to quality which is going to affect the development of our product through the product development cycle. It'll help us decide what it is, we need to monitor and control for quality to ensure that these must bees are happening and that they're happening at the level that they need to for the characteristics that are neutral. Maybe the customer doesn't care about it, but is it needed for processing to be able to make the product? There may be internal customers that need this characteristic even if it doesn't satisfy the customer. So the model is a great thing to be able to use in concept development because it's going to help you further define your product characteristic priorities, things you want to manage in product management and product development, the decisions that you make about quality controls later and also your internal customers.

With these two models, the benefit breakout and the Kano model, we can move from benefits to features and design inputs and then evaluate the importance of those inputs to customer satisfaction. Let's review the steps that we use to explore benefits. We first list out features and break out benefits into their features and their impact. Then we list the potential ways we can drive the feature availability in our product. Then list ways to drive its impact to occur. Then we get team consensus on a qualitative rating of customer satisfaction. That level of customer satisfaction can be applied to the drivers and the design inputs that we're developing. We can also prioritize features against each other using the ideas of the Kano model with all of this information, with our cross functional team, we can really start to explore those design benefits and their drivers and start drafting design inputs and we can maintain this information and continue to use it throughout the development process. This exercise can also lead us to more questions in which we would want to go back to our customers and ask them those questions. We use this as a learning opportunity with our cross functional team before we start doing engineering design. But we're going to get a lot of user information about our product concept that we can use for great designs.

What did we talk about in this lesson? We talked about a whole lot. We know the difference between needs which are gaps benefits, which are values and experiences and how features and design inputs relate to those things. We used a benefits model with a benefits statement to help break down those customer experiences into something that we can iterate for design features and for design inputs. We also related those features to a level of customer satisfaction and we now have a way to assess that customer satisfaction to really determine how much we want to implement that feature into our product design. What's its priority? Thanks for joining me in the lesson today and I'll see you in the next lesson.

[progressally_media post_id="12202" media_id="3"]