Conference 7.286::digital

    Just what IS your problem???
    
    You complain that
    >It appears that gathering product requirements is treated as just a check
    >off item in the Phased Review Process.
    
    and,
    >Even when products are created to fill a perceived market need it seems
    >engineering groups decide what the product should be even before they
    >start soliciting input.  Requirements gathered during the Phased Review
    >are only incorporated when they fit the preconceptions of the engineers.
    
    yet,
    >sender but I get so many of the stupid things that's not feasable.  So
    >guess what happens to 99% of the requests for requirements I receive:
    >Off to the bit bucket.
    
    Talk about a self-fullfilling prophecy.  You can't have it both ways. 
    If you want input to Phase 0, then provide it.  They are sending out
    "blue sky", "good ideas" for comments that can be used in developing a
    Product Requirements Document.  Of course they are vague.  They are
    SUPPOSED to be vague.  If they were more detailed, they would not 
    need your help.
    
    Quit complaining about products not meeting market needs until you are
    ready to stop throwing away the requests for input to those products!!
    
    Finally,
    
    >software product whose sales projections were wet dreams.  From my
    >perspective it's obvious why we have so many software product failures.

    The engineering team asks for your valuable, first hand field input and
    you do not provide it.  Being rational thinkers and not hearing to the
    contrary, they just presume they were right in the first place. From MY
    perspective, you are part of the problem, not the solution. 
    
    
    Just my opinion, of course.
    
    	Dave

    Re .1
    
    Hey, go easy on .0. I for one agree with him. I have never seen any
    Phase 0 request that reads as follows:
    
    We think there is an opportunity in the XYZ market to provide a set of
    functions to solve the ABC, DEF problems that we have noticed a lot of
    people having. Do you have any ideas on what a product should look like
    to be successful in this market. If you have customers in this market
    I'd be particularly interested in your input.
    
    instead I see things like the following. Note that they are not worded
    like this but might as well be:
    
    Here is a description of a product that our engineering group has
    nearly finished designing. I the product manager am getting a lot of
    pressure to close Phase 0 because the engineering group have a schedule
    to meet and want to close Phase 1. If you've got any suggestions on any
    one-pluses please send them to me. And by the way please send me this
    input within the next week because I'm going to get my arse shot off if
    I don't get Phase 1 closed soon. You see our business manager has
    decreed that no Phase 0 shall be open longer than 3 months and I
    couldn't even have thought about asking for product requirements before
    I had a draft product spec to work from.
    
    Note there is NEVER any mention of MARKET, never any mention of what
    problem is trying to be solved. But always mention of how the product
    is envisioned to be.
    
    Dave
    
     

re: .0

At least you get the darn things!

re: .1

Let's not forget that the way they are written, I'm supposed to have done my
own market analysis, etc., since they want to know how much business we will
lose if we don't implement my suggestion, etc.

