slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
PSNWebForum-Sati.. PowerPoint Presentation
Download Presentation
PSNWebForum-Sati..

Loading in 2 Seconds...

  share
play fullscreen
1 / 32
Download Presentation

PSNWebForum-Sati.. - PowerPoint PPT Presentation

Donna
198 Views
Download Presentation

PSNWebForum-Sati..

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

    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:Todays 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 teams solution. Requirements = Needs: Statements of what functionality a product or service possesses in order to satisfy or delight. At this point, Im introducing specialized words with specific meanings which require us to avoid ambiguity. Lets consider the following definitions. When I refer to these so-called requirement statements, Im 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 designers 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, Im introducing specialized words with specific meanings which require us to avoid ambiguity. Lets consider the following definitions. When I refer to these so-called requirement statements, Im 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 designers 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 Todays 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 MEDRADs 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 MEDRADs 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, were referring to the set of people who in any way are beneficiaries of the products 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 customers 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 divers 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 divers 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 customers 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 youve 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, were referring to the set of people who in any way are beneficiaries of the products 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 customers 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 divers 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 divers 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 customers 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 youve 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