Remember the “Year of the LAN”?  What about “Groupware”?  Who developed the first online application with a distributed graphical user interface -- six years before the web?   When was the first automated software generator invented — and by whom?  What did EMC initially call its storage architecture? (Hint: It wasn’t RAID.)

Throughout my career I’ve had the privilege to write about some of technology’s most significant milestones while having the companies responsible for those achievements as my clients.  The six cases here showcase some of those milestones.  They also illustrate classic strategies to achieve what remains a central marketing objective — selling innovation.

Classic play:  Connect the dots between a technology innovation and a societal impact — “welcome to the revolution!”

Guessing the future is a perennial favorite pastime of almost everyone involved with technology — most of all market influencers who get paid to do it.  They’re also looking for the “bigger story” — how something happening in a lab has an impact on real people.

That’s the story behind the story of this white paper that served both as an Information Week Final Word essay and as the trigger for a Wall Street Journal article.

Year written: 1986

Classic play:  Attack the conventional wisdom.

Before EMC came along few organizations stored their precious mainframe data on arrays of small PC-style disks.  Now, of course, that is exactly how most organizations store their data.

But back in 1990 this was a very hard sell — especially since EMC adopted a different small disk architecture than the one proposed by most other newcomers in the space.

Here’s EMC’s first white paper on its small disk architecture.  See how we made the case.

Year written: 1990

Classic play:  Mark a milestone.

Trend articles — whether you buck the trend or ride the trend — are a classic strategy for looking strong.  The key is to take a clear position either way and then back it up with a clearly articulated argument that is well supported by facts.

As the cover suggests, the magazine in which this bylined article appeared was focused on how big a role PCs would play in corporate IT in the years ahead.  So it was a natural environment in which to make the case Digital was making.  In fact, not appearing in this issue, or not taking issue with what pundits were saying, would have been a mistake.

Year written: 1990

Classic play:  Exploit the tension between standards and innovation.

Many people say standards are good because without them compatibility doesn’t happen.  Think VHS and Betamax or Blu-ray and HD DVD.  But if you think standards are boring, the tension between standards and innovation is not.  Specifically, how do you integrate both standards and innovation into products in a way that’s sustainable?

This white paper for Microcom uses that tension to introduce MNP, which did in fact become the de-facto standard for all data exchange on dial-up networks.

Year written: 1990

Classic play:  Make business strategy the star and technology the enabler.

When United Airlines came to Hill and Knowlton and asked us to promote its technology leadership, some people on my account team scratched their heads.  Why should the flying public care about United’s first-ever commercial deployment of distributed windowing technology, a graphical user interface, or n-tier client/server computing?  (This was six years before the web.)

But the audience wasn’t the flying public.  It was investors and market makers interested in pricing United’s technology spin-off.  As my ghost-written column shows, it’s a classic example of using technology as a business strategy proof point.

Year written: 1988

Classic play:  Hype your product’s comparative advantages with articles about the best way to compare products.

Here they are:  The first two articles of my professional career.  What I like about them — beside their nostalgic value — is that they show how to break two cardinal rules of public relations and get away with it.  Rule #1 is you can never publish an article under your company’s name that claims your product is better.  Rule #2 is you can never publish the performance benchmarks that prove it.

In the first article, we wrote specifically about benchmarking — in other words, what’s the best way to compare products — and then used our benchmarks as an example.

In the second article, we wrote about best practices OEMs could use to improve product performance — again with examples from our own products — and sold to OEMs.

Year written: 1983