9 ways product owner can destroy team's morale

Good product owners are gold. Not only they help you deliver better products by representing business needs. But also can lift up team's morale and make work fun by showing how much developers work makes influence ❤️

But bad ones are like vampires. They can drain strength from the team, feel people meaningless and ignored. The worst part is many of them don't realize that.

Here's my list of 9 morale crushing things a product owner can do.

Vague stories

You know something is wrong when you need to ask a lot of questions about a story only to find out that PO actually doesn't understand what business needs and the story gets moved to another grooming.

That doesn't put much trust into PO. If this happens often team may start questioning the leadership of PO.

No grand vision

It's great to pack every sprint with new features and fixes. It's great to do demos with stakeholders and get positive feedback. But what's even better is understanding why are we doing what we are doing and what we want to achieve in the long term. Sure it may change, but at least understanding this in current moment of time.

Also knowing what needs to be achieved makes opportunity to actually celebrate achieving it. So having some goals, KPIs, etc. is good.

Usually when developers know the end goal they can make better decision about the implementation.

Constant fire fighting and running in circle

Perfect example is grooming stories just to ignore them in the next sprint. Or redoing what was done recently because something was implemented not the right way. The worst case is being swamped with bugs, business side emergencies - it makes PO look like she doesn't understand what's going on and doesn't have control over it.

It makes people frustrated. There's no way to plan anything meaningful.

Ignoring team's ideas

Developers knowing what needs to be achieved can suggest different and sometimes better ways of doing it. Usually developers have sharp analytical minds that are able to simplify things, make shortcuts, etc. - we like to optimize things so it not rare when developers find a better way to do something.

Bad PO will ignore those ideas and stick to her own. Or worse will not want to discuss them. You can hear phrases like "let's do this first as I described and later we will think how to make it better", "we don't have time for that now", "I know exactly what business wants" 🏃

No time to collect or analyze the data

As 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.

One thing is to talk to users to get ideas or feedback. The other is to observe them and collect data. PO should be doing both.

Lets say you want to shorten time some action takes, you get some evidence from users how much it takes now. Now the team spends time redesigning the flow, user interface, etc. and for what if you don't track it?

Being too agile

Agile promotes addressing business needs first, the cheapest, the simplest way only to see if the solution sticks. But some POs take it too far. Adding yet another checkbox user has to click, or yet another search field is fast and simple as long as you don't end up with 30 of them on a single page. Then it hurts the user.

Also it takes away the pride from developers work. Sometimes it worth to consider more complex, more polished option from the beginning.

No time for engineering tasks

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

But there's a time you need to start paying this debt. Having a project with dependencies that weren't updated for years is bad and will hurt you. Think about fixing a security vulnerability in a lib that was abandoned by everyone else.

Also don't forget that many engineering tasks result in the team becoming more efficient - for example introducing new tools or refactoring code or changing the infrastructure may seem initially like something you can live without. Things like that are often postponed as they are hard. But usually they pay off if and make team value their work more.

It also sends a signal that improvements (small or big) are welcome. Kaizen.

Ignoring velocity, putting too much into sprints

Remember it's not a sprint, it's a marathon. Putting too much staff into the sprint and making it actually a sprint might be good once or twice. But if you run every sprint like that you hurt your team. Some slack time is good. Many great ideas appear when someone has time to play with things.

Also if every spring ends up with many tasks still open you don't see progress, you don't appreciate what you have done, but only see what was left.

Separating developers from users

Probably PO shouldn't be the only person talking with users and business. I saw great things coming out of developers meeting with users and just observing them how they use the tool. It also makes it easier for both sides to understand each other and build trust.

Also developers taking part in discussion on forums, or helping with customer support builds better understanding of customer problems.

What to do if your PO is guilty of things I mentioned?

It's worth talking with her and helping understand that good team dynamics actually help PO achieve her goals. Sometimes it's just a matter of inexperience, sometimes it can be caused by some external influence.

Also it's good to speak with one voice so talking with your team leader and helping the team leader be the voice of the team is also good.

The most important thing is that both sides should understand each other and their constraints, communication is important. We all want to succeed.

Let me know if there's anything you would like to add to the list, or you have some ideas how to solve the problems I mentioned. Reach me on Twitter

PS

Here's a good article on 10 ways POs can earn the respect and trust