Bob

    
    Re: .0 and .2
    
    You're both right that often is the case.
    
    Re: .1
    
    You're right, too.
    
    
    Steve_who_was_a_product_manager_and_happy_the_word_is_WAS.
    
    

    
    So what's the right way to gather product requirements? Inquiring
    engineers want to know.
    
    Let's take a stab at _fixing_ this one...
    

    I must take exception to both previous notes, the way things are going
    lately is that we always seem to be a day late and a dollar short. The
    necessary skills are detriment in throwing the darts at someone's 
    inflated wish list.

    re: .5
    
    Product requirements should be gathered from potential customers of the
    new product.  The information needs to be gathered in a systematic way,
    so we can say with some confidence how many sales will be lost for lack
    of each optional feature, and how many sales will be lost for each
    month the product is delayed.
    
    With that information we can make intelligent tradeoffs between
    features and time-to-market.
        John Sauter

    The collection of market requirements (phase 0) is generally corrupt:
    
    Where the Business Units have the opportunity they will turn to outside
    suppliers and contract with them for the software they want, they do
    and avoid the process entirely.
    
    Software Engineers are the power brokers of the formal phase review:
    they pass judgement on what can be done and what cannot be done, and
    what can be done usually matches the agenda and skill sets at hand.
    
    This isn't a conspiracy, it's a tradition and the real villains are the
    indifferent sales managers who don't listen to sales reps and hear what
    their customers want or why there are so many non-customers.  It's a
    legacy of times when we thought that Digital's software engineer's
    needs were representative of our customers needs.  Look at how long we
    were able to avoid transaction processing, for example.  Something that
    our customers were asking for years before ACMS was shipped.
    
    It's 1991 and to any sales manager who complains that the products are
    NG, I say where were you in 1990 or 1989?...  What are you going to do
    in 1991 to influence 1992 or 1993?
    
    If a sales rep or manager (as opposed to a consulting engineer wanna-be
    like me) showed up at a Phase 0 Review, I'm sure it would make
    headlines in Livewire.
    
    If you want a customer-driven company, you've got to consider the sales
    rep the surrogate for the customer.

    Oh good, another complaints note.   :-)
    
    My particular complaint is about the names of things.  I get
    requests for requirements for products with names like 
    Digital Information Access Facility.   If I'm really
    lucky, the memo will explain to me that the Information
    Access Facility is intended to allow customers to 
    "organize" their "information" and to "use" it.
    
    Yeah, really useful explanation. I understand perfectly.
    (Hmm, maybe it's a new memory controller chip?)
    
    If I can't even figure out what problem area the thing is aimed
    at, based on the request-for-requirements, I won't be
    surprised if customers can't figure out what it does,
    either.
    
    --
    
    Any similarity between names used in this note, and actual
    products, living or dead, is purely coincidental!

	Re: .9, What he said...

	I received one a couple of days ago that only referenced the
	product by its initials; neither the full name of the product
	or a description of what it would do, the intended market, etc.
	was present.

	Off to the bit bucket they go...    

    This comment applies to both Hardware and Software:
    
    The key ingredient is "The Customer."  Engineering should involve the
    "Customer" at conception.  However, Engineering must also partner with
    the other functions as well "Sales, Service and Manufacturing" to name
    a few.  Why don't we tie the engineers' performance rating to the
    success of the product in terms of ROI (Return on Investment) or
    Profitablility over the life of the product.  Also, make the engineer
    responsible for the product even after it ships.  One final note, Sr
    Mangement needs to support this thinking.  

        From .2:

>    Here is a description of a product that our engineering group has
>    nearly finished designing. I the product manager am getting a lot of
>    pressure to close Phase 0 because the engineering group have a schedule
>    to meet and want to close Phase 1. If you've got any suggestions on any
>    one-pluses please send them to me. And by the way please send me this
>    input within the next week because I'm going to get my arse shot off if
>    I don't get Phase 1 closed soon. You see our business manager has
>    decreed that no Phase 0 shall be open longer than 3 months and I
>    couldn't even have thought about asking for product requirements before
>    I had a draft product spec to work from.

        There are a couple of catch-22s that can help cause product
        requirements to end up like this.  They don't hit all products,
        but they hit more than enough.

        The V1.0 catch-22:

        In order to avoid wasting resources, no product management,
        technical writing, or other support is given to the project
        until some code is demonstrated to work.  Once it works, the
        story is `ship it as soon as possible' so pressure is placed
        on the product manager to close Phase 0 rapidly, and send out
        a message like above.

        The V1.1 catch-22:

        Development on a new version has to start right away after the
        previous version ships, or else `the developers will be idle and
        assigned to another project and no one will ever work on this
        project again'.  If the product manager gathers input before the
        design of the new version starts, then Phase 0 for V1.1 has to close
        before any customer sees V1.0.  If the product manager waits for
        customer input, then the new version is almost designed.  This
        catch-22 doesn't apply once several versions of the product have
        been released, because customer comments from V1.0 can be
        applied to V1.2 (and hopefully V1.1 didn't go in the wrong
        direction).

        The motivations behind these problems are good--a desire to
        reduce costs and decrease time to market.
        
        					B.J.

>               <<< Note 1417.5 by ESCROW::KILGORE "Wild Bill" >>>
>
>    
>    So what's the right way to gather product requirements? Inquiring
>    engineers want to know.
>    
>    Let's take a stab at _fixing_ this one...
 
Time on site...  

If you can't do it personally...  Become buddies with some of the field groups
who can...

    There can be no "surrogates" for the customer - not marketing, not
    sales, no one.  The best way to gather customer requirements are
    through techniques like Contextual Inquiries and QFD's which involve
    direct interaction with end users.
    
    Sales, marketing, service, manufacturing, engineering must all
    participate actively in the requirement phase working together as a
    single team - not passing documents over walls for input or review. 
    
    The the "voice of  customer" must continue to echo loud and clear all
    through the development process. 
    
    When user needs change, then Phase Reviews Processes must not stand 
    in the way of changing the product.
    
    A product delivered on time and on budget is of little value if market
    conditions have changed since the requirements. 
    
    

    
>    There can be no "surrogates" for the customer - not marketing, not
>    sales, no one.  
    
    Amen!  This is not to say that field personnel (Sales, Sales support,
    EIS) can't provide suggestions and direction.  Unfortunately these
    folks (I'm one of them) have a necessarily narrow perspective (like how
    many customers does one EIS consultant see in a year?) and NO charter
    to spend time on market research studies.
    
    I can tell you what MY customers' likes and dislikes are regarding a
    product, but I'm in no position to tell you if my customers are
    reperesentative, or what percentage of the market they might represent
    or how many bucks we'll gain or lose if feature X is/isn't implemented. 
    As a result, I'm pretty effectively locked out of Phase 0.
    
    One approach to field feedback is the NOVA::RDB_WISH conference.  I've
    found this a useful channel for passing along customer requirements.
    
    -dave

    
    I essentially agree with .14 and .15.
    
    Re: What is the right way to get product requirements?
    
    There is no ONE right way, but there can definitely be a wrong
    time.  The wrong time is after you've done the design and committed
    yourself to it.  We do that a lot.
    
    Re: If we don't do this feature or deliver by this date how many
    sales will we lose?
    
    This should NOT be a/the metric.  It emphasizes the wrong thing!
    Our customers are particularly sensitive to this mindset and 
    are not happy with it.  I suggest we turn this around to say "If
    we don't do this feature or deliver by this date how many
    dissatisfied customers will we have?"  Believe me there is a BIG
    difference between saying it this way and saying it in terms of
    sales in both how we will behave and how our customers will view us.
    
    Steve

	This is a real bear of a problem.  We really need to get the 
    customers involved, but we can not ask the customers because that might
    just make some of them think we would do what they tell us to do.  (This
    is NOT a joke.  By asking them we might set some expectations that will
    not or can not be met.)

	So we should ask the people who talk to customers.  The sales people,
    the sales support people, the field service people, the software service
    people, the specialists at the CSCs, the secreties in the field offices,
    the call routers and dispatchers and any employee who attends customer
    DECUS should have a clear mechanism for reporting ANYTHING they hear from
    customers.  It then has to be sifted for the useful information it contains
    by someone who knows what they are doing.

	After something useful has been found, the source of the information
    has to be rewarded so more information like it will be produced and so the
    communication channels will stay open.  Then the information has to be 
    used to make the company more profitable, so there will continue to be
    more rewards available to continue the cycle.

	This whole set of activities is called market research and is something
    DEC is noted for NOT doing.  And DEC is NOT likely to do it in the near
    future either.  If it was done right, Engineering would not WRITE phase 0 
    requests but would READ them.  This would be too drastic a change from the
    current way things are done and would shift control out of Engineering's
    hands, so it will never be done.

	Even if someone did get an idea from a customer (or anywhere else for
    that mater) that they could not immediatly turn into a phase 0 proposial,
    it would be buried, rather than turned over to someone who could do 
    something with it, because that good idea might end up competing with the
    current project and winning!

	The only possible way to fix this would be to start a new company 
    inside DEC with the proper structure and then transfer people and functions
    into it as it became strong enough to support/use those people and 
    functions and make sure it could not be killed by the people who have a
    vested interest in the old structure.  It would take a minimum of three or
    four years and some very smart people indeed to do this.

    re: .16
    
    While I agree that there is a difference between emphasizing profit and
    emphasizing customer satisfaction, I still feel that profit is the
    proper place to put our emphasis.  We should do something unprofitable
    in order to achieve customer satisfaction only when a decision has been
    made that the investment in customer satisfaction will improve our
    profit in the long run.
    
    If we don't emphasize profit, there will be no long run for the
    corporation.
    
    re: .17
    
    The specialists at the Colorado Springs CSC write a contact report 
    for each customer call they take.  I have found those contact reports 
    good for developing a feel for how customers are reacting to my product.
    
    I think you are too pessimestic about Engineering's reaction to changes
    in the requirements gathering process.  In our group, the Product
    Manager gathers suggestions and summarizes them into the product
    requirements document.  There is essentially no input by anyone else
    in Engineering into this process.  Where Engineering gets involved is
    in taking those requirements and developing a plan to satisfy some of
    them in the next release.  Sometimes we don't just take the N most
    popular items and design a release strategy around that, though I think
    we should.
        John Sauter

    re one or 2 back;
    
    I find the assertion that we can't discuss product futures with
    customers without creating an implied commitment a bit ridiculous.  We
    simply haven't tried.
    
    1.	How many customers know that they can submit an SPR to suggest a
    	new or modified feature?  When I was a cusomer, I didn't.
    
    2.	Why do we support DECUS, if not to get an open forum where such
    	discussions can take place?
    
    3.	Has no one ever heard of focus groups?
    
    4.	Independent market research companies?  As an MIS manager, I
    	participated in several new-product studies without ever knowing
    	who the prospective manufacturer was.
    
    I'm a techie, not a marketeer.  If I can think up this many approaches
    in 3 minutes, I'm certain a marketing professional could do a whole lot
    better...
    
    -dave

    re all previous notes suggesting "talking to customers" ...
    
    It is not sufficient to simply talk to our customers.  It's necessary
    and beneficial, but it's not sufficient.
    
    There are more PROSPECTS out there than there are CUSTOMERS.  By
    talking only to our customers, we are focusing on the needs of our
    installed base.  We also need to talk to prospects and understand their
    needs in order to expand our base.
    
    	+Don 

    Listen to, not Talk to.
    
    Limiting the interviews to organizations who have already bought
    stuff from us, especially large amounts of stuff from us, would
    bias the results and not necessarily be representative of the market.

    
    Re: .18
    
    >While I agree that there is a difference between emphasizing profit and
    >emphasizing customer satisfaction, I still feel that profit is the
    >proper place to put our emphasis.  We should do something unprofitable
    >in order to achieve customer satisfaction only when a decision has been
    >made that the investment in customer satisfaction will improve our
    >profit in the long run.
    > 
    >If we don't emphasize profit, there will be no long run for the
    >corporation.
    
    That changes it a bit, because you first termed it as sales.  Sales
    and profit are totally different.  There are more than a few products
    that we sell, but lose money on.
    
    I suppose we'll have to agree to disagree.  If we don't emphasize
    customer satisfaction, there will be no long run for the company.  This
    is NOT to say that profit is not important, but profit impresses
    stockholders, not customers.  Stockholders don't keep us in business,
    customers do.  If we don't meet their needs, they won't buy.  It
    really IS that simple.
    
    Steve
    

Re .18 on .16:

	Right on!

Re .18 on .17:

	If more engineers and managers were like you, the company would be
    overtaking IBM at the same rate now as we were in '87.  Unfortunatly,
    most engineers and engineering managers are more narowly focused than 
    you are.  You've noted yourself that the extra time you have put into
    the quality of your product may have been career limiting, if I remember
    correctly.

	It would not be impossible to restructure engineering along more 
    market oriented lines, but it is very unlikely to happen.  There would
    have to be several things done first.

	The first would be a customer contact tracking system, with elements
    similar to the call reporting system used by the CSCs.  If done properly,
    it would help the sales and sales support people a lot.  For one thing,
    it would give the COMPANY a memory of what we have said to customers;  We
    would no longer have to rely so heavily on the memory of our sales and
    sales support people.  This would have lots of direct benifits to the
    sales organization and would have the secondary effect of providing the
    marketing information we don't currently have.

	Once the data gathering mechanism is in place, someone would have to
    go through it, looking for marketable ideas.  After the ideas are 
    identified, they need to be grouped into a product.  After that a check
    should be made to see if there is already a product similar to the one
    proposed.  If there is, it should be checked out to see if there is really
    a market for the product.  Then the idea should be circulated to see if 
    anybody thinks they can do the job.  Then come the all the stuff for Phase
    0.

	This looks like a lot of overhead and it is.  The sales part of the
    overhead would justify itself in improved customer satisfaction, a higher
    order rate and lower overall costs, IF it is done right.  The marketing
    research part could be justified if it cut out some of those .7% projects
    mentioned elsewhere.  (And that is one of the reasons it will never fly.)

    I read all 23 notes andcan see the real need for such a focal group.
    
    Unfortunately we are more competitive internally than externally which
    is why starting a business discribed in the previous notes would be
    hard to get started. Not only would some groups not want to shared
    information,they would view this group as a treat to thier future.
    
    It dose boggle the mind when you think of the savings of NOT developing
    a product that doesn't quit have all the bells and whisles. Quality
    products, not quantity of products. 
    
    

    Those in previous notes who seem to feel that product requirements can
    be garnered without actually meeting the customer should go and boil
    their heads!
    
    A lot more people should go and talk to Russ Doane, who has a clear and
    simple message which compels the conclusion that it is highly unlikely
    that a successful product can be developed without *experiencing* the
    customer's needs. This demands such approaches as contextual inquiry.
    
    By the way, I have successfully met with over 300 customers over the
    past (mumble) months and sat in the workplace with over 10 of them.
    I've run QFD's with over 25 of them. I've even copied them some of the
    reports!
    
    I've found that:
    
    	1) There appear to be no legal problems, and I've used a Digital
    	   lawyer, too.
    
    	2) After over a year in getting my first requirements, the data
    	   is having a big effect on the company's product development.
    
    	3) Customers don't come back to us with the expectation that we
    	   should have finished a product for them.
    
    	4) Most of those customers are calling me and my colleagues and
    	   asking if they could go through the same sessions again, because
    	   they learned more about their own jobs and information systems
    	   than they knew before we asked 'em!
    
    Do it, it works.
    
    Ray

