Background

Barbara Nelson said in The Politics of Agile, “When product managers weren’t looking, the developers went agile.” Indeed, many Product Managers were taken by surprise at the speed of Agile’s adoption. And with the introduction of a new Product Owner role and its perceived overlap with the traditional Product Manager function, Product Managers have expressed some anxiety about the future of their role.

Agile was borne from frustrated development teams who were constantly blamed for non-delivery and missed business goals. Nothing in life is black and white, and objectively speaking, problems could be found on both sides. Nevertheless, Agile was a response from tactical teams that wanted to control the rules of the game and redefine the criteria for success.

Since the Agile process was created by tactical teams, it concentrates on development practices. At times, Agile may seem inattentive to the environment in which projects are delivered, and to hold idealistic views of reality. However, Agile has many merits, and for organizations to be fully successful, the changes of Agile need to happen not only on the tactical level of delivery, but across the whole organization. It is not enough to have a fully functional and efficient development team that delivers, if it does not translate into success of the company. As product managers, we bear the responsibility for bridging the two worlds – technical and business, and need to influence both. Ultimately, we are responsible for the success of the product and, thus, the company. We cannot point fingers anymore and say, “It was the developers who did not deliver,” or, “It was the business unit that did not have a coherent strategy.” Although there may be some truth to these statements, the art of product management is to influence strategies and plans even if we do not have direct authority over them.

Change must happen on two levels across the organization:

• Technical – Roles and responsibilities must be understood, accepted, and adopted.

• Cultural – Attitudes, expectations, political ambitions, and how we collaborate must change.

Obviously, Agile should not be introduced with a ‘big-bang’ approach. Instead, by demonstrating that the new process works on a tactical level, and building confidence within the organization, we can show the way forward for the rest.

In this article I concentrate on the role of the Product Owner. This role is critical to the success of any initiative, and yet it is not widely understood. For tactical teams, the Product Owner represents the business, yet there is no clear definition of who that person should be. Articles or books by technical Agile authors almost always present the Product Owner as a jack of all trades—whatever information a team needs, the Product Owner delivers. Posts on the website of Scrum Alliance (the professional organization of Scrum practitioners) call for more training of Product Owners so they understand what it means to be ‘good’ Product Owners. Clearly they are not getting what they need from this role.

Since Scrum describes what this role should do, but does not say who specifically from the traditional world should play this role, Product Managers are put in an ambiguous position. According to Scrum, the Product Owner can be anybody – the Business Manager, an internal or external client, or the Product Manager—as long as this person is part of the team and can devote enough time to the role. The simplistic assumption is that the Product Owner contributes to the success of the company by performing whatever business-side functions are possible. This assumption may be true as long as this person sees the big picture, understands the market or client problems, sees the market opportunities and trends, and is able to quantify them. In other words, the expectation is that the Product Owner is, at least partly, also the Product Manager, regardless of title.

So there is overlap between what teams expect from the Product Owner and the traditional role of Product Manager, but is this the same person?

The Problem

The founders of Scrum did not explicitly call the ‘Product Owner’ the ‘Product Manager.’ If they had, the role of ‘Product Owner’ would have no ambiguity. I think one of the reasons for this oversight is that, as Product Managers, we failed to communicate the value that we bring to organizations. Only one side of product management has been seen by delivery teams – as the enforcers of deadlines and the police force of the business. In addition, the metrics currently used by business units to measure progress reinforce the perception by development that Product Managers are part of the problem rather than the solution. Agile is trying to break this ‘us vs. them’ dichotomy by integrating the business unit with development.

Over the last 50 years, the software industry has undergone a full evolution of roles. Initially, a developer was an architect, analyst, project manager, coder and tester. Over time, software became more complex, technologies changed, markets grew, and development teams became larger. As a result, specializations in roles developed. Product Managers became specialists in understanding markets, Project Managers in delivery of projects, Business Analysts in solidifying requirements, and so on. Roles became even more fragmented when specific skills were recognized, as for example defined by Pragmatic Marketing - Product Managers could then be Product Strategy Champions, Technical Product Managers, or Marketing Product Managers. Similar splits happened with other roles; for example, now we have either Business or Technical Project Managers.
Some of these roles have endured and are clearly defined. But new methodologies, such as Scrum, have called the boundaries and definitions of other roles into question. For sure, Scrum has raised issues in mapping traditional Product and Project Manager responsibilities into Product Owner and Scrum Master functions.

Let’s have a brief look at the expectations of two roles – Product Owner and Scrum Master.

The Product Owner is responsible for:

• Representing the voice of the customer.
• Understanding and delivering on ROI.
• Managing business stakeholders.
• Maintaining constant communication with the team.
• Making rapid tactical development decisions if they impact functionality or usability.
• Participating in technical release planning.
• Writing user stories and scenarios.
• Maintaining product backlog.
• Helping the team to estimate development time for each scenario.
• Participating in Sprint review meetings and providing feedback to the team.
• Monitoring progress and making constant adjustments based on larger strategic objectives.

The Scrum Master is responsible for:

