In the early 1980s I was part of Digital Equipment Corporation’s (DEC) Software Services group in Charlotte, NC.  The unit I was a part of consisted of 10 software specialists and a manager.  Due to the nature of our remote work at customer sites, we rarely saw each other.  Therefore, we always enjoyed getting together for our monthly unit meetings.  Yet, we were always disappointed when each meeting turned into yet another exercise in administrivia.  What should have been a great forum for sharing our learnings about our products and customer needs over the last month, shared problem solving, and new service creation brainstorming, always turned into going over the guidelines for filling out the latest paper form that had come down from the bureaucrats on high.

My officemate, John Churin, and I got so fed up after one meeting that we decided to design a solution to the administrivia problem.  Anything that would ease our pain would be greatly appreciated by others as well.  We determined that what we needed was a way to move the form filling from paper to networked computer systems along with a rich electronic mail and help system that would have more explanation about the forms than you could ever want.  We figured that if we could move the routine communications to email, our manager would know that we’d received and read the material and then we could use face to face time for learning and really creative stuff.  As luck would have it, John and I both had a couple of free days between customer engagements.

We spent the next two days in design mode rapidly iterating between the needs our organization had and the skills that existed between the two of us (real time processing, electronic forms design, database management, transaction processing, and networking).  We also looked at the expense side of what it was costing the company to do things manually with a horrendous amount of expensive multi-part paper forms.  We quickly estimated that it was costing $200 per week per specialist just to do the basic time reporting and expense reporting to support our revenue stream.  These costs included the paper forms, data entry personnel, maintenance programmers, and computer systems.  Not included in these costs were the management and facilities costs that a robust analysis would include.  We were excited just to find that our own unit had $100,000 of expenses associated with time reporting during the year.

While the expense side was one part of the value equation, unfortunately that expense was in another part of the organization.  The only offer that would really fly in our department would be increasing revenue, either in the form of generating more systems integration projects or selling large amounts of DEC hardware.  We were quite pleased with our analysis of the needs and our initial design which would be based on electronic mail.  We realized that if you looked at email as more than just pushing text around, particularly adding a robust electronic forms capability, you could solve a wide range of our administrative needs.

On the “building it” side, we examined DEC’s product pipeline which consisted of large timesharing systems (DECsystem 10s and 20s), small real time computers (PDP-11s), and the recently introduced VAX systems.  While there was only one model of the VAX at the time (VAX 11/780) it was clear that this was the system of the future.  More engineering dollars were going into the VAX hardware and software platform than the other two combined.  We knew that there would be lower end models and higher end models so that configurations of very small and very large networks would be possible in the next two years.  While there wasn’t a lot of application software on the VAX, most of the PDP-11 software already ran on VAX systems.

As we emerged from looking at our own needs, we became aware that what we were really working on was what the marketplace started calling office automation (OA).  The components of office automation were: word processing, calendaring, electronic mail, spread sheets, electronic forms, and data management.  These systems required both local and wide area networking.  Early competitors in the space were Wang, Datapoint, and IBM with a mainframe adaptation (PROFS).  At the time DEC was primarily known for its capabilities in the scientific/technical, medical and manufacturing environments.  However, the company realized that its next level of growth would come from the commercial markets.

Office automation provided a nice entry point in the commercial market because you didn’t have to go up against IBM’s mainframe database processing stronghold.  What was common with all the competitive products was that they had fixed functionality – what you saw was what you got.  Our own needs and a cursory look at other needs showed that no two office automation problems looked alike.  You had to take a customizing and component approach in order to be successful. Since the hardware was relatively inexpensive, you couldn’t require a large custom project to get the system going.

We spent some time discussing what our intent should be.  Did we want to just solve our unit’s administrative problems or did we want to go after something bigger?  If we were interested in building a product, should we form a new company, stay at Digital, or try and transfer up to the central engineering group responsible for building application products?  As we worked through these issues John and I realized that first and foremost we wanted to build a successful product.  We each had built what we thought were products before coming to DEC, but they hadn’t succeeded because we only looked at the coding part of the product effort.  We knew that to be successful, you had to think of a whole product (see diagram) and all the functions required to create the product, get it to market and sold, get it installed, and have it be supported.  We knew that the likelihood of the two of us doing it on our own was slim, but if we could use DEC’s resources then we had a chance of being very successful.  So we decided that our intent would be to build an office automation product within DEC, preferably within our systems integration group so that we didn’t have to relocate.

