PSNWebForum-Sati..

Slide 1: www.ProductStrategyNetwork.com September 19, 2008 - 12 Noon Eastern U.S. Time

Slide 2:FYI 40-45 minute presentation plus up to 20 minute Q&A Use the Q&A panel of the web conferencing software to submit questions at any time, and after the presentation. This webinar is being recorded. The presentation with audio will be available for download by PSN Members from the Product Strategy Network website. Participants can request a copy of the slides by sending an e-mail to: info@productstrategynetwork.com The attendee list is not made available (privacy policy)

Slide 3:Today�s Speaker

Slide 4:Agenda Definitions Motivation To institute a formal Design for Gross Margin (DFGM) process Process Overview What we are going to talk about What we will pass over Introduction of individual Stages and Tools

Slide 5:Definitions Price: Customers will pay a price for features that they perceive value in. We determine �price� in terms of features Cost: Our company implements with production and supplied hardware which has associated costs. We determine �cost� in terms of hardware & service Margin: The difference between the price the customer is willing to pay for our product and our costs to produce it. GM=(price-cost)/price Features: Offerings or elements of a product that are embodied in a specific form. The resulting response to requirements that are often the team�s �solution.� Requirements = Needs: Statements of what functionality a product or service possesses in order to satisfy or delight. At this point, I�m introducing specialized words with specific meanings which require us to avoid ambiguity. Let�s consider the following definitions. When I refer to these so-called requirement statements, I�m speaking of solution-free articulations of functionality, that is, these statements contain no description of means. A recent study conducted by our firm indicates that a majority of both marketing and engineering professionals do not readily distinguish between the two terms. The importance of the distinction is clear when it is realized to what extent a designer�s hands are tied when so-called requirements are solution-oriented; in fact, much stronger (read: innovative) solutions may be feasible if the opportunity to creatively develop these is presented. . At this point, I�m introducing specialized words with specific meanings which require us to avoid ambiguity. Let�s consider the following definitions. When I refer to these so-called requirement statements, I�m speaking of solution-free articulations of functionality, that is, these statements contain no description of means. A recent study conducted by our firm indicates that a majority of both marketing and engineering professionals do not readily distinguish between the two terms. The importance of the distinction is clear when it is realized to what extent a designer�s hands are tied when so-called requirements are solution-oriented; in fact, much stronger (read: innovative) solutions may be feasible if the opportunity to creatively develop these is presented. .

Slide 6:Why Institute a DFGM Process? MEDRAD is market leader in all modalities we serve MEDRAD persistently achieves double digit growth rates year over year We continue to introduce products that meet and exceed customer expectations But �! Our products become ever more sophisticated, feature rich, and complex Margins are necessary to continuously fuel innovation The cost of goods is growing faster than achievable prices

Slide 7:What Do We Expect Of The Process Should be repeatable and simple to follow Should integrate or link to the stages of the existing product development process Should not overwhelm with additional work but contribute to required deliverables of NPD Should engage the entire product development team and facilitate communication with other business functions

Slide 8:DFGM Process Overview

Slide 9:Focus of Today�s Session

Slide 10:Introduction of the Example An example which I hope all of you will be able to relate to but it is not a current MEDRAD project The reasons are: Not many of you may know the purpose and functionality of MEDRAD�s products The process goes into a lot of detail in terms of feature performance, pricing, and cost Most of this information is proprietary in nature Development of a new cell phone Code name: �Babble�

Slide 11:Brief Recap of the MEDRAD�s VOC Process

