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
Planning Matrix, Numerical
• 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
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
Key to roof / correlation
matrix symbols
+ Positive / Supporting
- Negative / Tradeoff
DIRECTION OF IMPROVEMENT
TECHNICAL
REQUIREMENTS
PLANNING MATRIX
CUSTOMER
REQUIREMENTS
TECHNICAL PRIORITIES
Total (100%)
PERCENTAGE OF TOTAL
Our Product
Key to interrelationship matrix symbols
Competitor A's Product
Strong interrelationship
Competitor B's Product
Medium interreltionship
DESIGN TARGETS
Weak interrelationship
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 twosided
• +/- 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