Last updated on | Product Owner

Find out these great 20 Product Owner AntiPatterns in Scrum

by Luís Gonçalves
product owner antipatterns


During whole my professional life, people spent hours telling me the importance of good design patterns. I believe all of us bought books about design partners, cookbook recipes or any other type of book that would give you the right practices of the industry.

I do not have anything against that and how could I? Myself wrote a book about Agile Retrospectives tools box :). All these books are useful and necessary, but during my career, I understood that writing about good practices is not enough. We must write about what we should not do, the anti-patterns, the smells like I call them.

During the next few weeks, I will be spending some time writing about this topic. I will be writing several blog posts about the smells of different roles in Scrum and about various errors that companies usually do when we implement scrum. I will start this series with Product Owner AntiPatterns.

No single Product Owner for one team

I see this phenomenon happening quite often in organisations that implemented SAFe (Scaling Agile Framework) in the past, dropped and returned to simple Scrum. In the SAFe framework, you have two roles: Product Manager and Product Owner. The Product Manager is the one thinking more in a strategically way; the Product Owner is the one thinking more about the daily activities.

When companies go back to Scrum there is no more two roles, there is only Product Owner, but companies do not want to fire anyone, so they assign two product owners to the team, even if they still use the same mindset: assigning one person to the strategically part and another to the daily activities I see this as a failure.

I believe it’s tough to work with this scenario; you must have one single person responsible for the whole product, like a friend of mine used to say “one single neck”.


Companies must understand that is not possible to have this scenario and they must provide an environment where each team has one single product owner.

Interference with the daily work

I saw this happening in several organisations but mainly because of two significant causes. First, cause the Product Owner in his past was a typical project manager where he was chasing people to get a job done. Second reason relies on the fact the Scrum Master is not active, and the Product Owner must step into and do a lot of the activities of the Scrum Master, taking the role to serious ending up controlling and interfering more than helping.

In this situation is normal to see Product Owner taking a quite active role on the dailies, manipulating the normal process. Another problem that I see quite often relies on the fact of Product Owners track what developers are doing.

I saw several examples of Product Owner talking directly with developers asking what they are doing because they are not assigned to any task. Now imagine how developers felt when suffering this kind of control.


I believe the solution for this case is to find a strong and experienced Scrum Master. An experienced Scrum Master understands quite well both roles (Scrum Master and Product Owner) and can coach the Product Owner to allow the team to take responsibility for their tasks.

One of the roles of Scrum Masters is to protect the team from intrusions, having a strong and experience strong master within the team will allow the team to remain isolated and protected from unwanted interferences, and at the same time will allow Product Owners to be coached on right behaviours.

Stories built around product layers

This is a tricky topic. Over the last months, I have been working with teams that cannot deliver as fast as they could if they would use other approaches. They made a quite typical mistake; they have user stories that are built around layers of the product.

As an outcome user stories are dependent on each others causing a lot of delays to deliver a product that can be usable by the customer.


In general, a good user story should be written covering all the layers of the product. Should be an end to end user story. The solution for this problem is the coach the Product Owner and the team about this.

For me works quite well when I explain to developers that do not matter if we deliver 200 back end user stories when in reality the customer cannot use them without the front end part. Below there is a picture from Ángel Medinilla that shows in a great way how stories should be built.

Product Owner AntiPatterns

No projection of the product backlog

Usually, the Scrum Master produces burn down charts showing how the sprint went. This is quite common, what is not so common is the Release/Program burn down or burn up. This is a quite common problem in many of the organisations where I worked for.

Not having this kind of information make the life of Product Owner harder because it gets harder to know if the team is on track or not.

With this kind of information available, the Product Owner can take better decisions about the scope to deliver the product on time, bringing the biggest amount of value to the customer.


The solution here is quite easy. The Product Owner should build a product burn down/burn up exactly as the Scrum Master does, but instead of being focused on the sprint, the Product Owner focuses on the release. A possible example can be observed below.


Backlog is filled with a bunch of “Strings”, not proper user stories