Slide 12:Stages of the MEDRAD VOC Process The MDPD process flow may be seen as consisting of five stages, each cumulatively adding value to the definition effort toward the dual goals of increased market acceptance and reduce development time. Gathering Customer Information has two objectives: to gather or collect raw, unfiltered soft or language data from customers. By the way, when we speak of customers, we�re referring to the set of people who in any way are beneficiaries of the product�s functionality's or are involved with the purchase or handling of the product. In this light, some prefer to substitute the word �stakeholder� for �customer� to imply this broader consideration. The second objective of this stage is to develop an understanding of the customer�s environment of use for the intended product or service. Think of this topic in an extreme case: suppose for example that we are rather un-expectantly charged with defining and developing a new SCUBA diver�s mask! How many folks in this group have significant experience using or are very knowledgeable on this topic? [objective is to have no hands raised!] Would it not be sensible to become intimately familiar with the SCUBA diver�s environments of use (recreational and commercial?) before designing a product to meet or exceed their expectations? This is the same argument which strongly prompts your team to develop a sense of walking in your customer�s shoes, of developing a contextual anchor in the minds of the team members. The output of this first stage of visitation will be a documentation of this contextual understanding. In fact, because just one document will be produced by the team, we see that this understanding of the customer will be common amongst the team! When was the last time both your marketing and engineering groups seamlessly agreed on their understanding of the customer, including their current problems and frustrations? Now, visiting customers is not a new concept. Most readers will have a fairly extensive history of discussions with customers. But I would now ask, what do you do with the data once you�ve heard it? Or perhaps more to the point, how do you process the data in order to discover customer needs? Most firms have little if any experience in systematic, exhaustive and reliable approaches to analyzing soft language data collected from customers. This is one unique aspect of the MDPD process technology; where the rubber meets the road. The second stage calls us to convert the raw data collected during the first stage from customer language into company language, or into a form which the team can act on. The result of this conversion or translation are statements of what functionality the intended product or service may possess. The MDPD process flow may be seen as consisting of five stages, each cumulatively adding value to the definition effort toward the dual goals of increased market acceptance and reduce development time. Gathering Customer Information has two objectives: to gather or collect raw, unfiltered soft or language data from customers. By the way, when we speak of customers, we�re referring to the set of people who in any way are beneficiaries of the product�s functionality's or are involved with the purchase or handling of the product. In this light, some prefer to substitute the word �stakeholder� for �customer� to imply this broader consideration. The second objective of this stage is to develop an understanding of the customer�s environment of use for the intended product or service. Think of this topic in an extreme case: suppose for example that we are rather un-expectantly charged with defining and developing a new SCUBA diver�s mask! How many folks in this group have significant experience using or are very knowledgeable on this topic? [objective is to have no hands raised!] Would it not be sensible to become intimately familiar with the SCUBA diver�s environments of use (recreational and commercial?) before designing a product to meet or exceed their expectations? This is the same argument which strongly prompts your team to develop a sense of walking in your customer�s shoes, of developing a contextual anchor in the minds of the team members. The output of this first stage of visitation will be a documentation of this contextual understanding. In fact, because just one document will be produced by the team, we see that this understanding of the customer will be common amongst the team! When was the last time both your marketing and engineering groups seamlessly agreed on their understanding of the customer, including their current problems and frustrations? Now, visiting customers is not a new concept. Most readers will have a fairly extensive history of discussions with customers. But I would now ask, what do you do with the data once you�ve heard it? Or perhaps more to the point, how do you process the data in order to discover customer needs? Most firms have little if any experience in systematic, exhaustive and reliable approaches to analyzing soft language data collected from customers. This is one unique aspect of the MDPD process technology; where the rubber meets the road. The second stage calls us to convert the raw data collected during the first stage from customer language into company language, or into a form which the team can act on. The result of this conversion or translation are statements of what functionality the intended product or service may possess.

Slide 13:�Babble� Customer Requirements (CR)

Slide 14:Kano Analysis to Classify �Babble� Customer Requirements

Slide 15:Where Do We Go From Here? We have uncovered and classified requirements (Kano Method)

Slide 16:Value Feature MatrixOrganizing Requirements in a Structured Approach

Slide 17:How Do We Intensify Our High Level Understanding Of Requirements? So far we know what the customer needs/ requirements are We know which ones are most important We know who we need to compare ourselves to We have an idea which approach seems suitable in comparison to the competitive offering

Slide 18:What Customers Value in a Cell Pone � and How Much? �Babble� Feature Tree

Slide 19:Determining Design Targets

Slide 20:Select Those Requirements/Features Which Offer Most Design Freedom

Slide 21:Customer Value CurvesDetermine Target Values in Performance Range

Slide 22:�Babble� Customer Value Curves

Slide 23:Determine Sub-Assembly Profitability

Slide 24:Feature/Requirements to Sub-Assembly Spreadsheet

Slide 25:Step One � Analyzing Price Define the top-level architecture (major sub-systems) of the product Determine what portion of a feature (here the $90 feature �Reception Coverage�) is implemented in each sub-system

Slide 26:Repeat for all Features

Slide 27:Spreadsheet Automatically Provides Analysis of Sub-Assembly Target Price

Slide 28:Step Two � Inputting Cost

Slide 29:Result Understanding How requirements/features contribute to price What the target prices are of sub-assemblies What the margins are for each sub-assembly Where trade-offs can be made to achieve overall margin Iterative approach allows for updates throughout the development process and ass new information becomes available

Slide 30:Summary of Introduced Process Steps

Slide 31:DFGM Process

Slide 32: www.ProductStrategyNetwork.com Satisfying Customer Needs AND Target Margins