Reality set in after the two days, when John and I were pulled back to our customer commitments and our support of the sales representatives.  Yet, there was a subtle shift for both of us.  Where before any customer project was as good, bad or indifferent as the next; now we were actively looking for customers which met our intent – building an office automation product.

The design of our product concept changed our worldview.  Now almost every customer or sales situation we touched seemed like an office automation opportunity.  We talked about our ideas to anyone who would listen.  While none of the sales reps or customers looked at us as a first choice, several were now looking at us as a last resort rather than giving up on a piece of business or project.

Our first break came at RJ Reynolds Industries (RJR).  They were looking for a way to replace their aging papertape Telex systems that were cumbersome to use and expensive to operate.  As RJR was expanding their number of office and manufacturing sites, the speed with which they could move information was becoming increasingly important.  We did a half day analysis and realized that our preliminary design would nicely match their needs since this was primarily an electronic mail application.  Then the client gave us a rude awakening.   They liked our ideas but IBM had agreed to give them a systems analyst and a corporate telecommunications consultant for a month to analyze their needs.  We knew we could not match that offer but got the customer to agree to give us a chance to bid on the results of the IBM system analysis.

A month later we got called back in and given a copy of the IBM analysis.  My spirits soared.  The IBM folks just drew a few illustrations and copied some brochures.  I knew that we could do better in a few short hours.  We recently installed one of our new word processors so we could turn out a nice looking document in short order.  I asked if we could come back the next afternoon with the analysis and proposal that we had been working on for the last month (a small white lie, but the work that we would do that evening would look like several months work compared to the IBM analysis).  The client agreed and we hurried back from Winston-Salem, NC to Charlotte, NC.  I phoned ahead to John to get him to start cleaning up some of the architecture diagrams that we created previously.

Drawing on the early design work we created a 20 page analysis with several diagrams and a three page consulting contract to design their system for real, for a mere $50,000.  We took the proposal back the next afternoon and the customer was most impressed.  They never expected DEC to upstage IBM, and to do a free analysis in the process.  The customer agreed to our proposal and the next day sent us the approved purchase order.  This was a first for our region, getting a paid project just to do a specification.  We were off and running.

While John and I were the primary consultants on the project, having real customer dollars allowed us to tap into expertise around the country that we didn’t have.  Also, under the guise of project reviews we received great guidance and criticism of the completeness of our designs.  We went back with well over a 100 page specification and a twenty page proposal for the next phase of the project.  Once again, the customer was most impressed, but then gave us the bad news that RJR was reorganizing and that this project was cancelled.  While disappointed, we now had a very complete specification that we’d been paid for.  We had received real customer dollars without requiring our own company to invest.

In parallel, we worked on consulting projects to Milliken in Spartanburg, SC, a very large textile manufacturer.  DEC was the major supplier for their plant industrial automation. Milliken realized that as they automated processes like the creation of fibers and the making of carpets that their automation had an incredible amount of paperwork that followed the products around.  They were starting to do the prototyping for a plant office automation system and were working with Datapoint on the prototype.  As they showed us what they liked about the Datapoint offering, we realized that with our specification and a little bit of rapid prototyping we could provide a much better system.

While Milliken was not willing to pay for our time to develop the demonstration, the District Sales Manager realized that he could sell them triple the amount of hardware systems if they bought our approach to office automation.  Further, he could keep an unwelcome competitor out of the environment.  So he funded our next activity which was to take our specification and create a demonstration.  We estimated that we could do that in three short weeks.

