In the previous post we have seen what the Product Owner (PO) does, what differs him from typical project management roles and what are some of the skills or personal characteristics that are expected from him.
In this post we will go through the problems that might occur with Product Owner role and through challenges that POs face in their work. At the very end I’ll give my view on where should this role sit in the organizational structure.
Let’s start with problems that might occur with certain PO.
Pusher of the team happens when PO believes that development team has to be pushed in order to deliver. This might be consequence of his personality, company culture or a belief that team should produce more features. Scrum Master has important role in overcoming this. He should help PO understand the efforts made by the team. He should, also, help PO get closer to the team, include him in team events. In this way PO will be exposed to what happens in the team and what the team is working on, what obstacles they face which will help him understand that pushing them by force won’t make them more productive.
Management’s pup is a PO that tends to agree with everything said by the management. Generally this is the person without his own opinion, the one asking line managers to make decisions. Often this comes from Project Managers who got the PO role without true understanding of the Scrum or the roles in it. PO is a part of the team and should defend team same as Scrum Master, just in different situations and from different stakeholders. In this case, presence of external coach might be of help. Sometimes person from outside of the company is needed to notice and propose action in situations like this.
Inexperienced or PO without empowerment cannot make decisions, often asks his superiors for permissions or opinions. The consequence is negative impact to velocity, team losing focus, him losing credibility. While this sort of PO might resemble to the one described above the motivation is different. Whereas the pup acts from his beliefs, this sort acts because he cannot do differently. The solution is to empower him for decision making and also to reassure him that he has trust from the organization. Matching inexperienced PO (if this is the only choice) with an experienced Scrum Master could help the team dynamics.
Organizational setup turning PO to sorting algorithm, or in other words PO becomes proxy to developers. Consequence of this is that product development and product future are under question because it is not clear who is responsible for the product strategy. If there’s someone else in the organization who is responsible for product vision and strategy, then PO role becomes questionable. Here, organization has to ask itself whether it needs PO, and with it, whether it needs Scrum and Agility. In order to overcome this, a decision has to be made upon organization strategy.
PO a micromanager, trying to control team to details. This might create an issue with Scrum Master as this kind of PO can start overtaking some functions taken by the SM. In addition this behavior creates frustration in the team. This can be handled through communication between PO and SM, but things can get smooth with presence of external coach.
One PO works with multiple teams – generally, there should be one PO for one team. Deviations can work if there are 2 teams that perform over one product, or 2 teams working on closely connected and relatively simple products. But giving 2 or more products to single persons, something will suffer. When you look back to what are the tasks of PO and imagine that this person has to perform all of them for 2, 3 or more (!) products, it is obvious that focus will be lost and that prioritization will start happening.
At that point none of the products/teams is treated well. Those that are in focus still suffer because they don’t get full attention, those that are not in focus suffer as they get only minimal attention which is just enough to be not-dead, but not nearly enough to be really alive. Here solution is clear, a new PO should be introduced for separate product.
Let’s take a look at some of the challenges POs meet in their work.
Organization or the team doesn’t understand PO role. This happens in the early phase of Scrum introduction into the organization. Some misconceptions have been mentioned in the first part of the post. PO role is confused with roles already known to the organization. This leads to wrong expectations from the PO resulting to frustrations of both the PO and rest of organization (or the team). Way to overcome this is education of the organization which has to be led by a PO with support of SM.
Management expecting hard commitment regarding deadlines for feature delivery. This is, probably a field where many battles have been fought and undoubtedly where many a good PO sacrificed his live (or at least nerves). Management used to waterfall delivered projects will tend to ask for exact launch date of the product or specific feature which may be months away. Understanding that the team is not committing to a set of features but to quality and value to the customer is very often serious stumbling block in PO – management discussions. Simply, introducing Scrum into the organization used to waterfall will cause a clash of cultures. Here, a top management committing to agilizing company, as well as education of middle management can help.
Somehow hand in hand with this one comes management expectation towards bug-free code. This one is not solely PO’s concern, but also a SM’s, as questions like: “Do we have to spend time on bug fixing?”, “Can’t you produce bug-free code?” and similar come both to PO and to SM. However, PO is at the first line defending the team toward the management. To be clear, question like: “What can we do to reduce number of bugs?”, or “How can we spot bugs sooner?” are completely legitimate, but imagining that bug-free code can be produced shows deep incomprehension of the software development. Education of the organization, possibly by someone outside of organization (e.g. coach) could provide help here.
Work processes are not aligned with Scrum/Agile. This one goes outside of software development and usually is visible in connection with finance or sourcing team. Typical example is the way how budgeting is done. Traditionally, a budget is decided up-front for the whole project, or in case of product budgeting is done quarterly (at some organizations even yearly). The mismatch between this way of budgeting and Scrum which operates in incomparably different time scale is huge. While the organization is trying to get a one year commitment for the costs and benefits of the project, PO works in a fast lane of delivery value in sprint by sprint rhythm, with constantly changing scope of the project. The problem with this challenge is that finance processes are most rigorous, rigid and hard to change. So POs are usually stuck with them to fight any way they can. I’d like to stress here that there are alternative ways of budgeting should organization be willing to try.
Uninterested management. This type of management occurs when organization has decided to adopt Scrum because it seems as modern thing to do. The good thing is that you (as a PO) can do whatever you want. The bad thing is that if you need a support to push something through organization – you don’t get it.
Organization focused on resource optimization instead on value delivery. This one is typical for corporations. The biggest concern is if all the people will, at all the time, be fully utilized. The things like, what they are doing and if they are producing value with the lowest possible level of waste, are out of the picture. Again this shows clash of cultures. This issue comes from inconsistent strategy. Should company decide to be Agile, it should embrace all the values of Agile way of work. In this example, the ultimate goal should be value delivery, and if that requires that some people are not 100% utilized, then so be it. Maximal value delivery to customers brings more value to company than fully utilized workforce.
No real support for the decision making. In the companies starting their transformation journey toward more Agile company it is no wonder that management (even top management) states that they support Agile way of doing things, Scrum, PO role. However, often this stays at official announcements or official speeches, whereas in real life there is serious lack of concrete support. The solution for this is complex and goes into the direction of change management and execution of digital transformation. Without going into details here, I would say that decision to go into the direction of higher agility has to be anchored into the corporate strategy, engagement of external coach, strong ownership of transformation journey by chief digital officer and refreshing corporate culture with newcomers from digital industry.
Finally, at the end, let’s check where in the organizational structure PO sits.
Sometimes people get confused on this as PO is closely connected to development team, but also acts in the product management area.
PO is part of the team. He sits together with Scrum Master, developers, UX designers… It is vital for the success of the product and the team that all those people sit together. When we speak of the line organization, usually PO sits with the business side. Depending on the organizational structure it might be a position in product management, marketing, digital or product development.
Where he is on the org chart is less important. What is important is that PO should be empowered to make decisions. He has to be the owner of the product, not just formally, but truly. He should be able to set vision, and do whatever it takes for the product to be a success. Don’t forget, PO is the one who is accountable for the product. This, by all means, requires a great trust to be put in a PO, but in general, it’s all about trust. If you don’t trust in the decisions made by PO, change the PO, don’t change his role.
If you want to understand more about Product Owner role Certified Scrum Product Owner Course is the right choice for you! The next public Certified Scrum Product Owner Course is in upcoming Agile Month – Spring 2019.
