The term stakeholders is often used to categorize everyone that a team works with who is not explicitly a customer or a user of their product. There are a lot of different types of stakeholders that have different interactions with your team. One of the more important types of stakeholders is the Subject Matter Expert (SME). These are the people who know the most about your business process or your technical architecture.
SMEs may also be users depending on the nature of the product you are working on.
They are important people to interact with, especially if you’re working on an internal product because they are the ones who know the most about the business processes you’re building a product to support and the infrastructure on which you’re trying to build the product.
They can also be difficult people to work with. Because SMEs are by definition experts, they tend to be few and far between and subsequently are in high demand in your organization. This means that they may not always be as available as you might like. In addition, if a SME knows that they are in demand, they may view that as a form of job insurance and be more difficult to work with as a result.
But because they have all that expertise, you have to work with them. You could view it as a necessary evil, or an opportunity to build character. Whichever way you look at it, there’s certainly value in figuring out how to have a good working relationship with the SMEs in your organization. Here is a collection of information to help you work with SMEs, including:
- Who should be a SME?
- Challenges of working with SMEs
- Ways to work effectively with SMEs
- Techniques for working with SMEs
Who should be a SME?
When you’re trying to figure out who your SME(s) should be, look for people who are experts in the business process you’re supporting, the business rules you’re enforcing, or the infrastructure on which you’re building your product.
Be prepared to work with multiple subject matter experts. There probably won’t be one person that has sufficient knowledge about the entire business process. You’ll also find the people that are the experts in the rules and processes are not the same people who are experts in the technology.
You may find it’s helpful to have different perspectives in order to come up with the most effective solution. So in some cases you may need to have multiple experts covering the same subject matter, in which case you’ll need to have some concrete tools in place to discern all the input you get and determine the ultimate direction you take.
For a product I worked on recently, we had four SMEs – in addition to the product owner – that we worked with. Two of the SMEs were the people that used the product we were replacing. They usually provided specifics around the day-to-day aspects of their business process. We found that they had different areas of focus in the current product, and one had a better grasp on why they did the things they did.
We had another person who was SME on the broader business process and the business rules that were key the the product. They did not use the product any more, but relied on the outputs from their product to make significant business impactful decisions.
The fourth SME was the person who built the product we were replacing. They had some knowledge of the business process, primarily with respect to how it interacted with other systems and had in depth knowledge about how the current product worked. We ran into a lot of “oh and another thing” moments in our interactions with this SME – one of the potential downsides of iterative discovery. An interesting side note – this SME was a business analyst, which will play into the discussion below about whether product people should be SMEs.
Overall, my team was able to build up a good working relationship with this group of SMEs. I learned after some missteps that it was best to adopt a “trust but verify” approach to any information I got from this group. When I got information about rules from the two users, I would confirm that information with the business process SME. When I got information from the SME regarding how the existing product ran, I would always check against the actual code. And I always confirmed information I got with data from the current system and examples.
How do you find a SME?
When you start work on a project, the first place to look for SMEs is the business unit(s) that are currently use or will use the internal product you’re working on or replacing. If you’re working on a new payroll system, you’re going to end up talking to people that do payroll. If you’re working on a new website your SMEs will be the people that maintain and provide content for your website. If you’re building a new internal product to automate an existing process, your SMEs will be the people who do that business process manually today.
In some organizations, identifying SMEs is part of the work that is done to assess potential projects. If you work for an organization, chances are you are familiar with the key SMEs in different business units, or know who to ask for that type of information. If you’re coming from outside an organization for a specific project, you’ll need to rely on your main contact to help identify those people.
When you start out, Assume that the people identified as SMEs are in fact experts, and plan on confirming whether that is actually the case. Gauge their level of expertise and reliability through your initial discussions and examining confirmatory information. Your more day to day focused SMEs will give you lots of details, but may not be able to tie them together or explain why they do certain things. Your broader picture SMEs will have more insight into why you do things, but will not know the day to day specifics (though they will often claim that they do).
You are not always going to know who your SMEs should be right away. If you’re working on an entirely new internal product for a new process it may not be clear who the SMEs should be. You may not have clarity over who the SME should be for the overall process, but you may be able to identify SMEs for various aspects involved with the process.
Even if you are working on an existing internal product, you may not know who all your SMEs are. In either of these cases, having a discussion around a context diagram can be extremely helpful.
The context diagram is a model that shows how your product interacts with external agents (people, business units, other organizations, and/or systems). The context diagram helps you to identify the interfaces you need to account for, helps you to identify scope, identify potential stakeholders, and build a better understanding of the context in which you are working. From that understanding of stakeholders you can determine where SMEs may be helpful and what business units/organizations you need to contact to identify someone.
A key aspect of creating a context diagram is identifying the external agents that your product interacts with. Once you determine which external agents are relevant you can then identify the people who know the most about those external agents and can provide you with information about data that those external agents provide to your product, or can indicate what those external agents need from your product.
Should product people be a SME?
There’s a lot of discussion in the product community about whether product people need to be, or even should be, a SME. I’m not sure there is a clear cut answer.
My perspective is that product people do not need to be experts in the domain in which they are working, but they should be experts in being a product person. I have also found in the many products I’ve worked on by the time I’m done with a project I tend to be a SME on that particular product. So you don’t need to be a SME to start, but there may be something wrong if you’re not able to be (or viewed as) a SME once you’ve been working on the product for a while.
That’s my perspective. I thought I’d share some others so that you can form your own opinion.
Should business analysts be a SME?
When Marty Cagan shared his perspective on SMEs it was clear that he didn’t (and may still not) consider business analysts to be product people: “in some companies, there is another role that exists and it goes by various titles including Subject Matter Experts (SME), Domain Experts, and Business Analysts.” That stands to reason, since Marty comes from the perspective of software product companies where business analysts tend to serve a different function than they do in internal product situations.
Those in the business analysis community who main function in internal product context tend to see things differently. Neil Schiller for example believes that “a Business Analyst is not, to my mind, an SME – a Subject Matter Expert. Businesses already have them, they’re the people that do the jobs that make the organisation tick. If you think you need to bring a BA in to pick up the role these people play then you have a misunderstanding of what a BA is and, more importantly, you have serious problems within your business.”
And Adrian Reed described the “ongoing debate within the BA community over the level of industry (business domain) specific knowledge that a BA should be expected to have. Some organizations require their BAs to have extensive business domain knowledge, and will generally only recruit BAs who have worked in the same (or a very similar) industry. Others look for core analysis skills, and are happy to recruit BAs from completely different industries.”
Should product owners be a SME?
The question of whether product owners should be SMEs is exacerbated by how many organizations identify their product owners for internal products. It’s common for organizations in the midst of an agile transformation to identify someone from the business unit to be the product owner.
Those organizations typically pick one of two types of people from the business unit. The product owner may be a power user who has a great deal of subject matter expertise (that may be dated) and little real decision making authority. In other cases the product owner is someone in a leadership position that has decision making responsibility but little true subject matter expertise in the day to day aspects of the product and even less time to effectively interact with the team.
Neither situation is ideal.
Robbin Schuurman took a look at the Subject Matter Expert question in relation to product owners. His conclusion is that it can be both a blessing and a curse when a product owner takes a Subject Matter Expert stance. His concern is that a PO who is also the SME can tend to micro-manage and spoon feed the development team. “Although there’s nothing wrong with understanding the business processes really well as a Product Owner, you don’t have to be the expert!”
Should product managers be a SME?
You’ll see it commonly said that product managers should become experts in the customers and their needs. If that’s the case, it’s definitely a form of subject matter expertise.
Darren Duarte explores the value of subject matter expertise for product managers and one way to provide that expertise: two product managers working within one team. In this post, he explores the attributes of a Product Manager subject matter expert (SME) and a Product Manager Expert. These concepts are useful for any organisation wanting success in their teams, especially those with teams in their early stages.
Challenges of working with your SME
You’ve probably already discovered that SMEs are an essential part of any successful project. You’ve also probably experienced that working with SMEs is not always rainbows and unicorns. In fact it can often be quite the opposite.
Here are some challenges that you may run into when working with SMEs. If you are prepared to encounter these challenges, you may find your interactions with SMEs aren’t as painful as they could be.
The ideas in this section were adapted from Working With Subject Matter Experts: The Ultimate Guide by Christopher Pappas and applied to product development.
They are not part of your project team.
More often than not, SMEs are the people you need to work with to get information about the process, rules and infrastructure you’re working with. The better an expert they are, the more in demand they are because chances are your team is not the only team that’s looking to them for more information.
They also usually have another full time job that they are trying to do. That means you have to find ways to get the time you need with them and make the most of that time when you get. Several of the ideas listed in the Ways to work effectively with SMEs section gives you ideas to do that.
The Curse of Knowledge
They are such experts in the business process or rules that they’re talking about, they’ve forgotten more about the process than you will ever know, and they don’t realize that you don’t know all the things they do. That leads to assumptions what what you do know and they forget to mention key aspects of the process or extremely important rules.
To overcome the curse of knowledge, have multiple conversations with your SMEs and supplement what they tell you with other sources of information. When you do run into “oh and another thing” situations, make sure you dig deeper to understand whether that “and another thing” is still needed. In situations when you’re rebuilding an existing product the longer that product has been around the more features that may not be used anymore.
That’s how we’ve always done it
Another side of the curse of knowledge is that your SME may not be willing to see past “that’s how we’ve always done it” and fight changes to the process or implementing a new product. The SME may not be able to see new ways to solve existing problems, or even know why they do things today. You’ll especially get this from your tactical day to day SMEs.
Always seek to understand ask why they do things a certain way and get to the problem they really want to solve. I’ve had more than one occasion where I was rebuilding an existing internal product and the SMEs I’m working with ask for changes that attempt to remake the new product in the guise of the old product.
Try to understand why they want that change and understand what problem they’re trying to solve. You’ll often find a different way to address the problem or be able to show how the new product already takes care of that issue.
The Faux SME
You may find that some people who were suggested as SMEs, or are self proclaimed SMEs, really aren’t experts. When you determine that’s the case, it’s often best to identify alternative sources of information, whether that is other SME’s or documentation, code and existing data.
As to how much you continue to engage with the faux SME, you’ll have to assess that in relation to the political climate of your organization. Understanding where that particular person sits on the stakeholder map can help guide your decision.
If the faux SME was just someone who was identified but is not particularly interested, you can probably scale back your interaction with them. If the faux SME is self proclaimed as an expert, that’s probably a sign they have a lot of interest, so you’ll probably have to engage with them more, but the extent to which you engage probably depends on the amount of influence they have.
Ways to work effectively with your SME
Sure there are challenges in working with SMEs, but all hope is not lost. Here are some things to consider when you work with SMEs to make sure make the most out of your interactions.
These ideas are adaptated from The Complete Guide to Using Subject Matter Experts for Better Content Marketing by Angela Morris and Working With Subject Matter Experts: The Ultimate Guide by Christopher Pappas applied to a product development context.
Build a good relationship
Make sure you make it clear that you respect your SMEs knowledge and you appreciate any time that they can spend with you. Take some time when you first start working together to agree how you’ll interact and make it easy for them to work with you. Takes steps such that your SME looks at working with your team as something they get to do rather than something they have to do.
You are probably focused entirely on your product. Your SME has probably got several things going on at the same time. Make it easy for the SME to work with you by altering your approach to working to fit what works best for your SME.
Adjust to their schedule and location rather than expecting them to meld to yours. An exception to that is when getting out of the normal routine is a benefit for your SME.
One SME I worked with would get pulled in several different directions at once and longed for opportunities to get away from the office so that he could focus. My team was working remotely from the organization we were building the product for, so I invited the SME over to our office to meet and discuss some topics. I was able to get his undivided attention for a couple of hours and get a lot of information and make some key decisions.
Do your homework.
A key aspect of respecting your SME’s time is coming to your discussions prepared. Your SME will appreciate that you are not looking for them to tell you everything. Do some research before you talk with them, whether that’s on the industry as a whole or the specifics of the process you’re working with.
When I can explore supplementary information before I like to formulate questions or event put some information together and seek to confirm information I’ve already pulled together rather than asking for information cold. This signals to the SME that you do respect their time and it has typically caused them to prefer to work with me and my team rather than other teams that don’t do any preparatory work.
Doing your homework ahead of time helps you to be organized. It also helps you recognize when you may be getting incorrect information or it gives you background knowledge you can use to identify opportunities to dig deeper.
Build shared understanding.
To make sure your interactions with SMEs are as effective as possible, you want to make sure you are on the same page about what several things.
I’ve already mentioned establishing agreements about how you will work together. It’s also extremely helpful that you and your SME are trying to solve the same problem. Always assume that when you start working with a SME that you don’t have the same picture in your head about the problem you’re trying to solve.
Spend some time when you start working with the SME to establish a shared understanding of the problem to solve. If you’ve identified your key SMEs when you work with your team and stakeholders to establish your targeted outcomes, include those SMEs in that discussion.
Another way to maintain shared understanding is to use consistent terminology in your product and when talking about business process and business rules. When you establish those terms use language that is relevant for business folk, and keep a glossary to establish agreed upon terms and definitions.
Practice Active Listening
Active listening is one of those skills that not only helps you work with working with SMEs but it will help you with the rest of your professional and personal life.
Active listening is about being present when you’re talking to your SME. Do not run through your next question in your head while they are talking but focus all of your attention on what your SME is saying.
If something they say does not make sense, ask. Ask for clarification. Ask to understand.
Avoid distractions that may mean that you should take notes with a pen and notebook instead of your computer if you think you’ll get distracted by email or social media or all of those notifications that keep popping up on your screen. Better yet, take your notes on a whiteboard so that your SME can see what you’re writing and help clarify. You can also let the whiteboard sketches amplify your conversation.
When you practice active listening you’ll retain more information and you’ll reinforce your respect and appreciation for your SME.
Techniques for working with your SME
Your main reason for working with Subject Matter Experts (SMEs) is to elicit all of the knowledge they have about the processes you’re trying to support and the rules you need to enforce.
This is extremely relevant when you’re working on an internal product because often the processes and rules already exist and you need to figure out how to effectively support them.
Working with SMEs to understand those business processes and business rules can be a challenging endeavor. They know a great deal about the business process, but they can also suffer from the curse of knowledge. They can often assume other people know more than what they really do.
Here are some techniques that will help you elicit the information you need from your SMEs in order to develop a clear understanding of the problem you’re trying to solve and constraints on the solution you need to deliver.
Initial discovery for an internal product
Here’s a description of how a team I worked with performed initial discovery with SMEs to understand the outcome we we’re trying to achieve. Those activities resulted in a broad (but relatively thin) understanding of our solution and helped us organize our approach to doing deep dive on thin slices of the product as we move into an ongoing delivery/development cycle.
What Jobs to Be Done Teaches us about Interviews
While Jobs To Be Done (JTBD) mostly applies to products for external use, there is some applicability for working inside an organization. Particularly when it comes to conducting interviews. Here are four things to consider when interviewing stakeholders prior to working on an internal product.
Socratic questioning is another way to structure your conversations with SMEs that you can use to draw out answers. First establish a thesis of what your stakeholder thinks their need is (usually expressed as a solution). Then engage in a dialog structured as a series of questions in an attempt to refute or disprove the thesis and get to the actual need.
Collaborative modeling refers to the use of well-known requirements analysis and modeling techniques in a collaborative fashion to build and maintain a shared understanding of the problem space and the potential solution. These are great techniques to supplement your conversations with SMEs when trying to gain a clearer understanding of the problem you’re trying to solve and constraints on the solution.
What’s your experience with SMEs?
This post contains some things I’ve learned and found helpful when working with SMEs but I know that all of us are smarter than one of us.
I’d love to hear your experiences and epiphanies about working with SMEs. Leave your thoughts in the comments.
The following sources influenced the ideas in this guide, provide more information, and share some different perspectives around working with SMEs.
- Subject Matter Experts by Marty Cagan
- How Product-Pairing can grow the next generation of Product Managers by Darren Duarte
- The Subject Matter Expert (A Misunderstood Product Owner Stance) by Robbin Schuurman
- The Complete Guide to Using Subject Matter Experts for Better Content Marketing by Angela Morris
- Working With Subject Matter Experts: The Ultimate Guide by Christopher Pappas
- The Business Analyst and the Subject Matter Expert by Neil Schiller
- Business Analyst or Subject Matter Expert? By Adrian Reed