This problem is by far one of the most commons that I observed during the last years. Most of the times the product owner does not write the stories in a proper format, he just writes few key words, and that´s it. The problem with this approach relies on the fact that everyone outside of Product Owner head will not understand what the user story is about. And to be honest, I saw some examples where not even the product owner knew what he wanted to solve with some of the user stories that he wrote.

To point out to the solution, I am using a blog post from Roman Pichler. “10 Tips to write good user stories“.

The Product Owner is underpowered and does not act as the guard of the backlog

I saw this situation happening in some of the companies where I worked. Unfortunately, companies do not realise how dangerous this is. In these companies, the product owner did not have the power to decide anything and managers could change the backlog as much as they wanted.

This situation leads the Product Owners to no longer care about the product. They started to not care with the ROI, and they completely lost all their entrepreneurial behaviour.

Usually, this happens with traditional management, where they want to control everything that is part of the Product Backlog, not giving any freedom or trust to the Product Owner.


My experience tells me this situation is quite difficult to resolve because most of the time this problem comes from managers above the Product Owner.

In this case, the Scrum Master or the Agile Coach has a fundamental role to play. He is responsible for talking with the management (or with anyone else who is behaving in this way) and explaining how this behaviour has an impact on the company and the quality of the product.

I have witnessed several situations where the Agile Coach was able to explain to Senior Management what was happening and was able to help management to change their behaviour.

The Product Owner that uses estimates to set deadline demos for clients

Here we have a typical problem that is common in people who do not understand the basics of software development. This is much deeper than Agile software development. The people who do this do not understand how software development works, so their estimates are just an approximate calculation; they do not guarantee that everything will be done by a certain date.


A lot of people approach me telling me that sometimes we do not choose the release dates and we have deadlines to be met. Therefore, there is no way to behave in a different manner in this kind of setup; the customers just want to have their product.

For those who do not know me, I worked for a huge mobile manufacturing company for years, so I understand what dates set by the market means.

Every year we had Christmas sales where the phones needed to be out; there was no other solution, so how could we manage this? The answer is simple: follow basic agile principles.

The Product Owner must educate the client that after every sprint the team has got something to show (with this the Product Owner gets his demos). During the sprint demo/review, the client has the opportunity to provide feedback on what was delivered.

And more importantly, has the opportunity to select the most important things that are on the backlog, enabling the team to always deliver the most value to the client.

At the same time (and this is one of the most frequently forgotten practices), the Product Owner checks the overall release status using Releases Burn Downs. This practice allows the Product Owner to know exactly where the team will land, and start a discussion with the client about what can be dropped in the event the team is not able to deliver on time.

If the client is not open to all these suggestions, the company should start to reconsider if the client is someone with whom the company would like to work in the future. The problems that will arise from future interactions will be so complex that the relationship will not benefit any of the parties.

The Product Owner is too busy for the team; he has too many teams

I see this problem too often, Product Owners who are completely overloaded with work: the overworked Product Owner.


Product Owner should not have more than two teams. Of course, this is a general rule, and it might be possible to have more, but if he/she has more than that, it can be difficult to give full support to the teams.

The Product Owner is too busy for the team. He spends a lot of time in meetings with clients

This case is a bit different than the previous one, but the result is the same (for the team). In both cases, the team does not have the support of their Product Owner, making the task of developing the right software difficult.


The job of a Product Owner is not simple; it´s a tremendous and complex job, sometimes the product is so complex that one single person might not be able to manage everything.

I’ve seen some companies that brought business analysts to the team; these people took the responsibility of talking with clients to see what the market needs, leaving the responsibility of the technical product to the actual Product Owner. I saw this technique in several companies, and it worked quite nicely.

The Product Owner Proxy

This person acts as a placeholder for the actual product owner. This can lead to delayed decisions or even conflicts. The author of Agile Product Management with Scrum, Roman Pichler, refers to a case where the PO was too busy to take the role. Therefore a company got a proxy PO.

In the end, there were various conflicts because the proxy PO was not empowered to make decisions and all decisions were supposed to be made by the official PO who was never available.