The other requirement that the customer had that no other competitor could deal with is the necessity for their large engineering staff to be able to add to the base capabilities of the system and to customize the capabilities.  So an important part of our demonstration was illustrating the rate at which new functionality could be added.  Therefore, a part of our offer and needs analysis was to have meetings with the client every three days to demonstrate progress and gain critical feedback on our approach and understanding of their problem.  In three short weeks we had a demonstration of our office automation system and the customer was quite impressed.  They were ready to buy.  However, we still had some important lessons to learn about marketing and sales proposals.

In parallel with our demonstration project, the senior management team of Milliken was meeting with the top management of Digital for their quarterly meeting.  The Milliken upper management knew that the plant office automation team selected Digital as the top vendor, but none of us had thought to brief top DEC management on our capabilities.  So when Roger Milliken, CEO, asked Win Hindle, DEC Executive VP, about DEC’s office automation products and could they see a demonstration of the products, Hindle replied that we had no products in that area.  Further, he told them that he expected that it would be two years before we would have any products in Office Automation and that there were no products to demonstrate.  Talk about snatching defeat from the jaws of victory.  No amount of lobbying on our part could overcome the authority of our own top management.  While we didn’t get the Milliken office automation project, we were selected as the hardware vendor of choice and the customer elected to develop their own proprietary system.

We now had a demo of our capabilities and we took every opportunity to demonstrate that DEC and the VAX computer systems were the best platform for office automation.  In short order, the DuPont sales team from Wilmington, DE, contacted us to propose our system to DuPont.  The DuPont productivity team wanted to do a demonstration project of what OA technology could mean for a Fortune 50 company.  We analyzed their pilot needs, recast our specification and demo, and made a proposal for a project to transform the demo into a scaleable product for $100,000.  The sales team liked it and we started the multi-layer sales process required in old line hierarchical companies.  Finally, we made it to the top of the chain to present to Ray Cairns, DuPont Information Systems VP.

As part of the presales process, the sales rep and I went to lunch with Ray in the magnificent Hotel DuPont, and we talked quite a bit about the history of our efforts and the capabilities of our ideas.  He was an active questioner and probed far and wide about where we’d been and where we expected to go with the product.  He knew that we were developing this capability in conjunction with our customers and then would move it into DEC central engineering.  They liked our unique offer that for the cost of the project, they would have an unlimited use license for the software within DuPont.  Then, if they liked the tools, they would have to buy licenses for the next version of the product.  This offer allowed them to amortize the cost of the project over quite a few hardware systems which made the costs appealing to their financial analysts.  We appeared to be giving up quite a bit of future software revenue, but we were betting that we would have a new version of the product well before they were ready to deploy the software across a lot of systems.  This offer was win-win for both parties.

I relaxed and felt quite good that the decision maker would decide in our favor.  Little did I know what I was in for with the formal agenda with Ray and meeting all twelve of his direct reports.  We had professionally designed 35mm slides to present our story and product ideas.  At the end of the presentation, Ray asked several warm up questions and then hit me with the question that stood me on my heels: “how has this product helped impact Digital’s bottom line, either positively or negatively?”  He knew from our lunch time conversation that the product didn’t even exist, so that it couldn’t have much of an impact.  I knew he wasn’t a stupid man, so what was going on here?

In a flash, it came to me, that he wasn’t really asking about DEC, he was using me as a convenient foil to get critical education across to his management team.  I mumbled a few things about our unique approach to developing application software in conjunction with a customer.  Then, I turned the question around to the DuPont management team and asked them how they thought this product might affect DEC’s bottom line.  It is much easier to speculate about the cause and effect in someone else’s organization when you are at a level of optimal ignorance than to do speculation about your own organization.  What ensued was a great one hour conversation about the implications of such a product and technology on a large, complex organizational system like a Fortune 50 company.

After the meeting, we were awarded the order and we now had the funding to take the ideas of our specification and our demonstration into a full blown product.  The learning for me in this meeting was quite revealing.  Our way of approaching the selling of our ideas to individual contributors and middle managers was the traditional sales pitch of features and benefits.  What Ray Cairns made clear is that at a certain level of management, the rules change and the offer must move from features and benefits to second order implications.  In our case, what effect would buying our software have on both the revenue side of DuPont and the expense side of DuPont?  In order to answer that kind of question you have to move from the product under study to the system under study.  In particular you have to look at the interactions of an entity with its environment.  In later years, I would come across the third order thinking which is how will this product or service change a company’s valuation either positively or negatively.

