How to Overcome the Most Common Product Owners’ Anti-Patterns
Knowing what not to do is often more relevant than knowing what to do
Knowing what not to do is often more relevant than knowing what to do
It was around a decade ago when I moved from a small town in Brazil to São Paulo, the biggest city in the country. Back then, I was a software developer and got to know someone who believed I could be a Product Owner. Although I had no idea what this role was all about, I was eager to start a new adventure. Little did I know what awaited me.
Like most changes in life, the beginning brings a lot of excitement and challenges. I was just 24, full of energy and courage. Yet, I confess, I was scared as hell. I often asked myself whether I could live up to the responsibilities of a Product Owner while getting used to this massive city called São Paulo.
Fortunately, my curiosity and optimism always pushed me forward. But that doesn’t mean everything went smoothly. My road was not a German Autobahn, where you can drive at full speed and barely find any obstacle on your way. The truth is, my road was bumpy, surprising, and frightening; often, I doubted I could reach any destination at all.
Let me share what I wish somebody had told me when I started my Product Owner journey. When I look back, there are many things I wish I knew, yet nobody told me. I had to figure out my mistakes on my own.
Product Management
It’s impossible to succeed as a Product Owner without solid Product Management skills. Being a robust Product Owner goes beyond doing Scrum well. For example, the Scrum Guide tells us our responsibilities but not how to live up to them. Here are some pitfalls you will eventually face:
Please stakeholders: prioritization is key to success. Yet, it’s as hard as hell doing that. Product Owners receive pressure from all layers of the organization. Everyone wants something done by yesterday. That’s why it’s easy to bow to the pressure and lead teams in pointless directions. Great Product Owners strive for commitment instead of consensus. They prioritize delivering value instead of pleasing stakeholders.
Ignore end-users: no matter which product or service you work on, it exists because it helps someone overcome certain hurdles. It’s impossible to build meaningful products without profoundly understanding the real end-users. Yet, it’s trivial to fall in love with solutions, ignore the end-users, and inevitably create something stakeholders love but nobody needs.
Ignore the outcome: delivering features is one thing; creating value is an entirely different one. All features are irrelevant until end-users can benefit from them. Measuring the impact caused by the Scrum Team’s work is a complex task and yet core to success.
Skip events: nobody likes failing, yet avoiding it is improbable. Often, Scrum Teams will find themselves in a critical situation where they are under pressure and lose track of the Sprint. A typical solution is to skip an event like a refinement or Sprint Retrospective. I encouraged teams to do that in the past, and I learned it’s a horrible idea. It’s like throwing dust under the carpet, the floor remains dirty, but you don’t see it.
Sometimes we have to face failure as bitter as that could be; nothing will teach us better than that.
Managing the Product Backlog
An excellent Product Backlog contains problems to solve instead of requirements to implement. Creating items that reflect a plan to follow will transform your Agile framework into a waterfall one. Here are some traps you need to be aware of:
Dinosaurs: backlog items should have a short life. If they don’t make it to a Sprint in a couple of months, you should remove them from the backlog. Old items become obstructions to new ones. Only when the old goes away, the new will find space.
Too much detail upfront: the level of details you put in the items will define how the team will tackle them. If everything is defined upfront, the team focuses on execution. However, if you bring a problem and clarify why it’s essential to solve it, you open the room for creativity. By bringing open questions, you encourage people to search for answers.
Protect the backlog: the Product Owner owns the Product Backlog, but that doesn’t mean you should be the only one who creates items there. Let stakeholders and team members contribute to the backlog, and then you can decide what will end in a Sprint and what will go out.
Everything goes to the backlog: without clarity on what to achieve, the backlog becomes an extensive wish-list. It’s vital to have clarity on the goal, and then only items that would contribute to it should go to the backlog.
Refinement Sessions
I had awful and terrific experiences with refinements. Until now, I haven’t found a perfect receipt for success. Yet, I identified what leads to disappointing results:
Focus on the solution: the session should be about building a shared understanding around the problem to solve instead of focusing on the boundaries and details of solutions. First, the team gains clarity on the problem, and then they can talk about solutions. If you invert that, you get a team of executors instead of problem-solvers.
Refine pointless items: deciding what to refine is critical. The Scrum Team should refine things they can work on soon. For example, they waste their energy when the team refines something that won’t be in the upcoming Sprints. If you have nothing new for the upcoming Sprints, it’s better to skip a session than focus on something irrelevant.
Endless tech discussions: during the sessions, it’s easy to fall into deep tech discussions, though that’s not the goal of refinements. Often, developers have an urge to clarify tech aspects because they are pressured to give precise estimates and match arbitrary deadlines.
Focus on the estimate: providing an estimate doesn’t represent a commitment to a time to implement. For me, estimates show if the team members share the same view on the complexity of the items. The process of estimating is more critical than the estimate itself.
Sprint Planning
When a group of people shares the same goal, they collaborate intensively to reach it. That’s why planning the Sprint is critical to fostering collaboration. Yet, it’s easy to fall into some pitfalls and transform Scrum Teams into a waterfall approach. Here is what I suggest avoiding at all costs:
Absence of a Sprint Goal: the first and most crucial part of any Sprint is its goal. Without that, the team has little or no reason to collaborate. When the Sprint Goal is blurry or inexistent, the Scrum Teams receive a high pressure to deliver more output, leading to compressed Sprints focused on delivering tasks instead of reaching a goal.
A little bit of everything: Sprint is not meant to keep the feature factory running. It’s not about choosing what fits the team’s capacity but about deciding which problem is worth solving. A diverse Sprint will lead to constant context switching, low performance, and ultimately a watered-down result.
Divide and conquer: I’ve used segmented Sprints like 50% new features, 20% bug fixes, 20% tech debt, and 10% slack time. Well, looking superficially, it makes sense, but when I understood its impacts, I stopped doing so. Defining time for bug fixes or tech debt is impossible. A solid product owner focuses on crafting a relevant Sprint Goal and then lets the team decide what they will do. The Scrum Team commits to the goal; if they want to refactor something or take care of tech debt, it’s their decision, not the Product Owner’s one.
New items on the fly: bringing undigested thoughts to the planning causes distraction and confusion. For example, before the planning, you have an idea, and instead of reflecting on it and bringing it to a refinement session, you decide to put it in the next Sprint, the team will have to inject refinement into the planning. Of course, you could treat that as an exception, but it should not become the rule.
Daily Scrum
Every day developers get together to organize the work for the day, inspect, and adapt. The goal is to ensure they get a step closer to the Sprint Goal. Although Product Owners can attend the Daily Scrums, this event is not for them. I’ve come across several anti-patterns with Product Owners:
Status report: the Product Owner uses the daily as a status report; she names who speak and monitor if the person is on track with their tasks. Well, that’s a massive anti-pattern. Product Owners should never run a Daily Scrum, and if they participate, they should be there to listen and help instead of being a traditional Project Manager.
Be the boss: without the Product Owner, the daily doesn’t start. The team waits until she arrives and then starts the daily. Once the daily start, the Product Owner listens carefully to each team member and then defines who does what until when. Developers become passive, and they wait for the Product Owner’s instruction.
Distractions: the Product Owner comes to the daily and highjacks her requests. Instead of helping the team progress towards the Sprint Goal, she adds more to their plate. Sometimes an “urgent” situation appears, and a developer needs to support the Product Owner for a day or two, or a quick refinement is needed to get more support from stakeholders.
Sprint Review
At the end of each Sprint, a review takes place. The Scrum Team presents what they achieved and receives feedback from the stakeholders. Until now, I’ve experienced a wide variety of Sprint Reviews, from energy-draining sessions to powerful and inspiring ones. Here is what Product Owners should not do during such sessions:
Take the stage: the Product Owner becomes the showman and keeps developers behind the curtains. Proudly, she presents all the team’s features during the Sprint and ensures that developers remain silent once a stakeholder provides feedback because the Product Owner owns the show. I had several sessions like that, developers inevitably disengaged and eventually lost interest in the product.
Make promises on output: stakeholders tend to ask for new features during the Sprint Review; that’s normal. However, how Product Owners address such requests is critical to the Scrum Team’s success. Bad Product Owners will make promises and create new backlog items, and good Product Owners will strive to understand the need behind the wishes.
Focus on Sprint’s Increment: only showing the result of the Sprint is often not enough. To engage with the stakeholders, it’s vital to connect the dots by showing how the Increment changes their lives in their context. Ignoring the big picture will lead to low engagement.
Ignore the impact: focusing solely on the output of each Sprint will not help stakeholders understand the real value the team created. As the Scrum Team gains clarity on the outcome generated by previous Sprints, it’s crucial to show that during the Sprint Reviews.
Without clarity on the outcome, Product Owners will face a hard time gaining support from stakeholders.
Endnote
As embarrassing as it can be, I fell into all traps I mentioned in this post. And sometimes, I still do. I learned that being a great Product Owner is not about being perfect but about being humble and recognizing our mistakes.
Once we can see our flaws, we can progress and become a better version of ourselves.
Thanks Sjoerd Nijland and Erik de Bos for reviewing this post, your inputs helped me make it clearer!
