5 Reasons Why Developers Hate Product Owners
A thin line between love and hate defines most relationships between Product Owners and Developers.
A thin line between love and hate defines most relationships between Product Owners and Developers.
In a Scrum Team, developers are the ones who transform Product Backlog Items into increments of value. Therefore, no one else can tell them how to do their work. Yet, Product Owners often ignore this aspect by behaving like a Developer Owner, who defines how developers should do their job. The result is an inevitable frustration. As Steve Jobs said:
“It doesn’t make sense to hire smart people and then tell them what to do. We hire smart people so they can tell us what to do.”
From my experience, the relationship between Product Owners and developers is like a thin line between love and hate. When trust is absent, dangerous lines are crossed, friction is the only certainty. For example, if Product Owners mistrust that the team can reach the Sprint Goal, they become obsessed with the burndown chart and start pressuring the team instead of helping them overcome the challenges.
I’ve identified five common misbehaviors of Product Owners that put the Scrum Team down. Allow me to share them with you, and hopefully, you can benefit from my learnings.
1. Let Developers Out of Decisions
Bringing a well-defined solution with a deadline is a perfect way of driving developers mad. Although I’ve been in this situation many times, a tipping point for me happened when a frustrated developer told me, “It’s always like this, you talk to a lot of people, define how to solve a problem and when to deliver the solution. Then, we are the last to know about it. I feel you don’t trust our competence! That’s why you leave us out of any decisions.” After that, I was speechless. I knew I had to change my approach.
I asked myself, “Why do I make agreements without involving developers?” I realized most of the time I wanted to help. I didn’t want to overwhelm developers with thousands of requests. My professional background fooled me because I could understand the technical details; thus, I could evaluate the solution feasibility. That’s where I missed the point. Developers feel mistrusted when they are out of decisions.
After such situations, I learned the importance of collaborating instead of throwing work over the fence. The following attitudes have helped me avoid these pitfalls:
Whenever the word solution comes out, let developers decide what the best approach for the product is. Nobody knows the product better than those who work on it.
Don’t surprise developers with already defined roadmaps. Instead, invite them to be part of it.
As a Product Owner, focus on identifying problems that worth solving. Then, find solutions with developers.
2. Bossy Behavior
In my opinion, the name Product Owner sucks. It sounds like we own something, and that leads to a behavioral trap. Stick with me. Imagine you own a house, and you want to paint the walls. Then, you hire a painter and tell him exactly how you want the job done, he will execute your demands, but he has no room to challenge you as you are the owner and pay for his service. Well, this behavior won’t work for products.
Scrum has no hierarchy. Yet, one of the roles is the ‘owner of the product’. For me, that doesn’t go hand in hand. In my opinion, Product Owners don’t own anything at all. But as long as they behave as the owners, misconceptions are unavoidable, and here are some of them:
Nobody can touch the Product Backlog besides the Product Owner.
Nobody can talk to developers without the Product Owner present.
Nobody can set Product Backlog Items to be done besides the Product Owner.
A bossy behavior is a perfect receipt for lack of commitment, frustration, and demotivation. Developers won’t give their best as long as Product Owners try manage them. If you want to succeed in this role, you should be a leader. My favorite definition of a leader comes from Simon Sinek:
“The role of a leader is not to come up with all the great ideas. The role of a leader is to create an environment in which great ideas can happen.”
3. No Space for Tech debt and Refactoring
Software is like a car. To keep your car running longer and avoid unpleasant surprises, you take it at least once a year to the maintenance center. Although you can skip that, you know it’s a foolish decision because it will cost you more in the long run. Software is no different; if you only add new features and don’t do any maintenance, eventually, your product becomes unsustainable.
In the business world, stakeholders are hungry for more features. But, no matter how much you deliver, it will never be enough to feed the beast. Unfortunately, many people bow to the stakeholders' pressure and focus solely on features while ignoring developers' warnings.
From my experience, if developers are asking for time to work on tech debt or refactoring, it’s a sign of a trust problem. As I already mentioned, developers are the ones who know the product best. So if they say something needs maintenance, something needs maintenance.
Often, Product Owners don’t set a Sprint Goal; instead, they ‘force’ the team to commit on feature level- In this case, developers have no room to work on any other thing besides features. With a Sprint Goal, it’s easy to avoid this trap. First, developers have clarity on the goal, and then they can do whatever is needed to reach the goal, including refactoring and tech debts.
“Empowered teams that produce extraordinary results don’t require exceptional hires.”
― Marty Cagan
4. More Output Is All that Matters
“We leave lucrative jobs to take low-paying ones that provide a clearer sense of purpose.”
― Daniel H. Pink, Drive: The Surprising Truth About What Motivates Us
Work consumes a considerable portion of our day. But, it’s gone the time work is only a means to put food on the table. People long for more. We need a purpose; we don’t want to waste our time on something meaningless. Yet, Product Owners often fail to help developers understand what the impact of their work is.
Some years ago, one developer was annoyed with me, and he said, “I understand we have to deliver features because the business wants, but I don’t understand why such features are important.” After this, I realized I failed to tell them the problem we wanted to solve and why it was necessary.
Developers don’t go to work to write code for the sake of doing it. Instead, they want to make people's lives better. As a Product Owner, it’s your responsibility to ensure developers understand the problem you want to solve and why it’s worth spending time on it.
5. Burndown Obsession
When I started my first job as a Product Owner, I was in love with the burndown chart. Many times a day, I would check how the chart looked; whenever I realized ‘we might not finish everything,’ I panicked, and as a consequence, I disturbed developers. What I failed to understand is that the Scrum Team commits to the Sprint Goal. There’s no such thing as a daily commitment.
The burndown obsession made me focus on a shallow picture. I often asked developers stupid questions like, “What can we do to improve our daily burn rate?” It doesn’t matter how many story points the team delivers a day. What matters is achieving the Sprint Goal by the end of the Sprint.
No one is pleased by people frequently asking them if they can deliver what they committed to. Giving the team the space to reach the goal is critical. Also, Product Owners should focus on the product instead of micro-managing the team.
My burndown obsession led to a mistrust feeling among developers because I was micromanaging them. Nowadays, I don’t care about the burndown. I trust the team will reach the Sprint Goal; that’s my expectation.
“The best way to find out if you can trust somebody is to trust them.”
― Ernest Hemingway
