5 Ways a Product Owner should NOT Behave, Part 3

In this subseries’s third and last blog, I tackle the final five ways that Product Owners should not behave. Taken together, this gives you a nice list of traits and behaviors to avoid when selecting or evaluating a Product Owner.

Not listening to the developers

Problem

Developers generally have a lot of insight into product development. Unfortunately, many Product Owners tend to forget that the Developers are stakeholders, too. By not seeking out or not listening to what they have to say, important considerations such as technical dependencies may be missed.

speaking and listening

Solution

Since Developers are stakeholders, they should always be consulted. Their knowledge is important to consider when sequencing the Product Backlog and doing Backlog Refinement. You might not always understand everything they say, but you do need to understand what the impact is on prioritization.

Never satisfied

Problem

Product Owners who are never satisfied probably don’t understand Scrum or Agile principles. The whole idea of “maximizing the art of work not done” is lost on them. The concepts of Minimal Viable Product or Feature may also be missing. Dissatisfied Product Owners feel that way because they don’t get what it means to be Agile.

Solution

Understanding Agile is key to solving this problem. This problem most often occurs with Product Owners who used to have some other role in a traditional project environment. Their tendency is to gold plate everything, expecting it to be perfect right out of the gate. That’s not the point of Agile. The point is to progressively elaborate, experiment, learn, and adapt.

Decision-hoarding

Problem

While the Product Owner is the key decision-maker about the product overall, that doesn’t mean that every decision must be made by that person. If every single itty bitty detail must be run past the Product Owner, it leads to a giant backlog of things that need to be reviewed, and then nothing gets done.

Solution

post-it notes on a board, with one that says "make things happen" in the center

Decisions should be pushed down to the lowest level possible – where the work happens. Developers on the Scrum Team should be empowered to make the call on how they do their work. Remember, the Product Owner’s job isn’t to dictate how the work gets done – it’s the Developers’ responsibility to figure that out. As such, decisions about the day-to-day work are up to the people doing the work. The Product Owner is still responsible for the product and its outcomes, but also needs to trust the team to make the right decisions for the good of the product.

Lack of transparency

Problem

Is your Product Backlog visible? Do you have consistently scheduled Sprint Reviews with the right people in attendance? Are your stakeholders aware of how your Scrum Team is executing against your roadmap? Do you feel the need to “hide” things from either your team or stakeholders if you don’t feel that things are going well? All these things are symptoms of a lack of transparency, and therefore a lack of trust and safety.

Solution

Your job as a Product Owner is to represent the voice of the customer and manage stakeholder communications and expectations. A key tenant of Agile is transparency. Without it, you will fall right back into the traps of traditional project management. You must be transparent if you want your product to succeed. If something goes wrong, acknowledge it. If things are going well, celebrate it. Honesty is always the best policy. And chances are that if you do run into issues, your stakeholders will be much more forgiving because they are already aware of the challenges you are facing.

Fixed mindset instead of a growth mindset

Problem

People with a fixed mindset are going nowhere fast. What is a fixed mindset, you ask? It’s an attitude that you know everything already and that there’s nothing new to learn. If you have a fixed mindset, you won’t be open to innovating or exploring new ideas, which leads to the creation of a sub-par product.

Solution

fixed versus growth mindset

Be open and willing to learn new things. Even better, constantly seek out new learning on your own. My personal feeling is that if you’re not learning, you’re not really living. Every day is an opportunity to learn something new, and to grow your knowledge. As a Product Owner, this is especially important as you are responsible for making sure your product is competitive in the market, and if you’re not continually exploring (and outpacing) the competition, you’ll get left in the dust.

Final Thoughts

Well, that’s a wrap! Watch out for all these personality and behavior problems in your Product Owners and do whatever you can to avoid them. Now, is there anything I missed? Are there any other problematic behaviors or traits you have seen in Product Owners? If so, let me know in the comments below!