Subject: Re: Support as insurance
From: "Stephen J. Turnbull" <>
Date: Wed, 1 Dec 1999 18:17:10 +0900 (JST)

>>>>> "Ian" == Ian Lance Taylor <> writes:

   From: "sjt" == "Stephen J. Turnbull" <>
   Date: Wed, 1 Dec 1999 14:47:45 +0900 (JST)

   >>>>> "Bob" == Bob Young <> writes:

       Bob> Just to be very clear here: my point is that customers don't
       Bob> want "features".  They do want the "benefits" those features
       Bob> provide.

    sjt> This is not a distinction that is easy to make in practice.

    Ian> I disagree.  You have to learn to think that way, but, once
    Ian> you do, it's pretty easy.  Benefits are the things you want.
    Ian> Features are the things which bring you the things you want.

If you say so.  But you personally still have trouble, it seems:

    sjt> I prefer to ask the question:  "how are my customers being
    sjt> served?" rather than:  "what customer benefits do I provide?"

    Ian> The first question tells you what to do with your existing
    Ian> customers, or what to do with customers after you find them.

Well, actually the answers I had in mind were not "with mustard" or
"with double cheese", but "well" or "poorly."  How happy are they?
What can I do to make them happier?  What do I need to do to make new
customers happy?

You seem to be still thinking in terms of the features your product
provides, not benefits the customers receive, despite your disclaimer
that it becomes natural with practice.  (Mea culpa: I should have been
more careful to phrase it to show I meant to include my _potential_
customers.)  This is why I don't like the distinction "features"
vs. "benefits".

Sure, you can respond "I declare benefits `volatile'," but as
Stroustrup points out, most programmers don't notice that declaration.
If it works for _you_, great!  But my experience in teaching (personal
and watching my colleagues) is that it is too easy to reify student
"benefits" into something static, then associate them, more or less
permanently, with "features" that we put into lectures.  Fortunately
for us, we have tenure, so that doesn't put us out of business.

This also works for Microsoft, for now.  "Just keep loading on the
features, the customers can't get away."  But an FSB just can't do
that.  The product is too volatile; your customers keep changing it on
you.  Unless you figure out what they want before they do.  That's why
I state the question dynamically, with emphasis on the verb "to serve,"
rather than statically, with emphasis on the noun "benefits."

    Ian> The second question tells you how to find new customers--it
    Ian> tells you what market segments to focus on.

Again, you are presuming your product as currently defined by its
features.  In the short run, you must do that to survive---but in the
long run, you want to find out where the customers are going, and be
there when they arrive.[1]  There may not be very many customers in
shouting distance of your current product.  What then?

[1]  Microsoft got that very right:  "Where do you want to go today?"
Sometimes a big marketing budget hits it on the nose.  Not only is it
the right question, but it panders to those who have no idea where
they want to go but don't want to admit that in public.

University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
What are those two straight lines for?  "Free software rules."