Conference 7.286::digital

    re .0
    
    Didn't the writer of the Gardner Report W(es?) Melling used to work for
    Digital some 7 - 10 years ago ?
    
    John

    Could one of the reasons be that some in our sales and sales support
    like to be seen as the only one(s) who really know something about
    the product - like priests in some religions ;-).
    
    Sure, this has something to do with our mesuring systems which values
    presentations which are full of Digital jargon, not needs approach.
    
    --Ritva
     

    
    
    	re: .1
    
    	Yes, I do believe that this is the same Wes Melling of PC fame.
    

> treat competitive analysis as a feature list comparison

Could someone clarify this complaint?  What should competitive analysis
look like?  Are feature list comparisons verboten, missing the point,
or only a small piece of the comparison?

   Gary

(PS Chances are that this basenote, and my question, belong in the
MARKETING conference.)

    We could go into more detail in MARKETING, but I'd like to explore the
    idea here.  
    
    In my mind, competitive analysis needs to compare competitors in
    specific markets.  The feature list is what engineering can contribute
    to the discussion.  Marketing needs to identify what different
    customers in different markets prefer so we can understand how adding
    feature p to product X will help sales and compare that to the cost of
    the feature.  
    
    Of course, this is a purely academic analysis.  In the real world,
    decisions are made based on some important person's gut feeling, not
    any business analysis.  :-)
    
    In summary, competitive analysis includes customer information, not
    just product information.
    
    fwiw,
    
    /rab

    Not to change the subject, but could someone point me the the
    Marketing notesfile?  
    
    Thanks,
    Renee

        The marketing notes file is at NODEMO::MARKETING.  The moderator
    is PSW::PW::WINALSKI.  KP7 is set up.

>>  In my mind, competitive analysis needs to compare competitors in
>>  specific markets.  The feature list is what engineering can contribute
>>  to the discussion.  Marketing needs to identify what different
>>  customers in different markets prefer so we can understand how adding
>>  feature p to product X will help sales and compare that to the cost of
>>  the feature.  
    
    I doubt there is any product development effort underway within Digital
    that does NOT have "time-to-market" as the primary "goal".  I.e., get
    SOMETHING-ANYTHING into the price book, "so we can generate revenue."
    
    The problem with this, is that
    	(1) The scope of development becomes "meet current competition",
    	    only our final product turns out 6 months or more behind the
    	    competition.
    	(2) We crank out "mouse traps" instead of better mousetraps
    	(3) We defer so damn much functionality to "version 1.1", then
    	    have to direct too damn much effort fixing the bugs in 1.0 that
    	    we can't get 1.1 started - much less shipping - in a reasonable
    	    timeframe.
    	(4) We build Cadillac limosines, when the consumer wants VWs or
    	    911s.  Worse, we build cars when the consumer needs a boat.
    	(5) We "integrate" all kinds of things, but haphazardly.  How old
    	    is "CDA"? - and we are just now getting a smattering of
    	    compatibility across other popular data formats (e.g. Microsoft
    	    Word <-> DECwrite) - what about BMP, GIF or TIF images?  Nah!
    	(6) We largely ignore the user interface (my favorite example is
    	    ALL-IN-1 mail asking an Executive Director if he wanted to do a
    	    "local, world or progressive search of the directory" - as if
    	    he even had a clue as to what this meant).
    
    We market the dickens out of our hardware, but not our software - Alpha
    has been plastered over every trade rag's cover for months.  How much
    coverage for, say, DECdesign, SQL Multimedia, MAILbus Postmaster,
    VAXset tools, RdbExpert, InstantSQL, DECreport, TEAMlinks, TEAMroute,
    or ALL-IN-1?  We CERTAINLY DO NOT market our Systems Integration
    business, CASE/Repository or the Digital Program Methodology
    environments in the way that, say, Oracle markets their CASE
    environment.  Alpha will merely be a faster way to do nothing until the
    higher-ups realize that its not TIME TO MARKET that counts as much as
    does FEATURE TO MARKET.
    
    We laugh (or cry) at the phrase "May be implemented in a possible future
    release".  We keep new developments under wraps until they are almost
    ready to ship - THEN the consumers/field support start giving feedback
    on what is REALLY needed or wanted, but it is too late to make changes.
    All in the name of protecting competitive advantage, preserving valuable
    intellectual properties, etc, etc.  We cut loose highly competent
    technically-oriented personnel even while very important products are
    dying from lack of man- (umm, "person-") power.
    
    I believe Digital will continue to exist, even get better. But it will be 
    by individual efforts, and definitely NOT because of veeps charting a course
    for success - although they will take full credit for it.
    
    
    Don

    Re: .8
    
