Why You Suck at Scrum: The Product Owner

When companies try to move from project based to a more product based approach, one of the key roles they hear they need to fill is the Product Owner. They may or may not have had a similar role identified when delivering projects, as this person typically represents the business or market need for the solution being developed. While this is also typically the perspective of the Product Owner in this new way of working, the way this person interacts with the team and the process to deliver the solution has changed from their previous role. These changes to the role are often overlooked and misunderstood, leading to a breakdown in the process, and ultimately another point of failure in their adoption of Agile frameworks such as Scrum.

Here is a list of anti-pattern examples that you may be seeing in your organizations implementation of Scrum:

Lack of empowerment

• Too many ‘Product Owners’ are merely order takers or an extension of the true decision maker. They receive their orders and pass them on to the delivery team. They may have great ideas on how to improve the products they are working on, however they may not sit high enough in the hierarchy to have a seat or voice at the table. Those at the table set the vision & strategy, and pass it on to the ‘Product Owners’ that are meant to work with the teams to execute on it.
• The Product Owner should be the voice of the customer, and by extension, the market that they are serving. They should have the pulse of the needs being identified, collecting feedback from users, watching trends and anticipating future needs. If this person is the closest to this information, why are others that are furthest from the work making decisions, typically months in advance, for the product?
• See related article ‘Product Owner Empowerment’

Not part of the team

• Possibly equally as bad or worse than the Product Owner that works as part of the team not having empowerment to drive their product, is the true Product Owner & decision maker not being part of the team, but rather stays too far removed as they ‘don’t have time to work with the team’, ‘someone else can do that part’.
• Let me state that again: Too busy to work with the team that will be designing & creating the experience your customers will interact with. The experience that may determine if your product thrives, or withers away into non-existence. Making time to discuss your product’s needs and to refine the potential solutions to those needs with the people that will actually be building those solutions is not a high enough priority, or worse is beneath your level or title. You’ve got people to do that.
• When your product does not perform as desired, or features delivered do not meet the needs you envisioned, you’ll blame Scrum, stating that you saw no improvement in the product delivered using this new way of working. But did you actually change the way you worked?

Not collaborative

• When these Product Owners used to work on delivering projects, they were normally expected to come up with all of the ideas for the product, and drive it’s success. They would take months defining needs, and then solutions that they wanted the delivery teams to produce. They were expected to know exactly what they needed, and to clearly articulate what they wanted the teams to build.
• This is a difficult mentality to break, both for the organization that has these expectations of the Product Owner, as well as the Product Owner themselves. This was how it was always done, and their performance was based on the successful delivery of a new product, or modifications to an existing product. It all rested on their shoulders.
• In this new way of working, they do have a responsibility to identify the needs, that is the problem to solve, or the opportunity to take advantage of. They should be able to clearly articulate the value of solving this problem and how it may align to the great product vision. If they can share this information with the delivery team they are working with, together they can develop a solution, collaboratively, bringing everyone’s expertise to the conversation.

Asked to provide complete requirements and deadlines with no room for learning

• Another anti-pattern that has been imprinted on Product Owners is that they need to submit a full and complete plan on how they will exactly solve the problem or opportunity identified. When we were delivering projects, these plans were locked in for months or even years, every step accounted for with no room for error.
• If the Product Owner is the voice of the customer and the market, wouldn’t we want them to have the opportunity to check in along the way to validate that what they and the team are creating is actually adding value? One of the core benefits of moving to a framework such as Scrum is to do exactly that, it’s a key part of the process.
• Every time we deliver something to our customers, it’s an opportunity to learn and validate. If we make unwavering plans with the only purpose being to deliver something across a far distant finish line, this creates a tunnel vision that misses the point entirely. When we do this we cut ourselves off at the knees, missing multiple opportunities to pivot to meet the real needs and add real value, not just what we perceived the needs were a year ago.

When moving to a new way of working it is critical to understand all parts of that change, and what it means to your organization. If the process is changing, then it needs to be acknowledged that what we are asking our people to do is going to be different. The way they approach the work, focusing on achieving outcomes rather than output, and iterating on those solutions collaboratively with a team is a huge change to the role and responsibilities we ask of our Product Owners. If you overlook this or worse undervalue it, you will greatly decrease your chances of success moving forward, and sadly, will blame the process rather than solving the problem and reaping the benefits.