Product Manager / Director, Product Delivery

iWork Software

1999 - 2000

I was hired to manage the existing product line which was an ERP system that extended the BPCS manufacturing software to the shop floor. As the product manager, I was responsible for minor product enhancements and product support. It was the latter that consumed 90% of my time originally.

The product itself had some bugs, but that was not the main cause of the problem. The help desk was not being responsive to the customer complaints and wasn't communicating effectively within the company. Customers were calling developers directly and problems were not even being tracked. The lines of distinction between level 1, level 2 and level 3 support were entirely blurred. As the person with responsibility for level 3 support, this concerned me.

Shortly after I got there, the help desk got new management: a former Vanguard employee. We had an instant rapport.

The solution to this problem started with metrics. How big was the problem and where is it happening? The help desk put in a call tracking system, and I started taking measurements. Several months later we found the problem areas.

90% of our problems were with the AS/400 product. We hired an second AS/400 programmer and that helped stem the tide some. The number of issues being worked simultaneously in level 3 support peaked out at 40! The turn-around time for problem resolution was 15 working days. In the midst of this gloom, I was predicting better days ahead. The metrics were telling me that any nudge in a positive direction would send the call count declining. I advised against hiring yet another AS/400 programmer.

Instead we worked on the second part of the problem: help desk education. We took a level 2 support person and put her in the pit with the AS/400 programmers. She got to see the problems first hand and learned some basic troubleshooting skills. When she returned to the help desk and started to train others there, the number of calls being sent to us by level 2 started to decline. Originally 50% of the problems that made it to level 2 made it to level 3. Only 12% of the problems actually required code changes. After training, 25% of the calls to level 2 made it to level 3 and those that did get through were better defined.

The third thrust of the attack was getting the field people involved. We started giving them better notice of programming changes. We established a message board in Lotus Notes so they can share ideas. We got together with the Account Executives and asked their help in getting us better problem definition.

The wave of calls handled by level 3 was just beginning to decline 10 months after I got there when I got promoted. Two months later it fell from 40 tickets and 15 days to 5 tickets and 5 days.

My new job was to oversee the back end of our product life cycle. I was responsible for everything exclusive of software development and marketing. I had to manage what it took to get the product from the developer's machine into the customer's hands. I was responsible for the departments that provided quality assurance, documentation, training and initial product delivery.

Traditionally, these function were treated as afterthoughts to the development process: "We're done coding - do something with it." We commissioned a multidisciplinary team (which contained not a single manager) to develop a process to make the information flow better. They succeeded in putting what they call the "Unified Process" together. We ran one project under it, and where it was applied conscientiously, it worked.

Even though I had people actually reporting to me in this position, I still had to lead by influence especially to get the products placed with customers who were willing to beta test them.

The promotion proved to be a bane; six months after getting it, my position was eliminated.