In any product initiative, there can be several important stakeholders. One of the most impactful, yet often overlooked, stakeholders is a subject matter expert (SME.)
In my experiences, I’ve leaned on a variety of SMEs for their expertise in everything, from creating a more natural product user experience to ensuring decisions are legally compliant. For a product manager with numerous responsibilities and a wide scope in their role, an SME can be an incredibly valuable resource in making the right calls.
In this article, we’ll review the types of subject matter experts, how they operate within an organization, and some of the best practices for working with SMEs to ensure success in your role.
A subject matter expert (SME) has a high level of domain expertise and, by definition, is an expert in that area.
An SME can provide guidance and valuable insights from discovery through launch and help ensure you’re making the right decisions. SMEs can help you avoid making domain-level mistakes and improve your overall outcomes.
At the start of a new initiative or at the beginning of the discovery process, think about what type of people could provide support to you with their domain expertise.
There are two different types of SMEs — internal domain expertise SMEs (aka internal SMEs) and external domain expertise SMEs (aka external SMEs):
Internal SMEs can be found across many teams within an organization — sometimes your greatest resources can be found in-house! Think of people across your organization that could provide valuable insights for your product needs.
In my role as a product manager, I worked on an initiative to build a text platform for recruiters and one of my most valuable SMEs was a member of our legal team. She provided resources and incredible support that helped me define the guidelines of our product’s functionality. She helped us craft our outreach language to be legally compliant and was key in determining our text authorization structure. Without her support, we could have been at risk of steep fines if any of the strict laws around text communication were broken.
Internal SMEs can be found anywhere in the organization such as within legal teams, HR, IT, tech/engineering, or finance to name a few.
Some organizations work with industry-focused external SMEs to gain a unique perspective and ensure they are moving in the right direction. External SMEs can be anyone outside of your organization with strong domain expertise that can add value to your product.
While not always the case, some SMEs can also be super users who have a strong understanding of the industry and domain expertise. Super users as external SMEs can provide early customer insights and support through testing.
Organizations can sometimes struggle with understanding how to work with SMEs, as well as where and when they can be involved in the process. When working with an external domain SME, you might have been introduced through a sales team member or need to be conscious of the history of an existing customer relationship.
In my experience, SMEs can be the most valuable when working closely with product management teams directly. Product teams can gain valuable insights about a business problem early on in the discovery process by working with SMEs. Depending on the type of SME, they can also become a partner to QA with test plan support and determine a user’s expected behavior.
SMEs can be essential in helping a product team make stronger decisions and often will directly lead to more impactful and innovative solutions.
Below is a list of examples of subject matter experts:
This question comes up a lot for debate with differing opinions. My take on the answer is sometimes yes in unique situations, but more often no.
By all means, product managers should know their customers, their industry focus, and have a firm grasp on the needs of the business. Some companies might expect all of their product managers to be SMEs, but it can be virtually impossible to be a subject matter expert across every domain. This becomes especially true with a product or team where the expertise needed can be quite large.
Asking a product manager to be an SME for all parts of the product is like asking someone to be a chef, mechanic, and chiropractor all at once. While this might sound like a dream Bumble date, this person doesn’t exist and you could actually end up with more of a Frankenstein — stretched too thin across numerous product needs. This is why identifying SMEs for specific domains can provide incredibly valuable support to the product team.
In one of my roles as a product manager, I worked on an applicant tracking system at a staffing company where I was focused on building an internal recruiter experience. As someone with a very non-linear career, I was able to use my own unique experience as a former recruiter for some of my product initiatives. I was very familiar with what it’s like to be a user, and I know a lot of the ins and outs of this industry.
However, as an SME-lite, I was actively conscious that my own experience could lead to biases or lack the fuller picture. As we learned from Ted Lasso, “Be curious, not judgmental.” I often worked with other SMEs from all across my organization and was always able to learn so much more from their experiences and domain expertise.
If you are in a position as a product manager where you can be an SME, be sure to avoid relying on your assumptions and test whenever possible:
Based on my experience, I’ve found three big reasons why it having a PM double as an SME can be risky:
CS and sales can often share essential information about customer needs and can become great advocates for the user. They can help you better understand the market, and the needs of future customers. While CS and sales can be very important stakeholders, they are often not the target user themselves and might not have the domain expertise you need.
In essence, you’re getting information secondhand when the customer might instead be a more valuable SME. To avoid a common pitfall, ask yourself if they are truly a subject matter expert in this domain or if they are representing a customer. Whenever possible, it’s always better to work directly with an SME rather than rely on information from a third party.
Think about who could help early in your discovery process. Early conversations can be very helpful and inform a root cause analysis to learn more about underlying problems.
Also, get support for the right introductions. Connect with people in your organization, like sales team members, who might be able to make introductions to someone who could be external SMEs.
It’s important to set expectations and be transparent about the level of involvement. Since not everyone is familiar with your product team and the process, discuss the level of investment from an SME and be cognizant of their comfort level in different activity types.
Some people work well in brainstorming sessions, while others might prefer to provide a document that outlines their perspective and advice. In my experience, I find one-on-one conversations to be really valuable. If applicable, ask your SME if they are open to usability testing or support with a launch later on.
Further, establish a regular check-in time. This can help you avoid over-communication with a potential internal SME, and set a regular cadence for those outside of your organization.
Unsurprisingly, good communication can save a lot of headaches. One big tip is to avoid getting too in the weeds. Ask broad questions to steer conversations to a higher level when you find your SME getting too hyper-focused on minor details.
Next, let SMEs speak for themselves. Share what you can about the long-term vision but be sure not to lead them in a specific direction. They are there to provide their perspective and insights, not parrot back your assumptions.
Prepare and be ready to veer off-course. It’s always helpful to have a set of topics and questions, but always expect to go in a different direction- especially early in the discovery process.
Finally, keep track of your findings. While working with SMEs, you’re on an information hunt and it’s important to document your findings throughout the process. As your process becomes more complex, you might need to recall information later in the process or want to follow up with other SMEs to confirm a topic point. This can be extremely important working with SMEs with legal or technical expertise.
Share your outcomes and successes! Your SMEs want to know how things go and be sure to share an update post-launch. If your SMEs were part of a new innovative product, be sure to give them credit for their support. If you’re working with an internal SME, give them a shout-out on any product update calls within the organization. With a little recognition, you might find more future internal SMEs.
After the fact, ask about future involvement. You might discover that some people love to work with product teams! Post-launch, check in with your SMEs to see if they are interested in continuing to work with you. This will make the discovery process a lot more smooth in the future.
Subject matter experts are people with extensive domain expertise that can provide valuable insights to your product team. Support your discovery by identifying both internal and external SMEs early in your process and setting expectations around their level of involvement. By including SMEs in your process, you can expand your knowledge of different domains, make stronger product decisions, and elevate your product’s chances of success.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Anish Chadda discusses the importance of having a “bias for action” — iterating quickly instead of focusing on creating a perfect prototype.
The dynamic system development method (DSDM) was first released in 1994 as a software development method to provide some discipline to RAD.
David Krell, VP of Product at Going, talks about the fallacy that PMs have to be in a position of authority to do vision-led work.
Think of product-led growth as a self-sufficient user experience that leads to business growth by providing value to your users.
Learn more →
