How important is it for a product manager to have deep domain expertise? Marty Cagan (founder of Silicon Valley Product Group and author of several touchstone books on product management has weighed in on this question:

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.

He wrote that two decades ago however, and my sense is that a shift has taken place since then. Based on what I’ve seen in job descriptions and postings in recent years, and what I’ve heard from hiring managers and executives, more companies these days are looking for domain expertise when hiring PMs. One COO told me recently he is looking for “a unicorn,” someone who has both deep domain expertise and strong product management skills, because who wouldn’t want that? With all the recent layoffs, maybe it’s a good time to look for unicorns, but in any case, he usefully highlights a distinction between knowledge and skills that I want to focus on.

Domain Expert or Practice Expert?

Imagine you own an Italian restaurant, and you need to hire a cook. You haven’t found a unicorn yet, but you have two promising candidates for the job. One has managed Italian restaurants for ten years and has a deep understanding of Italian cuisine and culture. He has helped out in kitchens but has never worked as a cook. The other candidate has worked as a cook for ten years in various restaurants, though none served Italian food. The first candidate is a domain expert, and the second is a practice expert with professional kitchen skills. Which is more important? Personally, I’d hire the cook, because so many of a cook’s skills are only learned through doing and are transferable to any cuisine. There are domain-specific things he will need to learn, but he should be able to gather a lot from his coworkers and other sources more easily than he could gather knife skills, or the ability to sense when his skillet is at the right temperature, or to know when to fire a steak so that it’s cooked perfectly and in sync with the gnocchi. Again, those kinds of things are only learned through practice (and often from mistakes).

I think it’s mostly the same with product management. There are of course many situations when domain knowledge is essential, but in a typical organization there are already plenty of domain experts, and one of the main skills of a PM is discovery—the ability to draw on those domain experts and synthesize their expertise into an actionable plan. Discovery is its own skillset, and one that a domain expert might lack. Any true product manager will know how to run a discovery effort, and a non-domain-expert will also bring a beginner’s mindset with fewer preconceptions about the domain. They will approach the work with curiosity and humility. It’s true that a domain expert might not need to do as much discovery work as a non-expert, which can be more efficient, but then they (and the organization) might miss out on some… useful discoveries! Do you want to be just another good Italian restaurant, or do you want to build something truly groundbreaking and special?

Discovery is just one example. There are many more PM skills that apply across domains. I mentioned “synthesis” and “actionable plan.” Those unpack into various important domain-agnostic PM skills, along with others:

• Prioritizing work: This includes macro prioritization (road maps) as well as the regular work of backlog grooming, sprint planning, and continually weighing the relative costs and benefits of new features, fixes, infrastructure and hardening, etc. 
• Writing requirements: This requires an understanding of how systems work, how their components interrelate, and how stuff gets built, plus awareness of edge cases, etc. It is an art and a science to write requirements thoroughly and with testable success criteria. It helps to have frameworks like JTBD and RICE in your toolbox.
• UI / UX and Product Sense: Years of experience seeing what worked and what failed instills a good product manager with an intuitive sense of what a quality product looks like, which helps avoid mistakes and dead ends.
• Software Development Lifecycle (SDLC): Knowing how the sausage is made enables a PM to sequence work in ways to mitigate risks and optimize for learning. A good PM is able to partner effectively with engineers, to negotiate the tensions between building fast versus building right, and navigate tradeoffs in the triangle of scope, time, and resources.
• Stakeholder management: PMs operate in the spaces between different groups and teams—e.g. between the product and users, and between designers, execs, and engineers. A PM’s success depends on being able to manage all those different interests and priorities and produce something like harmony.

Much has been written about each of those. They are domain-agnostic skills, and you can only get good at them by practicing. There are other PM skills where domain expertise does play a big part, but even these are honed through PM experience as much as by deepening domain knowledge:

• Understanding customers and users
• Defining goals and objectives (possibly using a framework like OKRs or SMART goals)
• Navigating unique domain constraints and opportunities (e.g. regulation and compliance issues)

When domain expertise matters

In today’s environment where it seems like companies really want domain expertise in their product managers, I’ll admit I’m making a pitch for PMs like me, domain generalists who are practice experts. It’s personal, but research validates me on this. In his book, Range: Why Generalists Triumph in a Specialized World, David Epstein makes the argument that:

…in most fields—especially those that are complex and unpredictable—generalists, not specialists, are primed to excel. Generalists often find their path late, and they juggle many interests rather than focusing on one. They’re also more creative, more agile, and able to make connections their more specialized peers can’t see.

That said, there are situations where domain knowledge is non-negotiable—technical PMs often, and PMs who work on highly specialized and niche products like medical devices or aviation. There are other situations where domain expertise would seem highly desirable, like when you want to branch out into an entirely new product line or make a big pivot. But even then, domain knowledge is a kind of guidepost. It informs prioritization and requirements, but it doesn’t broadly or deeply impact the day-to-day work of product management.

A PM needs access to domain experts but doesn’t need to be one. If there is no shortage of domain expertise in your organization, then consider whether you really need it in new product managers. Instead of adding more of what you already have, prioritize what you actually need, so that you can build something truly exceptional.