I used to think that the hard part of creating a product was developing the technology. That’s not a surprising attitude for an MIT graduate, steeped in the lore of plucky inventor heroes who toil in their labs for years before making scientific breakthroughs that bestow great benefits on mankind. I scorned all that “MBA crap” of marketing and sales and believed that the best technical solution was the one that would win (“If you build it, they will come”). I worked as a consultant and as a research prototype developer, and in both cases, once I delivered software that worked for that one person in that one situation, I was done. Getting the technology right was my only task so I thought it was the only thing that mattered.

I have since been involved in launching a couple products into the world (CellKey and the latest version of FogBugz) and have realized that getting the technology right is only a small part of releasing a product. Once the technology is “done”, finishing the product involves:

• Making sure that customers want to buy the product (“Did we build the right thing?”)
• Testing it in all possible situations that might be encountered in the world (“Wait, somebody’s trying to run FogBugz on a linux distro and MySql version that are both four years out of date?”)
• Fixing all the bugs that arise in such unanticipated field environments.
• Making sure that customers can actually buy the product (“Oops, we need to re-design the website“).
• Publicizing the product so that potential customers who might benefit from the product know about it and proving to those potential customers that your solution solves their problem. This was a particular issue with CellKey since it was a new technology so nobody had any idea how to incorporate it into their process. It comes up with FogBugz as well; despite the name, it’s a full-featured project management system, but doesn’t work like Microsoft Project, so customers aren’t quite sure what to make of it.

To do all of these other tasks, companies have to create what Joel Spolsky calls the development abstraction layer. As a technologist at small companies doing mostly consulting-type work, I didn’t really understand what most people did at larger companies. But those people are doing all of the support work necessary for the development abstraction layer, from QA to support to sales and marketing.

The first priority is making sure that the technologists build something of value to the customer. Technologists have an unfortunate tendency to believe that everybody else values the same things that they do. Back in 1996, I couldn’t understand why anybody wouldn’t run Linux on their home computer as I did, because it was clearly more stable than Windows, and had far more power via the command line than the Macintosh froofy graphical interface. It took me years of working directly with end-users to learn that powerful software was not defined by technology metrics, but by whether the software enabled the end-user to do what they want. Delivering a product means understanding the customer well enough to anticipate their needs and designing a solution to meet or exceed those needs.

Once a potential product is developed, it needs to be released. Big successful companies are built around having the infrastructure and machinery necessary to consistently release products. MDS Sciex had “phase gates” for the CellKey project every few months, and I didn’t understand the point of the gates until a more experienced colleague explained to me that each gate answered one of the questions from the development abstraction layer above. Early gates were about confirming the market need and that we were building something that customers would want, while later gates confirmed that we had built something that would work consistently in the field. A good company works to answer those questions about a potential product, so that once a new technology is developed, the company has the resources in place to successfully bring it to market.

Getting this infrastructure right is easier said than done. Sciex had a process in place, but it was too rigid, so we had culture clashes trying to adapt their process to the completely new product that CellKey was for them. Startups have not had the time to develop a process, so everything is done haphazardly and releases can drag on for months as people say “Oops, we forgot to do the documentation” and “Oops, we need to fix the product in this environment”. Unfortunately, customers don’t really want to wait while a company gets all these details right, so they get frustrated watching the company screw up. I’m not sure there’s a real model for getting all aspects of this infrastructure right, although a company like GE might be a candidate.

The world was a much simpler black-and-white place when I first entered industry as a software developer. New products developed by forward-thinking technologists were released into the world where customers made buying decisions based on technical brilliance. Alas, the world is more complicated than my naive perspective, and technology is not the only metric used to make decisions. There is an enormous amount of work necessary to take a promising technology and turn it into a product, work that is outside the scope of the technologist. Understanding that puts me in a powerful position where I can connect the technologist’s perspective to the larger context necessary for companies to consistently release successful products.