Gordon Bell, DEC Senior VP of Engineering at the time (now at Microsoft Research), noticed a heuristic that no product ever made it out the door by requiring more than three new insights or inventions.  During the specification and rapid prototyping stage we hit on two core insights – that email was the core engine and that emailing should have multiple data types, not just text.  Yet there was still something missing as we moved into the implementation phase.  We couldn’t figure out how to implement our ideas without having to rewrite parts of the VAX/VMS operating system, which neither of us wanted any part of modifying.  The whole excitement of the VAX architecture was that we could build as complete an application as we were looking at without any systems work.

One day a happy accident occurred when all of a sudden the contents of my VT100 screen changed.  I was editing a file and all of a sudden a data entry form appeared on my screen.  It was eerily like Alexander Graham Bell yelling “Watson come here!” through his new invention – the phone.  The joy was realizing the power of the messaging architecture already built into the VMS Operating System.  While a bit esoteric, what it meant is that our system could be built on messaging from top to bottom and be fully recursive.  With a few architectural rules, the system could generate a wide range of custom applications.

We expanded our team by three and developed the code, installation procedures, documentation and training for the pilot site at DuPont.  During the process, I learned several invaluable lessons about engineers and product quality.  Any problem an engineer experiences directly gets fixed immediately.  The difficulty is that most critical problems in an application are rarely used by a software engineer.  So they never see the problems and the problems never get fixed.  Not only did I have to see the product opportunity at DuPont, and develop it, but I was also the person that went to install the software and train the users.  The things that worked fine on our development computer didn’t work fine on their computer system.

No amount of asking, cajoling, screaming or yelling could get the engineers to fix the problems. Unfortunately, the problems were in an area of the code that I was unfamiliar with.  Through shear desperation, I had John make the next trip to Wilmington, DE, to install the latest update.  Imagine how I had to keep from laughing (or crying) when he came back after the trip and asked me why I hadn’t told him about all the problems.  Magically, they were all fixed within a couple of hours.  Direct observation of problems or activities is worth far more than an abstract narrative.

Shuttling back and forth got old pretty quick so we created the next product support innovation – direct connection of our development network with their pilot prototype network (remember this was 1980).  The connection improved the reporting of problems, the suggestion of improvements, and the quick delivery of new software and documentation.  The beauty was that we were able to charge more for this service as it enhanced both companies capabilities.

We were really moving now.  We had a product (in today’s terms it would be a beta of a product), we had a paying customer, and we had a development staff.  Life couldn’t be better.  However, our intent was to build a successful product business.  John and I had gotten this far before.  How did we get farther?  It was time to put a distribution channel in place and find a set of complementors.  Little did we know we’d find them in the same place.  About this time, the Corporate Software Services Organization made a proposal to the corporation that we could grow from a $60 million business to a $1 billion business in less than five years.  One of the core assumptions was that there were already systems integration projects that DEC retained the intellectual property rights to and therefore could turn them into application products.  The ALL-IN-1 product effort became the test case for this idea.

The first thing we needed to do was to train some of our best consultants on the product.  The training was scheduled, but little time was allocated to prepare materials for the class.  On the Sunday night before starting the training, I was looking at only a four hours worth of material for a five day class.  I had no idea as I started lecturing Monday morning how I was going to make it through the week.  Through desperate acts, brilliance emerges.  During that first morning’s presentation, I kept getting questions about whether the product had this feature or that feature.  Could the product be used to solve this customer need or that customer need?  As I started to answer “No” to each of these and feel quilty that we didn’t have those features or capabilities in our product, I realized that each of the things they were asking for was easy to produce with the core functionality that we did have in the product.  So now the answer to each question became “No, we don’t have that capability yet, but you now have your homework assignment for the afternoon.”

