The idea that one can be an expert of process and contribute something worthwhile in any domain is a key foundation of the management consultancy industry. After all, how can the likes of McKinsey, Boston and Bain make such huge salaries in just one industry? Once they’ve messed up two or three soft drinks firms and taken them for a $10m ride, they need to move on to pastures new. So appearing to be an expert, without the inconvenience of actually acquiring the domain knowledge, is vital to their survival.
Stewart recalls receiving advice from his mentor during his early days in consultancy: “As Luigi helpfully pointed out to me one day, when a consultant reboots his computer, he becomes an expert in information technology. If he bought the computer himself, he is a technology sourcing guru. And if he takes it with him on a flight, he becomes an authority on the aviation industry.”[i]
Stewart reports that Richard Rumelt, professor of strategy at UCLA, quipped “If you know how to design a great motorcycle engine, I can teach you all you need to know about strategy in a few days. If you have a Ph.D in strategy, years of labor are unlikely to give you the ability to design great new motorcycle engines.”
Of course, the answer is that we need Product Managers who have deep domain knowledge, technical understanding and great PM skills. If you are in a niche market there may be very few people with all of these characteristics, maybe none (if the few PMs in that market are self-taught). So how do you choose? Here are some ‘pros’ and ‘cons’ to consider.
| Pros | Cons | |
| Expert in technology | Can see where technology is going
Imagines technical solutions to tough problems |
Sees a technical solution when there may be a simpler alternative
May hear only technical issues rather than wider customer needs |
| Expert in the field | Deep understanding of workflow
Knowledge of competitive products Knowledge of standards Lots of contacts |
Can be firmly fixed in the status quo of “the way things are done” and may find it hard to ask the naive questions and conceive of disruptive products |
| Expert in the process | Understands key issues of each stage of the product process
Knows how to uncover user needs Used to negotiating priorities and resources Can take a fresh look at habitual solutions |
Could follow process into a product dead-end which experts in field of technology might avoid
Might miss the significance of key technology or market news |
I believe a vital skill of a good Product Manager is the ability to listen with an open mind, and learn. That skill, coupled with an enquiring and intelligent mind, will help them through a lack of knowledge in a particular industry or technology. Similarly, that mind could certainly acquire expertise in the process given the right resources or mentoring.
Ultimately we have to make sure that our product teams have all of these issues covered adequately. That might be one super-PM, or more likely it could be two or more people who can cover it between them. If we include engineers and product designers in this team then we have the chance of making a smooth transition from need in a market to technology, design, and to an innovative product which delivers functionality which satisfies those needs.
So, hire the best possible PM you can, then make sure that the product team covers all the bases.
[i] Stewart, M. “The Management Myth”, W. W. Norton & Co. 2009
How important is domain knowledge for a Product Manager? This is something that is effectively addressed by Communities of Practice. By self-directing the tacit knowledge management with an organization, PMs can come together in a CoP to identify, codify, refine and share the domain knowledge. By managing this knowledge at the appropriate level of complexity and quantity, PMs will be able to leverage the domain knowledge necessary to execute organizational strategy and become better Product Managers.
More here http://redcanary.mypublicsquare.com/view/ryma-launches
Cheers,
Justin T. Smith
Thanks Justin, I’ll take a look.
Chris
How important is domain knowledge for a Product Manager? This is something that is effectively addressed by Communities of Practice. By self-directing the tacit knowledge management with an organization, PMs can come together in a CoP to identify, codify, refine and share the domain knowledge. By managing this knowledge at the appropriate level of complexity and quantity, PMs will be able to leverage the domain knowledge necessary to execute organizational strategy and become better Product Managers.
More here http://redcanary.mypublicsquare.com/view/ryma-launches
Cheers,
Justin T. Smith
Thanks Justin, I’ll take a look.
Chris
This is an ongoing discussion. I wrote this last year .)
I still stand by my answer – you cannont teach everyone the product management/product marketing skills that are needed; but, you can learn about the industry, whatever it is.
Yes, it would be embarassing to send a new PM into the field and have s/he ask how to spell a competitors’ name and/or product; but, it is equally embarassing to have a motorcycle “expert” speak with a market crowd of newbies who don’t know the clutch from the brake and he/she deems them an unworthy market.
I think the answer lies in understanding your market, and serving their needs in the way they need to be served. If it is a very specialized market/industry/product, then maybe there needs to be a collaborative approach to outward facing activities; conversely, if the topic is one that is/has been easily grasped for discussion, perhaps it is more about the individual capabilites and not a general statement or policy direction.
I think we as a professional field don’t help our own credibility when we continue to behave that way.
This is an ongoing discussion. I wrote this last year .)
I still stand by my answer – you cannont teach everyone the product management/product marketing skills that are needed; but, you can learn about the industry, whatever it is.
Yes, it would be embarassing to send a new PM into the field and have s/he ask how to spell a competitors’ name and/or product; but, it is equally embarassing to have a motorcycle “expert” speak with a market crowd of newbies who don’t know the clutch from the brake and he/she deems them an unworthy market.
I think the answer lies in understanding your market, and serving their needs in the way they need to be served. If it is a very specialized market/industry/product, then maybe there needs to be a collaborative approach to outward facing activities; conversely, if the topic is one that is/has been easily grasped for discussion, perhaps it is more about the individual capabilites and not a general statement or policy direction.
I think we as a professional field don’t help our own credibility when we continue to behave that way.
Thanks Jennifer, I’ll certainly buy “I think the answer lies in understanding your market”.
One of the “refreshing” things about working with small tech companies is that they face each issue as though they are the first to face it, ever. Then they try to solve it from first principles. That’s how they solve their other problems, right?
Enjoy!
I once took a consulting job working directly for a product manager in a company that was private venture capital funded. This is a pump and dump deal. That’s what private venture capital funds do. They hit one out of the park, and then sell the company to the highest paying sucker. The company had a brand, but wasn’t first in its category back in the day, so they were M&Aed again and again. Having a brand means that that name recognition goes a long way to hitting one out of the ball park. They invested in the existing valuation of the not yet forgotten brand.
The category was post-commoditization, and living through its second generation of the hype cycle.
I did some research in books like “xxx for Idiots.” Author pointed out that this particularly component of the product offer always sucked. Well, that was my part of the product offer, and no this time it wasn’t going to suck.
The product manager had domain knowledge. He had been in the category for years now. He told me what he wanted at the micro level, omitting the macro level considerations. Hell, he wasn’t me, so what did he know about those macro level considerations. He did tell me he fired my predecessor, so I had been warned. Pay attention to such warnings. Don’t take such jobs. But, I did. Somebody shoot me.
It turned out that this product manger was too heads down to tell me what he wanted. He assumed. Frankly, he wanted “sucky.” But, those of us who do this for a living know what sucky is are trained to deliver otherwise. He’d say “On, I don’t like that.” What? Should I hire a beautician? And, “Get rid of that,” but through a third party, rather than stick his head up over the cube, so we could discuss the matter. He assumed a lot.
When it was over, the VP of Design loved it. Product Manager hated it. Product Manager prevailed. Back to sucky. Such is the sin of domain knowledge, or what some might call domain knowledge. Hell, the customers were no longer category geeks. The customers were normal people, people that the product manager with domain knowledge might never meet even if they are standing three feet away. Geeks talk to Geeks. Product managers talk to geeks as well, particularly when they are trapped in the past and think that the Geek is the customer. The technology adoption lifecycle serves up a series of independent market populations that are unlike the earlier ones, so knowing the early populations is of little help. Domain knowledge in a product manager works if that product manager will be serving the exact same customers as those of their experience, otherwise, domain knowledge is a mistake as a hiring consideration.
As luck would have it, this company actually was going to interview me as a product manager, but I already had this consulting gig. They wanted me to handle technical evangelism. I worried that they might want me to have a P&L at the same time. Not good. Geeks are not a market, a for dollars market. Seats sure, but dollars no. I skipped that interview. Dah!
Anyway, I’ve seen domain knowledge blow up in people’s faces.
Great comment, thanks so much David! That’s a great story, I was really feeling for you when I was reading through it.
I think you’ve put your finger on the risk of domain knowledge, but is that exclusive? What about me and you? We’ve built up domain knowledge, right? So does that mean we have to cross off industries one at a time and hope we get to retirement before the end of the list?
Hell, no. We can do both!
It is the folks who’ve built up the domain knowledge without finding out anything about what drives product management. They are the liabilities.
All the best,
Chris
Chris, the way to deal with the problem of domain knowledge is to realize that you, as a product manager cannot rely on it, and to realize that a product in a different technology adoption lifecycle phase is in a different place than you might have been. If that product manager would have communicated, been responsive to requests for feedback, and was open to learning, things would have turned out differently. But, that would have required a more proactive perspective, which takes much effort.
I’ve often tweeted the need to see heads down reactivity as a bug in the product management process. As such, when we get reactive, we need to realize that we’ve taken the eyes off the field by focusing on the ball. We need to fix our processes, so we can keep our eyes on the field, the team, the goal. The ball will get to the right place if we lead, rather than do.
I once took a consulting job working directly for a product manager in a company that was private venture capital funded. This is a pump and dump deal. That’s what private venture capital funds do. They hit one out of the park, and then sell the company to the highest paying sucker. The company had a brand, but wasn’t first in its category back in the day, so they were M&Aed again and again. Having a brand means that that name recognition goes a long way to hitting one out of the ball park. They invested in the existing valuation of the not yet forgotten brand.
The category was post-commoditization, and living through its second generation of the hype cycle.
I did some research in books like “xxx for Idiots.” Author pointed out that this particularly component of the product offer always sucked. Well, that was my part of the product offer, and no this time it wasn’t going to suck.
The product manager had domain knowledge. He had been in the category for years now. He told me what he wanted at the micro level, omitting the macro level considerations. Hell, he wasn’t me, so what did he know about those macro level considerations. He did tell me he fired my predecessor, so I had been warned. Pay attention to such warnings. Don’t take such jobs. But, I did. Somebody shoot me.
It turned out that this product manger was too heads down to tell me what he wanted. He assumed. Frankly, he wanted “sucky.” But, those of us who do this for a living know what sucky is are trained to deliver otherwise. He’d say “On, I don’t like that.” What? Should I hire a beautician? And, “Get rid of that,” but through a third party, rather than stick his head up over the cube, so we could discuss the matter. He assumed a lot.
When it was over, the VP of Design loved it. Product Manager hated it. Product Manager prevailed. Back to sucky. Such is the sin of domain knowledge, or what some might call domain knowledge. Hell, the customers were no longer category geeks. The customers were normal people, people that the product manager with domain knowledge might never meet even if they are standing three feet away. Geeks talk to Geeks. Product managers talk to geeks as well, particularly when they are trapped in the past and think that the Geek is the customer. The technology adoption lifecycle serves up a series of independent market populations that are unlike the earlier ones, so knowing the early populations is of little help. Domain knowledge in a product manager works if that product manager will be serving the exact same customers as those of their experience, otherwise, domain knowledge is a mistake as a hiring consideration.
As luck would have it, this company actually was going to interview me as a product manager, but I already had this consulting gig. They wanted me to handle technical evangelism. I worried that they might want me to have a P&L at the same time. Not good. Geeks are not a market, a for dollars market. Seats sure, but dollars no. I skipped that interview. Dah!
Anyway, I’ve seen domain knowledge blow up in people’s faces.
Great comment, thanks so much David! That’s a great story, I was really feeling for you when I was reading through it.
I think you’ve put your finger on the risk of domain knowledge, but is that exclusive? What about me and you? We’ve built up domain knowledge, right? So does that mean we have to cross off industries one at a time and hope we get to retirement before the end of the list?
Hell, no. We can do both!
It is the folks who’ve built up the domain knowledge without finding out anything about what drives product management. They are the liabilities.
All the best,
Chris
Chris, the way to deal with the problem of domain knowledge is to realize that you, as a product manager cannot rely on it, and to realize that a product in a different technology adoption lifecycle phase is in a different place than you might have been. If that product manager would have communicated, been responsive to requests for feedback, and was open to learning, things would have turned out differently. But, that would have required a more proactive perspective, which takes much effort.
I’ve often tweeted the need to see heads down reactivity as a bug in the product management process. As such, when we get reactive, we need to realize that we’ve taken the eyes off the field by focusing on the ball. We need to fix our processes, so we can keep our eyes on the field, the team, the goal. The ball will get to the right place if we lead, rather than do.
“He told me what he wanted at the micro level, omitting the macro level considerations.”
Interesting comment David – this sums up one of the biggest problems in product management that I’ve seen – the ability to move between different levels of abstraction and aggregation. Detail is easy to get your hands on, but connecting it to the big picture is another story altogether.
Perhaps you could develop a PM “bomb suit” to help diagnose and diffuse domain knowledge land mines?
Thanks for the comment Justin.
Love the idea of the “PM “bomb suit” to help diagnose and diffuse domain knowledge land mines” – how else do you challenge decades of “how it works in this industry”, whilst the likes of us are thinking “yep, it was in the days of the dinosaurs, and you’re one…”
Many thanks,
Chris
“He told me what he wanted at the micro level, omitting the macro level considerations.”
Interesting comment David – this sums up one of the biggest problems in product management that I’ve seen – the ability to move between different levels of abstraction and aggregation. Detail is easy to get your hands on, but connecting it to the big picture is another story altogether.
Perhaps you could develop a PM “bomb suit” to help diagnose and diffuse domain knowledge land mines?
Thanks for the comment Justin.
Love the idea of the “PM “bomb suit” to help diagnose and diffuse domain knowledge land mines” – how else do you challenge decades of “how it works in this industry”, whilst the likes of us are thinking “yep, it was in the days of the dinosaurs, and you’re one…”
Many thanks,
Chris