Ask Women in Product: Does domain expertise really matter?

Kate Griggs and Tanya Elkins share their thoughts on this week’s question: Does domain expertise really matter? If you’re a PM at, say, Linkedin or Slack, would you consider hiring a PM from the airline industry?

Image by Jordan Y. Jackson at Twenty20

Answer from Tanya Elkins, Product Management Executive

As a hiring manager, I know that I’ll need to invest in any new person I bring to the team. The only question is: what proportion of that time will I spend transferring my knowledge of the customer and the domain as opposed to teaching my new hire how to carry out the job duties of a product manager?

It’s a risky proposition to hold out for the “unicorn hire” — that rare person who knows your industry, understands your customers’ business problems, and is proficient in Product Management disciplines.

The answer to that question depends largely on the seniority level of my hire and my industry. For most industries and most companies, domain experience is preferred for individual contributors in product manager and senior product manager roles, but it’s a criterion that is not frequently met. Hiring managers know they will likely need to coach and mentor a new product team member for several months to transfer domain knowledge, and they should have a comprehensive onboarding plan for doing so. For director-level hires, domain experience is even more valued and yet usually still hard to find on the open market. In fact, director-level hires are more often nationwide searches conducted by two or more recruiting resources.

Due to the difficulty of finding domain expertise, it’s a risky proposition to hold out for the “unicorn hire” — that rare person who knows your industry, understands your customers’ business problems, and possesses proficiency in the PM disciplines. For this reason, I’m an advocate for prioritizing product management qualifications and other criteria over domain expertise, in most cases.

A hiring manager can use dozens of criteria to score and assess candidates. The four broad categories described below are the ones that I consider noteworthy.

  • Product Management Experience. Product management is a wildly diverse business function and career path, which is why it’s not a two-years-for-the-resume kind of job. PMs have a decision-making role that touches just about everything in a company, and mastering all aspects of it requires several years of relevant experience. Every two years, you can expect to learn about 15% of the product function, and since your business, customer, industry, and technology are changing the entire time, you’ll only use about 80% of that learning to move forward. For example, you could have invested time performing market analysis, learned how to build a credible and realistic roadmap, and established best practices for requirements gathering when, all of a sudden, your team decides to move into agile. Unexpectedly, you’ll now have to spend the next six months figuring out the user story conventions or migrate to a new requirements management system while at the same time strengthening your strategic muscles in product ROI or pricing. In my book, any candidate whose resume shows a breadth and depth of product management experience will always be worthy of consideration.
  • Fit. Fit with the team and fit with the customer are important. You can assess how well a candidate will fit your needs by including representatives of the core team in the hiring process. You can determine how applicable a candidate’s job history is by evaluating the depth of customer interaction that the candidate has had in prior roles and comparing it to the type of customer interactions she will need to have in the role you are hiring for. A less-than-perfect fit is not a show-stopper if the candidate can demonstrate learning agility and will adapt quickly to a new customer engagement model.
  • Unique Contributions. What does the candidate bring to the team that’s unique? Even in a team where there are multiple people in each role — with product owners and product managers at varying levels of experience and seniority — I still want the new hire to bring something new or different that’s beneficial to the team so that the team as a whole makes some gains. Knowing you have something to learn from your new co-worker from the get-go creates a positive dynamic in the relationship compared to seeing the new hire as a drain on the team’s capacity while he or she is onboarding. And let’s face it, especially when the domain is specific, the onboarding process can be rather lengthy and involved, requiring contributions by the entire team to give the padawan learner the exposure and assignments that allow her to grow her competency, productivity, and autonomy at the appropriate time. Having a unique contribution that results in a “quick win” sets the new hire up for success on an inter-personal and intra-personal level that is hard to quantify yet easy to celebrate.
  • Domain. Industry knowledge is generally the least important factor in the decision to bring on any new team member provided that the candidate is strong in the three preceding criteria. The hiring manager determines how much time will need to be invested in the candidate’s growth in domain experience based on: (a) the likelihood that the new hire will be in their position for at least 2–3 years, and (b) the new hire’s potential for further advancement.

