Why Product Owners should challenge technical solutions
When I started out as a Product Owner I never challenged my teams on the technical solution. I believed it was not my job to do so.
As I gained more experience and technical understanding, my opinion changed. I now do think it is my job to challenge them on the technical solution. Allow me to give a concrete example.
At refinement we discussed a new epic. I explained the why, the business value and what we wanted to achieve. It was something that needed to run just once per day.
We talked about how we can best break it down in smaller chunks.
Before you can break it down in smaller chunks, the team has to agree on a high-level technical solution. Will we incorporate it in an existing micro-service? Will we build it as a new micro-service? Will a serverless lambda function suffice?
My team proposed to build a new micro-service. I challenged them on this.
Why do we need a new micro-service? It’s something that needs to run just once per day. Why can’t we build it using a lambda function where the server disappears?
A lambda function would speed up time-to-market and save money on infrastructure costs. We would not need to keep a server running 24/7. There also would be less code to maintain.
My team claimed it would impossible to build as a lambda function. The lambda function would run for too long and time out.
My team had never built a lambda function before. How can you claim something is impossible when you don’t have experience with lambda functions? Other teams I consulted were telling me it would be possible.
So I asked them to build a small Proof-of-Concept first. This would allow us to gain more knowledge and make a more informed decision. If after this we still would want to build it as a new micro-service, then this would be fine as well.
After the PoC, We decided to build it using a lambda function. We also gained valuable knowledge on whether using a lambda function may be appropriate.
Challenging developers can be frustrating for both sides
Challenging developers on the technical solution can be quite frustrating. Product Owners often know less than their Development Team about the technical solution.
In my case this is absolutely true. The arguments of the Development Teams are sometimes hard to understand for me. This increases frustration on their end, as they feel like I am not listening and just do not understand.
Developers often believe the technical solution is completely up to them. To justify their belief they refer to the following passage in the Scrum Guide:
No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
This is interpreted as a carte blanche to build a technical solution however they see fit.
I am entering dangerous territory, but I don’t agree with this! Challenging someone is not the same as telling them what to do.
I challenge my team if I believe the technical solution is not right for what we want to achieve. I believe Product Owners should be able to challenge the Development Team on the technical solution.
I have three main arguments why Product Owners should be able to challenge the Development Team on the technical solution.
1. The ability to challenge each other forms the bedrock of high-performing teams
Patrick Lencioni created the ‘ The Five Dysfunctions of a Team’ model. It outlines the 5 root causes of dysfunctional teams and how to overcome them. High-performing teams do not suffer from these dysfunctions.
I will explain the two bottom layers of the model. These two layers show that the ability to challenge each other is necessary to build high-performing teams. The dysfunctions at the bottom of the pyramid need to be abolished first before you can work towards resolving the dysfunctions at the top.
Dysfunction 1: Absence of Trust
The fear of being vulnerable with each other prevents building trust.
Dysfunction 2: Fear of Conflict
The desire to preserve artificial harmony despite disagreeing with each other prevents constructive conflicts.
So how does this relate to the claim that the ability to challenge each other is the bedrock of high performing teams?
Before you feel safe enough to voice your disagreement there needs to be trust. When people in a team do not trust each other, they won’t voice disagreement. Once there is trust, the door to constructive conflict opens. Constructive conflict is necessary to achieve better results.
In short: It is necessary for individuals challenge each other to be able to achieve the best results.
The Product Owner, Scrum Master and Development are all part of the same team: The Scrum Team. For teams to be high-performing, healthy debate is necessary. Even if you have different areas of expertise.
Challenging each other is different than overruling each other. Nobody is perfect and different perspectives lead to better results. No one on the Scrum Team should act like a dictator without listening to others. Otherwise the performance of the whole team will be affected negatively.
2. The Product Owner is responsible for maximizing value
The Scrum Guide writes the following about the Product Owner role:
The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team
This opens the door for a Product Owner to be able to challenge the technical solution.
By building simple solutions you speed up time-to-market and decrease total cost of ownership.
Product Owners have a tendency to under-engineer. Let’s ship it and move on to the next valuable thing. This may lead to technical debt with decreased ability to deliver value and increased total cost of ownership as a result.
Development Teams have a tendency to over-engineer. Let’s build something complex because it is fun. This may lead to increased time-to-market, technical debt and increased total cost of ownership.
A healthy tension between Product Owner and Development Team leads to technical solutions that deliver more value. Solutions that won’t be too simple and increase technical debt. Solutions that won’t be too complex and delay time-to-market before we prove it delivers value.
As a Product Owner, if I ask my team to deliver something that they believe is not valuable or worth the effort, I expect them to challenge me. I may have done a poor job of explaining the value we expect to deliver. It may also be that the Development Team is right and we should not do it.
3. The Scrum Guide does not say the technical solution is only up to the Development Team
I will repeat the part of the Scrum Guide I quoted at the beginning of this article:
No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
The ‘how’ in the passage does not refer to the technical solution, instead it refers to how the team performs their work.
No one tells the team how to build something. What to build and how it works is still up for debate by whole Scrum Team. Telling also doesn’t exclude guiding or supporting the team towards simple solutions. By building simple solutions you maximize the amount of work not done.
You should answer the following question together as a Scrum Team:
”What is the least complex way to achieve the most valuable thing?”
So if people use the Scrum Guide to claim that the technical solution is only up to the Development Team, then I believe they are misguided.
Challenging each other is good, overruling is not
There are three reasons why I believe Product Owners should be able to challenge the technical solution:
- The ability to challenge each other forms the foundation of high-performing teams.
- The Product Owner is responsible for maximizing value. The technical solution affects value through time-to-market, technical debt and total cost of ownership.
- According to the Scrum Guide the Development Team is responsible for the development process. No one tells the Development how to do their job from a process point of view. What to build and how it works is an entirely different thing.
The whole Scrum Team is responsible for the technical solution. Everybody should be able to challenge each other, regardless of role. The ability to challenge each other leads to different perspectives being incorporated in the final product. This leads to better results.
Listen and try to understand each other, and most of the time you will not end up a situation where you need to overrule each other. Even though you may have the ability to pull a final say card, you should try to never do this. Overruling each other within the team undermines the team effort you need to deliver great products.
