Mar 2005
The Role of Domain Experience
03.28.05 Filed in: SVPG Blog
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?
Email to a friend
Sign up for the free newsletter here.
Famous Product Managers
03.11.05 Filed in: SVPG Blog
What do the following people all have in common?
- Marc Andreessen, co-founder of Netscape
- Jeff Bezos, founder of Amazon
- Steve Case, co-founder of AOL
- Michael Dell, founder of Dell
- Larry Ellison, co-founder of Oracle
- David Filo, co-founder of Yahoo!
- Bill Gates, co-founder of Microsoft
- Steve Jobs, co-founder of Apple
- Pierre Omidyar, founder of eBay
- Larry Page, co-founder of Google
- David Packard, co-founder of HP
- Fred Smith, founder of FedEx
In addition to being leaders of the most successful high-tech companies in the world, it turns out that they all share several other characteristics as well. Most importantly, all of them served as product manager (although the title they had was typically founder and/or CEO of their startup). But in fact these were the people that identified the product opportunity, established the product strategy, defined the product, inspired the product team, and championed the product’s use. In my book, that’s a product manager in the best sense of the term. In a few cases these people also helped build the initial product but mostly not.
Interestingly, none of these leaders went to business school, and several of them didn’t even finish college. But they all had an intimate understanding of an underserved market, a passion for finding a better solution, and a deep knowledge of emerging technologies and how they might be applied to their respective problems.
All of these product leaders possessed great empathy for the customer, insight into what was possible, and the ability to see what was essential and what was incidental. They had a deep understanding of the customer as well as their own team’s capabilities. They operated from a strong basis of knowledge and confidence. They defined products that could be executed with a strong effort.
I don’t believe that any of them would say they were “market-driven” in the sense that it is typically used today. They didn’t go out and gather customer requirements which then told them what to build. But they did, in a very real and meaningful sense, spend time with and get to know the people that would become their customers.
While none of them may have had an MBA, none were pure technologists either. Rather, these were very technology savvy people that saw how they could apply what they knew to solving real problems for real people.
I believe that there are many valuable lessons to be learned from studying these famous product managers. When I look at what they did to create the products that formed the basis of their companies, and then I look at what most companies do to create new products, the differences are striking and many.
For starters, most high-tech products today are created one of two ways. Either the team essentially builds what their customers tell them to, or they let their engineers “innovate,” and then the team productizes what they come up with. I’ve written elsewhere about these very common pitfalls (see www.svproduct.com/papers/toppmmistakes.pdf) but I think it's useful to contrast this with the approach of the product leaders above.
In future articles we’ll look at this and other fundamental differences between the most successful product managers and how most people practice product management.
Email to a friend
Sign up for the free newsletter here.