20 Bad Behaviors of Agile Development Product Owners


I've worked with some very strong Agile Product Owners, others that needed a lot of help transitioning from BRD centric waterfall product management, and others that have strong backgrounds in other product roles (product strategy, management, or marketing) and are new to agile product development. 

I've partnered with many successful agile product owners that have launched innovative products, instituted new technologies and transformed business processes. But even with the strongest, most successful ones I've witnessed bad behaviors from time to time.


Agile Product Owners Behaving Badly

So here are some of the destructive behaviors of a product owner. I've compiled the list so that product owners can review and reflect on their own behaviors and practices and for Teams to point bad behaviors when they surface. 


Bad Behaviors

  1. Doesn't show up for demos 

  2. Never thanks the Team - always wants more

  3. Blames the agile practice and the Team when things go wrong


Issues in Product Definition and Requirements

  1. Anti - MVP. Does not define simple products. Focuses on the edge use cases and complexity

  2. Defines solutions, can't state the business problem

  3. Thinks the Dev Team should only be consulted once the product is defined

  4. Angered over missed requirements, but doesn't read the stories

  5. Still writes the BRD, then expects the Team to translate them to user stories

  6. Under-invests in reviewing usage and performance data to determine product priorities

  7. Lives outside the agile tool and process

  8. Sets and communicates the release timeline without consulting the Team

  9. I've delivered the product roadmap, please send me your project plan and costs

  10. Drives teams to brainstorm solutions for feature/epics that are not formally prioritized

Difficulties Partnering with Technology Teams

  1. Selects technologies (including SaaS) and expects the IT Team to implement them

  2. Expects Spikes (stories for research and development) to succeed all the time

  3. Under allocates time to tech debt, research, and documentation

  4. Doesn't formally prioritize and shifts priorities in the middle of sprints

  5. Pushes the team to compromise on technical standards (security, data governance, IT Ops)

  6. Holds teams accountable to early story estimates and circumvents estimation process 

  7. Attempts to micromanage and wants granular details on how stories are being allocated to team members

If you've experienced any of these with your product owners or you'd like me to elaborate on any of them, please comment!


1 comment:

  1. This is like a bio for my current Product Manager. Spot on!

    ReplyDelete

Share