Dan's Blog

July 21, 2010

Transferrable skills and attitudes

Filed under: Customer Service,general,job search,Product Management — ddswanson01 @ 12:29 pm

I am interested in two different types of positions, Manager of Customer/Product/Software/Technical Support and Product Manager for Software Products and Services.  I keep running into people who don’t quite see how closely related the two positions are, and how the attributes of a good Support Manager transfer to Product Management. I am looking for a position as either type of Manager; I’m hoping this post will highlight some of my skills and show how they transfer…

I am a very good Manager of Support (actually, I’m outstanding, but I’m too modest to say that – oops, no I’m not!, I have references to prove it, too) and I am certain I would be a very good Product Manager. At my last job I actually received an award for filling in for a Product Manager in the development of 2 software products, so I have potential!

Here are a few attributes that I believe make a good Manager of Support, related to attributes of a Product Manager.

  • Ownership of the Product. Support is a product. It is mostly a ‘service product’ as opposed to a physical product, but it is one of your company’s products and everyone who contacts your support organization will add their impression of your support to their evaluation of your company. The Manager of Support is responsible for the quality of the support content, the quality of the delivery of the content, the infrastructure required to deliver the content, the relationship between support and other stakeholders and insuring that the overall Support product suite is current and meets customer needs and the company’s business objectives.  As well, the Manager of Support needs to work with the business office to develop a sustainable long term support strategy that aligns with the goals of the company.Product Ownership is an attitude. It means ‘I am interested in everything that relates to my product, and I want everything that is related to be the best.’ Successful Support Managers have to have it; successful Product Managers as well.
  • Uncovering and documenting stakeholder needs.  As Manager of Support, I dealt with customers and internal stakeholders, all of whom needed something from my support group, on a daily basis. Determining their actual needs, rather than what they originally expressed, is extremely important, as working on the wrong issues is very unproductive.Documenting the needs and making them into action items is even more important. The people or groups who will take action are usually less familiar with the operation of the software than a support agent (or the Product Manager) and the universal response to a poorly-documented action item is ‘I can’t figure out/replicate the issue; I need more details and a better explanation – and I’m not going to do anything until you give me a better description.

    Product Managers work with the same product stakeholders as those who support their products. The issues are the same – uncovering the real issues and documenting them concisely and accurately.

  • Developing Product Strategy. A good Support organization requires a long term strategy, which acknowledges and integrates with the company’s business strategy and the product strategies of the various Product Managers. It is important to offer valuable support products, adding new products and perhaps sunsetting older products, as time goes on. The strategy should be reviewed every year (or more) and adjusted as required to accommodate new technology (for example, how is social networking going to be integrated into support?), changes in the user base, and changes in the vision and/or mission of the company.The Manager of Support is responsible for the development, implementation and maintenance of Support strategy, just as the Product Manager is responsible for the Product Strategies.

In addition, both types of managers are intimately familiar with the software development process, often having worked as a developer or closely with developers in a prior position.

There are a lot more similarities, but I try to stress these ones.  Nobody goes to school to learn to be a Product Manager or a Manager of Support (this is changing, so it might not be ‘nobody’ now, but the number is very few); everyone who does these jobs learns on the job. It seems to me that the skills learned in either one of these positions is a very solid background for the other.

Advertisements

February 23, 2010

What good are Product Managers?

Filed under: Product Management,publishing — ddswanson01 @ 10:32 am

I’m not an expert Product Manager yet, though I expect to become one, but one thing I am an expert on is things that can happen if you don’t have a Product Manager, and today I’ll describe an incident that shows some of these things. I’m talking about a time when my company didn’t have Product Managers, and I’m depending on memory, so the details might not be exact, but the incident described below did happen. The company desire to lower costs by avoiding incidents similar to this is one of the reasons the PM position was created, back around 2001 or so.

A new edition of a textbook and an ancillary software product were released. Instructors who had used the prior edition of this textbook and software started calling the famous author, because the software for the new edition was missing one of the features found in the prior edition. Instructors threatened to go back to the old edition, or worse yet, adopt a different author’s book from another publisher.

An extremely important part of the Product Manager’s job is to uncover market needs and address them in new products and product upgrades. This missing feature was not just a market need, it was a critical need for the product, and any good or even adequate Product Manager had better recognize critical needs and prioritize them accordingly.

The missing feature was a skill-building exercise. The student was presented with a problem similar to a homework problem from the book. The student solved the problem and the program verified the answer. If desired, the student could then solve another similar problem, and the program would present a different problem each time. Solving similar yet different problems was supposed to build the student’s knowledge about this particular type of problem.

The problem was conveyed to a project manager and although I didn’t actually see the specifications that were provided, my later experience with the feature suggests they were something like this:
· Create a self-grading skill-building exercise for this product.
· Do it fast and cheap

The upgraded product was quickly re-released. The new feature did not resemble at all the skill-builder from the earlier version; it had apparently been designed by the developer based on the specs above. Tech Support quickly became intimately familiar with this new skill-builder; it seemed that every student who used it called support. In addition, the author got even more calls from instructors about the new feature than there had been about the missing feature. There were two problems with the new feature:
· It graded the first problem it presented to the student correctly; every subsequent iteration of the problem was graded incorrectly.
· The presentation of the problem was such that even when it worked correctly, it did not promote student learning.

Our hypothetical ‘good or even adequate’ Product Manager would have insured that these issues never made it into the release. The PRD would have given more details on what the skill-builder should do, and the test cases in the user stories would have avoided both issues.

The bad feature was quickly updated and the product re-released (still without a PM) and guess what? Only the first issue was addressed. Whoever prioritized these issues didn’t understand that a skill-builder that doesn’t promote learning is as useless as a skill-builder that doesn’t work. Our PM would have prioritized these issues correctly.

What did this particular problem cost us? We could accurately compute Development and Testing costs, Tech Support cost and the cost of scrapping bad inventory and building new inventory (three times!). Sales provided the dollar value of lost adoptions. Harder to calculate are: costs for future lost adoptions; opportunity cost of reassigning the development resources; the dollar value of loss of goodwill from authors and customers and damaged morale of the product stakeholders, and the resistance of the Sales Team to selling this product in the future.

What is clear is that the lack of a Product Manager had a direct impact on the bottom line. Perhaps for a single textbook the expense wasn’t that much compared to the bottom line. But we sold over 200 textbooks. The example above was an extreme case; most ancillary products didn’t have issues as severe or expensive as this one. But with over 200 products and less than 1 Product Manager, there were definitely other similar issues.

We did learn from this incident and others like it, and Product Managers were hired and Product Management methodology adopted. And our products got better!

Blog at WordPress.com.