As they broke for the afternoon laboratory, we had more than enough enhancement requests to go around to each of the “students.”  The students were all excited because they were getting to work on something that they cared about and in most cases they knew exactly which of their customers would be interested in that capability.  Some of the features required the core ALL-IN-1 engine to change.  So John would work with those students to figure out a good operational split between what the application engine would do and what the ALL-IN-1 applet should do.  They worked together to define what the interface or syntax between them should be.  With 20 students and a week’s worth of exercises that all arose from their questions, the product grew by leaps and bounds before our eyes.  This was our first experience with the power of an open architecture and a large group of collaborators.

The second order of brilliance was letting the students know that we would include all of their functionality in the next product distribution tape and we would give attribution to each of them for the parts that they contributed.  With that simple context switch, the afternoon exercises took on new significance.  Knowing that their work would be distributed, they didn’t just do something that demonstrated that the function could be done.  They switched into engineering mode and thought through the general case, implemented the functionality, tested it under a variety of customizations, and documented the features.

The next week we were teaching a group of 20 DuPont systems analysts who would be moving ALL-IN-1 beyond the pilot environment.  We taught the class in the same format.  In the morning, we lectured and explained the different capabilities of the system.  As questions arose about whether the system could do this or that kind of application, those questions became the person’s laboratory assignment for the afternoon.  Very quickly several different departmental systems emerged – Human Resources, Plant Office Automation, Order Processing, Strategic Planning – and we made the same offer to them.  We would include their efforts on the distribution tape internal to DuPont and external to DuPont if the feature were generic and give attribution to the person who created it.  Unknowingly what we did was create 20 disciples who couldn’t wait for the next Monday morning to demonstrate “their” creation to their peers or their internal clients.

Within three years, largely through the efforts of the 50 DuPont analysts who went through these courses, DEC installed $450 million of ALL-IN-1 systems in Wilmington County Delaware.  Largely through the efforts of the first 100 DEC software specialists we trained in this manner and the sales representatives they converted, ALL-IN-1 systems became a $1 billion a year business for DEC for 18 years in succession.  When I visited Health Partners in Minneapolis, MN in 1999 and found that they were still using ALL-IN-1 as their primary corporate electronic mail system, I was filled with awe and much trepidation (since the system was quite dated being in maintenance mode for the previous 14 years)

The last of the core lessons we learned was the power of tailoring far beyond what we’d anticipated.  I was asked to speak at the DEC European Software Services Meeting in Majorca in 1982 to describe what we were doing in the U.S. with Office Automation.  I gave an overview of the product and the kinds of customer solutions we were generating AND the revenue we were creating.  This got their attention as they were going through a revenue shortfall at the time.   The immediate set of questions I got were around translating the product into each European language.  It was an “oh, of course” type of question for me, but was unheard of in products of the early 1980s where the user interfaces were hardwired into the software code.  I shared “sure, it should be no problem, if you want to localize the interfaces, just change the ALL-IN-1 interface forms using the standard VMS tools.  All of the messages that we present on the screen are forms;  just go ahead and change them.  And we’ve adhered to all the VAX VMS coding conventions so all the National Replacement character sets should work.”

It was like I ignited a bomb.  Everyone came out of their seats and started throwing a hundred questions at me.  Seizing the moment, David Stone, DEC’s European Software Services VP, called a half hour break so that the attendees could get their questions answered informally or for country management groups to caucus on what this meant for their business.  He then called the whole group back to order and gave them a challenge.  Based on what they heard did they think they could make up any part of the $100 million revenue bookings shortfall Europe was projected to have for the year.

He first asked each country group to gather together and develop a straw plan for using the ALL-IN-1 product to address the revenue shortfall.  In the process, the groups were to identify any issues, questions or concerns that they had and they could pose those to me in their group presentations.  Each group went off and spent ninety minutes discussing the opportunity.  Then each of the ten country groups made their reports and identified their issues.  As each group reported, I went through my large library of 35mm slides to find the slides that addressed each issue or question.  I got David to stall for a few minutes after the last group presented so I could arrange the slides in some semblance of presentation order.

