One of the great entrepreneurs of the 20th Century died in 2011 – Ken Olsen who founded Digital Equipment Corporation (DEC).  For 23 years, Gordon Bell served as the Executive Vice President for Research and Development (both hardware and software) working closely with Ken Olsen to generate innovative hardware and software systems.  I had the privilege of learning from both men during the years at DEC when I was building ALL-IN-1.  One of the joys of being on email in the early 1980s was getting messages like the following from Gordon Bell.  It is a tribute to Gordon that most of these recommendations are as fresh today as they were thirty years ago.

INTEROFFICE MAIL TO KEN OLSEN FROM GORDON BELL
Dated Sunday 15 March 1981

Gordon Bell

Product goodness is somewhat like pornography, it can’t fully be described, but we’re told people know it when they see it. There are lots of heuristics in the book Computer Engineering. Since quality and competitive products must be our number one focus in these next generations, these heuristics are intended to help us. Only the four following need be attended to:

• A responsible, productive and creative engineering group
• Understanding the design constraints
• Knowing when to create new direction, when to evolve, and when to break with the past
• Ability to get the product built and sold

ENGINEERING GROUP
As a company whose management includes mostly engineers, we encourage engineering groups to form and design products. With this right of organizing, there are some responsibilities.

• Understanding leadership who understands the product space and who has engineered successful products.
• Having skills and disciplines required in the respective product area, eg: ergonometrics, acoustics, radiation, microprogramming, data bases, security, reliability.
• Having skills on board to make the proposal so that we adhere to the cardinal rule of Digital, “He Who Proposes, Does”. Approving a plan, based on no implementers violates this.
• Having openness, external reviews, clearly written descriptions of the product for inspection.
• As a corollary of being prepared with leadership and skills, we occasionally enter very new areas, requiring research and advanced development; product commitment should not be made until fully operational breadboards exist.
• As a corollary, start up groups with no previous or poor previous track record, may need review.

PRODUCT METRICS
Since most of our products are evolutionary, engineering is responsible for knowing their product area, in terms of:

• Major competitor cost, performance and functions together with what they will introduce over the next 5 years.
• Leading edge, innovative small company product introductions.

DESIGN CONSTRAINTS
Design constraints such as acoustics and radiation, are basically useful because they limit choice of often trivial design decisions. We should meet the following design constraints, and if unacceptable, go about an orderly change:

• DEC Engineering practice for producability. These assimilate the critical external standards such as VDE, and FCC as rapidly as possible.
• Information processing and communications standards, such as COBOL, Codasyl, IEEE 488 and EIA.
• Information processing standards as determined by the key supplier, such as IBM SNA. For example, all eight versions of VISICALC we are implementing, should be compatible with external VISICALCs.
• The architecture of existing DEC products. For example, future editors should be compatible with the past editors, unless it can be shown experimentally that there is a significant (x2) benefit to change. These include:
  • ISPs of the PDP-8s, several PDP 11 ‘s, VAX-11, 8048, 8080 and are likely to include a 16-bit micro.
  • Physical busses for interconnect. Fundamentally this insures that future products can evolve.
  • File, command language, human interface, calling sequence, screen/form management, keyboard, etc.
  • We must not be undone by historically poor standards which constrain us to poor products. Currently, the 19″ rack and the metal boxes we put in it, and then ship on pallets to our customers, act as constraints on building cost-effective PDP-11 Systems. The “mind-set” standard is impeding our ability to produce products that meet the 20% cost decline. A target should be the shipment of systems in cardboard boxes which the customer assembles.
• Ability to be implemented easily in the natural language, given that we are selling products in all countries.

WHEN TO CREATE A NEW PRODUCT DIRECTION OR WHEN TO EVOLVE THE OLD

Given all the constraints, can we ever create a new product, or is everything just an evolutionary extension of the past? Also do we know or care where product ideas come from? There are a whole set of places to look for products, but that’s another set of heuristics, and the object of these heuristics is simplicity. The important aspect about product ideas is:

• Ideas must exist to have products!