• Facilitating the Scrum process.
• Removing impediments to sprint and release goals.
• Enforcing Scrum process rules.

Clearly, both roles are a mixture of traditional product, project, and business analysis roles. But this mixture creates a conflict between internal and external drivers. On one side there is responsibility for big-picture goals of operating and positioning the product in the market. On the other side there is involvement in the daily tactical delivery of the product. Either one of these drivers alone can be a full-time job.

To resolve the conflict, we need to look at underlying assumptions:

• The Product Owner has enough time to perform both functions.
• The Product Owner has enough knowledge and skills to handle both functions.
  

The time constraint is a serious problem. If focusing on the team is a full-time job, how does the Product Owner find time for watching market trends and competitors, building relationships with clients, conducting market research and win/loss analysis, creating business cases and pricing strategies, and maintaining vendor relationships, just to mention a few tasks? Equally important is the question of skills. Someone who is good at marketing may not necessarily be effective at analyzing user stories and scenarios of the application.
Another unresolved issue is the scaling of teams. Scrum works well on smaller projects with 6 to 8 team members. But for larger projects with multiple teams, coordination needs to be structured with ‘Scrums of Scrums’ – daily meetings of key representatives from each team that follow daily Scrum team stand-up meetings. While these meetings are effective for aligning tactical efforts by Scrum Masters, Product Owners need another forum for review, coordination and response planning to ever-changing market conditions.

Product Manager Redefined

Although there is much overlap in the responsibilities of Product Owner and Product Manager, these are clearly not the same roles.

Both roles optimize process, but one role focuses on delivery process (local), while the other role focuses on product strategy and achieving company business goals (global). One function cannot be performed at the expense of the other. In any economy, but especially today’s, it is crucial that the right markets are targeted with the right products at the right time. Therefore, with Agile, we need to have both roles – a Product Manager who is externally focused, and a Product Owner who is oriented toward the team. As well, a strong relationship must exist between the two roles.

The Product Manager role combines the functions of Strategy Champion and Marketing Product Manager. This role is most probably closest to the traditional product management function, although the technical responsibilities move to the Product Owner. The Scrum process still requires participation by The Product Manager.

The Product Owner plays a critical role as a link between the business unit and the delivery team, merging the roles of Technical Product Manager, Business Project Manager and Business Analyst.

The Scrum Master plays the role of traditional Technical Project Manager and Project Leader.

It is important to remember that while this structure represents a transition from traditional roles to an Agile environment, there is also a shift in how the roles cooperate. Particularly, Agile stresses ego-less communication between the team, Scrum Master, Product Owner and Product Manager, and insists on sharing of responsibilities.

Here is a short overview of the project stakeholders and the roles they play in Scrum:

In general, a good match for the position of Product Owner would be a Business Analyst with some project management skills. Scrum changes the traditional role of the Business Analyst; there is no longer a need for large volumes of documentation, because requirements are created just-in-time, as late in the process as possible. These requirements are then communicated and worked out directly with the team. Also, Business Analysts are usually experienced in working with Product Managers and clients.

Large Scale Product Owner Organization

When implementing Scrum in large-scale development projects, ‘Scrum of Scrums’ meetings should occur. These meetings usually follow the daily Scrum team stand-up meetings. The Scrum of Scrums is used for managing and coordinating progress of current iterations. The participants are the Scrum Masters from various teams. It is highly advisable that the Product Owner participates in these meetings as well, in order to understand the activities, relationships, constraints, change impacts, and delivery sequences of related component teams.

In addition, because the Scrum of Scrums is tactically oriented, the Product Owners, together with the Product Managers, should have their own forum to review market conditions and conduct marketing release planning. This meeting should be held on a weekly or biweekly basis.

Conclusion

The Agile methodology does not remove the need for Product Managers. The Product Manager and Product Owner are distinctly different roles. The Product Manager is focused on the external side of product development—visioning, positioning, marketing and operations. The Product Owner plays a critical role as the link between the business unit and the development teams, contributing business perspectives and prioritizing activities through the product backlog.
Since Product Managers do not spend as much time working directly with delivery teams as Product Owners, there must be a constant flow of information between the two. Product Managers need to be made aware of how the development of the product is evolving, but must also provide information about changes that potentially could impact the next iteration or release. Both roles must be able to react and adjust to ever-shifting situations in both worlds–business and development. Quick 15-minute stand-up meetings daily between the Product Manager and Product Owner should be sufficient to satisfy this need. Additionally, both roles need to have periodic—weekly or biweekly—planning sessions to review market conditions, client feedback, suggestions for potential new business opportunities, competitor activities, and so on.

From the perspective of traditional roles in project teams, the closest match to Product Owner is the Business Analyst. The transition of Business Analyst to Product Owner should be fairly straightforward. Both roles are similar in nature, and most Product Managers are already accustomed to working with Business Analysts. Although Agile changes the role of the Business Analyst by removing the requirement for detailed documentation up-front, it does not remove the requirement altogether. Instead, documentation evolves as the development process progresses. This change, therefore, should not produce anxiety about the future marketability of the Business Analyst profession.