The Subject Matter Expert (A Misunderstood Product Owner Stance)

The Subject Matter Expert or SME is the expert in telling you how stuff works. Product Owners that favor this stance are a blessing and a curse. When you bring relevant domain knowledge to the Scrum Team, they can make more informed decisions and create a better plan to achieve (Sprint) Goals.

It can also lead to a single point of knowledge, and rather than taking the stance of the Story Writer and forgoing discussion, this stance manifests itself as micro-management and spoon-feeding the development team. In many organizations, it seems to be expected that the Product Owner is also the Subject Matter Expert.

The person with the most knowledge about the business processes and the nitty-gritty details. Although there's nothing wrong with understanding the business processes really well as a Product Owner, you don't have to be the expert!

A subject-matter expert ( SME) or domain expert is a person who is an authority in a particular area or topic. The term domain expert is frequently used in expert systems software development, and there the term always refers to the domain other than the software domain. A domain expert is a person with special knowledge or skills in a particular area of endeavour (e.g. an accountant is an expert in the domain of accountancy). The development of accounting software requires knowledge in two different domains: accounting and software. Some of the development workers may be experts in one domain and not the other.
— Wikipedia, Oktober 2019 -

The Subject Matter Expert is also referred to as the senior user, key user, process manager, domain expert or business expert.

With the many Product Owners and Product Managers we have trained and coached in their daily practice, we've observed the following patterns in Product Owners that we would classify as SMEs:

• The SME has the ability to specify work up to a great level of detail. Since SMEs are, like the term says, typically experts in their business, domain or technical field, they know all about all the tiny little details. Most of them aren't afraid to make sure that everybody knows.
  • One of the traps of having SME Product Owners is that they can talk about all the details for hours. It's not uncommon that meetings take way longer than expected and that all the tiny details were discussed, but nobody really understands the goals that we're working towards.
• The SMEquite frequently speaks phrases like: "You don't need to know that." or "I'll let you know about the next steps when we get there." It feels like the information they have is valuable, yet it is kept under close guard. Sometimes by design, sometimes by unawareness.
  • Knowledge is power, and in difficult times being the expert with a lot of knowledge can be perceived as job security. The SME, therefore, isn't necessarily in favor of knowledge sharing, they instead love spoon-feeding the Development Team with tiny pieces of the total picture, so that they are constantly being involved throughout the development effort.
• Another risky behavior that SMEsfrequently display, is to both be Product Owner and Development Team member. For example; being both Product Owner and Software/Enterprise Architect or being both Product Owner and Business Developer or maybe being both Customer Journey Expert and Product Owner.
  • There is obviously a risk in having multiple jobs and roles in the team; however, being the senior or expert on the team often reveals the pitfall of stepping in and doing it yourself.
  • It wouldn't be the first time that the senior Developer or Architect would rearrange the codebase overnight or during the weekend. Neither would it be a first-timer for a "Marketing Product Owner" to redesign the whole marketing campaign plans overnight...
• Other associated behaviors with the Subject Matter Expert type of Product Owner are: being the architect, being the technical (development) expert, being the test manager, being the senior (technical) person on the team who decides on all the details, being the (UX) designer, being a micromanager, distributing tasks amongst team members, reducing effort estimates by the Development Team.

Obviously, not all (Product Owner) SMEs are the same, and not all the results/effects may be visible in your context. That being said though, what we typically observe when Product Owners act like SMEs is:

• Focus on details, effects, and short term results.
• Little to none focus on long term outcomes (TCO, ROI, P&L, etc).
• Slowing the Scrum Team down.
• The Scrum Team isn't learning and obtaining more business, domain, customer and product knowledge, because they can always ask the Subject Matter Expert anyway... This prevents them from making better, faster and more informed decisions and herewith increases self-organization.
• Too much focus on the details, typically not limited to 'what' and 'why', but also including acceptance criteria, maybe designs/sketches, functional and or technical documentation, etc. This is too much detail for a Product Owner to write down;
• Typically SMEs have no vision and strategy in place, and/or aren't actively sharing the vision and strategy with the Scrum Team and its stakeholders.
• The Development Team isn't learning to be self-organizing their own work, they won't be taking ownership (over planning, results, quality, etc), because they're being spoon-fed by the SME.

Many people love to be an expert at something. From various different researches, such as done by Dan Pink, they learned that Mastery is actually a big motivator for people: People like to become very good at something.

So, that leaves us with the challenging question: What can you do to move away from the misunderstood Subject Matter Expert stance? Well, there are a couple of options, but none of them will be a quick fix though...

• The first thing you should do as an expert is to evaluate how much this expert status means to you. Some people love to be an expert, and there is nothing wrong with that! It offers a feeling of pride, achievement, and status. These are all relevant experiences and feelings for people to have, so, before you do anything; decide if you want to be seen the expert or not...
• If you want to be the expert, if you want to know all about all the details, then maybe it's better for you to join a Development Team? Development Teams need to be self-organizing and with an expert like yourself in the team, they can definitely make some huge steps in becoming more self-organizing as a team!
• Or if you don't want to be the expert (anymore), or you don't care about this status anymore, then you probably already know what to do right? Start sharing your knowledge, make sure the Development Team gets full access to your domain expertise brain and make them more self-organizing. Also, don't interfere with the details anymore.
  • If you want them to learn, allow them to make mistakes (safe and slightly controlled, don't let them blow up the business of course). Maybe you should create some documentation, sketches, processes pictures, etc.
  • Make sure that you transfer and share your knowledge with the team(s), but also to connect them with the 'new' expert (your successor expert), so that they can have a direct collaboration with the right people and all continue their learning and development journeys.

This is a blog from the Stances of the Product Owner series, in which Professional Scrum Product Owner Trainers and Consultants Chris Lukassen and Robbin Schuurman explore preferred and misunderstood stances (attitudes) of Product Owners and (Agile) Product Managers.

If you're a Product Owner, Product Manager, Scrum Master or Agile Coach with about a year (or more) of experience under your belt, go and explore the Stances of the Product Owner in the Professional Scrum Product Owner-Advanced class.

Find a trainer to your liking or in your area, and deepen and expand your Product Management knowledge and skills. And let us know what you think about the training! What did you like? What can be improved? Let's collaborate to take the profession of Product Ownership to the next level.