I gathered together all of your most interesting comments, and added some
(admittedly sarcastic) comments.

   You may not appreciate this, but I learned some important things from
   the exercise, thanks to you all...
   
Dick

re Note 1417.0         KYOA::MIANO 

{1} ...
>I receive a phase 0 request for requirements for a new software product
>about once a day.  

do we start too many product designs?

{2} ...
>Rarely do the requests for requirements even say
>what markets we are trying to penatrate! 

why should engineering tell marketing what markets we are trying to
penetrate?

{3} ...
>Even when products are created to fill a perceived market need it seems
>engineering groups decide what the product should be even before they
>start soliciting input.  

why is engineering soliciting input, isn't marketing informing
engineering what products are needed to catisfy customer needs?

re Note 1417.2         SMAUG::GARROD 
...
>Note there is NEVER any mention of MARKET, never any mention of what
>problem is trying to be solved. But always mention of how the product
>is envisioned to be. {see 3}

re Note 1417.3         SCAACT::AINSLEY 

{4} ...
>Let's not forget that the way they are written, I'm supposed to have done my
>own market analysis, etc., since they want to know how much business we will
>lose if we don't implement my suggestion, etc. 

why are you surprised that engineering expects a marketer to do
his/her own market analysis?

Note 1417.6         GRANPA::JFARLEY                                       
{5} ...
    >I must take exception to both previous notes, the way things are going
    >lately is that we always seem to be a day late and a dollar short. The
    >necessary skills are detriment in throwing the darts at someone's 
    >inflated wish list.