>>  	(6) We largely ignore the user interface... 
    
    To be competitve, we must sell at a total price at or below the
    competition.  The total price includes front-end training and ongoing
    support for the product.  If the products' user interfaces are
    intuitive, and the user knows the business the product is supporting,
    then training & suppport costs, and therefore total cost should be down.
    
    There's also that gut feel (.-1) that decision makers use when they
    buy a product.  That "totally well thought out" feeling to a product
    often jumps right out out of the screen and handles some of the selling
    automatically.
    
    I think that all our products should be written to comply with a
    set of corporate standard user interfaces.  Apple & their software
    developers do a great job.
    
    Gord - Saskatoon

>    To be competitve, we must sell at a total price at or below the
>    competition...

Ouch. Providing meaningful value for a customer over the competition is the
real goal. Lower lifetime costs are only one aspect of this... you can
reduce your customers expenses or increase their ability to meet their
business goals; both should please the customer.

Still, besides this rathole, I agree with you. If nothing else, use CUA ;-)

								- Ian W.

re: .8

>    	(3) We defer so damn much functionality to "version 1.1", then
>    	    have to direct too damn much effort fixing the bugs in 1.0 that
>    	    we can't get 1.1 started - much less shipping - in a reasonable
>    	    timeframe.
>    	(4) We build Cadillac limosines, when the consumer wants VWs or
>    	    911s.  Worse, we build cars when the consumer needs a boat.
 
To some extent, these two items contradict each other.  The first says that we
leave features out, the second that we put too many (or at least the
wrong) features in.

This implies that we need to do a much better job at identifying the minimal
set of features that will make the next release of a product successful.  QFD
will help.  So will discipline.  But I'm not really sure there's a good
answer that will really solve this problem.

   Gary

    
    The basenote says to me that put plain and simply we don't understand
    the needs or interests of those persons whom we would like to be
    selling product to.
    
    When Charlie Christ first came to Digital, he talked with a number of
    customers to gain an understanding of how they see us.  One of them
    answered the question by explaining why he feels much more comfortable
    with IBM than DEC as follows:
    
         If DEC and IBM were in the dog food business I would expect
         them to approach me this way:  DEC comes in and reads the label
         of ingredients amid a dissertation on nutrition.  IBM comes in and
         tells me that their dog food will leave my dog with a shiny coat;
         bright, clear eyes; and a wagging tail.  I don't know anything
         about dog nutrition, but I can understand a dog with a wagging
         tail.
    
    I think this story says it all on this subject.
    
    Steve
    
    
    

    As one of my customers said ten years ago, "Digital is #2 in spite of
    it's organization, IBM is #1 in spite of it's product..."
    
    still applies.
    
    q
    

	re previous couple...

	This is an old story...until the software engineering
	groups emerge from the golden castle on the hill, nothing
	will change.

	It's like the bug in a sort routine in one particular
	runtime library for VMS:

	This routine was brrrrroken, yet, in the source comments,
	the author waxed eloquent about the elegance of the
	algorithm he chose, stressed to everyone NOT to tinker with
	his carefully implemented routine, etc.  The routine
	failed if called twice in the same program.

	Or, like the bug in another sort routine that caused customer
	programs to fail all over the country.

	The developers protested that "performance in the new release
	was improved 75% over the previous release."  But the danged
	thing didn't WORK !    

	175% of zero is ZERO !


	Steve H

    
.14>	This is an old story...until the software engineering
.14>	groups emerge from the golden castle on the hill, nothing
.14>	will change.
    
    It is interesting to note that the Gartner report did not zero in on
    this "problem".
    
    .0 does not say:
    
      "DEC's Reorganization: The Persistent Blind Spot"
  
      "Engineering Refuses to Vacate Ivory Tower"

    It does say:
    
      "DEC's Reorganization: The Persistent Blind Spot"
  
      "Failure to Communicate Strategic and Product Messages to Sales Force"

re ;-1,
I agree, 
we're so used to bashing ourselves because "Engineering is out of touch with
customers needs", that many of us missed the whole point of .0.

Read it again.
It does NOT say that "DEC's engineering is building the wrong products".
It says the opposite:
"DEC's products are in leadership positions.  The news just hasn't gotten to
the field."

What we have is NOT a failure in engineering , but a failure in communication.


So, what can we do to open up the pipeline of information between engineering
and the Field?


How can we expect Field personnel to keep up with not only the latest products
(ALL of them(!!!)), but with the underlying strategies and visions?
That's what it will take to sell our great technology.  Are you (whoever you
are) willing to dedicate some portion of your time to making that communication
happen?  If not, are you willing to accept the results of that communication
not happening?

