Nine Ways Product Owners Can Crush a Team's Morale

Good product owners are gold. Not only do they represent business needs to ensure delivery of great products, but they can also lift a team's morale by making work fun and letting developers see their influence on the product ❤️.

Sadly, bad product owners are more like vampires, draining the strength from their teams. Without even realizing that they’re doing it, a PO can leave developers feeling ignored and unable to see the meaning of their work.

Here's my list of ten morale crushing things product owner should avoid.

No Grand Vision

It's great to pack every sprint with new features and needed fixes. It's great to do demos with stakeholders and hear their positive feedback. But what's even better is understanding why you are doing what you’re doing, and what you want to achieve in the long term.

While the vision of the end product is always evolving, the PO should understand it well enough to guide discussions among the product team. They should ensure that decisions about which PBIs are included in a sprint, which to left for later and which are dropped to the bottom of the list serve the long term goal.

The fact that the goals have been clearly articulated means there’s something for the team to celebrate when it’s achieved. Having specific goals, KPIs, etc. is good for productivity and morale. When developers know – and have had input on – the end goal, they can make better decision about the implementation along the way.

Running in Circles

If a team is running around in circles: if stories are refined and then ignored; if recent work has to be redone because it was poorly implemented; if the dev team is swamped with bugs and emergency features – then the team will conclude that the PO does not have control of the product. The team will feel frustrated because their time is not spent on meaningfully advancing the product.

Ignoring the Team's Ideas

Developers know the product they’re building. They know what needs to be achieved and can suggest different and sometimes better ways of doing it. By nature, developers have sharp analytical minds. That, combined with their familiarity with the code means that they see opportunities for optimization.

If the PO says, “Let's do this as I described first, and later we can think about how to make it better,” or "We don't have time for that now, ” or “I know exactly what the business wants, ” not only will the dev team feel demoralized, but it’s also likely that you’ll end up with an inferior product.

Not Collecting / Analyzing the Data

Henry Ford famously said, "If I had asked my customers what they wanted they would have said a faster horse.” The same goes with users. Good POs talk to users to get ideas and/or feedback, but they also observe users, collect and analyze data.

For example, let's say you want to shorten the time an action takes. Get some evidence from users about how much time the action takes now, and about how and when they use the feature. Sharing that information with the dev team will allow them to redesigning the flow, user interface, etc. to better meet the needs of the user.

Being Too Agile

Agile promotes addressing business in the cheapest, simplest way first, and then seeing if the solution sticks. Some POs take this too far. Adding yet another checkbox the user has to click, or yet another search field is a fast and simple solution. But if you end up with a bad design, the user pays the price. Along with a sub-optimal product, if agile gets taken to the point of sloppy, developers may lose pride in their work.

Accumulating Too Much Technical Debt

We all need to cut corners from time to time. Many successful businesses succeeded because the founders moved forward, shipping business value and creating a lot of technical debt along the way.

But there's a time when you need to start paying that debt. Having a project with dependencies that haven’t been updated for years will hurt you. Imagine trying to fix a security vulnerability in a library that was abandoned by everyone else. Not fun.

Remember that investing time in engineering tasks will result in the team becoming more efficient and the product becoming more robust. Accumulated debt will eventually cause delays in developing new features and can make the entire system brittle. Tasks like introducing new tools, refactoring code or changing the infrastructure often get postponed because they are difficult, time consuming and don’t produce an obvious deliverable for the customer. But they pay off and addressing them sends a signal that improvements (small or large) are welcome. Kaizen.

Overloading Sprints

Product development isn’t a sprint, it's a marathon. Putting too much staff time into the sprint might be good once or twice, but if you run every sprint that way, you’ll burn out your team. Some slack time is good. Many great ideas appear when team members have time to play with the product.

Also, if every sprint after sprint ends up with many tasks still open, teams won’t be able to see progress. Focus will always be on what was left undone and some great work may go unappreciated.

Adding Stories & Bugs Mid-Sprint

POs can be tempted to alter a sprint in order to please an important customer or address emerging bugs. This is inefficient and frustrating for the developers who get interrupted just as they’re gaining momentum on the stories they’re working on. It’s better to let them finish the work they’ve committed to and build a little extra room into your sprints to address emergencies.

Separating Developers from Users

The PO shouldn't be the only person in contact with business users. I’ve seen great things come out of having developers meet with users, and observe them using the tool. It build trust, makes it easier for both sides to understand each other and reduces the time the PO needs to spend “translating” business requirements. Taking part in forums, support and discussions with users helps developers gain insights into users’ needs and frustrations, resulting in a better product.

What to Do if your PO is Guilty these Things?

Talk to your PO and help them understand that better team dynamics help the PO achieve their goals. Sometimes it's just a matter of inexperience, sometimes it can be caused by some external influence, sometimes the PO doesn’t even realize there’s a problem.

It's good to speak with one voice, so talk with your team lead. The team lead and PO might be able to launch a new team dynamic that is beneficial to both morale and the product. The most important thing is that both sides understand each other, their ideas and their constraints. Communication is the key to success.

‍