svpg
FREE newsletter

Subscribe via RSS

Subscribe

Tag Cloud

product management product discovery management company culture product portfolio planning product owner product development process product strategy product manager product marketing user experience design great products innovation marketing agile scrum project management user testing engineering prototype testing

Browse by Date

  • January 2012
  • December 2011
  • October 2011
  • August 2011
  • July 2011
  • June 2011
  • May 2011
  • April 2011
  • March 2011
  • February 2011
  • January 2011
  • December 2010
  • November 2010
  • October 2010
  • September 2010
  • August 2010
  • July 2010
  • June 2010
  • May 2010
  • April 2010
  • March 2010
  • February 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009
  • December 2008
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • November 2007
  • October 2007
  • September 2007
  • August 2007
  • July 2007
  • June 2007
  • May 2007
  • April 2007
  • March 2007
  • February 2007
  • January 2007
  • December 2006
  • November 2006
  • October 2006
  • September 2006
  • August 2006
  • July 2006
  • June 2006
  • May 2006
  • April 2006
  • March 2006
  • February 2006
  • January 2006
  • December 2005
  • November 2005
  • October 2005
  • September 2005
  • August 2005
  • July 2005
  • June 2005
  • May 2005
  • April 2005
  • March 2005
  • February 2005
  • January 2005
  • HOME
  • Services
    • Product Management
    • Product Marketing
    • Technology
    • User Experience
    • Public Workshops
  • Articles
    • Index
    • Blog
  • Clients
  • Resources
  • Company
    • Team
    • Manifesto
    • Contact Us

The Role of Domain Experience

Posted by Marty Cagan on March 28, 2005

Tags: domain experience, product management

This week a friend called to ask my opinion of a product management leader - I'll call him David - whom I've worked with in the past. The hiring manager is an exec at a large consumer internet services company. He really liked David, but his question to me was: "He's clearly an expert at Enterprise Software, but could he succeed at our type of business?"

I had to laugh, and I went on to explain that just over four years ago I got a similar call about David. His future manager was telling me that "clearly the guy was great at Infrastructure Software, but could he handle Enterprise Software?"

In truth, David is not an Infrastructure guy, or an Enterprise guy, or a Consumer Services guy. His education wasn't even in technology - he studied Finance. He is, however, a very smart guy, and one of the best product managers I know. One of the things that David does extremely well is that he can tackle new domains and new technologies very quickly, and this has allowed him to excel with several very different types of products.

I'm often asked about the need for applicable domain expertise for product managers. Many product managers, in fact, are hired exclusively for their domain experience. I do think there are a few products where domain expertise is truly essential - if I ever need a defibrillator one day, I hope there was a product manager that knew something about cardiac care. But in my experience, this is by far the exception rather than the rule.

I'll even go further. It can be dangerous for a product manager to have too much domain expertise. I say that because people that have spent a long time building their mastery of one domain often fall into another common product management trap - they believe that they can speak for the target customer, and that they are more like their target customer than they really are. The product manager needs to constantly revisit assumptions about the domain and the customers. It's not impossible for people with deep domain expertise to do this, but they have to work harder at it.

This is not to say that you don't need domain expertise in order to do a good job with your product - in fact I think understanding your product domain is absolutely essential. And I don’t mean superficial knowledge either. But I believe that strong product managers can come up to speed on most new product domains very quickly if they approach the education process aggressively. I've learned that it generally takes me 1-3 months to come up to speed on a domain I haven't worked on before, to the point where I feel confident charting a product strategy. Some people can probably learn faster, and others might take a little longer.

I also believe that there are some different skills required for leading enterprise products, versus infrastructure, versus consumer services versus consumer electronics. For example, if your product is sold to a relatively small number of large enterprises (as opposed to hundreds of thousands or millions of consumers), then there are some different techniques used to understand requirements and try out product ideas. It is also important to understand the different types of sales and distribution channels because these impact the product as well. If hardware is involved, you need to understand the process and timeline differences. For large scale consumer services, the issues of scale and community management can destroy you if you don’t know how to manage them.

But overall, I consider about 80% of the skills and talents of a product manager to be applicable across the different types of products. (My white paper "Behind Every Great Product" goes into considerable detail on the common requirements for a strong product manager).

This is also not a statement against the value of experience in general, but the most valuable experience is not what you learn about some product domain or technology that is probably obsolete now anyway, but rather what you've learned about the process of creating great products, leading a product team, managing growth, and what you've learned about yourself and how to improve the next time.

Very related to domain expertise is the topic of technology expertise. This used to come up more frequently than it does now, but I still hear it. I saw a description the other day for a product manager for an enterprise application company looking for direct experience creating Linux-based products. While it's true that there are some important differences between operating systems, if the product manager can't very quickly grok the important points as it impacts his product then this person has much greater issues than just lacking Linux expertise.

With technology, it's all about how quickly you can learn new technologies, and most importantly, envision how you can apply the new technology to the problems you are trying to solve.

Technologies change so fast that product managers must be skilled at quickly learning new technologies and solving problems in new domains. When I interview prospective product managers, I'm looking not to see exactly what they already know, but for each of their products, what did they need to learn, how long did it take them, and how did they apply that knowledge?


  • Product Management
  • Product Marketing
  • Technology
  • User Experience

© 2009 Silicon Valley Product Group. All rights reserved.