Kevin

    
    Re: .16
    
    > "DEC's products are in leadership positions.  The news just hasn't
    > gotten to the field."
    
    Well yes, but not exactly.  It says that LOTS of information is getting
    to the field, but that it isn't useful.  It clearly says that Sales
    Update, for example, continues to wax eloquent with technical data that
    is so voluminous and arcane that the sales force largely ignores it
    because they don't understand it.
    
    Clearly it says that Digital still appears to believe that technical
    wizardry is goodness, but that the sales force has no idea how to
    describe what it does in words that will make sense to the customer. 
    It further lays the blame for that lack of knowledge on Digital's love
    affair with technical elegance at the expense of ensuring that it is
    useful for something and knowing what that something is.
    
    Steve
    

OK, so, to put it another way:
How do we communicate the information that Sales and other field organizations
needs, in a way which will be meaningful to those receiving the information?

We can transfer megabytes worth of information across the world at lightning
speeds.  This is not communication.  This is data transfer. How do we
COMMUNICATE this information? (implies that the party on the other end actually
absorbed the info)

Kevin

    
    >So, what can we do to open up the pipeline of information
    >between engineering and the Field?
    
    The first question to ask is why is the pipline clogged?  
    
    >How can we expect Field personnel to keep up with not only the latest
    >products (ALL of them(!!!)), but with the underlying strategies and visions?
    
    We can't if the pipline is indeed clogged.
    
    Why is the pipline clogged?  I suspect we are seeing the "information
    hoarding" phenomenon I've ranted and raved about for some time.  The 
    major premise of the PID process, for example, is that sales people
    and support types cannot be trusted with information unless it is processed,
    sterilized, codified, and emasculated in the process.
    
    Now, I know a number of DEC people who spend a lot of time focusing on 
    wading through the political and social quagmires within DEC and get 
    the "Holy Grail" of inside information and "leverage" it so they can 
    advance their status within the organization.
    
    In general, the successful sales & sales support types don't use the 
    formally instituted mechanisms to get info.  This is in keeping with
    Digital's culture which says: *WHO* you *KNOW* determines *WHAT* you
    know. This is absurd.  Who you *ARE* should determine what you *KNOW*.
    
    Possible solutions?
    
    1) Create notes conferences for the discussion of those issues currently
       forbidden such as schedules and features of products.  Make participation
       these conferences *MANDATORY* for product managers.  I don't have a problem 
       with making these conferences restricted, but restrictions should be based
       on job code.
    
    2) The PID process must be made a 2-way street.  A summary of customer 
       comments should be sent to product management and should be reviewed
       by someone in engineering.  I know we do a lot of PIDs, but I think 
       someone should have the job of gathering information from those of us
       presenting PIDs each week.  We can't let product management have this
       "Moses bringing the field  the Ten-Commandments" mentality any more.
    
    3) Marketing internships for field sales & support.  The partner's program
       approaches this, but there is still a seperation between the field and
       marketing personnel.  If we had part of a field person's time billed 
       to a marketing cost center, we might get a little more input.  
    
    In general, we need to get rid of the idea that free flowing information is
    dangerous.  I think denying the field infomation is even more dangerous
    because dissatisfaction with DEC's ability to communicate may be the biggest
    reason for field attrition.  People who have the tools they need to acheive
    their goals are less stressed out and are less likely to leave.
    
    JMHO,
    
    -Ed
    

    
    re .17:
    
    Well, you could interpret it that way... or you could interpret it to
    say that we've always had, and always needed, the technical data, but
    have not learned how to translate for the non-technical customer.
    
    Bring it back to the dog food analogy.
    
    For a company to sell dog food successfully, there have to be at
    least two areas of expertise:
    
    1) The dog food engineer has to understand the composition of a good
       dog food; what nutrients, in what ratio, will comprise an edible,
       balanced diet.
    
    2) The dog food marketing/sales person has to figure out what will
       attract consumers to buy the food, something your basic dog owner
       can related to; eg "your dog will have a shiny coat and a wagging
       tail."
    
    If you remove from 2 the ability to translate "balanced diet" to "your
    dog will have a wagging tail," you wind up trying to sell the dog food
    by reading a list of ingredients. Specifically, 2 gets a list of
    ingredients from 1 and passes it on, with no value added, to the
    customer.
    
    In an organization of many dog food engineers and many dog food
    marketing/sales people, you don't expect each engineer to hand to each
    sales person a list of ingredients. You expect a small group of dog
    food engineering managers to hand the list to a small group of dog food
    marketing/sales managers, who then make the connection between a list of
    ingredients and "wagging tail", and pass the "wagging tail"
    information to the sales people. In that model, if the customers are
    consistently getting a list of ingredients instead of a "wagging tail"
    message, it's fairly easy to see where the problem lies.
    

    re  .20
    
    TYPICAL-
    
    there is NOTHING in your discussion at all that talks about the dog
    EATING the dogfood!
    
    The nutrients may be there,
    	the benefits message may be there,
    		the packaging may be there,
    
    			BUT THE DOG HAS TO EAT IT
    
    				or the 'master' won't buy it again!
    
    -Barry-
    

