|
Part 1 | Part 2
An Interview with
Sheila Mello (2/2)
Getting the
Customer's Pain:
Using Customer-Centered Definition to Drive Product Development - Part
2
In her new book, Customer-Centric
Product Definition (AMACOM, 2002), consultant and author Sheila
Mello outlines a process called “Market Driven Product Definition” (MDPD®)
which takes the guesswork out of the discovery of customer
requirements. MDPD is a replicable process for discovering,
understanding, systematizing and prioritizing customer requirements
– including customer’s latent needs. The process encourages
cross-functional involvement in a program of visits where developers
observe customers in their own environment, developing a holistic
view of their products in actual use. In the second part of this
interview, Mello describes a process by which product developers can
ensure a greater likelihood of success at product launch.
PDBPR: In your
book, you speak of collecting a large number of customer images and
then narrowing down that group to a chosen few that will be used to
define a new product. How does MDPD narrow down the number of images
so as to include only the best?
Sheila Mello:
This portion of MDPD is based on Japanese anthropological research,
which involved techniques for distilling down a lot of facts to a
number that’s manageable. In the MDPD process, the images are
written on Post Itsâ and then the participants read them repeatedly
and, through a process of digestion, slowly eliminate the ones that
are less rich. Once they’ve read all of them a number of times they
can then see which ones are the most useful. If you ask people to
eliminate some images before they had read them a half-dozen times
(or more) then they tend to feel that they have eliminated some
important ones. By the time we get to that last round of reading the
Post Its, and we tell them they can choose only two or three each,
they have a hard time choosing even that many, because, by this
point, they are able to eliminate so many of them.
PDBPR: Can you
describe the process used to choose which images are the most
significant?
Sheila Mello:
Each person reads the images and selects which ones they want to
consider further. By reading and rereading the images, they become
more discriminating and are able to reduce the number of
possibilities so they can choose the best images more easily. What
came out of the anthropology was a theory about how,
psychologically, people could feel good about picking just a few
from a large pool of images. When NASDAQ used this process, they
began with 2000 images. One thousand were eliminated in the first
round. There were so many that we couldn’t walk around them – we
placed them on pieces of paper and passed them around. But people
read them all and we eliminated all but 20 or 30 in a half-day.
Normally this activity takes a couple of hours.
PDBPR: After
synthesizing all the data related to the customer images and voices,
the participants in the MDPD process then proceed to derive customer
requirements. How do you know when you’ve got a good customer
requirement?
Sheila Mello:
A good customer requirement is something that a customer needs that
is missing from the current functionality. This does not mean that
everyone is missing this functionality, but that that customer, the
one you know of, is missing it. Later in the process, we also do a
survey to get a sense of how important this missing functionality is
to a broader customer base. In this process, we ask: “what is the
verb?” By this we mean, what action is missing that the customer
might require? Then we ask, “how is this missing functionality
measurable? How do we know when we have satisfied the requirement?”
We need to understand what exactly we are measuring: Is it time? Is
it number of steps? How can it be measured?
PDBPR: Does every
customer requirement have a metric?
Sheila Mello:
Every requirement that is ultimately selected has a metric that
gives direction to development. As you begin to write requirements,
it is necessary that you make sure that each requirement is
measurable. For example, a customer might have said: “I want to read
the newspaper in such-and-such an environment.” The missing
functionality is that the customer can’t read the newspaper. But
what in this requirement is measurable? Is it that they want to read
the newspaper quickly? Or is it that they want to read the newspaper
under minimum light conditions? Or is it that they want to read the
newspaper sitting in a confined area? How do I measure when I have
achieved success? Once you have selected the 20-30 key requirements
– through a process of digestion similar to that used to narrow down
the customer images – then each requirement is associated with a
metric, each of which has a test plan. In the Quality literature,
the definition of Quality was always this: “Does it meet the
functional requirements?” That’s not sufficient. A much more
important question is: “Does it meet the customer’s requirement?”
When we ask people why they do not make meeting customer
requirements the success measure they often say that it’s because
the customer requirements are not measurable. But they could be
measurable. In fact it’s easier to make a customer requirement
measurable than it is to make a feature measurable.
PDBPR: In moving
from customer requirements to metrics, the participants are moving
from a qualitative to a quantitative focus in terms of their own
thinking. Are there common pitfalls associated with this portion of
the process?
Sheila Mello:
One of the pitfalls is that people try to define the metric in terms
of the solution. The whole underpinning of crafting customer
requirements is to drive innovation. So you need to phrase your
metric in such a way that you do not box yourself into a single
solution. Let’s take an image from the game of golf. Suppose when
I’m on the golf course I want to be able to find the right golf club
with a minimum of effort. How should we measure that? One metric
would be the number of times I pulled out a club and it was the
wrong one. A metric for “minimum of effort” could also be based on
the amount of muscle power it would take to retrieve the right club
when you reach for it. Mistakes could be made in terms of setting a
solution that would only work for a very strong player, or one that
would only work for a very tall person.
PDBPR: Let’s talk
about the point where the team is brainstorming solutions. The point
is to eventually create a product that will meet a whole range of
customer needs. Isn’t it quite possible that by concentrating on
individual requirements and individual metrics, one will create a
solution that negates some other need or precludes an important
feature?
Sheila Mello:
When you start brainstorming solutions you want people to come up
with innovative – even crazy – solutions considering each
requirement separately regardless of its imagined impact on some
other requirement. Going back to the golf example, suppose I want to
maximize the number of times I reach for and get the right golf
club. I might, at the same time, have another requirement that says
that I want to minimize the weight of my golf equipment. Some
solutions to the first requirement might mean exceeding the weight
requirement. In MDPD, we decide, for each requirement, which is the
best solution and then merge them together later. This enables much
greater creativity and innovation to occur. Oftentimes, developers
divide the brainstorming into segments; first they brainstorm the
engineering part, and then the mechanical part, and then the
software part, but they do not break it down by customer
requirement. By breaking it down by requirements you get much
greater levels of innovation.
PDBPR: What is the
final output of the Market-Driven Product Definition Process?
Sheila Mello:
The final output is a winning new product. But it’s also important
to understand which requirements you really have to meet. So when
you get to the tradeoffs in development, and the schedule slips and
you need to cut something, you know which things you cannot cut.
There might be other features that, if you cut them out, you might
be diminishing the marketing aspect of the product, i.e., how you’re
going to sell it, but it’s important to understand why the product
has certain features. This information allows you to manage the
product development much more effectively. The reason I say that a
customer-centric product definition process is the key to great
product development is that it enables you to make better decisions.
It helps you make better tradeoffs. It also helps you in the
commercialization phase, with how you launch the product, how you
test it, etc. Your understanding of the product isn’t just that the
product needs to do these things, it’s that the product needs to
meet these needs. This is a very different perspective for the team
and it’s much more energizing as well.
PDBPR: What is the
core message regarding customer-centric product definition that
you’d like to put across to our readers?
Sheila Mello:
The message I’d like to get across is that designing and building
winning, profitable products begins with the thorough understanding
of customer requirements. Understanding customer requirements is
fundamental to improving return on investment. People are realizing
that, in this economy, you can’t afford to be wrong. You don’t have
that luxury and you have a lot of competition out there, which
speaks to a need for more differentiation. Another piece of it is
that companies are spending a lot of money on customer retention and
Customer Relationship Management (CRM) systems. There’s nothing
better for customer retention than giving customers products that
meet their needs. You do not need as much customer relationship
management if your products meet their needs
This article originally appeared in the
August 2002
issue of PDBPR
 To join our
e-mail list and receive future updates on "Voice
of the Customer," click here.
|
ABOUT