A cursory survey of over a dozen open job postings for Senior Product Managers (see Figure 1 below) shows that hiring managers are willing to de-prioritize domain experience when other strengths are present. Other than positions in the banking industry, no other Senior PM roles required or even “strongly preferred” specific domain experience.

Figure 1. Only Senior PM roles in banking strongly preferred domain expertise in a cursory survey of over a dozen current job postings

Lastly, it is well-understood that with all else being equal, the candidate with the deeper domain experience will likely prevail. However, the reality is that hiring managers will rarely suffer from the problem of needing to break a tie between a candidate with three years of experience and a candidate with five years experience in their industry or domain of interest. Far more often, a tie between two candidates is broken by considering the breadth and depth of their overall product experience, the contributions they’ll be bringing to the team, their culture fit and mindset, or some combination of these three factors. Because at the end of the day, all else is rarely equal when we consider the complexity of the product management role and its significant contributions to the organization’s performance.


Answer from Kate Griggs, Product Manager at Pivotal Labs

Hiring managers who seek only candidates with specific industry chops are missing out on the diamonds in the rough. Sure, it may take a bit longer for, say, a retail-savvy Product Manager to master the intricacies of the hospitality industry, but a PM’s current domain experience shouldn’t pigeon-hole them in one industry for life!

Job seekers should describe their work experience in a way that highlights their value beyond their current industry.

It’s not the industry experience that matters; it’s the experience itself.

When we talk about great product managers, we don’t typically focus on their industry expertise. Instead, we talk about how they achieved success. We talk about how they studied a problem space and moved towards a solution. We talk about failures and course corrections. We talk about how they measured and evolved that solution to be successful. We talk about how they adjusted and adapted their strategies as new data became available. In short, we talk about their experiences and what they have learned from them.

Frame your experiences in a way that extends beyond the industry.

Job seekers should describe their work experience in a way that highlights their value beyond their current industry. For example, consider the Airline industry and a hypothetical product manager who has worked on an In-Flight Beverages app:

“Our passengers complained about long delays between takeoff and receiving complimentary in-flight beverages, so we built a seatback screen app to let them pre-select their beverage choice upon seat arrival. We created a separate mobile interface that guides flight attendants to prepare and serve drinks quickly based on seat locations. We were able to reduce wait times by an average of 10 minutes, and our social listeners picked up multiple satisfied comments related to the experience.”

If I’m a hiring manager at another airline, I could ask about the flight routes that were tested. I could compare the seatback application devices used against the ones we have. I could even ask about the passenger survey methods that were used to get around common traveler privacy regulations and the like.

But if I’m a hiring manager in another industry, these are the key concepts I would be interested in:

  • How did you gather information about passenger needs? What tools and methods did you use? I want to know how you might communicate with and listen to our customers.
  • How did you determine the need for multiple user experiences? How did you go about determining the key outcomes to be designed? I want to know how you might understand and connect our varying user personas. I want to get a feel for how you’d prioritize new features.
  • What usability tests or assumptions did you validate along the way? Were there any pivots in direction? If yes, when and why did they came up? I want to know that you’ll make smart, validated choices with our product, even if it means potentially rolling back newer ideas.
  • How did you define success metrics? How did you measure initial baselines and determined business impact? I want to know you’re accountable for the investments that the business will make in your work, and I want to know you’ll keep us informed of real progress instead of providing vanity analytics.

Learn about the new product or problem space, then apply your product experience to yield relevant insight.

Job seekers should do some initial research into the product space at the new company they’re interested in. Find functional similarities between those products, apps, and tools. Practice speaking as to how that relates to your products or apps or tools. During the interview, ask how the company tackled the areas you worked on, like how they measured success, how the interface evolved, etc. Show that you speak product language, even if you can’t fluently speak the industry-specific language yet.

Ultimately, all businesses with money to spend on new and evolving products have people to please: their business stakeholders, and their customers or users. No matter the industry, companies need experienced product managers who can take charge, take calculated risks, and take care of their people.

Be ready to talk about how you deliver value, and companies across the spectrum will jump at the chance to have you on their team.