Anti-patterns that Doom a Product Owner to Fail

Organization

• Product Owner is not empowered by the organization
• The wrong person is selected to be the Product Owner
• The Product Owner is not given decision-making Authority

Product Owner Knowledge

• No training as a Product Owner
• Doesn’t understand Agile tools and practices
• Unable to adopt an Agile mindset
• Does not have the right skills and traits
• Not leveraging the Scrum Master as a coach

Leadership

• Can’t deal with conflict
• No leadership skills
• Inability to negotiate
• Not thanking and celebrating the Scrum Team’s accomplishments
• Inability to make trade-offs
• Directs the work rather than letting the team decide what to work on
• Picks solutions without consulting the developers
• Pressures the team to work overtime
• Decisions are not respected

Personality and Behaviors

• Control freaks
• Micro-management
• Lack of confidence
• Inability to say “No”
• Inflexibility
• Unapproachable
• Domineering
• Too optimistic and not realistic
• Lack of empathy for the team
• Lack of discipline
• Not listening to the developers
• Never satisfied
• Hoards decisions
• Lack of transparency
• Fixed mindset instead of a growth mindset

Fear

• Afraid to fail
• Won’t experiment or innovate
• Does not see failures as learning opportunities
• Avoids conflicts rather than facing and resolving them

Vision and Strategy

• No vision or strategy
• A vision exists, but it hasn’t been communicated or evangelized
• Not seeing the “big picture” of the product
• No success criteria for the product
• Not having an overarching Product Goal (new in the Scrum Guide as of 2020)
• Can’t articulate the business problem

Product Backlog

• Not doing backlog refinement with the Scrum Team
• Inability to prioritize
• Doesn’t protect the Product Backlog
• Thinks of the Product Backlog as a commitment
• Not providing enough “ready” stories to feed the team

Industry/Market Knowledge

• No industry or market research
• Not a subject matter expert
• No competitive analysis is performed
• Doesn’t know about or use the product

Planning

• Not planning at higher levels
• Not ready with “ready” stories at Sprint Planning

Scrum Team

• Not acting as part of the team
• Tries to control the team instead of being a Scrum Team member
• Interrupts the Scrum Team during a Sprint
• Doesn’t interact with the Scrum Team
• Lack of trust in the team
• A team without the necessary cross-functional skills to develop a done product increment

Commitment

• “Promoted” from a manager role
• Delegates Product Owner responsibilities (beware the Product Owner proxy)
• The role was foisted upon them
• Leaves the team to their own devices
• Present, but not engaged
• Only in the role because they are a department lead or manager
• Not invested in the product – it’s just a “job”
• Product Ownership conducted by Committee rather than one person

Financial

• No Control of the “Purse-Strings”
• Focusing on the wrong metrics
• No visibility into the product’s budget

Availability / Workload

• Unavailable to the Scrum Team
• Part-time responsibility
• Product Owner for more than one Product
• Product Owner has a “day job”
• Totally Missing in Action
• Not providing timely answers or feedback to the team

Stakeholders

• Caters to the stakeholder with the most power or influence
• Inability to get stakeholder interest or buy-in
• Too many stakeholders to manage and align
• Lack of access or unavailability of stakeholders
• A “know-it-all” who makes decisions without stakeholder consultation
• Keeps Scrum Team members from directly communicating with stakeholders
• Ignores stakeholder/customer feedback
• Unable to consider others’ opinions
• Not acting as the “Voice of the Customer”

Requirements

• The User Story is missing
• No acceptance criteria
• Horizontally sliced stories, rather than vertical
• Writing user stories in a silo
• Half-baked, poorly written user stories
• No definition of “Ready” or “Done”
• Stories that are too large are allowed into a sprint
• Focusing on perfection versus “good enough”
• “Technical” user stories that don’t deliver any direct business value
• An overwhelmingly large product backlog
• Dictating the how rather than the what and why
• Not following the INVEST acronym
• Pushing through unclear requirements
• Not questioning what the true business need is, versus expressed wants
• Stories that are not “ready” get pulled into a sprint
• Too many “research” spikes
• Gold-plated rather than building an MVP and iterating based on feedback

Technical

• Not dealing with Technical Debt
• Product Owner came from a technical background, rather than business
• Acting as a solution architect instead of a Product Owner
• Unrealistic expectations of the Scrum Team based on “experience”
• Product Owner sizes the stories instead of the developers
• Pre-assigns Product Backlog items to team members

Quality

• No governance
• No user testing until the end of a Sprint
• Overlooks quality in exchange for speed
• Does not recognize that everyone on the team is jointly responsible for quality

Accountability

• Not the “one neck to ring”
• Throws the team under the bus
• Not held accountable for the product and its outcomes
• No one can identify or say who owns the Product Owner accountability
• Takes all the credit for the team’s work
• Always making excuses

Scrum Events

• Participating in the daily Scrum rather than listening
• Leading the Sprint Review, rather than letting the developers share their work
• Skips required Scrum events
• Scrum events misused to gather new requirements
• Failing to terminate a sprint with the Sprint Goal becomes obsolete
• Lack of preparation
• Does not ensure a unifying Sprint Goal is created

Roles

• Role confusion
• Misunderstanding of Scrum accountabilities (formerly roles)
• Playing multiple Scrum roles

Value

• Doesn’t understand what value is in the product’s context
• Acts as an order-taker rather than value maximizer
• Focus is on outputs over outcomes
• Uses inappropriate criteria to measure the value