1. Customer Benefits, Product Features, Product Specifications IPD February 15, 2005

2. Specifications Each field has its own precise definition of specifications. For example (first entry in an EB search): “The design process can be dissected into five phases and is the same for most aerospace products. Phase one is a marketing analysis to determine customer specifications or requirements” Specifications specify; they tell us exactly what must be done.

3. Two perspectives on specs: 1.Specifications are used to define the scope of product work. 2.Specifications are used to make customer needs precise. Can you guess which is more important in this class, and in IPD in general?

4. Benefits, Features, Specs Google “benefit feature specification product” for thousands of hits germane to our discussion here. Many of those hits are from software. Note that in loose parlance, benefits and features are almost interchangeable, and specs can mean product performance or system requirements for product use. We are more precise.

5. Customer Benefits Come First What does the customer want/need? What would add value? These generally come from your product opportunity research. You can’t just dump the list of needs generated last term – we need to begin to think about what can be delivered. Everything should be in the customer’s “voice” – direct quotes are great, though not required.

6. Product Features Provide Customer Benefits What cool things does our product do to provide these benefits? Note that features can’t appear out of nowhere; if you want a feature that has no benefit, go back and put in the benefit. As much as possible, features should still be in the customer’s language.

7. Specs Specify Features How do we know we have actually implemented a feature? We need something measurable – that’s a specification. Different fields have different notions of “measurable” – key is to remove ambiguity. Product specs are high level, engineering specs will be more detailed. There is a whole process involved in cascading from the one to the other; we discuss it later. Once again, use the customer’s voice as much as possible.

8. Some Notes on Targets Targets are hard to pin down. You’re never sure what can be done until you’re done. Thus, targets tend to evolve. Don’t worry at this stage about getting accurate numerical targets. In fact, you’re lucky if you can get specifications for all your features.

9. More Notes on Assignment We expect you to be tempted to circumvent the nice linear benefit-feature- spec model. Don’t! It’s OK to leave some specifications not quite specified at this point. Though we will cascade product specs to engineering specs later, it can sometimes be better to cascade features straight to engineering specs. The Bad Old Model is that Specs come from the Business Unit as a mandate. Our Better IPD Model means we expect some constructive conflict!

10. Technical Specifications

11. Intro to HOQ/QFD The House of Quality (HOQ) is part of Quality Function Deployment [Hauser and Clausing] It’s a matrix method to structure discussion/decisions It is fairly arbitrary It has acronyms BUT: it covers useful ground

12. Because it Looks like a House Several “rooms”: Customer Needs Planning Matrix Technical Response Relationships Correlations Technical Matrix Lou Cohen, Quality Function Deployment, Addison-Wesley, 1995

13. Customer Needs and Benefits

14. Customer Needs and Benefits (Whats) Several Categories : Customer Needs Functions Reliability Target Values Substitute Quality Characteristics (SQC) Everything should be VOC Structured structuring

15. Customer Needs and Benefits As always, the up-front work is crucial Note that we have already gathered much VOC information SQC’s, targets are dealt with in detail later; they exist here only because customers offer them (and are often “wrong”) Structured Structuring: Affinity Diagrams, Trees, lists, color coding

16. Planning Matrix

17. Can be numerical or graphical Strategic Plan: How important is the need to the customer? How well do we meet it? How about the competition? Will the met need sell the product? How important is the need to us?

18. Planning Matrix Graphical version

19. Importance to Customer –Choice of scales: absolute, relative, ordinal –Ranks different needs/benefits Planning Matrix, Numerical

20. Customer Satisfaction –How good is the current solution from OUR company? –Usually comes from survey data –Intent is to pinpoint our capabilities –1 (low) – 5 (high) Planning Matrix, Numerical

21. Competitive Satisfaction –How well does the competition meet the need? –Again, intent is to focus our efforts on our strengths –1 (low) – 5 (high) Planning Matrix, Numerical

22. Goal and Improvement Ratio –Goal: our target for customer satisfaction –Improvement ratio: the goal divided by our current customer satisfaction –Where do we focus our efforts? Planning Matrix, Numerical

23. Sales Point –Added to the American version of QFD; original Japanese focused on customer satisfaction only –Asks, is this benefit a Kano delighter? (Does it engender surprise and delight?) Planning Matrix, Numerical

24. Raw/Normalized Weight –Quite arbitrary raw numerical ranking (Imp.to Cust.) x (Impr. Ratio) x (Sales Point) –Back to intent: what do we focus on? –Normalized Planning Matrix, Numerical

25. Technical Response “Hows” to fulfill the customer benefit “Whats” Things that can be measured, with an operational procedure.

26. Technical Response Substitute Quality Characteristics (SQCs) –Less is Better, More is Better, Nominal is Best –Hardest Step of Whole Process –Map from Customer Attributes (through function) –Can shift How’s to What’s, define new How’s and expand the hierarchy

27. Relationships and Impact Correlate customer needs and SQCs What is the impact of a particular SQC on a given need? Arbitrary integer scales: 0,1,3,9(5,7,10)

28. Blank House of Quality Matrix © Dr. A. J. Lowe 2000

29. Relationships and Impact

30. Technical Priorities Calculated from the relationship matrix: beware! Tell us which SQC’s are most important overall, and that is the important decision

31. Technical Correlations The Roof Do SQC’s support or impede each other? Note directions of improvement Another arbitrary integer/symbol scale

32. Technical Correlations Capture +/– effects Effects can be one- or two- sided +/- in roof refers to direction of change; also consider nature of target

33. Benchmarks Know the competition Don’t need to benchmark all SQC’s, just the important ones

34. Targets Targets take everything into account: –Importance of needs to customer –Product function –Our capabilities –The competition’s strengths and weaknesses There are calculations for these, but…

35. Closing Thoughts The end is a sensible set of targets Some steps to get there: –Understand customer need –Understand what we and others are good at right now, and what will sell –Translate needs (What’s) to measurables (How’s), perhaps in several steps –Decide how measurables interact –Decide which measurables should be pursued, and with what goal –(Allocate resources to accomplish the important) Don’t get too caught up in the mechanics Software can be a blessing or a curse