Customer Benefits,Product Features,

Product Specifications

IPD

February 15, 2005

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.

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?

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.

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.

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.

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.

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.

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!

Technical Specifications

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

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

Customer Needs and Benefits

Customer Needs and Benefits (Whats)

•Several Categories:

•Customer Needs

•Functions

•Reliability

•Target Values

•Substitute Quality Characteristics (SQC)

•Everything should be VOC

•Structured structuring

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

Planning Matrix

Planning Matrix

•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?

Planning Matrix

Graphical version

• Importance to Customer– Choice of scales:

absolute, relative, ordinal

– Ranks different needs/benefits

Planning Matrix, Numerical

• 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

• 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

• 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

• 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

• 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

Technical Response

• “Hows” to fulfill the customer benefit “Whats”

• Things that can be measured, with an operational procedure.

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

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)

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

D IR EC TIO N O F IM PR O VEM EN T

PLAN N IN G M ATR IXTEC H N IC ALR EQ U IR EM EN TS

C U STO M ERR EQ U IR EM EN TS

TEC H N IC AL PR IO R ITIES

PER C EN TAG E O F TO TAL

D ESIG N TAR G ETS

O ur P roduct

C om petitor A 's P roduct

C om petitor B 's P roduct

Key to roof / corre la tionm atrix sym bols+ Positive / Supporting- N egative / Tradeoff

S trong in terre lationship

M edium interre ltionship

W eak interre lationship

Key to in terre lationship m atrix sym bols

Tota l (100% )

Relationships and Impact

Technical Priorities

• Calculated from the relationship matrix: beware!

• Tell us which SQC’s are most important overall, and that is the important decision

Technical Correlations

• The Roof• Do SQC’s

support or impede each other?

• Note directions of improvement

• Another arbitrary integer/symbol scale

Technical Correlations

• Capture +/– effects

• Effects can be one- or two-sided

• +/- in roof refers to direction of change; also consider nature of target

Benchmarks

• Know the competition

• Don’t need to benchmark all SQC’s, just the important ones

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…

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