there isn't enough money for marketing to do its basic work?

re Note 1417.7         SAUTER::SAUTER 

{6} ...
    >Product requirements should be gathered from potential customers of the
    >new product.  The information needs to be gathered in a systematic way,
    >so we can say with some confidence how many sales will be lost for lack
    >of each optional feature, and how many sales will be lost for each
    >month the product is delayed.
    
    >With that information we can make intelligent tradeoffs between
    >features and time-to-market.  

does 'features' mean something besides sound, basic functionality
which will help a customer solve a problem?

re Note 1417.8         SDSVAX::SWEENEY 

{7} ...
    >The collection of market requirements (phase 0) is generally corrupt:
    
    >Where the Business Units have the opportunity they will turn to outside
    >suppliers and contract with them for the software they want, they do
    >and avoid the process entirely.

is the product stream too far removed from today's selling
opportunities to command the Business Units' attention?  Don't they have
a planning responsibility too?

{8} ...
    >Software Engineers are the power brokers of the formal phase review:
    >they pass judgement on what can be done and what cannot be done, and
    >what can be done usually matches the agenda and skill sets at hand.
    
can't we get some software engineers to wear a marketing hat, at
least temporarily?

{9} ...
    >This isn't a conspiracy, it's a tradition and the real villains are the
    >indifferent sales managers who don't listen to sales reps and hear what
    >their customers want or why there are so many non-customers. 