I then stood up and gave a “custom” presentation addressing all of their issues.  The management team was really excited now.  Until that moment I had not realized the power of a “custom” presentation to go along with our easily tailorable product.  The group correctly sensed that this product was quite real and could be adapted for each country’s unique business needs.  Until now, Europe had to take a one size fits all set of products that were English language and US culture centric.  Long delays would occur to get even minimal localization done for each country.  Now they’d found a product that could be introduced Europe wide in each natural language at the same time as the US introduction.

David Stone, then asked the country groups to get together with this new information and come back with a “committed” forecast of how much of the revenue shortfall they could make up with this product and what they needed to do to make this program happen in Europe.  The groups quickly formed and in 15 minutes came back with their commitments.  The commitments totaled $120 million.  David scaled the numbers back to total $100 million to mitigate the exuberance factor.  I was blown away and now fearful for my life.  I wondered what would happen if they all woke up and decided they’d been railroaded into a commitment in the bliss of the moment.  I figured they’d shoot the messenger – me.

The group then started to work on the marketing program to make their commitments happen.  Using the natural creative competitiveness of the countries Stone broke them into their country units to develop logos for the $100 million in 100 days campaign.  Several of the teams found a local T Shirt design shop and had their logos emblazoned on T Shirts for the attendees. Then he organized cross-functional and multi-country groups to develop:

• the 20 page newsletter that would go out to all sales and software personnel in Europe,
• the training program for sales and software personnel,
• the localization teams to translate ALL-IN-1 into each country’s natural language,
• other applications that could be combined with ALL-IN-1 in each geography.

By the end of the four day meeting, the Europeans now had a major new product that was their own, a marketing program that they could roll out, and a new found respect by their sales peers.  I was asked to stay over another week to train the software consultants who would be doing the translations.  My ask of the software consultants was that each country supply a software consultant to come work with our development team for a month at a time to make the core ALL-IN-1 engineers aware of multi-cultural needs.  Within the month they had ALL-IN-1 translated into 10 different languages and cultures.  Within the 100 days they’d exceeded their goals and in fact did $120 million of additional business.

In David Stone, I saw and appreciated a master at management leadership and motivation.  For the next year I spent as much time in Europe as I could to learn about changing the behavior of a large organization.  I asked David how he knew that my presentation would set off so much energy.  He laughed and said that he had no idea that it would.  “What I do is schedule an agenda that has as much informational diversity as possible running the gamut from product information, service information, corporate strategy, engineering strategy, organizational behavior change stuff, and management education.  I never know which of these will cause an energy hit with these 150 managers, but I’m confident that one of them will.  When that energy resonation occurs between the audience and the speaker then I go into action.  I’m not good at generating that energy.  However, I know how to move energy into action; that’s what I’m really good at.”

We succeeded so well in those first several months at promoting and selling our version of Office Automation that the company now had a dilemma.  Taking a portfolio approach, DEC had six different central engineering groups working on office automation projects.  The corporate powers that be met to decide which group would win and be anointed as THE office automation product.  There were pluses and minuses to each product and the capabilities that each would add to the VMS product line and the push into the commercial market.  But in the end, there was no clear winner at the features and benefits level.

Peter Christy was chartered by DEC’s executive management with evaluating all of the different DEC OA options.  Here are some excerpts from his evaluation.  Peter would have made a good economist with his report that was of the variety – on the one hand and on the other hand.  What I would have given for a one-handed Peter Christy at this juncture.

“The VAX/VMS office automation system developed by the Charlotte, NC, District Software Services office has been studied. Under the goals set forth in the “Grey Saturday” meeting, the Charlotte software is not an alternative to EMS/VMS. On the other hand, the Charlotte software deserves careful examination on its own merit. It offers new ideas on the design and marketing of office automation into large enterprises (e.g. Fortune 100 companies). . .