The other thing to note that the objective should be to get meaningful
information to customers and prospects. Sales and Sales support are important,
but nonetheless only one way of achieving the end.
								- Ian W.

    Don't the replies here indicate part of the problem?
    
    They are concentrating on "How do we ensure that marketing are able to
    tell the customer about the new technology in our products in a
    meaningful way?"
    
    Surely it should be the other way round - marketing should be telling
    Engineering what the customers need (in the dog food analogy they
    should be saying "Make us a food to give dogs shiny coats and wagging
    tails.")
    
    That way the marketing people KNOW what they're selling - because they
    (i.e. their customers) asked for it.
    
    Engineering's job is then to give that to the customers at the most
    cost effective price.
    
    Who really cares whether that involves the latest and greatest
    technology?
    
    As ever, this is just MHO!
    
    Mike

Re: .12

    <The basenote says to me that put plain and simply we don't understand
    <the needs or interests of those persons whom we would like to be
    <selling product to.
    
    <When Charlie Christ first came to Digital, he talked with a number of
    <customers to gain an understanding of how they see us.  One of them
    <answered the question by explaining why he feels much more comfortable
    <with IBM than DEC as follows:
    
    <     If DEC and IBM were in the dog food business I would expect
    <     them to approach me this way:  DEC comes in and reads the label
    <     of ingredients amid a dissertation on nutrition.  IBM comes in and
    <     tells me that their dog food will leave my dog with a shiny coat;
    <     bright, clear eyes; and a wagging tail.  I don't know anything
    <     about dog nutrition, but I can understand a dog with a wagging
    <     tail.
    
    <I think this story says it all on this subject.
    
    <Steve
    
Metaphors can be powerful -- they can also be misleading.  I suggest the
above metaphor can be made more relevant by asking WHO we are selling
the dog food to.  In an imaginary world where every dog owner
employed a personal veterinarian, we would be selling to veterinarians.
Veterinarians DO CARE about the specific technical details of dog food --
that's their business.  Likewise in our real business, we sell to IS
departments who care about details relevant to real work -- as well as
selling higher level benefits to CFO's...

I suggest that Digital's technical leadership is something we wouldn't
want to give up -- it's our "comparative advantage".  Which is not to say
we have a huge learning challenge ahead of us in better communicating
our technical advantages and associated benefits to the field force.

John

    
    In .0 Melling points out that Sales Update is inadequate for the needs
    of the Sales Force. If this is indeed the case then perhaps a start 
    in improving communications to the Field is to improve Sales Update.
    
    Perhaps those who rely on Sales Update could be asked for input as to what 
    it is that they need (ie. a vision of how product x, y, and z play
    together, etc.). It may be that they need both a technical section and a 
    section on what this means to the person on the street who views a computer
    as a way to get their job done and not what kind of processor is in the 
    box. 
    
    Bob
    
    
    
    
     

	An observation:

	I wonder if what is happening in this note is also what marketting
	and sales is trying to figure out...

	The statement "Feed your dog this stuff and his coat will shine"
	seems simple and straight forward to me,  yet you get all these 
	people coming out of the wood work asking what does this mean	
	exactly ?

	There shouldn't be any hidden message here....

	In different situations you need to know your audience and pitch the
	message/solution accordingly, however inorder to get the initial 
	interest of customers you need to be able to draw an *enlightening*
	parallel between an obvious problem and an obvious solution.

	Details come later...

	Just MHO.

						Mike
						----

	

    
    .25: Good point. Let's go back to .0 for a clue:

    "The cultural fall-out is evident in communications to the sales force.
    Heavily focused on "technofactoids" about product, DEC's sales literature
    and sales training presentations skim over broad trends, ignore "Why was
    it necessary to build this product?", treat competitive analysis as a
    feature list comparison and rarely offer long-term user strategies. An
    awful example is Sales Update... Sales Update is so full of detail, and
    so empty of perspective, that most sales reps are overwhelmed by it, and
    many don't even try to read it seriously."
    
    Why is Sales Update full of detail and empty of perspective? The detail
    comes from engineering. Whence comes (or, more correctly, *should*
    come) the perspective? Marketing, perhaps? Is that part of their "value
    added" to this company?
    

>    Perhaps those who rely on Sales Update could be asked for input as to what 
>    it is that they need (ie. a vision of how product x, y, and z play
>    together, etc.). It may be that they need both a technical section and a 
>    section on what this means to the person on the street who views a computer
>    as a way to get their job done and not what kind of processor is in the 
>    box. 
 
	I've talked to sales people about Sales Update. None of them use it.
	Right now there is very little technical information in it. It's all
	most all fluff and "what it means the the person" in various markets.
	Our salespeople know the customers and their needs. They can figure
	out what a product means to their customers without being spoon fed.
	They need more facts. Some salespeople have tried to give feedback
	but it appears that anything they feedback that doesn't fit an idea
	the marketing people already have is filtered out. So the salepeople
	just glance at the table of contents and then file it.

	Maybe the people I've talked to are rare exceptions but I wonder if
	anyone reads Sales Update. I also wonder if people who write for it
	are paid by the article or the word rather than how effectively the
	information is gotten out. What are the metrics there I wonder?

			Alfred

    There is one line in every Sales Update article that is useful to
    folks in the field.
    
    That is the product manager's name, DTN, and mailstop.
    
    It is useful for some limited amount of time (until it is no longer 
    accurate.)
    
    Other than that, most SU articles are pretty marginal.
    
    IMHO.
    
    K.

    
    sometimes unfortunately, Sales Update contains lots of technofacts
    because, (especially in V1.*'s) everything BUT end user functionality
    is present! Thus, a natural tendency is to point out all the neat
    tricks the product *could* do if only....
    
    What is even more disheartening, is you can have all the customer
    input you can gather from marketing, services, trade shows etc... but
    if the people who have the power to control the product don't care to
    listen, or insist they know better or just plain lie to get people off
    their backs, this situation is not preventable in our current culture.
    This situation does happen.
    
    The obvious solution would seem to be to insist on much shorter
    development times and more frequent ships to gather & enforce customer
    input.  This of course would upset anyone trying to develop a new
    operating system or framework type product(takes alot of time man), but 
    I've come to believe those objections are not valid. Even in these 
    situations you need to test from very early on that you are providing
    a platform that can deliver functionality that people will pay for.
    
    Ya, i'm a little off the track, but this does explain some of the
    things that get presented in Sales Update from time to time.
    
    
    	bob

    
    Re: Engineers in the field.
    
    I have to disagree here.  Ask any Sales Support person what their job 
    is like.  Putting a hardcore engineer in the field is a sure file way
    to turn him into a "Salesman Hater"  Seriously, the sales types will
    drive them nuts!
    
    Now, If you suggested we put PRODUCT MANAGERS in the field for 
    6 months....
    
    -Ed
    

    
    Well, "all" dog foods say it will make the dogs coat shine, etc., etc.
    so why should I buy yours instead of xyz's?
    
    If you look at articles in the Digital papers, (i.e., DTW etc.), that
    exploit the "large" sales that Digital has won, the one thing that
    seems to stick out, at least to me, is that all of these "large" sales
    were won with the effort of a "TEAM" of people.  Not just the sales 
    person, but a support person who KNOWS networks, one who KNOWS storage,
    one who KNOWS "systems", one who KNOWS "software", etc.
    
    There is too much "stuff" in todays computing world for one sales
    person to know everything about everything.
    
    IMHO we need more "expert" teams to help sales put together a proposal
    for the customer that will convince the customer that he should buy our
    dog food and not xyz's....even for the "little" customer.
    
    Let the sales people present to the customer what the experts have put
    together, a proposal that fits what the customer needs, AND will work
    when it gets installed, AND will not be missing cables, or whatever.
    
    Its not all the sales persons fault, we have taken the "proprietary"
    bit to the extreme.  Every "option" built by a different PCU has their
    own special configuration to make it work, and OBTW, you  need to know
    which variant is the one you need.
    
    FWIW
    
    
    
    

re Note 1969.27 by CROW::KILGORE:

>     .25: Good point. Let's go back to .0 for a clue:
> 
>     "The cultural fall-out is evident in communications to the sales force.
>     Heavily focused on "technofactoids" about product, DEC's sales literature
>     and sales training presentations skim over broad trends, ignore "Why was
>     it necessary to build this product?", treat competitive analysis as a
>     feature list comparison and rarely offer long-term user strategies. 

        Compare .0 with the following excerpt from comp.unix.ultrix
        by Ted Lemon <lupine!mellon@uunet.UUCP>:

              "I think that a large percentage of DEC's users would
              just like to see DEC making decisions that reflect an
              understanding of the customer's needs, rather than some
              sort of "strategy" that DEC has come up with on its
              own.

              "I believe this tendency to strategize in a vacuum is
              at the heart of DEC's credibility problem...."

        Could our strategies be good, and their execution competent,
        and the result impressive to industry analysts, and yet
        still be out of touch with the customers' perceived needs?

        The information flow in strategy-building cannot be one-way: 
        if a cornerstone strategy is unknown or incomprehensible to
        the field, then this means, at a minimum, that the field sees
        little immediate connection between the world they see in the
        market and the strategy.

        A strategy that impresses industry analysts is a nice thing
        to have, but a strategy that impresses the field and the
        customers is vital.  Something is wrong with a strategy that
        cannot be easily communicated to the field and the customers
        -- it isn't all the fault of those who write "Sales Update."

        Bob

    
    re: .34 - Thank you for describing far more politely than the response
    to another note on same subject I was about to enter, and thought
    better about.
    
    	Yes - there seems to be a thriving industry in telling strategist's
    what they want to hear! It is the end-user who ultimately judges
    whether we've helped 'em or screwed 'em! 
    
    bob

    re: .11
    
    Poor shoice of wording on my part.  Basically, my point was that we
    often create "Cadillacs", flashy and possessing some wonderful features
    - that many or all consumers have no need for.
    
    don

re: - several

I think the Gartner Group report points to something very basic.  We
are having trouble generating and delivering context-full 
information (knowledge).  The problem is not so much a failure to
deliver information (or even a failure to deliver accurate information) 
as it is a failure to help the field and customers develop a context 
that allows that information to be turned into knowledge.

This is a very bad thing for a company in the information business and 
we are being roundly condemned and punished by the market for this
failure.  David Stone has had some interesting things to say recently on the
subject of data-->information-->knowledge-->wisdom.

This is a non-trivial problem.  I certainly don't have the
answers for it.  I do know that there is some recognition of the fact
that we tend to shoot information out of a firehose in some cases,
but in other cases the information becomes a drip by the time
it reaches customers.  I know that there is work going on within
some organizations to get a handle on the problem, to put together
the myriad groups who generate information and the myriad consumers
of the information, to work out protocols and an architecture to
help get the problem under control.

One of the most promising things I've heard is the recognition
by some that we need to construct information "pull" 
rather than information "push" environments.  This, to me, means 
that we are beginning to recognize the need to act more like
an information utility: we need to make information available via our
sophisticated infrastructure, but must understand that the consumers
of that information need to decide how much, what type, and when they
need that information.

I have an early draft of a paper that *begins* to discuss some of this
stuff.  It may never see the light of day, because I am not yet convinced
it's any good.  I wrote it over a weekend, mostly to help myself step back
and get a handle on the overall context; I don't know yet whether I
    succeeded or just confused myself even more.  If anyone wants a copy 
let me know and I'll mail a postscript file to you.

Glenn 
                                          

    The last I knew, the articles in Sales Update were written by the
    Product Manager.  Someone said that the only useful information in SU
    was the Product Manager's name and number.  If the PM's write the
    "useless" stuff in SU, why would you think that talking to the PM would
    be any more productive?
    
    Also in my (past) experience, while planning a release, PM's go to
    Engineering with a 'wish list' and negiotiates with Engineering to get
    the features and fixes that our customers want included in new versions
    of a product.  PM and (at least 2 years ago) Marketing, had input into
    what Engineering would or would not do but they did not have the power
    or influence to actually TELL Engineering what they should do. 
    Engineering has always seemed to have the right to do whatever they
    wanted.
    
    Now that the company is to be driven by Marketing maybe we'll see more
    attention to the customer's needs and less catering to the desires of
    Engineering to build new bells and whistles while only considering the
    techincal issues of product development.
    
    Marv
     

    The reason the contact name in the SU article is the best information
    is because you have to call them to find out what the article *really*
    says.  Too many SU articles are incomplete, inaccurate, and leaves one 
    with more questions than answers.  Worse, the inconsistency that
    Gartner mentioned.  Some articles are a microscopic, detailed view
    filled with techno-babble, others are a birds-eye view full of fluff.
    
    No perspective indeed.  
    
    I also have the same problem with the much touted audio tapes, which
    come across sometimes like you've stepped into a conversation and you
    don't know the topic.  I wish sometimes that sales people would write
    the articles and produce the tapes; after all, isn't sales and sales
    support the primary audience?  Who better to communicate than someone
    from the intended audience?
    
    re: responses so far.  Very interesting and somewhat typical at
    Digital.  No one has said "gosh, is Gartner right?  Is this accurate?
    What can we do to change this?" Instead, I see replies
    on measuring systems, the right kind of competitive analysis,
    engineering and marketing's role, price points for success, a
    discussion on 1.0 vs. 1.1 functionality, successful team approaches, 
    and strategy discussions.  Reply .16 hit it on the head: THIS IS A
    COMMUNICATION PROBLEM.
    
    I've felt for a long time we need a (people) communication
    architecture.  It appears to me no one is looking at the "big picture:"
    	Sales Update		inconsistent, incomplete, inaccurate
    	System/Option Catalog	dated, no pricing, no benefits, no
    				perspective
    	DECdirect Catalogs	dated, nice pictures and benefits, not
    				enough configuration information, hype
    	Customer Update		Sanitized, *no pricing*, some benefits
    	Product Bulletins	No pricing, lots of marketing hype and 
    				benefits, no part numbers or configuration
    				info.
    
    Consequently, we have a *communication problem* noted by Gartner, the
    field, and sadly, our customers.  We overkill the customer with the
    above documents because they are all needed to explain the Digital
    solution.  
    
    What a waste of trees and company expenses!  What an awesome company
    we could be if we weren't "embarassed" to sell!!  What a frustrating 
    company to sell for!!!!!!!!!!!!!!
    			
     

    Just to add to the points made by .39.
    
    	- SOFTBASE is not up to date, there is info in there that is
    		inaccurate and woofully outdated (ie, vendors who are
    		no longer CMPs and/or no longer exist).
    
    	- OPAL does not contain presentation materials uniformly across
    		marketing/whatever groups (ie, I think every presentation
    		created by marketing, services, etc... should be available
    		thru OPAL).
    
    	- Company profiles are not kept up to date in VTX.   Every
    		company I've ever researched has D&B info no more
    		recent than 1990.
    
    The problem is that these databases and others are only maintained
    by some groups and individuals.   I can find some excellent proposals
    in VTX, but it is a limited set of services and capabilities
    represented there.
    
    So, I agree about an information architecture for sales and sales
    support information.   What good is the info, if you can't find it?
    
    regards......
    
    Kevin	

    
    Actually, during the 80's I saw large efforts to control the
    information we put out, and to ensure everyone spoke the correct
    party lines etc etc etc...
    
    I suspect this has only had negative effects - needed or useful
    information comes far to constrained and most likely quite useless
    to bizarre via some sources.  DECUS used to be a place where customers
    sent their engineers to try and get the real scoop on info. They would
    go away feeling "good" that some engineer gave them the "inside" story,
    and it did build a lot of confidence at the end-user level.
    
    We became more "corporate" and started talking with the bigger fish
    to make the million/billion dollar deals, and thus started laundering
    the messages for that audience.  While it certainly made us some big
    bucks for a while, it seems to have also eroded end-user confidence
    either by giving them junk, or to many contentless messages or maybe
    both - they do not appear to be coming back for seconds anymore! You
    can much easier fool someone up the chain then the person who depends
    on our products to operate them to earn their pay!  I'd wonder if we
    might be better off by not trying to contain or channel product
    information.  The percieved harm of openness maybe more lethal than
    letting too many messages out!
    
    something to think about...
    
    bob

  FWIW, if you feed your dog arsenic it will make his coat shine ... for a
  little while anyway.

  [ This practice was common amongst farmers trying to sell a 'dubious' cow
  at the turn of the century - let it graze in the field polluted by mining
  spill runoff for a few days, it's coat becomes glossy and appealing, then
  sell it before the longer term effects become visible.  Come to think of
  it, we do that with some of our software projects too ... give them some
  flashy features to sell it to the customer before they realise that the
  underlying bits are pretty buggy ... ]

  Frank

      .37 is interesting on data->info->knowledge->wisdom, and I'd agree
    it's a non-trivial problem.   If you look at what people want to buy from
    computer vendors, though, you can represent it as a form of "packaged"
    knowledge to help get their job done.   
               
      As Ken Olsen says, (approximately) people don't buy computers, they buy
    things that they think will help in their work.   Data and information
    on computers is useless to non-experts.   They want to "know" how to
    use a computer to do something - since about all they can do is turn it
    on, read text and type at a keyboard (and MAYBE drive a mouse), we have
    to make something that fools them into thinking they know how to use
    the set of product(s).
    
      On how to structure data and information into knowledge (and maybe
    wisdom), I remember reading a long time ago about a guy called Gagnier
    (sp?) who produced a cognitive hierarchy, or taxonomy, based on studies
    with USAF training in the Fifties, on what it took to get raw
    conscripts to use complex pieces of equipment and follow complex
    procedures correctly.  
    
      The ranking went up through being able to identify, recall, analyse,
    synthese, and generate actions, from reading or being told data.
    I've always kept this idea at the back of my head when doing
    "knowledge-engineering"-type data capture and analysis, and found it
    helped to partition data, training, and process roles into groups which
    were easier to describe.   Has anyone heard of this guy or similar
    work?   Could it be used in defining an "information" or "knowledge"
    architecture for product information, has anything already been done in
    this area? 

	A lot of the Gartner Group's criticisms fit in with the similar
	criticisms I've read from the Internet about Digital's flipflop
	on OSF/1 for MIPS.

	In the latter discussion, one typical response wondered why people
	at Digital were allowed to make public announcements without
	clearing them with "higher authority". This clearly makes the
	reasonable assumption that there is a "higher authority" that
	makes, or at least arbitrates, Digital's global strategies
	and the annopuncements we make about them.

	I believe that assumption to be totally false. The way Digital
	seems to work is that anyone can make a business proposal and,
	if it is approved, run that business as long as it appears to
	be profitable. This leads to

		(1) A plethora of more or less independent businesses
		    or "product lines" (not all of them represented in
		    Corporate Engineering, though most are).

		(2) Each of these "enterprises" is led by a bunch of
		    managers whose careers depend on making it successful.

	BUT! There is no overall measurement system, as far as I know, to
	track which businesses are really successful and which are not. There
	must be thousands of ways of fudging the books to make it look as
	if your business is far more successful than it really is - and
	this activity is so pervasive, so accepted as part of a manager's
	normal behaviour, that people take it for granted. Since "perception
	is all", this also involves an extreme form of "success has many
	parents, but failure is an orphan". It seems as though thousands
	of eagle-eyed vultures are watching each infant enterprise - if it
	looks at all like turning sour, they descend in a cloud and rend
	it to pieces (e.g. VAX 9000) - if it seems a success, there are an
	amazing number of people who invented it, proposed it, sponsored it,
	manage it, etc etc. In many cases, I believe external announcements
	are just another weapon in the struggle to win internal mindshare.

	Why is the information that percolates to the field and to customers
	of such poor quality? I would isolate the following contributing
	factors:

	(1) Because Digital lacks a properly designed and managed Marketing
	    function, the collection of requirements is only approximate.
	    Thus, and also because we often aim for mass markets, products
	    tend to supply "infrastructure" rather than "end user" features.
	    Take some of the NAS stuff, like ACA Services or SQL Services.
	    These are not easy to use, yet they are astonishingly powerful.
	    In the form in which Engineering ships them, they have 95% of
	    what's needed to delight end users, but are sufficiently complex
	    and unclear that 95% of sales people and customers can't make
	    head or tail of them. There are two solutions to this problem:

		A. Finer-tuned requirements collection (which The New Software
		   Group and others are doing through QFD and other methods.

		B. Properly staffed, funded and resources corporate teams
		   tasked with taking (e.g.) "raw" ACA Services, and turning
		   out demos, readable papers, manuals, real applications,
		   and even Sales Guides. Collection of reference sites and
		   testimonials would also fall in this team's remit. They
		   have to add the extra 5% to turn the raw products into
		   products which customers will actually stand in line for.

	(2) A lot of decision-makers, senior and middle management, have
	    to be consulted. These people often have no clear idea of the
	    real value of use of the technology they are responsible for
	    getting sold. They tend to get stuck at the "general cliche"
	    level. Then the Sales Update and other supporting material
	    tends to get written by product managers or others with "product
	    blinkers" on - i.e. they don't know much about anything except
	    their own product. This tends to contribute to a style which
	    is short on useful facts (not known or considered "secret"),
	    and substitutes bluster and hype.

	(3) The most important factor is that Engineering is still organised
	    on a strictly per-product basis. So DATATRIEVE, for example,
	    produces one Sales Update article when a new version ships.
	    So does RALLY, so does DECdecision, so does DECquery, etc.
	    But what sales people want to know about - at the msot - is
	    "why buy 4GLs and decision support tools from Digital?" So
	    really a step forward would be if all those products banded
	    together, pooled their features and competitive analysis, and
	    wrote a single article - no longer than 4 or 5 pages.

	/Tom

re .-1

A pretty good summary of what's wrong, in my opinion.

    
    ditto. I forwarded the note to a number of friends with the header:
    
    	this sums it up
    
    

  re: .0

  Obviously, I've just run across this note and all its replies.  I, too, like
  the summation given approximately 3 replies prior to this ...

  Strangely, it seems as if one very important aspect of the Gartner Group
  article hasn't been discussed (at least not directly) and that is the author's
  concluding paragraph about "Open Systems:"

>>Won't the New Organization Fix This?
>>
>> We are pessimistic. As a DEC sales executive said to us at DECworld, "65
>> percent of fixing a problem is recognizing you have it, and admitting it.
>> Only 35 percent is actually doing the fix."  We believe that DEC senior 
>> managers do not understand the seriousness of this issue (0.7 probability).
>> We are convinced that they are not ready to admit it except as lip service.
>> We are forced to conclude that DEC will let the window close on much of its
>> current technological advantage without turning it into market share (0.8
>> probability through 1994).

  It is this which scares me.  Unless something is done, the proverbial horse
  will have left the barn!

	-- ron