What a Product Owner Should NOT Do? : Biggest Pitfalls to Avoid

Introduction

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” – Antoine de Saint-Exupéry

In the dynamic world of Agile, the Product Owner (PO) stands as a pivotal figure, the champion of the product vision, and the crucial link between stakeholders and the development team. They are entrusted with maximizing the value of the product on which the Scrum Team is working. But like any critical role, the path of a Product Owner is fraught with potential pitfalls. While countless resources illuminate the “Dos” of effective PO practice, understanding what a Product Owner should absolutely Not Do is equally vital for increasing the successful Agile outcomes.

I remember that many years back I gave a webinar on anti-patterns in agile and scrum for one of Benzne’s agile consulting and training partner and following are some of the screenshots of my slides on Product Owner anti-patterns and when I read them, I found that almost all of them are still true!

This blog on ‘What should a Product Owner not do?’ delves into the forbidden territory of Product Ownership, exploring the common mistakes that can derail even the most well-intentioned POs. By understanding these “do nots,” aspiring and seasoned Product Owners alike can navigate their responsibilities with greater clarity, ultimately leading to more valuable products and empowered, high-performing teams.

What is an Agile Product Owner?

Imagine there is a busy restaurant in a suburb where,

• The restaurant owners (stakeholders) provide the overall business goals, budget, and target market.
• The diners (customers) provide feedback on the food, what they like, what they do-not, and what they might want in the future.
• The Head Chef (Product Owner) constantly interacts with both, understanding their needs and preferences to shape the menu.
• The kitchen staff (development team) are the culinary experts who actually prepare the dishes.

Following are the traits & responsibilities:

• The Head Chef doesn’t tell them exactly how to chop every vegetable or stir every sauce (micro-managing), but clearly communicates the desired outcome – the delicious and well-presented dish. The Chef trusts their skills and expertise to execute the menu effectively.
• The Head Chef decides on daily specials or seasonal items based on ingredient availability, customer demand, and restaurant strategy, just like prioritising the backlog. Less popular or less profitable dishes might be removed or revised (backlog grooming).
• Before a dish goes out to a diner, the Head Chef tastes and inspects it to ensure it meets their standards and the diner’s expectations (Definition of Done and acceptance criteria). If it’s not up to par, it’s sent back for refinement.

Before we venture into the “do nots,” let’s briefly revisit the essence of an Agile Product Owner. In the context of Scrum and broader Agile methodologies, the PO is the single point of accountability for the Product Backlog. They are responsible for defining, prioritizing, and communicating the product vision to the Scrum Team. The PO acts as the voice of the customer and stakeholders, ensuring the team builds the right product at the right time.

Understanding the Product Owner’s Role

The Product Owner’s responsibilities are multifaceted and demand a unique blend of strategic thinking, communication prowess, and decisiveness. Key responsibilities include:

• Articulating the “why” behind the product and painting a clear picture of its future
• Creating, maintaining, and ordering the backlog items based on value, risk, priority, and dependencies
• Ensuring the team works on the most valuable items first to maximize business outcomes
• Collaborating with various stakeholders (customers, business owners, users, etc.) to understand their needs and translate them into actionable backlog items
• Ensuring the delivered increments meet the Definition of Done and the acceptance criteria of the backlog items
• Providing clarity and guidance during Sprint Planning, offering feedback during Sprint Reviews, and contributing to Sprint Retrospectives.

I once worked with a Product Owner, Priya, during my agile coaching stint for a mobile app development company, and Priya was working with her team building a new e-commerce platform for the client of the firm. Initially, the client stakeholders had a laundry list of features they wanted, everything from complex personalization engines to intricate loyalty programs. Priya, our Head Chef, listened intently to the “owners” but also spent significant time understanding the “diners” – conducting user interviews and analyzing market trends.

Instead of blindly adding everything to the “menu” (backlog), Priya focused on the core experience first like a smooth browsing experience, a clear checkout process, and reliable order fulfillment. She resisted the urge to immediately implement the complex personalization engine, recognizing that without a solid foundation, those advanced features wouldn’t deliver value.

The stakeholders initially pushed back, wanting all the “bells and whistles” upfront. However, Priya patiently explained her rationale, emphasizing the need to deliver a Minimum Viable Product (MVP) quickly to gather real user feedback. She used the analogy of a restaurant needing to perfect its core dishes before experimenting with elaborate specials.

The initial launch was a success. Users loved the simplicity and ease of use. Based on their feedback and early sales data, Priya then strategically introduced the personalization features in subsequent “menu updates” (sprints), ensuring they were aligned with actual user needs and behavior.

