After Software Edge was sold, I worked for INTERSOLV for about a year, and started my second company, TeamShare, in early 1996.  This was in the very early stages of the Internet taking off, so like a lot of people, I was thinking about how to do something useful in the new era.

I went back to my roots with defect tracking, which by now I had built up nearly four years of domain expertise in.  Being shy and introverted, I didn't do any customer interviews at all.  I simply drew upon the customer experience I already had from building DCS.

Based on that experience, I thought a browser-based interface would solve three problems.  First, it would be easier for distributed teams to work together, and I knew from DCS that there were lots of customers that had distributed, or extended teams.  Second, it would eliminate client installs, which caused a lot of problems with DCS when we did upgrades from one version to the next.  Basically everyone had to do the upgrade at the same time, and people using an old client version couldn't talk to the new server.  It was hard for people to coordinate their upgrades.  Third, there was a technical problem with the way DCS handled its user inbox, which was used for defect notifications.  If someone hadn't logged in for a long time, we had to synchronize changes down to the desktop.  It was a slow process and made a lot of customers angry.  I figured a browser-based interface would eliminate the need for this desktop synchronization.

I wasn't sure if making it web-based would be enough of a differentiator from PVCS Tracker, so I looked for a couple of other features I could add to make TeamTrack better than PVCS Tracker.

DCS had a lot of built-in reports, which customers liked.  We also had the concept of projects, which allowed customers to delineate their development groups from each other.  The reports worked on a per-project basis.  This worked well at the tactical level, but as upper management started to use the system, they complained about not being able to see the big picture.  There was no way to run reports across multiple projects to get a consolidated, high-level view.  I remember Bob Pinna telling me, "Kevin, people want cross-project reports.  If you can just crack that nut, we'll have it made."

To deliver this feature, I decided to implement hierarchical projects.  I figured if projects could be arranged hierarchically, then reports could be run recursively across multiple projects, and customers would have what they'd been asking for.

The other need I decided to tackle was required fields.  What customers said to us was, "The reports you have in DCS is great, but they're useless to me.  No one ever fills in the fields they're supposed to, so we don't have good data to use in the reports."  So I thought a lot about how to have a good implementation of required fields.  I realized that it wasn't just about getting the required fields filled in, but they had to be filled in at the right time.  So I decided to build into TeamTrack the concept of workflow, consisting of states and transitions.  I could then associate required fields with each transition in the workflow, and customers would have what they asked for ... fields getting filled in with good data to facilitate proper reporting.  To my knowledge, TeamTrack was the first defect tracking system to implement workflow, a feature which went on to be copied by nearly all defect tracking systems that came after it.

So let's review what I did.  I didn't conduct any interviews, but I had the luxury of not doing that because I had all the experience from DCS fresh in my mind.  The ideas I had weren't born of my own fanciful wishes, but were based on real problems experienced by real customers.

But there's something else that I think is also interesting.  In DCS, no one asked for a web-based interface, they asked for simpler client upgrades and faster inbox refreshing.  No one asked for hierarchical projects, but instead they asked for high-level reports across multiple projects.  And they didn't ask for workflow, they asked for a way to make sure fields got filled in at the right time.  It was then up to me, using the domain expertise that I had by now acquired, to map the customer needs into specific features.  That's an interesting part of the process.  You can't expect customers to tell you what features to add, they just tell you what their problems are and then you have to figure out how to design a system that will solve those problems.

So once again I think we see a combination of the two schools of thought about idea creation that I mentioned in Part 1 of this blog series.  Customer feedback was an important part of the process.  But so was applying personal ideas, creativity, and domain expertise about the problem.

In the next entry in this blog series, I'll examine how applicable these lessons are in the current era of software development.