| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 677.1 | Office of the Future is dead | AUNTB::WARNOCK | Todd Warnock @CBO | Fri Dec 16 1988 16:00 | 9 |
| At one time, I saw a list of things that were discussed. I gather
the big thing was that it was field driven, rather than than corporate
driven. The only thing I remember (without the list in front of
me) is that the "Office of the Future" concept is dead. In fact,
in the Carolina's District, we're already hearing rumblings about
retrofits for the 2-to-a-cube cubicles.
Todd Warnock
Sales Support - Carolinas District
|
| 677.2 | Two reasons! | MERIDN::JENNINGS | Just the VAX, please! | Fri Dec 16 1988 20:50 | 9 |
| I believe they are back east for two objectives:
1. DEctop University (for the 1/10 product announcement)
2. To get achance to talk to senior management who intends to listen.
If they intend to listen I hope they visit this notes file to
understand what the corporate sentiment is all about.
ED
|
| 677.3 | Drive a stake through the "office of the future" | CAADC::TRAINIPEREZ | The project penguin is dead! | Sat Dec 17 1988 10:54 | 5 |
| Do all the software (read delivery) unit managers ever do this? If
not, should they? Or better yet, maybe have those interested senior
management to talk to the field grunts that actually do the work...
D
|
| 677.4 | What I've Heard | UTEXAS::RESENDEP | following the yellow brick road... | Mon Dec 19 1988 11:23 | 33 |
| I'm not in Sales, and therefore wasn't invited to the meeting.
However, I work with Sales managers constantly, and have talked
to a number of them who attended the first meeting. I have also
talked with some people at corporate who have access to senior
management and could explain some of the underlying reasons for
calling such a meeting. When I combine that knowledge with what
I've read in Digital Review, I *must* have the complete, accurate
story, right? (^;
Seems Ken has known for some time that there were problems in the
Sales organization, but didn't know what or where. Aparently he's
recently come to some conclusions; you can speculate for yourself
what those might be, 'cause I'm not into career limiting public
statements today. Anyway, everything I've seen and heard indicates
that Ken is once again taking a firm hand in running the company.
As it was put by one presenter recently, "Senior management has
put down their megaphones and put on their hearing aids."
Specifically, the meeting was for three purposes:
a) Announcements about changes. Such as announcing an across-the-board
*sizable* reduction in the U.S. hardware budget for this FY. Such as
the car plan fiasco and what's being done about it. Etc. Don't
know if Office-Of-The-Future was discussed.
b) A huge "what's on your mind" session for Sales management. What
makes their jobs harder? What changes would make selling easier?
What effects have recent changes had on morale? On selling?
On our customers' opinions of us? Etc.
c) DECtop University.
Pat
|
| 677.5 | What I heard | TELGAR::WAKEMANLA | Another Eye Crossing Question! | Mon Dec 19 1988 13:03 | 43 |
| I heard that this was mostly a morale boosting session for the Sales Organization.
This meeting was suggested by Field Sales Management and announced at this
years DECathalon. The following were some of the items to be duscussed at the
meeting (I got these from a Sales Rep who wnet to DECathalon):
1. 150% credit for most 8000 series machines for 6 months
beginning October 31st.
2. Modification of SPG credit as in #1 above (applies to SP2
and DECathlon, etc.).
3. Announcement of the Quote Administration Function.
4. Reinstatement of Car Plan A.
5. Elimination of <$10K Certs Non-credited policies.
6. A further Field budget decrease based upon the
bottom-up rep assessment (total decrease now at 16%
across the U.S.).
7. Elimination of the Monday night forecast call (in their
current forum).
8. Establishment of an on-going committee structure
for Sales input to Headquarters decisions.
9. Simplification and decentralization of allowance
authorization procedures.
10. Loosening of PID requirements/restrictions.
11. Halting of the "Office of the Future" initiative.
12. Elimination of multi-services gates for TOPDEC.
13. Announcement of the Education initiative.
14. Announcement of strategic partnerships with key
vendors, Allen Bradley, Honeywell, DCMP.
|
| 677.6 | Question... | COMET::MARTIN | I'm the NRA | Mon Dec 19 1988 14:42 | 12 |
|
Off the subject momentarily, however curiousity has gotten the
better of me. Who is Allen Bradley and what do they manufacture?
Are they out of Milwaukee, by chance?
C.
|
| 677.7 | Allen Bradley --> PLC's | LAIDBK::RESKE | Life's a mystery & I haven't a clue | Mon Dec 19 1988 16:01 | 9 |
|
Allen Bradely is a company who manufactures and sells PLC's. They
may be into other things but that's what I know of them. Most (if
not all) of the PLC's talk to the target devices via a method (protocol)
know as the "data highway".
Donna
|
| 677.8 | Yep Milwaukee | VMSSPT::BUDA | Putsing along... | Mon Dec 19 1988 20:47 | 9 |
| > Are they out of Milwaukee, by chance?
Yep, They are no longered owned by the Bradleys though. The Bradley
sold and made something like $500 mil. They gave ~$20 mil to have a
new basketball arena made, called The Bradley Center!
Heading back there, Thursday for Christmas vacation... Nice town.
- mark
|
| 677.9 | There IS such a thing as a free lunch! | GLDOA::FULLER | Just a Field Service monkey | Mon Dec 19 1988 23:31 | 9 |
| Allen Bradley makes a wide variety of industrial controls (or at
least they used to before I started with DEC almost 10 years ago).
I used to service some machining equipment in the old plant in
Milwaukee. That was a great place to go if you were a visiting
vendor. They had a policy that the vendor could eat in their lunch
room for free, as well as the A-B contact. I never knew how many
contacts I had there until it was lunch time. Then they all seemed
to crawl out of the woodwork.
|
| 677.10 | re: .6 | CIMNET::SCHEID | | Tue Dec 20 1988 09:08 | 7 |
| re: .6
For more infomation on Allen-Bradley and their new products which
were jointly engineered with Digital, check out the note file
CIMNET::CIM_SALES_SUPPORT.
|
| 677.11 | Report on "Software Feedback" session from meeting | DR::BLINN | Round up the usual gang of suspects | Tue Jan 03 1989 12:59 | 361 |
| Posted with the author's permission.
From: SSGBPM::HORNBACH "Kathy Hornbach, CASE/System Software BPM"
Date: 28-DEC-1988 12:20
To: BPM,@ZK_CASE,@PHASE
CC: SPGDSS::MERCURY,HORNBACH
Subj: Report on Software Feedback session at West Coast Sales Mgr Meeting --
feel free to forward.
On Dec 13/14, all of the West Coast Sales Unit Managers met in downtown Boston.
Part of this meeting was a series of "feedback" sessions, to PBU managers, on
how the field viewed their products and issues. I attended the two software
feedback sessions, which were given by Bill Keating (head of SDT), and Kurt
Friedrich (head of VMS).
The following are comments I recorded, almost verbatim from this meeting.
Remember that these are comments from individuals, and are not necessarily the
consensus of the entire group (it was obvious that some reflected a particularly
sore sales situation). Nonetheless, taken it entirety, they give a good feel of
what the world is looking like from the field's point of view.
This was an outstanding opportunity to get input from the "front line".
Apparently this is the first time DEC has brought together all these people for
such a meeting. I hope it is done again soon -- the level of insight and
feedback available from that group was awesome.
I have prefaced the comments with a summary of the themes that seemed to be
recurring in many of the comments.
Hope you find this feedback as useful as I did.
--Kathy Hornbach
Systems Software Base Product Marketing
Themes:
- Software is driving the sales, and we have good software products. CASE and
All-in-One are especially well-respected, but there are few in the field who
know enough to demo or support CASE.
- Lack of adequate sales support is biggest problem. Too few people, they don't
know the products well enough, and now even the few sales support people we have
are being assigned part time to revenue-generating projects
- We have way too many products to understand and they are way too complex to
administer and license.
- Confusion from customers and the field about OSF/Ultrix/VMS/standards and
DEC's position w.r.t. these
- Field wants to know the *reasons* behind decisions and strategies.
- Sales want to know more about our products. We used to train on products, but
haven't been lately. They miss Success Train. They used to be able to give
overview technical presentations, but haven't been given the training to do
that.
- PID process is awful -- PIDs don't contain any meat, presentors aren't allowed
to elaborate at all, and presentors don't always have needed background to be
accepted as an authority on their subject
- Need to win the desktop - that's where the applications are, and applications
drive the backend.
- Need to have a customer visit center at Spit Brook, like manufacturing has set
up for CIM
------------------------------------------------------------------------
Specific comments (grouped by subject area):
*******VMS/OSF/Standards******
- Confusion in the market -- trade press is all OSF/UNIX!! VMS is still a
leadership product. Customers are making easy decisions. Have sold more Unix
in the last 8 months than the previous 8 years. The think, "I need portability,
therefore I will buy Unix". This is the easy solution, but often the wrong one
for the customer. We need to get the AIA/POSIX messages out.
- Field needs to understand what POSIX means over the long term; need to know
where are software architectures are going.
- Worry that if industry goes to a Unix standards, the Japanese can outdo us
- The reason Ultrix is not selling well is that people how want Unix tend to
want point solutions and go for the hotbox vendors. People who come to Digital
have come for another reason
- Need SMP on Ultrix
- Worried about performance implications of POSIX on VMS
- Precedent of OSF using AIX is difficult -- IBM has a selling advantage on the
superiority of AIX now.
- Need a white paper on Ultrix and VMS positioning
- Will IBM do OSF on MVS, or stick with SAA?
- Want an AIA manual for customers.
- What materials are there out there that show the VMS unique messages? What
makes VMS a superior operating system? People always say it is, but no one has
listed the specific, detailed reasons why.
- Need a point-by-point comparison of VMS vs MVS, in *their* terminology
******Sales Support/Training/Sales Tools*****
- CASE, OA, DB -- are all heavy sales resource intensive in the sales cycle;
and we don't have enough resources; makes it tough to sell into these
product areas
- Hardware is a commodity. Customers are looking towards applications. Training
in the field is lacking in applications
- We have terrific products, but we are struggling to find people to sell them
and to support them through the CSC. We should insist that we have sales
support training and CSC training before we ship a product. Cobol Generator and
VMS Services for MS-DOS are terrific -- way ahead of their time -- but they are
complex, and we don't have any sales support for them
- The reduction in sales support really hurts. We have a huge plate of products
-- we need to have sales support to be able to present them
- Audio tapes are the best way to get information out so people will learn it
- The key issue for big systems is the database, and software. Plus the
availability of support in the field.
- So many products to know -- need a way of quickly attaining basic literacy in
a minimal amount of time in a product space. There are no programs to make it
easy to get basic knowledge.
- Lack of sales support for our software products results in the field relying
on ISVs that have competing, but well-supported, products. Example is Oracle
vs. Rally.
- The field doesn't use enough of the tools themselves, that they sell. If they
use them, they will be much more comfortable selling them. Field applications
should be built using the arcitectures and technologies we are selling our
customers.
- There are still no workstations for people in the field to use
- Need to have reps that can deliver the message of CASE integration themselves,
not just rely on sales support
- An obstacle to software product sales is lack of training. Eagerly attended
training session on "Software Product Sales", hoping finally to get some product
information. Instead, it was how to look up license numbers!
- The little blue book on Posix that Cecil Dye's group did is a good example of
product information that is useful to the field
- Need a software equivalent to the overview brochure "The Digital Advantage".
For example, include the Forbes magazine reference to Cincom, who develop IBM
software on VAXes because it is so much more productive.
- They need access to expertise in the field, but often can't cross boundaries,
such as using PSS expertise
- Lack of knowledgeable sales support a real problem. South Central area had
three CASE people last year, who were busy all the time. But now two of them
have been moved off to projects.
- It's hard to find people that know the products to the depth that customers
need. Most of the sales support people don't have PSS background, so they don't
have hands on experience with our products, and can't convincingly present.
Need to open up SpitBrook to customers, like manufacturing has done.
_ "Every time we demoed CASE, we sold it"
- Field should fund people to come up to Spit Brook and apprentice for a period
of time
- Five years ago we could talk about clusters, and show them to people. Now its
harder. Everyone talks about "integration", but it's hard to show. How do we
get the story out? We don't have the sales tools!
- IBM is now saying "Who cares how good DEC's CASE tools are -- where are you
going to find people who know how to use them?" There wasn't a course on the
Cobol Generator for years after it was announced. And the current Rally course
is worthless.
*****Pricing/Licensing/Ease of doing business*****
- Need to have software priced on per user rather than per CPU basis, esp. for
ALL-in-One
- Customers are committed to distributed computing; our policies have to
reflect this
- Have to take better care of CMPS and OEMS -- give them additional discounting.
Need their applications to get market pull going. Get them to use our tools and
build on our architectures
- Customers feel that software is too expensive, especially on the lowend.
Figure for one case it cost $900/seat for a workstation, vs $100/seat for a
terminal running off a high-end VAX.
- Price has to be competitive to OS/2 for applications like word processing.
- Customers have 10-15K installed base of PCs - then we try to compete with PVAX
and unrealistic software pricing
- CASE pricing may be OK, but other areas have to be more competitive
- Want more user-based licensing; also corporate-wide licensing
- When queried, two out of 60 had heard of the Software Development Portfolio.
Those two were enthusiastic about it, however.
- 4 out of 40 had heard about the Software Development Portfolio in the second
session. Heard that there is trouble doing the monthly billing; customers not
billed for many months. Some heard it had been fixed; others heard there were
still problems. Once a product gets a reputation for a problem like this, reps
avoid it like the plague
- Software is being buried by all the model numbers. Have no information -- if
we're lucky, we'll see a copy of the SPD.
- Cost is the biggest obstacle in the volume space -- all our competition
provide free licenses and free support to ISVs(Oracle and Ingres specifically
mentioned).
- Digital has turned its back on the lowend technical OEM, and forced these
people to go to other vendors. We don't have a price competitive license
structure. PDP-11 license costs are up, but functionality and support are not.
We've abandoned the PDP11 business. One TOEM, been with DEC 10 years, at $4M/yr
has gone elsewhere because all he needs is an 11/23, not something fancier and
more expensive
- Cost of VMS too high for first time, low end user. Also an issue in
Commercial OEM -- moving to non-VAX from PDP cause price of VMS and VAX is not
competitive.
- Having to compete much harder in office space than before. Used to be a "no
brainer" for customers to pick All-in-one. DEC is at a 2:1 price/perf
disadvantage to office competitors. Focus for A1 has been functionality, but
price it going to start to get hit. For customers who only want to use A1 mail,
price is a big issue.
*** Product/Support Issues*****
- Need a better way to get back status on critical VMS bugs. Have to go through
CSC; not easy to find out. Customer is more willing to wait if they at least
now what is happening.
- Updates aren't released in synch. It was impossible to order, configure, and
ship a new CPU box (because of version skew and time lags in the ordering
process)
- C++ -- when will we get it?
- Need VT100 viewer for bookreader
- Lack of documentation for Pascal on PMAX is a real problem for field test
sites
- Need Ada/vectors
- User thinks the name of the box on his desktop is the name of the computer.
Since we have so few desktops, we have low visibility.
- It's important that we tie all the desktops together, and that we offer MSDOS
- We need to win the desktop because that's where the applications run, and the
applications drive the backend. Will the products announced at the President's
Panel be distributed by Digital (Lotus, Dbase, etc)? AIA and DDS are
differences we can sell.
- VMS Services for MSDOS is hard to install; need expert support people, which
we often don't have
****PIDs********
- After the DECwindows program announcement last year, we had a tough time
getting accurate information on where we were going. We've lost VMS market
share to Unix because we couldn't find this information. DECwindows was
announced under Ultrix last August, and didn't even know it til several weeks
later. If we program announce something, we need PID people who really know
their stuff and can give more information on those products
- IBM is talking futures, and there isn't enough meat in our PIDs. IBM is a
master at this -- they announce 1-2 years in advance, and then come in early.
Look like heros to their customers. We always slip. IBM lets people give input
during this 1-2 year period, and shape the direction of the product. People
really like that. We don't hear anything official from Corporate -- all we hear
are rumors and stories in the trade press - e.g. we hear now is that DECwindows
is a dog. If you don't tell us, we will just pick up someone else's rumors, and
won't have any accurate information to offset it.
- PID process stinks. Presentors can say only exactly what's in the
presentation, seemingly on pain of death. There's no information in them.
Customers get mad when they go through all the rigamarole to get ok'd for a PID,
then we give them empty PIDs, and parrot-like presentors who are forbidden to
say anything beyond the presentation. Makes the presentor and DEC look pretty
stupid. Need PIDS to be two years out, and presentors who know enough to, and
are allowed to, answer questions. OK to have the further out ones more general,
and positioned as things that might change.
****Misc:*****
- Takes a while to sell big machines into accounts -- corporate has to be
patient. Many of these shops do not currently have high end DEC machines, and
it takes a while to build a relationship
- Security consulting is a big opportunity
- Important for Digital to control the network backbone. We need to be able to
take over system management for an SNA network. This is a major major issue. We
could get more than 50% of the business if we had that capability, less than 10%
if we don't.
- We will never replace IBM network, but we have to try to control it. IBM is
trying to do the reverse to us. This is also an opportunity for ATT - they have
tools to manage both DECnet and SNA. Good foot in the door for them.
------------------------------------------------------------------------
I also attended an interactive session on sales support. Here are some of the
comments I recorded there.
What are some key successes that sales support has had; what works well?
- Having the MIS consultants work with key executives, help them develop
business procedures, really understand the overall business - Set up a Critical
Success Factors workshop; understand what stands between customer and success of
installation *after* the equipment has been delivered. - Have sales support
dedicated to a specific account; get to know the company on a partnership basis;
customer shares business issues, not just technical issues (but headcount slash
has diminished our ability to do this) - "Tapestry" program, out of MAA --
series of technical seminars, developed locally, now being spun out to other
areas. Allows sales support to hit many customers at once with new technology,
instead of one customer at a time.
Obstacles:
- Hard to get access to resources for long-term sales opportunities; if
the certs aren't for this year/this quarter, can't get the resources, no
matter how big the eventual opportunity
- Sales doesn't have ownership of the resources
- Hard to get resource that is in another district -- have a 20% chance
of getting a needed resource if it's in your district, 2% if outside
- The extent of these problems vary greatly by area.
- Sales support people are viewed as less important than PSS people, because
PSS are bringing in $$. Most excellence awards go to PSS rather than
sales support
- No clear career path from sales support; no place to go after they
reach senior sales support; losing many senior people because of this
- Lack of OLTP support a problem in some areas
- Proposal generation is a problem. Everything has to stop to get it out.
RFI is even harder, because the payback is more tenuous
- Need to have demos available for CASE and databases
- Lots of complaints about P3 (taking sales support for short term revenue
generating projects, such as teaching a course).
- Customers last year were told we are building up sales support; now we
are cutting back with P3. Doesn't look good.
- Hard to get access to benchmark centers (again, varied by area)
- Need to get sales more familiar with basics of products, so they don't
have to rely on sales support so much. Success Train has gone away, so
they don't have a chance to learn about products anymore
[Figures on sales support counts removed at author's request]
|
| 677.12 | It's ALL-IN-1 (TM) | GLORY::HULL | Hallalujah!! The Resurrection (Plan A) has come! | Tue Jan 03 1989 19:51 | 14 |
| Please note that the spelling of in the previous note of our premier office
automation software is ALL-IN-1, and is a Digital trademark. No other variation
in spelling is correct, and ALL-in-One (+its variations) is a brand of
pantyhose. All the Digital-market trade mags screw up our product name,
and most employees are also unaware of the proper spelling.
Please make an effort to use the name in its proper spelling (all caps,
hyphenated, digit 1).
If we don't pay attention to our trademarks, no-one else will either!
Regards,
Al, SWS OA delivery specialist
|
| 677.13 | Keep those trademarks, they pay your salary! | KYOA::KOCH | Any relation?... | Wed Jan 04 1989 09:10 | 7 |
| >If we don't pay attention to our trademarks, no-one else will either!
Al,
I agree with you. It would be nice if our editors automatically
checked for trademark words and such before letting you complete a document.
A built in automatic trademark checker?
|
| 677.14 | Get the message out Kathy... | TELGAR::WAKEMANLA | Another Eye Crossing Question! | Thu Jan 12 1989 12:58 | 66 |
| Yo Tom,
I must agree with Kathy on a few points. Right now I am delivering a
six month residency (which is why my noting is more infrequent then
before) due to manpower reductions in Sales Support.
>- Software is driving the sales, and we have good software products. CASE and
>All-in-One are especially well-respected, but there are few in the field who
>know enough to demo or support CASE.
I agree. This is also a problem with Rdb, Rally, Teamdata and many
others. Some of Kathy's other points point to the reasons.
>- Lack of adequate sales support is biggest problem. Too few people, they don't
>know the products well enough, and now even the few sales support people we have
>are being assigned part time to revenue-generating projects
Coming from Sales Support, I have to agree, but Sales Support is in a
RIF (reduction in force) which is a major reason why I am sitting at a
customer site entering this reply. Also the fact I needed a vacation
from Sales Support because it is too hectic due to the limited
staffing. We need more support people (and maybe less Sales People)
and the support people should be very specialized ( I was specializing
in any product that runs on Digital 16 bit and 32 bit processors). The
support people should also get lots of training in their specialty, to
help them stay current as well as help them to recommend courses to
customers. Play time is also a must. Can't learn a product if one
does not have access to it and get the chance to use it.
>- We have way too many products to understand and they are way too complex to
>administer and license.
We do have a lot of products, and administration of these products is
lacking, but which products would you eliminate? With enough
knowledgable support people, this would not be a problem.
>- Sales want to know more about our products. We used to train on products, but
>haven't been lately. They miss Success Train. They used to be able to give
>overview technical presentations, but haven't been given the training to do
>that.
They also need update courses on new products like they get when they
first join Digital. I know a couple of Sales Reps who don't know how
to position current VAXes because they have not been updated on them.
They do not read the Sales Updates, they don't have the time as the
Sales Updates tend to be too wordy.
>- PID process is awful -- PIDs don't contain any meat, presentors aren't allowed
>to elaborate at all, and presentors don't always have needed background to be
>accepted as an authority on their subject
Yes, the PID process is awful. Dated material, lack of content,
difficulty getting approval, PIDs prepared too late, difficulty
scheduling presenters. The 30 day PID window is just long enough so
that by the time the PID is approved and presentations can be
scheduled, the product is announced. Family PIDs need to be updated
more frequently then they are, like aim for a PID update every three
months. It can be really embarassing to give a PID that is a year old
like I had to do once.
>- Need to have a customer visit center at Spit Brook, like manufacturing has set
>up for CIM
I can see it now. The customer's next visit will be a month long, with
them going to Marlboro, Littleton, Shrewsbury, Spit Brook....
|
| 677.15 | INSERT EDITORIAL ASIDE HERE: | WOBBLE::CROWLEY | Speak for yourself | Fri Jan 13 1989 16:59 | 16 |
| In .11 I read a strong message to engineering:
> Design products that are easy to use
> Design products that are easy to learn
> Design products that don't require service
A feature-rich product results in loss of sales, unless the
features are accessible. All elegance requires simplicity.
The closer to our customers' concepts are products are, the
more value the customer sees in them. The closer to our
customers' concepts are products are, the more value the customer
will get out of them.
A product that always works is better than a product that has
outstanding remedial support. And it pulls a better profit, too.
|
| 677.16 | The customers say the same thing | AUSTIN::UNLAND | Sic Biscuitus Disintegratum | Fri Jan 13 1989 19:52 | 33 |
|
re: .14
>- Lack of adequate sales support is biggest problem. Too few people, they don't
>know the products well enough, and now even the few sales support people we have
>are being assigned part time to revenue-generating projects
This also came up in the recent Gartner Group conference on DEC,
for which Ken was the speaker. Many of our largest customers
evidently mentioned that we will never be able to seriously
compete with IBM until we provide an equivalent level of support.
Maybe Ken will listen to this message even if some of his managers
seem to be ignoring it ...
>- We have way too many products to understand and they are way too complex to
>administer and license.
We do have a lot of products, and administration of these products is
lacking, but which products would you eliminate? With enough
knowledgable support people, this would not be a problem.
I don't think the issue is so much that we have too many products,
it's the Rube Goldberg licensing system that is the issue. There
are anywhere from 1-100 different order variants for each product,
and the rules for which one to use are not only obscure, but many
actually change day-to-day. As part of an RFI team, I watched us
spend 11 man-hours of sales exec/consultant time trying to figure
out the correct order numbers for a $900 software product.
Some sales reps have made it a practice not to recommend useful
software, because it takes too much of their time to quote and
deliver properly. It has to fixed, and soon.
Geoff
|
| 677.17 | Needed: A Fresh Look at what is Sales Support | SDSVAX::SWEENEY | Patrick Sweeney | Mon Jan 16 1989 09:38 | 13 |
| More Sales Support? We need to take a step back and see what "sales
support" does. Part of the rethinking here is that "sales" has lost
its way and needs to do more of its own "sales support".
As Joe DiNucci says "It's become fashionable once again to know what
you're talking about."
Dealing with the internal complexitity of selling has gotten in the way
of sales people actually filling the role of consultant to the
customer. Unfortunately, it's beat up on the sales rep time and no one
appreciates the profit impact of the part number chaos/time sink
mentioned in .-1. Where's those distributed data bases when you need
them?
|
| 677.18 | Real Users | BMT::BOWERS | Count Zero Interrupt | Mon Jan 16 1989 11:35 | 22 |
| Regarding product design and features, we need to realize that most of
our customers probably use no more that 10% of the available functions
of many products. A classic example of this is the study of editor
usage done by our own human factors people (available through VTX,
keyword HUMAN). It was found that keyboard activities could be divided
into 4 categories, each about 1/2 the importance of its predecessor:
Typing
Deleting (the RUB key)
Moving the cursor (arrow keys)
Everything else
That means that *all* the wonderful bells and whistles we build into
our various editors are being used no more than 10% of the time!
The message here is that we could probably do quite well with
reduced-function products that were designed so as to make the critical
functions (from the users' standpoint) easy and intuitive. There
is also a fairly strong implication that we need to spend less time
in phase 0 on internal blue-skying and more time on doing the necessary
research to determine what real users want and need.
-dave
|
| 677.19 | Bad Yardstick | SEAPEN::PHIPPS | DTN 225-4959 | Mon Jan 16 1989 12:18 | 13 |
| I don't consider myself an average user however I believe the
criteria for measuring an editor as outlined in the previous
note are specious.
If you didn't have the "bells and whistles" you would find
the list looking something like this:
Typing [That figures!!]
Deleting (the RUB key)
Moving the cursor (arrow keys) [Indicates lack of knowledge
of the editor.]
Complaining about what you couldn't do [Perhaps more!]
|
| 677.20 | Shortcuts are NOT the answer | CADSYS::BAY | Don't worry, be nasty | Mon Jan 16 1989 12:31 | 40 |
| What you say may be true, and what I have to say is just my guess,
but...
The bells and whistles of which you speak aren't used by the majority
(numerically) because our user base is becoming less and less technical
as we penetrate more non-engineering accounts.
I believe our ability to penetrate new account areas is based on the
reputation of our product, its overall quality and attention to detail.
I don't think we would ever have been able to get to where we are, if
we didn't do it right in the first place.
Compromising on features, flexibility, expandability is being
penny-wise and dollar foolish. It is a true WYSIWYG mentality that
leaves no room for growth of technical expertise and user maturity.
Your statistics leave a lot to be desired as far as demography, and
over-emphasize numbers - the needs of the many outweigh the needs of
the few.
Regarding the issue of editors - in every account I have seen that
converted from XYZ vendor to DEC, complaints have been continuous and
numerous on the lack of flexibility and the ability to do it "the old
way". The cause of this, and also for people not using all available
features, is a lack of or improper education. When new software is
introduced, the philosophy of its use must be introduced, as well.
When new users learn "think" the way the software works, then they
begin to take advantage of it.
Perhaps my analogy limps, but I see this argument similar to the idea
that, since the majority of car owners don't like to drive in bad
weather, then don't bother to put windshield wipers on cars.
We put the bells and whistles there because of concern for the people
that can appreciate them, and for the users that may someday NEED them.
Customzing our product to the generic user is an attempt to achieve
mediocrity which will hurt us more in the long run.
Jim
|
| 677.21 | | DARTS::DIAZ | Los Angeles Locos de Tenacatita | Mon Jan 16 1989 12:46 | 12 |
| Re: Full feature product to no-frills product
I think the issue here is the lack of user's choice.
I, as a potential buyer, wouldn't like to pay for many bells and
whistles that I don't have any need for and probably will never use,
BUT.... I don't want a restricted bare bones products, SO.... I
definitely prefer to buy a product with the functions that I need and
some few more, and then give me the option in the future to add those
bells and whistles if I ever need them.
-OLD
|
| 677.22 | A complete waste of money? | DELNI::JONG | Steve Jong/NaC Pubs | Mon Jan 16 1989 13:25 | 15 |
| Here's a rathole if ever I saw one, but...
The last few replies have been classics! I've read the editor survey
cited previously, and the user community was checked on a keystroke
basis. One can attack the population sample as not representative;
I thought it was OK, and the experimenters know more about statistical
validity than most of us. Therefore, I accept the results.
Given that, I see that vendors (not Digital in particular) develop
many features that are hardly ever used, or *not used at all*, by
their customers.
I'm curious: how much money should we spend on development, test,
and support of features that customers do not use? I think whatever
resources we invest are a dead loss.
|
| 677.23 | One Man Shows don't cut it in the Real World! | AUSTIN::UNLAND | Sic Biscuitus Disintegratum | Mon Jan 16 1989 14:18 | 28 |
| RE: < Note 677.17 by SDSVAX::SWEENEY "Patrick Sweeney" >
> More Sales Support? We need to take a step back and see what "sales
> support" does. Part of the rethinking here is that "sales" has lost
> its way and needs to do more of its own "sales support".
Sales has indeed lost its way! When our complete product line turns
over about every 18 months, and the average sales rep gets maybe one
chance every two years to attend product training, you can bet that
they will fall behind; and they have. I see numerous sales reps
who spend a lot of time getting one set of configuration rules down
pat, only to fall prey to product obsolescence. Eventually, they
give up, and end up dealing mainly with installed-base customers
who are capable of doing their own configurations.
It's not a DEC problem; every vendor who has a rich product set
and high-technology products suffers from the same problem. But
it is our problem that we expect the sales rep to handle it alone.
I am a resident at a site where, even though DEC is the dominant
vendor in the mini/mainframe space over IBM, IBM has two full
time SEs and one part-time SE assigned here, above and beyond the
two full time sales reps. DEC has one local sales rep, and one
Area-level account manager. Period. No allocated sales support.
Anyone who thinks they can control an account this way, even if
we had *much* superior products, is sorely mistaken.
Geoff
|
| 677.24 | my 2 cents | LACV01::NEEDLEMAN | flagillate a deceased equine | Tue Jan 17 1989 13:32 | 108 |
| a little more on .14
After Decworld in Boston I read many of the debriefings. One
consistent customer complaint was (to paraphrase) "They aren't
techncal enough, my salesman does not know what he is selling
me, They do not speak our language or understand our needs".
This is similar to the statements about sales support now.
Well, I am an educator by background. When I read or hear
phrases like "doesn't know" or "don't understand" I start to
wonder about the training or education of the individual. We
hire bright good, experienced people (If this is wrong then
let's look at the hiring profile). If they do not understand
our products, if they do not know how to support them, if they
cannot understand positioning statements then we should look at
the time, resources, methods (and cost) spent on educating
these people and look at the measurement of that process.
If an individual is given a book but no system access for a
software product, it is like trying to learn to drive by
reading your rules of the road manual. Great in theory, a
disaster in practice. Competency requires time to develop. That
includes learning, practice and growth.
Maybe we need to redefine the skill set and knowledge required
to be a successful sales support or sales person.
As for the P.I.D. process, I was too close to the source to be
objective on this. Suffice it to say that twice I had agreement
from operations that the process should be changed to reflect
software issues and twice it came back without changes.
Maybe the third time it will work. I hope so.
I want to go back to Kathys excellent report for a minute.
> We should insist that we have sales support training and CSC
> training before we ship a product. Cobol Generator and VMS
> Services for MS-DOS are terrific -- way ahead of their time --
> but they are complex, and we don't have any sales support for
> them
>
> - Lack of sales support for our software products results in
> the field relying on ISVs that have competing, but
> well-supported, products. Example is Oracle vs. Rally
When I worked in base product marketing, I had one excellent
exercise in futility. It went like this.
I asked a generic salesrep - Why won't you sell VAX RALLY,
why are you bringing in COGNOS ?
answer: No support people in my office are trained to
demonstrate and build a prototype application.
I asked support: Why aren't you trained in VAX RALLY ?
answer: There are no classes available from ed. services
I asked ed. services: Why isn't there a class ?
answer: Customer training said that there have not been enough
sales to fill classrooms. We are a profit center. We will not
develop the class until there are sufficient sales. Internal
(sws) training said it wasn't funded for that year because
sufficient sales wer not predicted.
Well, I make my point. It is a vicious circle. You can't sell
what you can't support. You can't support what you don't know.
You can't know it till you get training. You can't get a
training class till you sell it.
Courses (and trained instructors) should be a part of the phase
process. A product should not go out the door without one.
> - The field doesn't use enough of the tools themselves, that
> they sell. If they use them, they will be much more
> comfortable selling them. Field applications should be built
> using the arcitectures and technologies we are selling our
> customers.
My own systems people have standards from their managers that
the feel prohibit them from using certain Digital products. Our
own internal groups use 3rd party software to gain a
competitive edge since in their opinion, our own productswill
not do.
I do not wish to enter this fray. My own opinion is that we do
not gain revenues as a corporation from internal sales so let
them pick the best solution too. We should always offer for
sale the Digital solution FIRST as the product(s) of choice. We
should feel comfortable in saying that if this choice will not
be succesful then we have the widest spectrum of additional 3rd
parties to offer as alternatives.
On the other hand, I do resent underwriting advertisements, ACT
training, benchmarking activites for 3rd party and CMP products
that is not first done for DEC products though.
Barry
|
| 677.25 | Can I borrow a pencil and paper? | CADSYS::BAY | Don't worry, be nasty | Tue Jan 17 1989 13:38 | 51 |
| re .22
This is just the old alpha/beta factor argument for user (not customer)
satisfaction.
High Alpha factor (or perhaps beta - I get them confused) means you
design the product so complete that no one will ever need any
additional features, but very few will actually use them *all*. You
have high user satisfaction, because no user wants for more. The
customer, on the other hand, pays more.
High Beta means you incorporate only the bare minimum functionality
required by all your users, with the expectation that you will have
dissatisfied users that don't get what they need to do their job, but
EVERYONE will have the bare essentials. Users, statistically, will be
more unhappy, but customers will pay less.
[Disclaimer - if not obvious, I am NOT a statistician]
FLAME ON!
I guess it depends who you are trying to please. And the indications
we've seen lately, that Wall Street (figures) mean more than anything
else, probably are signalling a trend toward your way of thinking.
Its unfortunate, because the "less than x%" features just played a
VITAL role in my ability to enter this message with a minimum of typos,
run-on sentences, etc., etc.
*I* am a user. I use these "little-used" features - EVERYDAY! In
fact, I count on them to do my job. In a presales role, I used these
"features" to sell products, because *my* experience (unsubstantiated
by *surveys*) tell me that customers (buyers) LIKE bells and whistles.
Features show the customer that our product is mature and
well-supported.
I hope that, if we start selling sub-functional products to customers,
we keep the good products in house for our developers. And by the way,
I guess no one cares about "use what you sell, and sell what you use"
anymore.
Personally, with this type of thinking, who even needs editors! Just
use the CREATE command and the left and right arrows. Think how much
time you could save on training! Oh heck, lets go all the way and come
out with a line of memory typewriters! Stone clubs and a blank cave
wall, anyone?
FLME OFF! (Damn, my correction key quit working!)
Jim
|
| 677.26 | | BMT::BOWERS | Count Zero Interrupt | Tue Jan 17 1989 17:38 | 31 |
| Gee Whiz, guys!
I didn't expect quite so many flames. In fact, I'm a little put
off by the level of personal attack in the replies. For the record
I'm a SWS/PSS Consultant who's been in the business for 20 years
or so -- I too use most of the available bells & whistles. This,
however, doesn't blind me to some fairly obvious facts.
- Our customers are increasingly non-technical.
- Products with too much visible complexity are intimidating.
- Intimidating products DON'T SELL!
- Products that are intuitive in use (and ergo easy to demonstrate)
are much easier to propose and sell.
I am NOT advocating "sub-functional", brain-dead products. I AM
suggesting that designing products for DEC software engineers may not
be the best way to produce products that will be well-received by
customers.
If you haven't read the human factors studies, you should. Don't be
enslaved by them, but at least consider that there is another way of
looking at the problem!
There is a real world of users and customers (read: non-technical
executives) out there and the field people have to deal with them
and sell to them. Features may sell products. So do ease of use,
intuitiveness, reliability and supportability.
-dave
|
| 677.27 | So now our software isn't reliable? | CADSYS::BAY | Don't worry, be nasty | Tue Jan 17 1989 18:31 | 39 |
| re: .26
>Features may sell products. So do ease of use, intuitiveness,
>reliability and supportability.
Which is my point. You have directed your comments at the issue of
"features", but it is not clear to me that customers don't use the
features because they are not reliable, supportable, etc. And I think
you'd have a hard time making a case for such a proposition, anyway.
It borders on a personal attack, but I don't intend it as such. But,
as the other notes in this topic seem to imply, perhaps its not a
matter of software quality, but an inability to sell the quality and
features effectively.
I've seen too many users that didn't even KNOW about the features, and
too many customers that didn't have any idea what they bought. Perhaps
there was great salesmanship going on, but it disturbs me when
customers don't have any idea what they are getting. *I* know they are
getting the best software, but what a poor testimony it is when the
customer has the world at his fingertips, and doesn't realize it.
We're talking not only sales opportunities for training, SPIs, CBIs,
DECstarts, etc., but long-term, more satisfied customers that feel like
they got their monies worth.
I agree with what some are saying, that the money should be put in
training sales and sales support so they can do a more effective job.
But reducing functionality so that sales people don't have as much to
sell? I think thats a bit backwards! But, at least then they wouldn't
need training. Quite a cost-saving idea!
And once more for emphasis, I think our software is intuitive,
reliable, supportable, ergonomic, high quality, and more. The problem
is not the product. Look for cost-cutting measures elsewhere.
Jim
|
| 677.28 | | EAGLE1::EGGERS | Tom, VAX & MIPS architecture | Tue Jan 17 1989 19:18 | 10 |
| It sounds to me like .26 is being reasonable and thoughtful. It also
sounds to me like .27 is missing .26's point and interpreting .26 in a
way that .26 didn't intend. That's just the way the previous two notes
sound to me. I suppose if I talked to the authors face to face I might
come to another conclusion.
But then who am I to make such comments. I've only been adding
"functionality" to DEC hardware and software for 25 years or so. I
wonder how many of the "features" I've added have done more harm than
good.
|
| 677.29 | Don't Jump! | BOSACT::EARLY | Slidin' down the razor blade of life. | Tue Jan 17 1989 22:16 | 50 |
| re: .26 (and probably some other notes)
Regarding your comments about being put off because you produced
so many "FLAMES" ...
Don't take it personally. I had a consultant (Presales) who once
visited one of our largest accounts (Corporate Account - significant
oepration) and ran into a rather irrate end user. The end user
was significant in that he had significant influence (a manager)
over future buying decisions.
Why was he ripped?
He said, "I can't STAND IT!! I have so many groups that I need to
communicate with and so many projects to review that I have accounts on
5 systems."
DEC: "Yes ... ... so?"
CUST: "SO? So I have 5 accounts that I have to log into every day
just to check all my mail messages!! What a PAIN!"
DEC: "So you're aggravated by the fact that logging into 5 systems
wastes time and you'd rather just log into one system and
get all your mail?"
CUST: "You've got it."
DEC: "No problem ... we can fix that. All we have to do is have
you log into each account, and we'll automatically forward
all your mail to one single account and you'll only have
to check one account from now on."
CUST: Blank Stare for a LONG time ...
CUST: "Are you kidding me?"
DEC: "No sir, it's a basic feature of the VAXmail system that
you're using here .... "
Point being ... I wonder what that customer's keystroke file would
have looked like and what conclusions we would have drawn (right
or wrong) from that ????
Knowledge of the system affects how it is used.
/se
|
| 677.30 | What happened to multi-layered software? | NEWVAX::PAVLICEK | Zot, the Ethical Hacker | Wed Jan 18 1989 11:54 | 74 |
| Once upon a time in a company far, far away...
I used to design some fairly heavy-duty software for a small company.
We had to tackle the ease of use vs. power problem all the time
-- and if we didn't tackle it properly, we knew that the company
would be in big trouble!
We arrived at a multi-level scheme of design which seemed to bridge
the gap very well.
For instance, an ad-hoc report could be generated in a number of
ways:
1. A Quick Report generator -- a simple module which asked a
few *EXCEEDINGLY* simple questions of the user. A user which
could follow directions (and press the HELP key when confused)
could master this technique in minutes (not an overstatement!).
Report formats were limited to basic columnar reports, but
the output was both professional-looking and adequate for
the vast majority of ad-hoc reports.
2. A Full Report generator -- a more complex module which asked
more detailed questions. A user needed to practice this
to get the full benefit from it, but report formats were
much more flexible.
3. A Reporting sublanguage -- a much more complex module which
relied entirely on user syntax, but report formats were
virtually unlimited.
From a sales perspective, you sold the customer showing the ease
of the Quick Report mechanism and stating "and if you should ever
need more complex report formats, you can learn to use the Full
Report Generator. All of our support people are well versed in
this and are available to help you, should you need it. It is
fully documented in our manuals." Most sales people didn't even
know of the existance of the sublanguage -- and didn't need to!
From a SW design standpoint, there was very little duplication of
effort, as the Quick Report generator called the Full report generator,
which in turn called the Report sublanguage to actually execute reports.
From a customer standpoint, there was essentially no learning curve to
begin report generation. The Quick Report handled 80%-90% (if not
more) of all queries (excluding any standard reports which might
be predefined for a specific software application). Many of our
customers never felt the need to learn to use the Full Report
Generator. Those that did learn, did so *AFTER* they were already
productive with their systems, and as such, were much more confident
and at-ease with the larger learning curve. I can't recall *ANY*
customer being trained in the actual report sublanguage, but we used
it occasionally in-house for bizarrely complex reports.
The bottom line is this: it is possible to create software which
is both feature-rich and easy to use. By shielding the customer
from the "frightening" complexity of the lower levels of the system,
it is possible to create a system which will not compromise on
features, yet remain easy to use for most users. Only after the
user sets his or her sights on a more complex task does the user
need to "get dirty" and learn a more complex approach.
I am just completing an application for a customer. Near the end
of the development, I whipped together a small DCL shell which asks
a few basic questions and generates a Datatreive report for fast
ad-hoc queries. The customer LOVED it! This little buzzard wasn't
even in the specs, but it has become one of the most POPULAR parts
of the system!!! I've made it as robust as I can (since they've
begun using it so much), but it's still basically a gutless module.
I wish Digital would supply that "zero startup" or "cream layer"
to products which would allow the user to become functional almost
immediately without knowledge of syntax, etc.
-- Russ (slipping back into Zot-mode)
|
| 677.31 | | BOLT::MINOW | Why doesn't someone make a simple Risk chip? | Wed Jan 18 1989 13:03 | 37 |
| We have completely left the topic "the UM meeting" for the far more
interesting pastures of "what should Dec be building anyway."
I like to think I've built usable widgets. I wish they were as usable
as the rinky-dink Macintosh on the card table at home. The problem is
that we never designed for usability from the ground up. There were
always other goals that were more pressing:
-- gotta fit in 16K.
-- gotta ship in September.
-- gotta be compatible with RSX-11M.
-- gotta be compatible with ISO-646.
-- gotta use the standard box (anyone remember Ken's word-processor?)
One essential difference between the Macintosh way of doing things
and ours: in DCL, *anything* I type is valid to the thing that reads
text from the terminal. On a well-written Macintosh application,
the user can only select legitimate applications.
We have made a number of applications (such as Datatrieve) that emphasized
usability. However, that has never been our focus as a corporation.
Perhaps this will turn out to be a long-term mistake.
Certainly, refusing to listen to our customers (both inside and outside)
is a mistake; and seeing our failing to make usable products as a failure
of the customer to understand the intricate beauty of the tools we produce
is a short-term mistake.
Your homework assignment is to read the following books:
-- Charles Perrow: "Normal Accidents." Basic Books.
-- Don Norman: "The Psychology of Everyday Objects." (I think that's the
title, it's quite new and should be in the Maynard library catalog.)
-- Victor Papenek (?) "How Things Don't Work."
Martin.
|
| 677.32 | Hot, but justified, I think | WV::BAY | Don't worry, be nasty | Wed Jan 18 1989 13:47 | 68 |
| re: .28
The easiest sin one can give in to in Notesfiles is to allow a complete
stranger's entry spark vivid memories, and react in a response to the
memories, rather than the person's actual entry. I gave in, an to the
author of .26, I apologize.
.30 brought me back to reality. I was in the field for 5 years facing
similar situations over and over.
- Going into an account and NEVER being given the lowdown in advance,
and being surprised when they don't know whats goin on
- Struggling with the customer through things that neither of us were
ever taught about. Putting up with hotshots coming in and saying "Gee,
you don't know how to do THAT?"
- Trying to do 30 things at once for the customer because it hurts so
much to watch "him" struggle, when you have been through the pain
already and can easily save him the pain
- Learning the hard way that you'll never get your OWN project finished
if you keep helping the customer in areas that aren't your
responsibility, so you just bite your lip and let "him" struggle
These are some of the bitter memories that went through my mind when I
read .26 and the previous notes. I have SEEN, many times, that
education, and NOT software complexity are the problem. In fact, the
elegance of the software is what gets us through the binds that the
lack of education (for customers and employees) put us in in the first
place.
And, someone else mentioned that they have confidence in the survey.
Candidly, and without any counter statistics of my own other than my
own experience, I don't have confidence in the survey, don't believe it
represents a fair cross section of users, and that it is intentionally
biased by unrealated factors.
Its typical of what happens when people take action based on misleading
statistics. It scares me. I resent it. And its very hard for me to
stand still when I see it happening.
The original note may represent years of experience, and thoughtful
meditation. But it runs counter to my own experience, which is typical
of real life (different people see different things). It was mentioned
in a discussion that was largely about a lack of training in the field
for sales and sales support people, so I *ASSUMED* it was in the vein
of a solution to that problem.
I contend that the recommended solution is not even related to the
problem under discussion, and before proposing something that seems
outlandish in terms of my own experience, that the proposer should have
a *LOT* of unqualified evidence to back it up - not a survey of
secretaries using word processers.
And two last nits:
1) the secretaries I know would have skewed the output of that survey
all to heck because of how effectively they use their tools
2) that survey doesn't even touch on how absolutely critical those 10
or 1 percent functions are. Take for instance, the GOLD/FILE key or
the EXIT command.
No offense to anyone intended - honest.
Jim
|
| 677.33 | | STAR::ROBERT | | Thu Jan 19 1989 09:32 | 11 |
| re: .30
I agree strongly with your design philosophy. It _is_ possible to
build software that is both complex and simple, and the right way
to do it is with the layering you suggest.
It can be done with report generators, editors, command languages,
system management, and all sorts of things, as long as you plan
for it from the outset.
- greg
|
| 677.34 | On features vs. quality | DELNI::JONG | Steve Jong/NaC Pubs | Thu Jan 19 1989 15:35 | 94 |
| I also find this a more interesting subject!
There has been a strong negative reaction here to suggestions that
not all functions are equally important, that in the case of
editors the simplest functions are used an overwhelming portion of
the time. I'll cite a few examples, not because they're unusual
in their tone, but because they are usual. There has been
hysterical reference to "sub-functional" and "bare-bones"
products. I characterize the response as "hysterical" because
there is evidence that people are responding to perceived
statements, not actual statements, viz (.20).:
>> Your statistics leave a lot to be desired as far as demography,
>> and over-emphasize numbers - the needs of the many outweigh the
>> needs of the few.
No demographics were given. I think you should read the HF
studies before dismissing them.
>> Personally, with this type of thinking, who even needs editors!
>> Just use the CREATE command and the left and right arrows. Think
>> how much time you could save on training! Oh heck, lets go all
>> the way and come out with a line of memory typewriters! Stone
>> clubs and a blank cave wall, anyone? [.25]
Someone suggests that not all features are needed, and this is the
response? (The response was meant as a joke...)
There's also been blaming the user:
>> Moving the cursor [using] arrow keys indicates lack of knowledge
>> of the editor [my paraphrase of .19]
>> When new users learn "think" the way the software works, then they
>> begin to take advantage of it... We put the bells and whistles
>> there because of concern for the people that can appreciate them,
>> and for the users that may someday NEED them. [.20]
Do you think that a user who does things the simple way is
ignorant of the alternatives? Do you think that if our users have
difficulty using the advanced features of our software that it is
their fault?
The terminal server I use lists about 150 systems. It's
interesting to see that in this engineering facility, about ten
percent of the system managers (who are often the "users" of the
machines) have made mistakes in their system banner messages, so
that instead of a cute saying, they are in effect advertising that
they cannot get the feature to work. Are one in ten of our system
managers to blame? or is the software?
I had an experience at another job that proved to me that some
software features simply are not used. I was asking if we could
eliminate some of the arcane argument descriptions from a manual
akin to the DCL Dictionary. "Sure," the project manager said. "I
can tell you exactly what to take out."
"How do you know?" I asked.
"Because these features don't work, and we've never gotten a bug
report on them! Obviously no one's using them."
Someone has introduced quality into the discussion, suggesting
that a product that is less than full-featured is lacking in
quality. Well, I subscribe to the Crosby Quality process. Crosby
defines quality as "conformance to requirements." If the product
requirements are A B C, then a product that does B C D E F G...
but not A isn't a high-quality product, any more than a product
that only does A B is. This definition of quality is useful
because it lets use see that having more features doesn't make
more quality. A Cadillac has more features than a Hyundai; does
that mean a Cadillac is a higher-quality car? Not necessarily.
It is possible to build a quality Hyundai (one that conforms to
the specifications of Hyundai Motors) and a poor Cadillac (one
whose doors are misaligned or whose engine doesn't run to spec, say).
The point of the editor study was more that common features
account for an overwhelming majority of the usage of all users,
and that therefore common features must perform well. An advanced
feature is used less simply because it is needed less.
Several respondents disagree with the assertion that adding more
features makes a product less easy to learn and use. I believe
that implicitly, but no matter. Let's try another one: All
projects have a finite budget, resources, and schedule. You have
to wonder about a product with bells and whistles galore. Where
was the compromise? I claim that in a project where the goals are
A B C, but the product as delivered does A B C D E F G, less
time and effort was spent on the actual requirements. It only
stands to reason! It may be that the project team exceeded their
goals, but on the projects I'm familiar with, it's more likely
the team delivered A and B and a plan to add C in an update. I
repeat my point of an earlier reply: how much investment is
reasonable on one or more features that you figure won't be used?
|
| 677.35 | Sic Plurus Combustibles | DPDMAI::DAVISGB | Gil Davis - N55591 | Mon Jan 23 1989 12:05 | 19 |
| re: building 'bells & whistles' into our products....
It appears that we've been reasonably successful at building fairly
good products, which customers continue to buy. We continue to
plod along with products that get the job done and, yes friends,
have 80% of their functionality collecting dust and mold.
On the other hand, ever try answering an Rfp with a product that
includes some kind of text editing capability, and be asked only
that it be capable of typing, deleting and filing text? Hence the
need for lots of functionality...
Barry, you're right on the nose with the vicious circle of
need-support, no support, no training, no P.O., no justification
for support, need support....We'll discuss this over a few beers
sometime and decide who we should memo to death regarding the subject.
Now....anyone know more about what went on at the sales meeting?
|