Priya’s approach, much like a skilled Head Chef, focused on delivering core value first, constantly seeking feedback, and strategically introducing more complex “dishes” based on what the “diners” truly craved. This iterative approach, guided by her clear vision and prioritization, ultimately led to a much more successful and user-loved product than if she had simply thrown every requested feature onto the initial “menu.

Hope both analogy & anecdote has helped you in knowing more about the Product Owner. With this understanding of the PO’s core responsibilities, we can now explore the common missteps that can hinder their effectiveness and ultimately jeopardize the success of the product.

Common Mistakes a Product Owner Should Avoid

Just like even the most promising Head Chef can stumble in the kitchen, the journey of a Product Owner is a learning curve where missteps are part of the process. However, recognizing and actively avoiding certain common pitfalls can significantly enhance a PO’s impact, ensuring the product delights its “diners.” Let’s look at some common “kitchen nightmares” for a PO:

1. Losing Sight of the Restaurant’s Concept (Not Understanding the Product Vision)

A Product Owner, like Priya, without a clear and compelling vision for the “restaurant” (product) is like a chef without a culinary identity. Without a guiding star, the overarching concept and target audience; the “menu” (backlog) becomes a random assortment of dishes, and the “kitchen staff” (team) lacks a unified purpose. This leads to preparing dishes (features) that don’t fit the restaurant’s theme, resulting in a confused and potentially less appealing offering. Priya must deeply understand the restaurant’s concept, articulate it passionately, and always refer back to it when deciding what goes on the menu. What our Product Owner should not do is to lose sight of the vision by getting distracted.

2. Hovering Over the Sous Chefs (Micro-managing the Team)

While Priya, as the Head Chef or Product Owner, owns the “what” dishes need to be and “why” they are on the menu, the “how” of preparing them belongs to the skilled “sous chefs” (Development Team). Micro-managing the team by dictating exactly how to dice an onion (technical solutions), assigning specific prep tasks, or constantly looking over their shoulders erodes trust, stifles culinary creativity, and undermines the team’s ability to self-organize. What our Product Owner should do is to clearly communicate the desired taste and presentation (outcomes) and empower the team to use their expertise to achieve it.

3. Issuing Cooking Instructions Without Tasting (Dictating Solutions Instead of encouraging Collaboration)

A PO who acts as the sole culinary visionary, prescribing recipes without involving the “sous chefs” (Development Team), misses out on their valuable culinary knowledge and innovative techniques. The team often has a deep understanding of the “kitchen” (technical landscape) and can suggest more efficient and delicious ways to prepare dishes. An effective PO, like Priya, should encourage collaboration, encourage the team to contribute to recipe development, and value their culinary insights. What the Product Owner should not do is to be adamant and thinking that they just know everything and speaking-with-authority, even though when they are hollow, is their right.

4. Obsessed with the First Menu Draft (Being Overly Attached to Their Vision and Ignoring Adaptability)

While Priya’s initial menu vision is important, she must also be adaptable and open to evolving it based on diner feedback, changes in available ingredients (market), and new culinary trends (learnings). Being stubbornly attached to the first menu, even when diners aren’t ordering certain dishes or new ingredients become popular, can lead to an outdated and unpopular restaurant. A successful PO balances a strong culinary concept with a willingness to experiment and adjust the menu based on what works.

5. Ignoring the Diners’ Reviews and the Sous Chefs’ Feedback (Ignoring Customer and Team Feedback)

The Product Owner, Priya, is at the heart of the “front-of-house” (customer needs) and the “back-of-house” (team capabilities). Ignoring feedback from the “diners” (customers) about what they enjoy or the “sous chefs” (team) about cooking challenges is a recipe for a bad review. Diner feedback provides crucial insights into what sells and what doesn’t, while team feedback highlights kitchen limitations and opportunities for smoother service. Priya must actively solicit, listen to, and synthesize feedback from both to make informed menu decisions and guide the restaurant effectively.

6. A Messy Pantry (Not Managing the Backlog Effectively)

The Product Backlog is Priya’s “pantry,” and neglecting its organization can lead to confusion and wasted ingredients. This includes letting ingredients (backlog items) become stale, mislabeled, or outdated. Priya must regularly organize the pantry (groom the backlog), refine recipes (user stories), ensure they are clear and easy to follow, and discard ingredients that are no longer needed (remove irrelevant items).

7. A Menu with No Clear Order of Importance (Neglecting Backlog Prioritization)

We have reviewed that many times a backlog leads to confusion for stakeholders & customers, a backlog without clear prioritization means delaying the delivery of what truly could satisfy the customer & at the same time helps business to grow. Priya must consistently prioritize the “menu” (backlog), making tough choices about what gets prepared first to maximize diner satisfaction and restaurant profitability.

