23 Product Owner Anti-Patterns from Job Ads: The Snitch, the Whip, the Bookkeeper, the Six Sigma Black Belt™

Stefan Wolpers February 3, 2021

TL; DR: Product Owner Anti-Patterns from Job Ads

Like a job ad for a Scrum Master position, the equivalent for the Product Owner position also reveals excellent insight into an organization’s progress on becoming agile. (February 03, 2021), I analyzed 60-plus randomly selected job ads from the UK, the US, and Germany for that purpose. Learn more about what makes job ads such a treasure trove with the following 23 Product Owner anti-patterns.

Analyzing Job Advertisements for Product Owner Positions

Probably, you are considering a position as a Product Owner in a particular organization. I suggest that before going all-in (the application process), you should consider analyzing the job description for Product Owner anti-patterns first.

How Large Organizations Create Job Ads

Usually, the organization’s people management department will create the job advertisement’s final text and post it to the chosen job sites. Hopefully, and depending on their process and level of collaboration (and agile mindset) in the organization, the Scrum team for which the new position was advertised may have participated in creating the job ad. This certainly avoids promoting the wrong description to prospective candidates.

However, too often, advertisements may read like a copy and paste from positions that an organization’s people management department believes to be similar to that of a Product Owner, for example, the business analyst or delivery manager role. Sometimes, the people management department copies from other Product Owner job ads that they believe correctly reflect the organization’s requirements. So, don’t be too surprised to see a job advertisement that looks like a Swiss-army knife of required skills and traits, including multiple Product Owner anti-patterns.

Red Flags: A Sign of Cargo Cult Agile or just on Organization at the Beginning of the Agile Transition?

This is often the case when an organization’s people management does not have a lot of experience in hiring agile practitioners because they are in the early stages of the agile transition. Therefore, an unusual job description does not imply that the organization is not trying to become agile; it may just mean that the people management department has not yet caught up with the new reality. Such an advertisement can help raise the topic and benefit during the job interview.

However, be aware that if an organization that claims to be agile is using this kind of advertisement despite being well underway on its agile transition, it then raises a red flag: miscommunication in the hiring process may indicate deeper issues or problems at the organizational level. It could be as critical as someone at the management level, to whom the new Product Owner would likely report, having no clue what becoming agile implies.

A Brief Refresh: The Product Owner Role According to the Scrum Guide

Before we dive into the job ads, let us briefly check the manual on the accountabilities of the Product Owner:

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is also accountable for effective Product Backlog management, which includes:

• Developing and explicitly communicating the Product Goal;
• Creating and clearly communicating Product Backlog items;
• Ordering Product Backlog items; and,
• Ensuring that the Product Backlog is transparent, visible and understood.

Source: Scrum Guide 2020.

Product Owner Anti-Patterns from Job Ads in 23 Examples

Let’s have a look at some examples of Product Owner anti-patterns from 60-plus German, UK, and US job descriptions that should raise a red flag:

1. The Scrum team spokesperson I: “Your responsibility: Provide product presentations to stakeholders and customers.” (All Scrum team members need to communicate with stakeholders and customers to avoid losing critical information in translation. That is a reason for having, for example, the Sprint Review with stakeholders and customers.)
2. The Scrum team spokesperson II: “Represents the team, when needed, to external stakeholders, leaders, and other teams to ensure alignment and understanding progress of the team.” (See above; it is crucial for any Scrum team’s success to directly communicate with stakeholders at all levels and from all constituencies.)
3. The business representative I: “You will partner with the scrum teams, solution architects, program/project managers, and business on transforming product vision into product releases.” (The Product Owner is a member of the Scrum team; partnering is hence not required. This notion points at a management model that still distinguishes between “business” and “engineering.”)
4. The business representative II: “The Product Owner represents the business team in prioritizing the features for development, approving user stories, and ensuring clear communication flows back and forth.” (See above; this example of Product Owner anti-patterns again points to a fundamental misunderstanding regarding the prerequisites of a successful Scrum application: there is no differentiation of “business” and “engineering.”)
5. The business representative III: “Acts as the single voice for all stakeholders to the Team.” (This ad features yet another formulation of the same fundamental issue, see above.)
6. The aide of the product manager: “Help your product manager think through products by making difficult tradeoffs and removing roadblocks.” (The Product Owner is seen as a tactical delivery aide for the product management when working with Scrum teams, the boot on the ground. This is barely compatible with Scrum’s understanding of the Product Owner: “For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.” Source: Scrum Guide 2020, see above.)
7. The enforcer: “Your tasks: Enforce smart solutions.” (“Enforcement” is not part of the vocabulary of a Scrum team, as Scrum values guide its way of working. The collaboration among the team members is based on respecting each other to be capable, independent people.)
8. The technologist: “Define a future-proof technology stack in accordance with the overall IT architecture. [You will] challenge technical decisions of engineers and review and evaluate deliverables in detail.” (The Product Owner provides the “why” a Scrum team shall build a Product Increment; however, the Developers decide on the “how” to maximize checks & balances within the Scrum team: “No one else tells [the Developers] how to turn Product Backlog items into Increments of value.” Source: Scrum Guide 2020, see above.)
9. The whip: “Monitor the project team, ensuring that tasks are allocated and delivered according to the plan and escalate where a deviation to plan is likely.” (The whole idea of applying empiricism is to mitigate risk and uncertainty with inspection and adaptation, which includes deviation from a no longer valid plan. And we do this in a self-managed manner; there is no need to escalate as we are all grown-ups.)
10. The delivery manager: “You manage the whole development process, from ideation to delivery.” (The Scrum team is self-managing; there is no need for a delivery manager as the Scrum team decides on this part collectively.)
11. The foreman: “You’ll work alongside the Product Manager to write epics, features and user stories and drive the sprint process.” (The Product Owner does not “drive the sprint process.” Inspecting progress towards meeting the Sprint Goal is the accountability of the Developers: “The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.” Source: Scrum Guide 2020, see above.)
12. The Scrum manager: “[You will be] running Sprints and Scrum.” (Scrum teams are self-managing, and Product Owners contribute in their capacity as team members; however, they do not “run” the show.)
13. The impediment remover: “You’ll be responsible for clarifying the acceptance criteria and for setting the sprint plan as well as removing roadblocks to enable features to be delivered in a timely manner.” (The Product Owner neither sets the “sprint plan” nor removes impediments. The latter is the task of the Scrum Master, provided the Developers cannot resolve the issue at hand themselves.)
14. The master of ceremonies: “Can lead agile ceremonies such as sprint planning, review, grooming, and retrospectives for your team(s).” (Again, Scrum teams are self-managing; there is no need for “leaders.”)
15. The Scrum mentor: “Leading and mentoring scrum teams.” (Scrum teams are self-managing; the Product Owner does not “lead” them. Also, mentoring is part of the Scrum Master job description. Of course, support from the Product Owner to other team members regarding product-related issues is always welcome.)
16. The compliance manager: “Every two weeks, you agree the functional scope to be implemented with the development team on the basis of stories that meet the Definition of Ready (sprint backlog).” (The Scrum team agrees on the Sprint Goal of the upcoming Sprint, and the Developers pick Product Backlog items accordingly. Whatever item they choose is right to go; a “Definition of Ready” is an anti-pattern in and of itself.)
17. The approval instance I: “You test finished stories and accept or reject them every two weeks (based on the Definition of Done).” (Product Backlog items do not require approval by any instance to become Product Increments. They do so by merely meeting the criteria of the Definition of Done. This additional quality assurance step signals a deep mistrust on the management’s side regarding the self-management of a Scrum Team.)
18. The approval instance II: “Providing sign off to accept each user story.” (There is no sign-off in Scrum; when a Product Backlog item meets the Definition of Done, a new Product Increment is created, and the Scrum team may decide to release it.)
19. The Six Sigma black belt: “Key skills required: Strong knowledge of Process strategy, design and implementation – ideally LEAN, Six Sigma, ITIL and Design Thinking.” (For successful Product Owners, Six Sigma and ITIL are questionable choices. I wonder how Design Thinking slipped into the selection of key skills.)
20. The snitch: “Escalating issues/concerns immediately in order to avert projects running over time or budget.” (The inability to understand complexity meets the industrial paradigm of budgeting and “resource” utilization maximation. Why look for a Product Owner in the first place when waterfall planning seems to work for your organization?)
21. The bookkeeper: “In collaboration with RTE and Scrum Master, provide periodic status updates to business stakeholders and upper management; is the point of contact for the agile team with the business and SMEs.” (Direct communication with stakeholders is vital for a Scrum team’s success in creating value for customers. Therefore, we entertain events like the Sprint Review where stakeholders get a first-hand impression of where the Scrum team is and how they may accomplish the next Product Goal.)
22. The planning optimizer: “You use story mapping, epics, user stories and other product management methods to plan your sprints optimally.” (Sprint Planning is a collective effort of all members of the Scrum team. Using “optimally” in this context may also hint at a mindset that maximizes team member utilization.)
23. The resource utilization maximizer: “Ensuring QA resource is available throughout the project, ensuring that the best use of resources at all times and is in line with the agreed delivery plan.” (Everyone on the Scrum team is responsible for quality as defined in the Definition of Done. There are no team members dedicated to quality assurance. And for the last time: humans are no resources.)

Conclusion — Product Owner Anti-Patterns from Job Ads

In my opinion, the jobs ads reveal three interesting organizational issues:

1. The idea of a self-managed Scrum team—including the Product Owner—that is so fundamental to Scrum’s success hasn’t yet arrived in many organizations. Still, the business needs to represented in the development team, and the latter has to be whipped into shape with scope, budget, and deadlines.
2. This effect may result from the confusion that organizations experience when they arbitrarily distinguish between a strategic product manager role and an operational or tactical Product Owner role.
3. As a consequence, organizations may sacrifice much of the effectiveness and productivity Scrum teams can achieve when not impeded by organizational dysfunctions and mistrust at the management or leadership level.

What other Product Owner anti-patterns from job ads have you noticed? Please share your findings with us in the comments.

Business & Finance Articles on Business 2 Community

(11)