have preferred to use a few lead developers and/or testers since they have the domain knowledge and technical expertise; however, we are reluctant to do this because of the impact on development resources. Therefore, I am hiring a few additional Product Owners from outside the company. I am finding that these people need to be technical, but also need to have good industry specific experience, and that is a difficult combination to find. So far, former developers/tech leads with business sense and good project management skills seem to be the best fit.
For example, one Product Owner we hired was a former developer/development manager with specific industry experience. Another was a very tech savvy developer/project manager who knew our technology, but was from outside our domain. This demonstrates that, in my view at least, technical skills are mandatory, and domain experience is a plus whenever I can get it."
BMC Software is a leading provider of IT Infrastructure Management Solutions. In 2006 and 2007, the Infrastructure Management Group (IMG) transformed their development organization (gt;100 practitioners) using agile development practices to deliver "a major product to the market in less time and with higher quality than previously possible" ( see BMC Case study ). Israel Gat, then VP of Infrastructure Management at BMC and now a Cutter Consortium consultant, led the transition. Recently, he described how they filled the Product Owner role (which they re-titled as "Requirements Architects") as follows:
"Between the product managers and the requirements architects we had enough "hands on deck". We must have needed half a dozen architects to become requirements architects, and we were able to generate them. We might have borrowed a little from the project leads, but the architects were our #1 pool. We did not borrow any from the project office."
When I pushed Israel on how he would envision a transition that involved 20-50 or more teams, he commented:
"A principle I would suggest generating 50 or 100 product owners must be done through apprenticeship (in addition, of course, to good training/consulting). If you accept this premise, you need to factor in a fair amount of time and grow the numbers gradually."
Other Thoughts on Larger Scale ISVs
When I was a VP at Rational Software, where we employed 900 or so software development types, we had a specialized role titled something like "Technical Marketing Specialist". This role was dedicated to working with the teams in defining and positioning the technical aspects of the solution to the marketplace. These individuals were typically collocated with the teams of their business units and they spent about half their time working with the teams in defining the solution and about half their time working with customers, training field engineers, etc. While this was a RUP, rather than agile shop, it occurs to me that the Technical Marketing Specialists were filling a role roughly equivalent to a Product Owner in agile. I mention this because I suspect that the Technical Marketing Specialist role, where it exists in the ISV today, could make a good role model for the Agile Product Owner in today's larger ISV.
Ryan Martens, founder and CTO of Rally Software and formerly a Product Manager at BEA, had similar thoughts when he commented on this topic:
"At BEA, we had a certain class of product managers called Technical Product Managers. They were exactly Product Owners."
Ryan went on to note that the title of "Program Manager" also performed a similar role in some larger scale contexts:
"After we acquired CrossGain, there was a tremendous amount of pressure to adopt the Microsoft titles of