Daisy Systems was founded in 1981 by a group of ex-Intel employees. They identified a need for computer aided design (CAD) tools to be used for designing printed circuit boards (PCBs) and integrated circuits (ICs). Daisy pioneered the field of ‘computer aided engineering’ (CAE) and become a leading company in that space. I joined Daisy in 1988 as a technical marketing manager. My job was to “translate” high level marketing requirements into functional specifications that our engineering team could implement. It was my very first job in marketing, and I learned a lot. I had an exciting 2.5 years working for Daisy, until the company went bankrupt and shut down. Yes, shut down.

So how does a pioneering company in an exciting new market reach bankruptcy? There were many contributing factors to Daisy’s eventual downfall: some bad financial decisions, a botched M&A, and a new management team that didn’t quite understand the company or its market. However I want to focus on what I perceive to be the first blunder that led Daisy down a slippery slope.

Before I continue, I want to emphasize that what I am describing here is my personal view, and the lessons I learned. Keep in mind that I was just a “lowly product manager” in the organization. What I could grasp from my standpoint was quite different from what was seen from the top. I am also careful not to “lay blame” on anyone directly or indirectly. The phrase “the road to hell is paved with good intentions” certainly applies in Daisy’s case.

So what was the fateful misstep (according to me)? I believe it had to do with misinterpreting a key customer requirement.

Daisy initially offered a “turn-key” system: a hardware platform, an operating system and a set of CAE applications – all developed by its own engineering teams. In the early 1980’s, there was no other choice. If you wanted to sell an interactive computer workstation – you had to build it yourself. The ‘Daisy Logician’ was a black workstation with fast graphics engine that did wonders for large electronic designs. Customers loved those ‘Logicians’, and bought them in droves.

But the market scene started changing. A new breed of general purpose computer workstations emerged, offered by companies such as Apollo Computer and Sun Microsystems. These workstations ran the UNIX operating system and were referred to as ‘Open Systems’. In theory, you could run any application on it, as long as the application vendor supported the platform. However Daisy’s beloved CAE applications only ran on Daisy’s operating system, and its Logician hardware.

Daisy heard the customers demand for ‘open systems’. But migrating from a proprietary system to an open one takes a lot of work. Plus it meant losing the great margins it made on the ‘Logician’ boxes. Well, let’s given them something “similar” the company decided. Let’s make our operating system UNIX-like, and call it Daisy UNIX, or DNIX. That ought to do it. The company spent significant resources and time reengineering its operating system and adjusting all its home grown applications to it.

But DNIX was a failure. It wasn’t the ‘open system’ UNIX the market wanted. But moving to an ‘open system’ involved another major hurdle: a significant portion of Daisy’s software was written specifically for the Intel x86 processor family. Moving to a true ‘open system’ meant a significant rewrite of application code.

By now Daisy was desperate to jump on the ‘open systems’ bandwagon. It approached Sun Microsystem and the two came up with a ‘compromise’: the Sun 386i workstation. As the name suggests, the Sun 386i was based on the Intel 386i processor. Porting Daisy’s CAE application to this platform was much easier, since the code could remain Intel processor specific. Another major ‘porting’ effort resulted in the launch of Daisy’s “open system” solution on the Sun 386i.

It was another major failure. Sun Microsystems previously announced it will develop its own processor architecture – the SPARC. Its main workstation line started using the SPARC processor. It didn’t take rocket science for customers to understand that the 386i was a sidetrack for Sun. And nobody wants to buy a computer system that is a “sidetrack”. The Sun 386i failed.

It was only after two major iterations, each consuming significant resources and time that Daisy Systems finally caught up with the market. It eventually launched its CAE application suite on a true open system – a SPAR based Sun platform running the UNIX operating system.

But it was too late and the company lost its momentum. The superfluous platform releases cost time, engineering resources and money. They were done at the expense of developing competitive applications and new features. Daisy never made it back to the top. A series of failed attempts to recapture market share resulted failed acquisitions and eventually led to bankruptcy.

This is not a story about villains or morons.  Daisy had many bright, hardworking individuals who did their best for the company to succeed. To me it was an example of misinterpreting a key customer requirement and failing to embrace a market trend. It can happen to the best of us, if we’re not careful. I personally took a few lessons from this:

–       Listen carefully: to what customers have to say and what the market trends are. Missing a key requirement, or worse – misinterpreting it, can be catastrophic.

–       Identify pivotal requirements: while you may end up collecting dozens or hundreds of customer requirements, you must identify the ones that will ‘make or break’ your business. Make sure those are addressed first.

–       Make hard choices: compromises are fine, most of the time. But there are moments when you need to make hard choices – make them. It may involve “betting the company” or the product, but avoiding a hard choice will doom your product or you’re your company.

I believe you can learn a lot from mistakes (yours or others).  It took many years for me to internalize and accept the “failure” I experienced at Daisy; too many years. In hindsight, Daisy was a great learning experience for me. Many of the skills I developed as a product manager were first used at Daisy. The “fear of failure” is something we all need to learn how to live with. Especially since as product managers we are tasked with making decisions that can be fatal to the product we manage. Indeed, companies and products can fail, but if this is all you can think of – you should find another job. I comfort myself with the knowledge that avoiding a choice is much worse than making a bad one, and then try to make the best choices I can.