are there well defined channels to provide this kind of intelligence?
are there any places where we can store it?


re Note 1417.10        HOBBLE::WILEY 

{10} ...
	>I received one a couple of days ago that only referenced the
	>product by its initials; neither the full name of the product
	>or a description of what it would do, the intended market, etc.
	>was present.

suppose you later found out that the XYZ widget was just what would
have clinched that $50,000,000 ten-year deal?  and you couldn't take the
time to ask what XYZ meant?


re Note 1417.11        NATASH::GARMAN 

{11} ...
    >Why don't we tie the engineers' performance rating to the
    >success of the product in terms of ROI (Return on Investment) or
    >Profitablility over the life of the product.  Also, make the engineer
    >responsible for the product even after it ships.  One final note, Sr
    >Mangement needs to support this thinking.  

senior management, surely you jest!  in digital, we don't make
system wide rules on anything!  no senior manager(s) have any real
authority, they have empowered their subordinates, who ...

{12} ...
        >In order to avoid wasting resources, no product management,
        >technical writing, or other support is given to the project
        >until some code is demonstrated to work. 

don't we 'invest' in good ideas in software?  if so, how?

{13} ...
        >Development on a new version has to start right away after the
        >previous version ships, or else `the developers will be idle and
        >assigned to another project and no one will ever work on this
        >project again'.  

that assumes that we do things sequentially, (and we do) but we
should be able to walk and chew gum.  the modus operandi should be that
we design a coherent 'family' of products such that v0 is proof of
concept, v1 has significant functionality, v2 is a major extension of v1,
and... we had that plan from phase 0!

re Note 1417.14        CALS::DIMANCESCO 

{14} ...
    >Sales, marketing, service, manufacturing, engineering must all
    >participate actively in the requirement phase working together as a
    >single team - not passing documents over walls for input or review. 

can you visualize just one representative from each of the five
stovepipes you mentioned having any common language in which to deal with
the product requirements? or even the basic notions of the technology?

{15} ...
    >When user needs change, then Phase Reviews Processes must not stand 
    >in the way of changing the product.

when does the 'real product' appear, if change is always allowed?

{16} ...
    >A product delivered on time and on budget is of little value if market
    >conditions have changed since the requirements. 

a company that makes products for today's market conditions will
fail.


re Note 1417.16        SQM::MACDONALD

{17} ...
    >I suggest we turn this around to say "If
    >we don't do this feature or deliver by this date how many
    >dissatisfied customers will we have?"  

this sounds like a very un-aggressive approach to the market.  we
need to aspire to something greater than trading off one customer against
another.  how about solving a core business problem?  maybe we should
talk to our customers' customers to understand what the problems in our
customers' industries are?


re Note 1417.17        VMSNET::WOODBURY 

{18} ...
>	So we should ask the people who talk to customers.  The sales people,
>    the sales support people, the field service people, the software service
>    people, the specialists at the CSCs, the secreties in the field offices,
>    the call routers and dispatchers and any employee who attends customer
>    DECUS should have a clear mechanism for reporting ANYTHING they hear from
>    customers.  It then has to be sifted for the useful information it contains
>    by someone who knows what they are doing.

>	After something useful has been found, the source of the information
>    has to be rewarded so more information like it will be produced and so the
>    communication channels will stay open.  Then the information has to be 
>    used to make the company more profitable, so there will continue to be
>    more rewards available to continue the cycle.

>	This whole set of activities is called market research and is something
>    DEC is noted for NOT doing.  And DEC is NOT likely to do it in the near
>    future either.  If it was done right, Engineering would not WRITE phase 0 
>    requests but would READ them.  This would be too drastic a change from the
>    current way things are done and would shift control out of Engineering's
>    hands, so it will never be done.
    
this is the proper direction, but market research is more than
accidental collection of intelligence, it's systematic research into the
entire business environment we find ourselves in.  it can't be limited by
geographies, markets, products, or whatever.  

{19} ...
>	The only possible way to fix this would be to start a new company 
>    inside DEC with the proper structure and then transfer people and functions
>    into it as it became strong enough to support/use those people and 
>    functions and make sure it could not be killed by the people who have a
>    vested interest in the old structure.  

creating a 'new digital' within the 'old digital' is a common
process, i've seen about three iterations in the last 15 years.

re Note 1417.23        VMSNET::WOODBURY 

{20} ...
>	The first would be a customer contact tracking system, with elements
>    similar to the call reporting system used by the CSCs.  If done properly,
>    it would help the sales and sales support people a lot.  For one thing,
>    it would give the COMPANY a memory of what we have said to customers;...

we don't have a systematic way of keeping track of intelligence? :-)
sure we do.  we hire a lot of engineers, salesmen, marketeers, and let
each of them learn as much as possible.  then we take them all to any
meeting and let them dump it back on the table for all of us.

re: .26

<re Note 1417.3         SCAACT::AINSLEY 
<
<{4} ...
<>Let's not forget that the way they are written, I'm supposed to have done my
<>own market analysis, etc., since they want to know how much business we will
<>lose if we don't implement my suggestion, etc. 

<why are you surprised that engineering expects a marketer to do
<his/her own market analysis?

Are you suggesting that only marketing should have input into PHASE 0?  It
seems to me that the user of a product, should be able to make a credible
suggestion to improve a product, without doing a market analysis.  For example,
if the writers of Phase 0 , currently Engineering, get a bunch of requests for
feature x, someone should conduct the appropriate marketing research.

Bob


    re Note 1417.27 by SCAACT::AINSLEY 
    
>Are you suggesting that only marketing should have input into PHASE 0?  It
>seems to me that the user of a product, should be able to make a credible
>suggestion to improve a product, without doing a market analysis.  For example,
>if the writers of Phase 0 , currently Engineering, get a bunch of requests for
>feature x, someone should conduct the appropriate marketing research.

    I  guess I have a strange view of things.  Somebody, somewhere, has to
    start the idea rolling.  Maybe  we don't  call  that phase 0, but I
    would  hope that there is someone charged with understanding, 
    analyzing, and planning to exploit business opportunities  in, say, the 
    oil exploration market.
    
    I don't  think that an engineer buried in the depths of Spitbrook is 
    well placed  to do that  job.   An oil exploration industry consultant
    is.  I would expect that it would  just be common sense that the 
    consultant would be  asked his opinions by or  would volunteer them to
    a market strategist,  whatever his/her title.  What kinds of problems
    are companies in the industry having or will they have during the next
    two to five years?  What kinds of  products, h/w or s/w would make us
    money in that market?  
    
    After someone asks and answers these questions, someone in engineering
    tries to create a product design to exploit the opportunity. 
    Hopefully, the originator of all this (and anyone else who might have
    some useful ideas) is asked if this product description is  close to
    meeting the market opportunity.  (That is what I understand Phase 0 to
    be).  
    
    Then, some specifics are discussed with specific customers in the same 
    market.  Their reactions are fed back into  the engineering and
    marketing organizations who adopt a joint plan for design and  sale of
    the potential product.  Soon after, a manufacturing plan is developed
    and we start turning these ideas into reality.
    
    
    I  admit that this is  pretty academic sounding, and ignores dozens of
    financial, political, and resource hurdles that the product must pass,
    but isn't it a reasonable simplistic model?
    
    Perhaps John Miano, the author of .0 is receiving phase 0 requests
    where he wasn't aware of  the pre-phase 0 work and it wasn't  well
    described.  I don't  know who is at fault, but I am disturbed by the
    implication that marketing people don't know what is going on in the
    product development space.  I can't imagine how we can expect anything
    good from the lack of communication.
    
    (a little more serious, this time),
    
    Dick

    
>>Are you suggesting that only marketing should have input into PHASE 0?  It
>>seems to me that the user of a product, should be able to make a credible
>>suggestion to improve a product, without doing a market analysis. For example,
>>if the writers of Phase 0 , currently Engineering, get a bunch of requests for
>>feature x, someone should conduct the appropriate marketing research.
>
>    I  guess I have a strange view of things.  Somebody, somewhere, has to
>    start the idea rolling.  Maybe  we don't  call  that phase 0, but I
>    would  hope that there is someone charged with understanding, 
>    analyzing, and planning to exploit business opportunities  in, say, the 
>    oil exploration market.
>    
>    I don't  think that an engineer buried in the depths of Spitbrook is
>    well placed  to do that  job.   An oil exploration industry consultant
>    is.  I would expect that it would  just be common sense that the 
>    consultant would be  asked his opinions by or  would volunteer them to
>    a market strategist,  whatever his/her title.

	What about PSS residents ?  We often live at a customer site for
	months or years.  It seems reasonable that we should be able to
	make decent recommendations.  However, it isn't reasonable to expect
	us to perform a market study.  I think the writer of .27 has it
	right: if there are enough requests for a given feature, then do
	the research to determine if it should be implemented.  Then provide
	a little feedback to indicate that the request was heard, and what the
	disposition was.  If people think their ideas are being ignored
	then they won't bother to send any in.

	Marshall Wiley - PSS