8. A Kitchen Overflowing with Ingredients (Overloading the Backlog with Too Many Items)

While a well-stocked pantry is good, a kitchen overflowing with ingredients creates chaos and makes it hard for the “sous chefs” (team) to find what they need. Similarly, overloading the backlog with too many items creates unnecessary complexity and can overwhelm the team. Product Owners like Priya should aim for a “just enough” inventory (backlog), containing ingredients (items) that will likely be used soon and are well-prepped (refined).

9. Deciding on New Dishes Without Tasting or Asking Diners (Making Decisions Without Data or Customer Insights)

While Priya’s culinary instincts are valuable, relying solely on them without tasting new recipes or asking diners what they would like is risky. Priya should strive to make menu decisions based on diner preferences (user research), what other successful restaurants are offering (market analysis), sales figures (analytics), and direct feedback. This ensures the restaurant’s offerings are driven by demand rather than assumptions.

10. Hiding in the Office During Service (Being Absent During Sprints and Not Communicating Effectively)

The Product Owner’s job is not done after planning the sprint. Being unavailable during busy service hours hinders the “waitstaff” (team) from getting quick clarifications on orders, making on-the-fly adjustments, and resolving issues. Similarly, poor communication – failing to clearly explain requirements, provide feedback to the development team, or inform the stakeholders about changes in the backlog priorities; all this can lead to misunderstandings, delays, and building solutions that do not meet expectations. Priya must be an active and engaged presence during service time at the restaurant, readily available for questions and proactively communicating important information.

Best Practices for a Successful Product Owner

Avoiding the “do nots” is crucial, but actively embracing best practices is what truly elevates a Product Owner to success. These are some of the practices we encourage PO cohorts at our clients to actively adopt in our agile consulting and training services engagements.

• Continuously refine and communicate the “why” and the “what” of the product
• Keep the backlog refined, and focused on delivering value
• Build strong relationships, actively listen and effectively communicate with all stakeholders
• Encourage open dialogue and actively involve the Development Team in solutioning
• Actively seek and incorporate feedback from customers and the team
• Base product decisions on evidence and insights

Conclusion

The role of the Product Owner is challenging yet incredibly rewarding. By understanding and actively avoiding the common pitfalls outlined above, and by diligently embracing best practices, Product Owners can significantly enhance their effectiveness, empower their teams, and ultimately drive the creation of valuable and successful products. The journey of a PO is one of continuous learning and refinement, and recognizing the ‘Don’ts’ is a vital step towards mastering this critical role.

With this, our blog on “What a Product Owner Should NOT Do? : Biggest Pitfalls to Avoid” comes to an end. We sincerely hope this has helped our readers get some clarity around it. We would be glad to discuss your unique agility adoption bottlenecks at Benzne Agile Transformation consulting and support your agile journey. Please write to us at “consult@benzne.com” for any further feedback or recommendations or in case you are looking for external coaching support.

Frequently Asked Questions

1. Can a Product Owner also be a Scrum Master?

While theoretically possible, it is generally not recommended for the same person to fulfill both roles, especially in larger or more complex projects. The Product Owner and Scrum Master have distinct focuses and often require different skill sets. The PO focuses on the “what” and “why” of the product, while the Scrum Master focuses on the “how” of the process and facilitating the team. Combining these roles can lead to conflicts of interest and overburdening a single individual.

2. What happens if a Product Owner does not attend sprint meetings?

The absence of the Product Owner from sprint meetings, particularly Sprint Planning and Sprint Review, can significantly hinder the team’s effectiveness. During Sprint Planning, the PO provides crucial clarity on the backlog items and helps the team understand the sprint goal. In the Sprint Review, the PO provides feedback on the delivered increment and guides future direction. Their absence can lead to the team working on the wrong things or delivering increments that don’t meet expectations.

3. Can a Product Owner delegate backlog management to someone else?

While a Product Owner remains accountable for the Product Backlog, they can and often should collaborate with the Development Team and other stakeholders in backlog refinement activities. However, the ultimate responsibility for prioritization and decision-making regarding the backlog lies with the Product Owner. Delegating these core responsibilities can lead to a disconnect between the product vision and the team’s work.

4. Is it a problem if a Product Owner lacks technical knowledge?

While deep technical expertise is not always a prerequisite, a Product Owner needs to have sufficient technical understanding to effectively communicate with the Development Team, understand technical constraints and opportunities, and make informed decisions about the product. A lack of technical understanding can lead to unrealistic expectations, poor decision-making, and communication breakdowns. However, a strong PO can mitigate this by actively engaging with the team and leveraging their technical expertise.