Each case is different, but as a general solution, I believe that we could try to use the same approach as in the first example. Having a business analyst within the team could help the Product Owner to get more time to help the team to deliver the right product.

Product owner community

This happens to companies that create a committee to be responsible for a product. When there is no one person responsible for the product, it can lead to delayed decisions. Often, most of the people involved want to reach an agreement between all parties, and this will lead to lengthy meetings without any proper outcome. This is a typical case of “too many chefs in the same kitchen”. This is quite similar to one of the problems that I raised above.


Each product should have only one Product Owner. My experience tells me if we have too many people responsible for a product we have none. Never assign more than one Product Owner to a product. If you have several products that are connected with each other, you might need to have a program.

In that case, you should get a Program Manager or a Chief Product Owner as some companies call it, but never more than one person responsible for a product.

The Product Owner sacrifices the quality of the product to ship the product faster

I see this happening quite often, especially when a Product Owner is under external pressure. Stakeholders push Product Owners to release the product faster, even if the quality is not the best.

Of course, this approach will damage the company over the long term; everyone knows that poor quality software will sooner or later create problems and damage the provider’s reputation.


This problem is quite serious and, in my opinion, is something that is part of the company´s culture (not caring about quality). The method I found most useful to reduce this problem is the presence of a Definition of Done Checklist.

Definition of Done Checklist is a simple list of tasks defined by the team that represents all the activities that must be done before a story goes into production.

Without a Definition of Done Checklist, it´s easier for the Product Owner to push the team to cut corners; if this list is there, on the other hand, it´s possible for developers to show that a story is not done until all tasks that are part of the Definition Of Done are completed. My experience tells me this helps to reduce the problem.

If you are interested to know how can you Mature Your Definition Of Done check this blog.

Confusing the Product Owner role with the Scrum Master Role

I saw this happen many times in companies where Scrum Masters were passive for a week or two. In this situation, Product Owners lack the necessary support from the Scrum Master, and they start to take care of all the activities inside of the team.

At some point, the Product Owner no longer knows what his role is, and what the Scrum Master role is. This causes a lot of confusion and, worst of all, conflicts and mistrust between the Product Owner and Scrum Master.


The solution here is quite simple, but not easy to implement at all. In this case, it is extremely important to get an experienced and strong Scrum Master. Great Scrum Masters can do their jobs in a well, but even more importantly, they can coach others in their jobs.

Great Scrum Masters are great coaches as well, so having a strong and competent Scrum Master in this situation is fundamental to improving these issues.

The Product Owner who expects a stretched commitment because “based on their experience it shouldn’t take that long.”

It is quite common to see this behaviour from old school project managers, where commitments were almost forced by project managers or stakeholders. Another possible cause lies in the fact that Product Owners are ex-tech leads or architects.

In this situation, the team is dealing with someone who has great technical skills and who expects the team to solve the issues in a faster way.


In both situations the Scrum Master’s job is quite important; he must protect the team. He must explain to the Product Owner that the team owns their estimates. They are the ones deciding how much it takes to deliver that amount of work and there is not much he can do.

The Scrum Master must explain to the Product Owner that the team’s members are doing their best and he needs to trust them.

Being Product Owner because they’re a department lead/manager. 

In some companies, the Product Owner role has some semblance of power, and many people will try to grab this position even if they do not have any interest in the product itself. They use this position as a platform to increase their political power.

As you can imagine, most of the time the outcome of this is poor and lacking in quality, driving everyone to frustration.


In this case, I truly believe there is not much that I can suggest; management must understand that a Product Owner is extremely important for the company and only people who understand customers and the market can do a good job.

Assigning people to these positions who do not understand the market or the customers is a recipe for disaster. I can only suggest that management assigns people based on quality and not based on political interest.

The Product Owner who feels it is not their role to maintain the backlog or delegates all of the actual User Story writing to the team and SM

