+38 099 5197809

How to Accelerate Agile Transformation: Understanding Product Owner Role

What every manager must know about the Product Owner role and a new leadership paradigm to speed up Agile transformation

In our previous article, “Agile Transformation: What Mistakes Should Bosses Correct Immediately?” we promised to give you more insight into the interaction between a Manager and a Product Owner. So let us consider such notions as Agile leadership, autonomy, and the Product Owner’s role.


Agile implementation entails organizational changes — not only structural or functional. It requires a leadership paradigm shift, a new mentality formation.

This challenge often causes tension between managers and employees that slows down or stops the transition.

What is the best way to remove this obstacle? How do we accelerate the Agile transformation in our companies?

From our consulting experience, we can boldly underline the following factors that hinder companies from implementing Agile, regardless of their industry or location:

lack of leadership training;
poor understanding of the difference between the old and new management paradigms;
disrespect for boundaries in an Agile framework.

Therefore we highlight the following three problems that decelerate Agile implementation:

  1. Lack of understanding Agile leadership concept.
  2. Managers don’t understand or respect autonomy in Scrum.
  3. Poor understanding of the Product Owner’s role.


Vyacheslav Moskalenko, a co-owner of Agile.Live and a certified Scrum coach, shares his experience of implementing Agile in a global company:

“I was impressed by the leadership competence of one company I worked with. Established in Australia back in 1874 it was not directly connected with the IT field, as it was specialized in explosive systems for the oil and gas industry.
With the rise of digital technology, its leaders recognized the demand of time and formed a digital solutions unit. That helped the company to optimize production processes, expand the range of services, and gain competitive advantages in the market.

I had the privilege to implement Agile in that unit. In particular, I trained a few teams to use Agile professionally.
I was fascinated by the executives’ attitude. They didn’t tell me what to do, didn’t interfere in the process, didn’t ruin the hard work we did with the staff. The leaders were respectful of the team’s roles within the framework, having a good understanding of the Scrum framework.”

The role of the leader in the Agile paradigm is not to dictate but serve. Its job is to create a good environment for achieving a common goal.

For example, a customer is ready to order your product, provided that in three months you adapt it — bring it in line with the requirements of his country’s legislation.

How can a leader help the team? He can simply give them the contacts of the experts who could help in the project or provide them with useful external data. He can also follow the work progress — to make sure everyone is on the same page and understands the overall goal. If necessary, he gives his feedback (but does not interfere with the process or impose his own opinion!)

In Agile, a manager serves as an advisor. This doesn’t mean he tells everyone what to do. When the team asks his opinion he shares it in an advisory manner. This is exactly what happened in the Australian company that launched its IT unit very well.

In contrast to innovative leadership thinking, some popular airlines wouldn’t let go of their old school methods. As a result, they paid a high price for their reluctance. Some of the airlines went bankrupt, others barely survived due to governmental support.

To a large extent, this happened because of their unwillingness to change, regular interventions in the process, direct orders from the top management, blockage of innovative ideas, cancellation of decisions made by scrum teams or Product Owners, personal ambitions, inability to be agile and quickly adapt to new realities.

This reminds the archaic methods of the previous century. For some reason, many have a perception that such vertical models are a relic of the past. But that’s not so. Lack of agility is a universal problem.

As to the Scrum team roles, the inside of the framework is important. That includes task formulation and prioritization, Backlog, increment creation, and similar (more on a Scrum team and its roles we provide separately in other blogs and articles on our Agile.Live website), while the leader’s role is to work on the “frame” only. In other words, the role of the leader is to provide the “framework” within which the team operates.

In Agile philosophy, the leader’s success depends on the team. An Agile leader is successful because his team is successful.


Self-organized teams and Product Owner’s autonomy are among the major Agile fundamentals. Failure to understand PO’s autonomy can be too costly and misrepresent Scrum.

Consider a negative example of how managers can disrespect the Product Owner’s autonomy and interfere with the team’s area of responsibility.

Disrespect of Autonomy

Holding on to the old methods, the old-paradigm leader:

  1. Sets key performance indicators (KPI) for the team on his own.
  2. Develops an action plan single-handedly.
  3. Sets the deadlines without asking the team.
  4. Controls, interferes, ruins the work.
  5. When something goes wrong, undertakes to resolve smaller-scale emergencies personally.
  6. Out of habit, gathers useless meetings.
  7. Makes team success dependent on his persona.

In contrast to such directive methods, the Agile approach insists that it is the team, in collaboration with the Product Owner, who is responsible for solving these and similar issues.


Product Owner (PO) in Scrum has autonomy presupposing a higher level of responsibility.

From the ‘vertical structures’ point of view, a Product Owner’s role may correspond to a middle management level, but in terms of functionality and authority, it can significantly surpass the ‘boss’.

In Scrum, the Product Owner is empowered to represent the whole organization and thus has the right to make any decision related to the product.

Besides, the Product Owner’s decisions cannot be canceled. This often surprises old-school managers. Practicing a command-and-control style, they tend to negate the agile approach. As a result, their statements (“…leading the company to a new level…” etc.) remain declarative, while the approach cannot be considered Scrum.

The Product Owner’s role is called so because he must “take ownership” over the work items related to product development in the Product Backlog, the ownership on the whole product in that way.

In particular, PO is responsible for setting a task or ‘work item’ priorities, which would be impossible to do if he had no “ownership” of them.

PO’s primary role is to understand the value of the product that he has to convey to the team, taking into account the needs of users and customers.

At the same time, the PO’s role has its limits. For example, the Product Owner should not answer the question “how” (which is the team’s prerogative), although he is fully responsible for “why” and can influence “what” and “who” to some extent.

Finally, the Product Owner is a communicator at all levels who also interacts with the Scrum Master (this is a separate topic that we will cover additionally on Agile.Live).


In conclusion, one of the first things that leaders should understand to implement Agile successfully is the limits of their power and roles.

The team should not depend on any manager’s persona. The leader succeeds if his team does so.
To implement Agile, a leader should develop a particular leadership style that includes the following:

  1. Competent feedback (not to interfere, but respond; not to dictate, but advise.)
  2. Hands off micromanagement (a whole team of professionals does not need any correction from a ‘patriarch’; it is fully able to fix any minor issues that occur in any work process.)
  3. Focus on the system and strategy, not occasional issues.
  4. Ensure that all team members understand the goals, requirements, success criteria, key performance indicators, quarterly/annual goals.
  5. Instead of telling others what to do, show interest, ask questions (developing a mentor style of leadership as opposed to ‘bossy’ management.)

Back to the Australian case, those leaders created a good environment for the team, made sure that everyone understood the goals, respected the Product Owner’s autonomy, and gave enough room for the team to implement “how”. They were the leaders of the new Agile paradigm who took their company to new heights.


Announcements of Public Trainings

You ordered
Webinar Consulting Training