“Recommendations:  The Charlotte software seems like an excellent office automation system, both to those of us that went and looked at it, and to the customers that the Charlotte people have been dealing with. Unfortunately, there is no simple reason to bring the software in and base product development on it. The most reasonable approaches today seem to be to begin a parallel development based on the software (which requires additional resources) or to continue to use the software for leveraged field consulting, with some effort expended to assure reasonable comnunication between field and home developers. Most critically, we need a broadly accepted decision on how to position this software.  The software is too attractive to just forget; it’s too dangerous to treat passively.”

However, only one of the six product alternatives had generated any revenue for the company – ALL-IN-1.  That made the decision quite easy in the end.

The implications of the decision were not so easy for me.  I was asked to manage all the groups that “lost” and meld them into one group producing the next version of ALL-IN-1.  Suddenly, I would be moving from managing 10 people to managing 250 people in five different organizations, in three sites, in two countries.  But that is a story for another time – global product management.

Gordon Bell was instrumental in getting ALL-IN-1 accepted as the primary office automation product development effort.  He sent the following memo in 1982:

SUBJECT: THANKS FOR ALL-IN-1 DEMO. LET’S BE #1 IN THE OFFICE BY SALES

“I thoroughly enjoyed the demo and interaction on ALL-In-1, and anxiously await to use it on our own VAX. It’s an impressive set 0f tools for the office and the basis for others to build additional tools that work together in a system.

“It is most urgent to get books out on it of the form:

1. A user’s manual that has the whole thing including DECmail for the heavy duty office environment for professional and secretary.

2. A tutorial on office automation where we feature it as being “this is what office automation is.”

“I hope that we might be able to help with the writing somehow.

“It should be noted that you folks have created a second generation office automation system. Because you adhere to the principles of VAX/VMS regarding providing an extendable fully compatible environment, versus just having a set of independent tools, you have the second generation.

“WE SHOULD ALL NOTE THAT A SECOND GENERATION SYSTEM IS PROBABLY NOT BUILDABLE ON ANY OF THE EARLIER SYSTEMS (eg. IBM 370, Prime, HP) . . . or for that matter, RSTS, RSX and Tops due to the difficulty of addressing and lack of common data dictionaries, etc. From my perspective, this is one of the few applications I’ve seen that begins to utilize VAX the way it was supposed to be.

“My only concern now is getting it marketed. This is a great product to go cream the IBM System 38, Wang and other parts of IBM with and to become number one. We must get market share while it is possible and the other folks get their products.

“As Pogo said: ‘We’ve met the enemy and he is us.'”

The exciting part of being selected to build ALL-IN-1 was that we quickly went from nowhere in the OA space to being one of the front runners.  Patty Seybold of the PSGroup put us on the front cover of her monthly report in 1983:

“As we move into the ‘big league,’ analyzing some of the product offerings which might be appropriate as the basis for the implementation of a large-scale organization-wide office system (such as Honeywell’s OAS, IBM’s PROFS, Wang’s Alliance/VS, DG’s CEO, Prime’s OAS, as well as the offerings from Datapoint and HP), we begin to look at a different set of criteria from those we used heretofore in evaluating smaller, dedicated systems. An organization-wide office system must, above all, excel in the areas of data communications and networking. Ideally, it should integrate well with the existing data processing, data base, and management information systems that are already in place within an organization. And it now appears that such large-scale integrated office systems must also interface serenely with the desk-top tools that managers and professionals will be using: personal and professional computers.

“Frankly, it was this third aspect—customizability—that attracted us to DEC’s All-in-1 system. We believe strongly that every office environment is different, since every business has different problems to solve. We also feel that each user of an office system should be able to mold the capabilities of the system to his own personality. DEC’s All-in-1 offering purports to do just that. We wanted to find out if it really did. . .

“What does the future hold?  We think that DEC will ‘pull it off’ – become a major office systems supplier, on a par with Wang and IBM, at least in part because DEC customers will insist that the vendor take an active, leading role in helping them determine their own strategic directions.”

During the process of developing, marketing and selling ALL-IN-1, I met so many wonderful professionals like John, David, Gordon, Peter and Patty.  The eight year ride of creating an innovative Office Automation System remains one of my top three innovation experiences.