I did not see this happening too often (fortunately) during my career, but it does happen. This type of Product Owner thinks his or her job is just to dump ideas into the backlog and that someone else should be doing the boring job of transforming the ideas into stories. This kind of Product Owner thinks that his job is too important to be spent on secondary tasks.


I believe the Scrum Master and the team itself have an important role here. Together they must explain to the Product Owner that the aforementioned is his job. They must explain that without a proper backlog the team cannot do their jobs.

The stories should be discussed between the Product Owner and the team. The Product Owner is the person ultimately responsible for keeping the product backlog in good shape.

The Scrum Master and the team must show to the Product Owner that it is extremely difficult to do any work if the product backlog is not maintained. A good story must be clear, optimally written in the INVEST (Independent, Negotiable, Valuable, Estimable, Scalable and Testable) format with proper Acceptance Criteria.

The Product Owner who thinks a Scrum Master is just a project manager whose role is to pester people into doing their job

Sadly, there are still a lot of people do not understand anything about human behaviour. There are a lot of people who still think that punishments and pressure work quite nicely to motivate people.

A lot of these Product Owners still believe that people are lazy and need project managers to keep them in line, and of course, the Scrum Master fits perfectly into this job (according to their point of view).


The solution here is not easy to achieve at all. I truly believe this has more to do with mindset than with any agile process. I would suggest taking this Product Owner to a good agile training session to make sure that he understands what the roles are in Agile software development.

To complement this, I would take him to a good training session about intrinsic motivators to help him understand what drives people to do a great job. If he would not like to attend any of these training sessions, maybe give him the book Drive by Daniel Pink. Hopefully, he will then understand that punishment or pressure will never motivate people.

Hopefully, he will then understand that punishment or pressure will never motivate people.

The Product Owner who refuses to choose between five top priorities 

I see this quite often; the Product Owner calls the most important story a Must, then there appears another story he says is more important, they become a Must-Must story, and so on. This clearly shows that the Product Owner does not understand what the single most important thing that must be achieved during the next sprint is.

Having the teams working on several important issues is a dangerous factor. Not too long ago, some of my teams were working on different goals to be achieved in a single sprint. The result was poor, there was no focus, and while everyone worked on everything, the teams constantly failed to achieve their goals.


Here it is quite important for the Product Owner to understand what the most important things are that must be delivered to the customers.

Product Owners must understand the team cannot deliver everything at the same time, so they really must understand what is the top priority that should be achieved during the next sprint.

When we applied this rule in some of my teams, teams got extremely focused, and they started to deliver much more stories per sprint. But more important than that, they started to deliver fully implemented features that could be shipped to the customer.

Before, the teams were delivering a lot of things, but none of their features was ready, blocking the release to the customers.

The Product Owner who insists on architecting the solution design

I mentioned above that sometimes the Product Owner is an ex-architect or an ex-tech leader. As a result, it’s normal to have this kind of anti-patterns. The Product Owner wants to be responsible for the architecture of the product, driving the team crazy.


The Scrum Master and the team must explain to the Product Owner that the design of architecture is not his responsibility. I always like to give this explanation: The Scrum Master and the team are responsible for “How”: How the product is made.

The Product Owner is responsible for the “What” part, meaning that the Product Owner should be the one saying what is supposed to be built.

The Product Owner who does not regard himself as a team member

I do not see this Product Owner Antipattern too often, but several people have mentioned it to me. Therefore I am adding it to my list. As the name suggests, the Product Owner does not feel himself part of the team. He feels that he should only be responsible for delivering the stories and nothing more.

As you can imagine, the cooperation between the team members and Product Owners will not be the best, and at some point, the collaboration will become extremely hard.


The Scrum Guide says:

“The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.”

Just because the Scrum Guide says that, of course, there is no guarantee the Product Owner will consider himself part of the team—But, I think this could be a good start nevertheless.

The Scrum Master or the team could explain to him that, according to the manual, the Product Owner is officially part of the team.

On top of this argument, the team and Scrum Master could explain to the Product Owner they are not able to do a fantastic job unless the Product Owner starts to become more connected to them. This could be a nice topic for one of the Retrospectives.


