If you're a software startup, how do you decide what to work on?  That's a question that I've put a  lot of deep thought into over the years.

As I've talked to people about this issue, there are two basic paradigms that standout.  They are extremes of each other, but they serve as useful pivot points for the discussion.

The one school of thought, headed up by my sales & marketing friends, says you should "Listen to your customers and do what they say."  Well, that sounds reasonable, but what if you're a true startup company and you don't have any customers?  Then who do you talk to?  My friends tell me that in this situation, you work your personal network, you make individual contact with people, you take them out to lunch, ask them very general, open-ended questions like "So Pat, what part of your job do you spend the most time on?", and then you engage in "active listening" to discern their needs.  After doing enough of these personal interviews, a common pattern of need will emerge, and there you have it ... you've got your product idea.

According to this way of thinking, you should not even begin to write your first line of code until you have lined up at least half-a-dozen reference customers who have not only committed to buying the product once it is available, but have agreed to pay you in advance for the costs of the product development.

The second school of thought, headed up by technically-inclined people such as myself, tend to think you should draw on your own personal experiences and your domain expertise in whatever field you are contemplating, think of a great idea, write the code, and once the product is available, begin the sales & marketing aspects of the business.  People who think this way are introverts by nature, and would love nothing more than to hole up in a cave somewhere, spend a couple of years writing the greatest product on Earth, and then tenderly and lovingly release its awesomeness to the world.

So which of these schools of thought is correct?  Probably neither.  But which one is closest to being correct?  I think there are probably examples of both kinds of success.  As I am currently working on my third startup company, for the sake of anecdotal data, let's examine my first two companies, which were both successfully sold to larger software companies.  How did those companies succeed?

In 1991 I was working as a software engineer at Hewlett-Packard.  During my tenure at HP, my project team was struggling to cope with the myriad of "to do's", bugs, and enhancement requests on the project.  We began using a very primitive UNIX-based defect tracking system named DDTS.  It sucked for two main reasons.  First, it used UNIX shell scripts as its core technology, which made it difficult to get useful information out of the system.  Just getting a list of defects assigned to you meant you had to write your own shell script.  Each engineer had to have their own personal script with their name hard-coded into it.  Second, it could only be accessed from a UNIX workstation, which meant I had to leave my PC-based development system, walk over to a UNIX workstation, and login to access DDTS.  How inconvenient.

From this experience I was aware that there was a need for defect tracking, and the current solution in place was very suboptimal.  I reckoned that the world could use something better.  While those thoughts were fermenting, my friend Bob Pinna told me he was going to leave HP and start his own company to make a defect tracking system.  Wow!  I'd been thinking about the same thing.  Bob had a few more years of experience than I did, and had done not just software engineering, but software project management as well.  I figured if Bob thought it was a good idea, then it probably was.  Bob drew on his personal  project management experiences, but also talked to several other project managers, mostly at HP, to figure out the initial feature set of the project.  Bob left HP and started working on the product full-time.  I stayed at HP and worked with Bob part-time to write the system documentation and help with testing.

When the product was ready, in October of 1992, and before we had made our first sale, I left HP to work with Bob full-time.  I had started at HP on August 1, 1990.  My last day was October 2, 1992.  My life as a salaried engineer working for a large company had lasted exactly two years, two months, and two days.  My life as a software entrepreneur had begun.  Our product, Defect Control System, or DCS, was released and sales grew rapidly.  Two years later the company was acquired by INTERSOLV and the product was renamed to PVCS Tracker.

Getting back to the idea generation process, in which two schools of thought does this model fit into?  To me it seems clear that some aspects of both methodologies were used.  Interviews were conducted and feedback was incorporated into the product.  The product was not developed in a vacuum.  However, the idea itself came from personal experiences of understanding the need for defect tracking, and understanding the weaknesses of the existing solution.  Interviews were done after the idea was decided upon, and for the purpose of honing the idea and deciding upon the exact feature set.  We showed the product to our friends who were still at HP, but there was no pre-commitment on the part of HP to buy the product once it was ready.

The process worked, although not without some misfires along the way.  One thing I remember is that because of the close ties we had with HP, the product had a Bugs per Thousand Hours report, which was an important metric used within HP.  Turns out, not too many organizations outside of HP were doing things that way, and the feature went mostly unused and was the source of a lot of customer confusion.  Other important features were missed, like the need to be able to create custom fields for tracking information specific to each organization.  Everyone did things a little differently.  The first version of DCS had custom fields, but you could only add a total of 8 custom fields, two text fields, and six drop-down selection fields.  This limitation turned out to be woefully inadequate, which we learned very quickly.  I don't think you'll ever get everything exactly right out of the gate, but hopefully you get pretty close.  I think we got a lot more things right than we got wrong.

In the next blog in this series, I'll talk about my second company, TeamShare, which made another defect tracking system, TeamTrack.