It is hard to determine whether something is an evolution or just an extension. If you look at our family tree of products, like the one for our computing systems, and which every product group should have and maintain, the critically successful products all occur the second time around. Some examples: 6, KA, Kl, KL, 2080; Tops 10, Tenex, 20; 5, 8, 8S, 8I/L, 8E/F/M; OS8-RT11; 11-20, 40, 34; RSX-A… M; TSS-8, RSTS; various versions of FORTRAN, COBOL and Basic all follow this; LA30, 36, 120; VT05, 50/52, 100; RK05, R101/2.

Some heuristics in designing good products:

• All products whether they be revolutionary (we have yet to have any that are really in this category), or creating a new base, or evolutionary, should:
• Offer at least a factor of two in terms of cost-effectiveness over a current product. If we build unique products that do not compete with ourselves, then we will have funds to build really good products.
• Be based on an idea which will offer an attribute or set goals and constraints for VAX included factor of two algorithm encoding and also offering ability to write a single program in multiple languages. VT100 got distinction by going to 132 columns and doing smooth scrolling.
• Build in generality and extensibility. We have not historically been sufficiently able to predict how applications will evolve, hence generality and extensibility allow us and our customers to deal with changing needs. We have built several dead end products with the intent of lower product cost, only to find that no one wants the particular collection of options. In reality, even the $200 calculators offer a familiarity of modular printer and mass storage options. For example, our 1-bit PDP-14 had no ability to do arithmetic or execute general purpose programs. As it began to be used, ad hoc extensions were installed to count, compare, etc. and it evolved into a digital computer.
• Build complete systems, not piece parts. The total system is what the user sees. A word processing system for example includes: mass storage, keyboard, tube, modems, CPU, documentation including how to unpack it, the programs, table (if there is one, if not then the method of using at the customer table), and shipping boxes.
• A new product base, such as a new ISP, physical interconnection specification, Operating System, approach to building Office Products must:
  • start a family tree for which we expect significant evolution to occur on, otherwise the investment for a point product is so short term and hence is likely to not pay off. In every case where we have successful evolutionary products, the successors are more successful than the first member of the family.
• A product family can evolve several ways as described on page 10 of Computer Engineering. The evolutionary paths are lower cost and relatively constant performance, constant cost and higher performance, and higher cost and performance. In looking at our successful evolutions:
  • Lower cost products can’t get by without adding functionality too, as in the VT100.
  • Constant cost, higher performance products are likely to be most useful, as economics of use are already established and a more powerful system such as the LA 120 will allow more work to get done.
• A product evolution is likely to need termination after successive implementations because new concepts in use have obsoleted its underlying structure. All structures decay with evolution and the trick is to know what the last member of a family is, such as the 132 column card and then not build it. This holds for physical components, processors, terminals, mass storage, operating systems, languages and applications. Some of the signs of product obsolescence:
  • It has been extended at least once and future extensions render it virtually unintelligible. (For example, PDP-8 memory addressing and ISP was extended three times.)
  • There are significantly better products available using another base.

SELLING AND BUILDING THE PRODUCT
Buy in of the product can come at any time. However, if all the other rules are adhered to, there is no guarantee that it will be promoted, or that customers will find out about it and
buy it. Some rules about selling it:

• It has to be producible and work. This, although seemingly trivial rule is often overlooked when explaining why a product is good or not.
• There should have been a business plan that several different marketing groups have contributed to in terms of ordering and selling. Just as it is unwise to depend on a single opinion in engineering for design and review, it is even more important that several different groups are intending to sell the product. Individual marketers are just as fallible as unchecked engineers.
• Never build a product for a single customer, although a particular customer may be used as an archetype user. Predicating a product on a sale is the one sure way to fail!
• It should be done in a timely fashion according to the committed schedule, at the committed price and with the committed functions.

Now isn’t it clear why building great products should be so easy?

Are there any heuristics that should be added? Or are patently wrong? Or need clarification?

Comments please!

The first paragraph with the 4 points says it all, but in case there’s need for detail, there are another 30 or so which follow. . . . in the words of Mies van der Rohe, “God is in the details.”