We have developed a free assessment in the form of a Scorecard to help you establish which areas of business you need to focus on to achieve your particular Organisational Mastery.

Take The Test

If you liked this article, feel free to visit my company Products and Services pages.

We provide Team CoachingAgile Training, and Agile ConsultingOKR TrainingOKR ConsultingInnovation Training and Innovation Consulting.

With my team, I built 5 main products: High Performing TeamsScrum Team CoachScrum Master MentoringOrganisational Mastery and the External Business Accelerator.

Rate this post:
Luís Gonçalves

About Luís Gonçalves

Luis Gonçalves is an Entrepreneur, Author & International Keynote Speaker that works exclusively with Senior Executives of 7 to 8 figure businesses on the deployment of his game changing ‘Organisational Mastery’ Methodology.


Share your point of view

  1. “Given this story, is it sufficient to write a test?” This is a question I ask during Spring Planning to enforce the concept of a properly written story and Acceptance Criteria. If one can write a test given the story, then TDD can be supported and the PO knowledge can be embodied in the test, and therefore in version control.

  2. Thank you very much for sharing this info. As a Scrum Master, this post helps me to reflect that some of the problems I’ve seen in my organization are really common. It brought me awareness and strength!

  3. Hi Luis,

    Nice article and it talks truth as I have similar experience.
    one the reason why PO tries to interfere with Dev team is if
    you have distributed team, where product owner and Dev team working in same time zone and SM is in other time zone.

  4. Good post Luis.

    You have pointed out exactly the problems that I see happening at my organization, particularly in less experienced scrum teams.

    I just think that you don’t point all the solutions exactly right. For example, what should be done if you can’t find an experienced scrum master to coach the PO? What can be done to empower the SM for example?

    1. Thanks Hugo.

      If you do not find a good internal Scrum Master that is able to coach the PO there is no miracles 🙂 Company must pick up an external with long experience 🙂

      What do you mean with: “What can be done to empower the SM for example” this too way to vague 🙂 I need some concrete examples :).


  5. Luis, love the entire article… except… the bit about the PO not being allowed to delegate the work of maintaining the PBL and stories.

    The Scrum Guide was changed in 2011 to allow the PO to delegate some or all of this legwork off to the Dev Team. “The Product Owner may do the above [Product Backlog Management], or have the Development Team do it. However, the Product Owner remains accountable.”

    I’m in 100% agreement with the SM not being involved in “doing the PBL” work, though the SM can “coach” the PO and/or Dev Team on good techniques for doing that of course.

    I would suggest a bit of word smithing to that section. I sometimes say that the PO owns the decisions of the PBL, but who does the legwork of maintaining the PBL is a combination of PO and Dev Team that will vary widely from team to team.

    1. Thanks Charles 🙂 for your nice explanation and share your ideas 🙂

      To spice up this conversation a bit I can tell you something 😉 I couldn’t care less with what the Scrum Guide says 🙂

      Scrum Guide is a Guide (like the name says). My experience tells me that before you can actually delegate BL responsibilities to the team or to the Scrum Master you must have a pretty good team (which in most of the cases takes months) then you can start to think about it :).

      Of course everything depends on the context around the team, but as general rule I like to keep the PO fully responsible for the backlog 🙂

      Big thanks once again,

  6. This is a great summary of most of the challenges with product ownership. I had similar experiences, when I decided to try to sketch a poster around such frustrations.

    There is also a tendency for companies to setup Product Managers (looking after business product use cases & strategic planning), and for each application platform, spawn off scrum teams, for each scrum team, assign a product owner (because that’s what Scrum prescribes right ;-). You then get into the topic of “ringfencing” which comes with its own set of challenges.

  7. It looks like the “Typical Product Owner mistakes in the organisations” page, linked in the introduction, redirects to this page. Where has it gone? 🙂

  8. Luis,

    Thanks for this post — I find it quite relevant and useful. I believe you touch upon a real flash point when you discuss having “one single neck.” I have swung both ways regarding the split between Product Owner and Product Manager, going back to the introduction of the concept in Moore’s book “Crossing the Chasm.” I am familiar with the SAFe concept, and have seen it in practice, with the associated confusion you note.

    On the other hand, there are some different skills required for the positions. Product development firms often elevate developers into Product Owner/Manager roles, and split out the marketing responsibilities into a different role. This reflects an engineering-centric approach. This works well for some of these firms, as exemplified by Google.

    Perhaps there is no one-size-fits all answer as to how best to cover the essential activities described by Product Owner/Technical Product Manager and Marketing Product Manager. I must admit, I do not have a neat answer myself.

  9. I’m a developer with 25 years experience. I know to walk away whenever I see a team setup where: 1) I don’t get to speak directly with end users to clarify requirements, 2) Nobody ever defines the problem being solved. They confuse describing one solution (theirs) to an undefined problem with that activity, 3) There are more people coming up with ideas than there are implementing ideas. Ideas in and of themselves are worthless. Most of us come up with ideas all the time. Execution of ideas is what matters.

    Other red flags include people that use UML predominantly to describe “requirements”. These diagrams were designed to be ambiguous. They are intended to allow each reader to see what they want to see, whilst each of the users, intermediaries and developers actually sees something different.

    If you’re not the person with the problem (a key user) or a person that can solve the problem using your own technical skills (a developer or architect), then you’ve no business being involved in the process. User Stories are a terrible way of communicating requirements. If I said to you “I want to go on holiday”, “it has to be somewhere sunny”, “I like learning foreign languages, so a different culture would be good”. I guarantee there would be a Business Analyst or Product Owner somewhere that would translate that into “buy 5 tickets to Iraq, and some swimming trunks”, and who would keep those underlying goals a secret.

    The roles of Product Owner, Business Analyst, UX Designer, etc, are only ever encountered in companies whose primary competence is not software development. Those teams attract poor developers who have no other options. Typical examples would be banks and the public sector, who are frequently fined for the poor performance of their IT systems. Other places don’t invent bureaucracy for its own sake. They have people who need problems solved (users), and people who can solve problems (developers). Everything else is just the software development version of a personal shopper: superfluous, unnecessary, and a sign of deep organisational incompetence.

    1. Thanks for your comment. I completely disagree: “The roles of Product Owner, Business Analyst, UX Designer, etc, are only ever encountered in companies whose primary competence is not software development.” I believe it could not be more incorrect 🙂


  10. Hi Luis,

    Congratulations for the post.
    It was really good written.
    I’m product owner from Brazil, and all these anti-patterns to happen here too, unhappily.

  11. Holly crap. Spot on, man. Thank you!
    What if I tell you that my PO suffers all of these symptions? Is there hope to get this person alligened? Or should I just quit my job because the organization is not seeing these symptoms as problems?

  12. Hi Luis, great article. I am interested in knowing your views on resolving a situation where the PO needs help/coaching but refuses to be coached or is not coachable ? Thanks

  13. “The Product Owner who feels it is not their role to maintain the backlog or delegates all of the actual User Story writing to the team and SM”.

    I am currently facing this scenario and was actually told by a consultant that the tech lead/team is responsible to write stories despite 8 years of experience in 4 other agile engagements telling me otherwise. Any advice on how to solve this one?

    1. That´s why I do not like most of the consultants 🙂 Even myself 😀 😀

      From my point of view (and I do not care what books say) Product Owner is responsible for Product Backlog. It’s very normal to have PO writing the stories, but I saw it many many times the other way around meaning the team write them.

      To be honest I could not care less, at the end of the day its a matter of talking with the team and find the best way. Forget the consultant and work with your SM and Team and figure out what is the best way for you guys.

  14. Great write up!
    I got another for you. PO only listens to business stakeholders for US and forgets the team. The normal symptom is that non functional requirements, NFR, like security / performance etc are seriously degraded over time since business normally has limited knowledge about those issues. Having someone from team responsible for driving NFR and having a fixed amount of time set off per sprint (20-30%) are some suggestions how to mitigate.