Product Owner Pitfalls — The Subject Matter Expert
Your Product Owner lives and breathes product Ypsilon. Ask a question and your PO has the answer. She not only knows the entire functionality but also a huge portion of the technical pieces. She is well aware of the strengths and weaknesses of Ypsilon. You may think having an all-knowing Product Owner is a perfect situation.
But is it always ideal? There are certainly potential issues for the team and the product they are building. In this article, I will discuss some of the pitfalls of a Subject Matter Expert Product Owner.
1. Assuming she always has the best answers
Someone else than the SME may know more about a facet of a product, whether it’s the source of a bug or usage of the product. The pitfall for the Product Owner SME is that she believes her views are still the best.
If the team believes the Product Owner has the best answers and doesn’t look further, they will not be open to alternative ideas. They will fail to look outside of the box and will not pay sufficient attention to additional information coming from others.
2. Lack of trust to let the Developers find the solution to a problem
Another pitfall for the SME is that she doesn’t trust others to find solutions to problems. Her solution is the only way. Alternatives from the other members of the Scrum Team are dismissed before even studying them.
In Scrum, the Developers are responsible to find out HOW to realise a specific goal. The Product Owner should focus on the WHAT instead.
This behaviour actually keeps the Product Owner the expert, as nobody has the chance to explore and figure out the best solution on their own. By playing around they will learn what they need to know.
3. Overshadowing the other Scrum Team members
Lack of trust and the assumption that she knows everything better than others may result in the Product Owner taking a dominating stance. What she says goes. The Scrum Team members only follow orders. The Product Owner doesn’t allow the Developers to self-manage their work, consciously or unconsciously.
In Scrum, Developers should be able to manage their own work. This allows for course corrections when the team needs to optimize the chances to meet the Sprint Goal.
4. Doing the work of the team
Some Product Owner SME even go as far as doing the work for the team. She does the refinement, the estimation, and possibly even the analysis. The Developers only have to code and test.
A Product Owner should respect the Developers to do their work and allow them to be self-managing professionals. A Product Owner can also be a Developer. But even then, it is not healthy to have a team leaning on one person to do all the thinking. It is a waste of creativity and opportunity.
5. Fear of people who might know more
When being the SME is what the Product Owner identifies with as being most important in her role, she could see people that know more as a threat. This could lead to dysfunctions like dismissing the other persons or their ideas. Working relations could be disrupted. With that, the product may not become as great as it could be.
6. Neglecting the other aspects of the PO role
A Product Owner SME who relies upon her expertise, only may neglect other aspects of the Accountability. It is crucial that a Product Owner:
- aligns with stakeholders;
- learns from earlier efforts and implementations;
- inspects and adapts based upon observations.
This all has a negative impact on the value of the product. The Product Owner fails to meet the needs of the stakeholders and misses opportunities for growth.
On top of that, a Product Owner should be open to learning new things about the product. When a product frequently has new increments, knowledge becomes outdated fast.
7. Not Looking beyond the current product
A Product Owner SME may have the tendency to stick to her beloved product. She may forget to look beyond the current state of the product to alternatives that could bring more value.
Perhaps it makes sense to start using new technology or alternative platforms. It would be a great loss if these opportunities wouldn’t be uncovered.
8. Failure to understand complex product environments
I saved the best one for the end. Scrum Teams work in a complex environment. What does it mean to be a Subject Matter Expert in such a product environment?
Here’s a nice snippet from the Scrum Guide to contemplate:
“Empiricism asserts that knowledge comes from experience and making decisions based on what is observed.” — Scrum Guide 2020
And here’s another one:
“In complex environments, what will happen is unknown.” — Scrum Guide 2020
In complex environments, an SME should understand there’s much to learn for her too. An SME should have a different stance than in complicated environments, where the right answers follow upon thorough analysis. Cynefin refers to this as sense — analyse — respond:
In complex environments, you wish to experiment to verify an assumption. Cynefin translates this to probe — sense — respond. This is in line with Scrum’s empiricism.
The Scrum team creates an Increment and then inspects this increment, together with key stakeholders. Typically, this happens at the Sprint Review. The team, including the Product Owner, learns from the inspection. They gain a bit more knowledge on the value of the product and what will bring the most value next.
If Scrum Teams consider the opinions of the SME to be the truth, they may forget to experiment to find evidence for the assumptions of the SME. In a complex environment, the opinions of the SME are assumptions too. Until they are proven right through inspection.
Subject Matter Expert: beware!
Having a Product Owner who is the product Subject Matter Expert is great. It is good to have people in the team who thoroughly understand the product. But it can also be a pitfall.
It is crucial to understand that Scrum Teams work in complex product environments. This means that the Product Backlog is filled with assumptions that need to be verified. It is for this reason that Sprints are as short as possible. You don’t want to run the risk to work based on unverified assumptions too long. A Product Owner who understands this has the right mindset. Then, being an SME can be of help instead of being a pitfall.
The realisation that the Product Owner only works with assumptions also impacts the relationship with the rest of the Scrum Team and the stakeholders. The Product Owner will welcome other product suggestions and technical solutions. She will be looking outside of the box and value input from all involved.
A Product Owner who bases her identity on being an SME would benefit from looking at alternatives to use her expertise. Like creating a vision to maximize the value of the product and leading the way in experimentations. This will benefit everyone and eventually also the product.
A Scrum Team that has a Product Owner who is the Subject Matter Expert is in a potentially great position. But they should together realise the pitfalls of an SME. Here the Scrum Master comes into play to coach Product Owner and Scrum Team to turn pitfalls into opportunities to grow.