What Are the Most Common Daily Mistakes of Product Owners?

You should be careful with the daily damage you cause to your?team.

The Product Owner role is full of responsibilities. It requires a lot of knowledge, soft skills, and continuous learning so that we can succeed. It's demanding and easy to fall into traps. Yet, I perceive many professionals exclusively focusing on what they should do while ignoring what not to do. Unfortunately, this results in many small mistakes that hold them from achieving their goals and hurts the teams’ performance.

Such mistakes cause considerable damage to the team. We should pay close attention to the anti-patterns and stop doing them. The worst daily mistakes I have noticed over my journey are related to the following:

• Daily Stand-up
• Interruptions
• No time for the team
• The people pleaser

Daily Scrum

It is hard to believe, but the most significant damage happens during daily stand-ups. The daily stand-up is where Product Owners love disturbing the team. I wonder how harmful we, as Product Owners, can be in only 15 minutes.

Let’s start from the beginning, the Daily Scrum is an event for developers, not for Product Owners.

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers. Scrum Guide

The Product Owner MUST avoid the following attitudes during the daily:

• Status Report: some Product Owners use the daily stand-up as a moment where each developer will give a status of what they are working on, then the Product Owner may push the team. Such attitude is command & control, which has nothing to do with Agile!
• Manager: it is curious why some Product Owners think they manage the team, which is a big misunderstanding. When that happens, the Product Owners will assign the tasks directly to the team members, telling them who does what, don’t be a Project Manager! Instead, trust the team. They know how to organize their work.
• New requests: this is another awful one. The Product Owner comes daily, and before it starts, they fire new demands so the team can take it. That is not the moment; new requests need to be refined and prioritized into a Sprint. When a Product Owner inserts new demands during the daily shows that there is no direction, I ask, how would the team trust such a Product Owner?
• Daily doesn’t start without the Product Owner: if the team doesn’t begin the daily when the Product Owner is absent, this event is probably a status report to the Product Owner. Keep in mind, Product Owners that the daily is not for you. That is a moment where the team gets the alignment they need to keep moving towards the Sprint Goal. The Product Owner is optional, and if available, a listener, no more than that.

There are many more anti-patterns happening, which Stefan Wolpers describes in his article about it. I took some examples because we should be cautious with this.

Planning meeting: The PO hijacks the Daily Scrum to discuss new requirements, to refine user stories, or to have a sort of micro (Sprint) planning meeting.

The talkative PO: The Product Owner actively participate in the Daily Scrum. (POs and Stakeholders are supposed to listen in but not distract the Development Team members during their inspection and adaptation.)

Interruptions

Product Owners will always receive many requests from different people, but that doesn’t mean you need to react immediately. Also, it doesn’t mean that the Product Owner should interrupt the team as soon as something emerges. Remember that they commit to the Sprint Goal, which is their focus. Here are some examples:

• Bug: if a bug comes, you don't interrupt the team. If you work in software development, there are always bugs. The Product Owner first needs to understand that impact before thinking about interrupting the Sprint. Specific critical issues require immediate action, but most of them don’t. The point is; first, you should understand the impact before you talk to the team.
• New features: sometimes, the Product Owner has some new ideas and wants to share them with the team. There is a moment for that, and it is called backlog refinement. If you interrupt the team to talk about all your ideas, the team will not focus on what they should. Before you interrupt, ask, “Is this relevant for our Sprint goal?” if not, wait for the right moment.
• Meetings: Product Owners take part in a lot of meetings, some of them for future possibilities that may never happen. However, some Product Owners insist on taking team members to such meetings, wasting their time. I am not saying that tech members should be far from business. I am saying that Product Owners should understand when to involve them, so they don’t waste time.

Remember one thing; Scrum is about maximizing the work not done, so we must remove every waste we may have!

“Simplicity — the art of maximizing the amount of work not done — is essential.” Agile Principles

No time for the?team

The Product Owner should be available for the team at least 30% of their time, which happens daily. But sometimes, the Product Owner only appears during some Scrum events (Sprint Planning, Review, and Retrospective). The rest of the time, the Product Owner is somewhere else, but not with the team.

Being an absent Product Owner will cause a big problem for the team because there is one principle in the Agile Manifesto that is broken once that happens:

“Individuals and Interactions over processes and?tools.”

Once you wear the hat of a Product Owner, you must communicate with the team daily. The best way of doing that is face to face. If your team is remote, then a video call is. But not through e-mails, comments on Jira, or other electronic formats. The interactions are what matter the most.

In short, the team needs you, dear Product Owner, so they don’t get blocked with doubts and misunderstandings. So don’t be too busy for them, because you are part of the team!

The PO is too busy to help the team, so they need the team to help them! — Vasco, The (surprising) 9 most common challenges that Product Owners face, and affect their Scrum Teams

The People?Pleaser

This scenario is a misunderstood instance of a Product Owner. It is known as the Clerk by Robbin Schuurman.

The Clerk is your personal waiter for all your user story serving. Gathering all the wishes, user stories and demands is what The Clerk does. (S)he isn’t focussed on achieving the product vision, nor on crafting clear goals and objectives and the Clerk most certainly never says ‘no’ to stakeholders. There’s nothing wrong with servant leading your customers and stakeholders as a Product Owner, but if your main purpose during the day is getting new ‘orders’ from stakeholders… then you’re missing the point of being a great Product Owner.

The main problem I have observed happens when Product Owners don’t focus on the value request brings to the business. As a result, the Product Backlog becomes a pointless bucket of wishes that leads nowhere. That is awful for the team because:

• There will be no direction
• There is no purpose
• Delivery of features instead of value
• No focus
• Demotivating the development team

If you are saying “yes” to everyone, you are far from being a Product Owner. Once you have no plan for the product, you will become someone else’s plan.

The key takeaway is that before we focus on what we should do as Product Owners, we should look in the mirror and understand the daily mistakes we commit. By eliminating them, we will already become a way better Product Owner!