Product Owner Career: How to Advance and What Books to Read?

What competencies should newbies raise to become professional Product Owners? What books should each PO read?

Here at Agile.Live we have repeatedly emphasized that the demand for Product Owners will only grow in the near future due to the rapid development of digital technology worldwide. However, the lack of Product Owner competence, as well as poor understanding of PO role by the top management can cost a lot.

Having trained more than 1000 Product Owners for banks, airlines, and developers, we want to share our experience with those who start their PO journey.

Here are a few questions we hear from them frequently:

John: “Everyone seems to hate me. Developers do not take me seriously. Managers are not happy either. Today they want one thing, tomorrow — another. There is growing tension in the team. Who is to blame? Me. What am I doing wrong?”

Dan: “We didn’t have a Product Owner or any budget to hire him. The team asked me to take this role. This is how I became a Product Owner. I feel I took a lot on myself. What do I do?”

Nancy: “I’ve just started my career as a Product Owner. I do not have any certification yet, but I want to understand the scope of my responsibilities better. What would you recommend me to read?”

To answer these and similar questions, we will consider the following three points:

1. Common problems of PO beginners.
2. Three areas of PO’s work.
3. Two initial levels: Analyst and Proxy.

I. Common problems of PO beginners.

Product Owner beginners often encounter the following problems:

1. Criticism.
2. Inconsistency.
3. Overload.

1. Criticism

People tend to seek ideals and believe in them. Only a few can say, “No expectations, no disappointments!” Whilst executives and teams imagine a perfect Product Owner. As soon as a problem occurs, they accuse him of all mortal sins!

Of course, there are legendary personalities who changed the world. For example, many people consider Jane Manning to be the ideal Product Owner. In two years, she launched Google Adwords with only ten team members.

Initially, the Google search engine was fundamentally simple for users and did not annoy them with colorful ads, unlike competitors. It was the ease and simplicity of Google that won the hearts of Internet users.

Jane Manning was able to find the right words and arguments to convince Google’s top management of the need to integrate advertising while preserving the company’s mission and principles.

Result — plus $60 billion.

Since then, the bosses wonder why their Product Owner is not ‘Jane Manning’.

On the other hand, criticism often has its basis. For example, when a Product Owner (PO) does not fully understand the three main areas of his work (see below) or autonomy within the Scrum framework. Lack of competence entails inconsistency.

2. Inconsistency

Many problems arise from PO’s inconsistency.

This is evident in the situations where different stakeholders influence a Product Owner easily. For example, a top manager comes in and insists on a new idea. The team starts implementing it. The next day he shows up with a surprise — a new idea! Should this not be the case, he cancels his previous decision (‘just changed his mind’.) Time and resources wasted.

On the other hand, the team may question the manager’s idea. It may not seem realistic to them. In such a case, some PO newbies are reluctant to act. They do not go to the boss to report a problem, discuss it, and find a consensus that would suit everyone.

3. Overload

Product Owner’s inconsistency leads to overloading.

Trying to please everyone, the PO beginner takes on too many responsibilities, delves into details, undertakes what the team should do, communicates poorly with the management because ‘they are busy’, and does not spend enough time for constructive discussion.

So, how should the Product Owner beginner put things in order? What should PO really do?

II. Three areas of PO’s work

Product Owner is responsible for the three major areas of work:

1. Continuous interaction with the team

Together with the team of engineers, developers, and testers, PO must figure out how to optimize product costs to meet business requirements.

Expert opinion:

“Beginners tend to get into little details. That is a mistake. Not knowing how to write a requirement correctly, POs describe them in too much detail, listing all kinds of specifications, technical or other nuances. They should not do that.

The Agile approach describes the PROBLEM to solve, while the traditional one provides the SOLUTION. The difference between the approaches is fundamental.

Unlearning such “classics” will help. Because there may be several solutions to the problem, and it is up to the team to come up with them.

The solution should be a clearly formulated proposal of what can actually be implemented in a specific time-limited period.”

— Slava Moskalenko,
certified Scrum coach, Co-Founder of Agile. Live

2. Interaction with stakeholders.

The Product Owner should communicate with the team well. To do that, PO needs to have particular data in place. In particular, PO should understand the company’s business objectives.

The problem is — managers tend to set too general and vague tasks. The goals may not be clear from the development point of view. In such a case, PO should specify the requirement before passing it on to the team.
Jane Manning (see above) is probably the ideal example of interacting with the top management. In addition to her own competence, Jane was able to build the bridge of understanding between the business and the team.

3. Communication with users

Finally, the Product Owner must be well aware of the users’ wishes, preferences, and even dissatisfaction. With valuable user experience data, POs will see a more realistic picture and have strong arguments for decision-making.
Obviously, the role of the Product Owner is not as simple as it seems.

So, what should the POs do to grow professionally?

Firstly, understand: you do not have to be a guru to become a Product Owner. Secondly, you should develop your PO competence: learn to analyze, work in all three areas, and gradually expand your expertise.

For this purpose, many Product Owners come to us to take a training course or get a certification (see the Training Schedule), but everyone can study professionally on their own.

What kind of books do we recommend to develop these three areas of the Product Owner role?

Before you read anything, you need to see the Professional Development Scale and your place on it. Understanding your current stage, you will buy time by focusing on exactly what you need now and practicing right away.

Given that, each level provides its respective literature. Let us consider the first two and recommendations for each of them.

III. Two initial levels: Analyst and Proxy

Gunther Verheyen shared the following Product Owner Scale of Professional Development in Agile paradigm:

Let us take a close look at the first two levels: Analyst and Proxy. They are the most important for PO beginners. Without understanding their specifics, a Product Owner will constantly “step on the same rake” and will not grow.

1. ANALYST

What should a Product Owner be able to do as an Analyst:

• analyze;
• prioritize.

Ability to analyze

1. The Product Owner must be able to analyze the information and communicate it clearly to developers. In other words, PO should be able to answer the question: “What does the boss want from the team?” At the same time, PO should understand the budget, technical, and other capabilities of the company.

2. Define the problem.

PO must be able to define the problem — describe, formulate, and articulate it clearly.

Why defining a problem is a “problem”? Because usually, managers approach developers with too abstract, general, or not fully clear ideas.

Uncertainty involves risks. For example, a team may work diligently on what the business does not need. All because of PO’s failure to describe the problem clearly.

Consider the following case:

A sales executive of a global sportswear manufacturer asked developers to create a new service that would increase sales.

Analyzing buyer behavior, he noticed an interesting pattern. Some people approached the checkout with the goods they selected to purchase. However, seeing a queue in front of them, the visitors suddenly put them aside and walked away not buying anything. The problem was systemic, pointing out the missed opportunities.

Therefore, the manager gave the task: “Find some solution.”

The Product Owner conveyed these words to the team literally. Without thinking twice, all began to work on the problem.

Six months later, after hard work and good budget consumption, the team invited the stakeholder to see the “solution.” Brilliant minds demonstrated an innovative self-checkout system. The sales executive could barely stand on his feet. He did not see what he wanted to see!

Firstly, the developers had no idea how costly it would be for the company to implement their “solution.” Secondly, if the manager wanted another “self-service” solution, he would have put it plainly: “Make me a new version of a self-service machine”!

As you can see, poor problem definition is costly. Thus, at the Analyst level, every Product Owner has to polish the golden skill of defining a problem.

3. Understand the basics of organizational management.

In large organizations, there is a certain distance between different units (developers, marketing, finance, etc.), which complicates internal communication between departments or specialists from different fields.

Besides, the executives are usually busy managing 500, 1000 or more staff, not to mention respective processes.

In such a context, the role of the Product Owner is important in principle.

Interestingly, even big companies do not always recruit Product Owners, but rather delegate this role internally, which is normal. However, the professional development of such an employee should be on their agenda.

4. Decompose big ideas into smaller tasks.

As simple as it may sound, the ability to decompose is one of the most complex and important skills.
That means the Product Owner’s teamwork planning should be realistic. Time and resources needed for task completion within each iteration should be taken into account. To calculate the costs, PO should work closely with the team.

5. Communicate.

Product Owner must be able to communicate with busy managers, set a specific time with the boss to coordinate actions, clarify expectations, exchange ideas, agree on the same direction, find consensus (none of these happened in the case with the self-service solution mentioned above).

→ What to read?

For developing the Analyst competence, we recommend the book User Stories Applied for Agile Software Development by Mike Cohn. Foreword by Kent Beck.)

Product Owner must be a master of User Stories. Each User Story should not exceed the duration of one iteration (2 weeks). In the given time period the team should implement 4-5 of such user stories.

To write user stories masterfully, the Product Owner must have the skills of analysis. Besides, PO should be able to deliver information in such a way that everyone (managers, developers, and other participants of product development) understands what the team is working on and sees the outcome in two weeks to agree on the next steps.

The Product Owner should write each user story so well that the team could evaluate it easily in terms of capacity and time to complete it.

Here is a simple example of a typical user story:

“As a regular online session facilitator, I want to be able to initiate voting for ideas in the meetings, using interactive cards in a small team of 3-4 members — and not waste my time on any additional voting tools.”

Ability to prioritize

In addition to the analysis, the Product Owner is responsible for the Product Backlog — an ‘artifact’ where all user stories are stored and prioritized (as one of the methods for describing a task or a problem; the problem must be concise, clear, and realistic to complete in one iteration.)

Thus, being a master of writing user stories, the Product Owner takes on the responsibility for the product backlog where he prioritizes them in terms of urgency and importance.

→ What to read?

To shape the skill of prioritization, we recommend the following book:

The Professional Product Owner. Leveraging Scrum As A Competitive Advantage. Don McGreal, Ralph Jocham. Foreword by Ken Schwaber.

Having developed both skills of analysis and prioritization, we can talk about the next level, Proxy.

2. PROXY

Having mastered the skills of analysis and task prioritization, the Product Owner must develop leadership skills.

At this level, he is able to take responsibility and focus the team’s primary tasks. PO knows also how to manage time, forecast, and plan. PO skillfully conveys the team’s opinion to the managers.

This assumes the following:

• The Proxy level Product Owner has strong planning skills (Agile Estimating and Planning);
• PO is endowed with autonomy within the Agile and Scrum framework.
• Autonomy implies competence, actual knowledge of the “mechanics”. Thus, PO knows what storypoints are and how to use them for forecasting.
• Going beyond the team circle. PO communicates with the product users.
• Time management. PO is proficient in time management, its tools, and techniques.
• The ability to delegate tasks according to the Scrum culture in co-operation with the Scrum Master and the team.
• Product Owner understands the different roles and nuances of the Scrum framework.
• PO interacts with the Scrum Master who can give valuable advice on a given issue.
• PO has good analytical skills based on the initial Analyst level — knows how to specify tasks, eliminate unnecessary items, carry a dialogue with different parties, and reach consensus.

→ What to read?

For Proxy POs, we recommend the following books:

• Agile Estimating and Planning. Mike Cohn.
• Scrum. A Smart Travel Companion. A Pocket Guide. Gunter Verheyen.
• User Story Mapping: Discover the Whole Story, Build the Right. Discover the Whole Story, Build the Right Product. Jeff Patton, with Peter Economy. Forewords by Martin Fowler, Alan Cooper, and Marty Cagan.

Here you will learn about the list of elements needed for product development. Developers should give a multi-level assessment so that the Product Owner, alongside the business representatives, could come up with a good plan. Following that, PO should help the team in its implementation, ensuring mutual understanding and unity. PO makes sure nothing interrupts the team. ‘All roads’ lead to the Product Owner who knows who to talk to and what questions to ask. The company benefits from the work of the PO who understands where the money goes and delivers the outcomes, accordingly.

Summary

In this article, we have covered three issues: common problems of PO beginners, their three areas of work, and the two levels of professional PO development: Analyst and Proxy.

Developing a professional career, the Product Owner should consider the following:

1. You do not have to be a guru to be successful. Start carrying out simple but clear responsibilities within the Scrum framework.
2. The first skill to shape is the ability to analyze the information from various sources regarding the product.
3. Learn to define a problem, set specific tasks, and describe user stories clearly.
4. The Product Owner is able to set priorities and focus on the main thing.
5. POs understand their autonomy and therefore ensure consistency in the team’s work, and protect it from any external interferences.
6. PO actively communicates — gets the right information, answers questions, explains.
7. In co-operation with various participants, the Product Owner finds optimal solutions for the business, taking into account its capacity including the budget, team, and technology.

We have also recommended the books each Product Owner should read in order to develop these skills.

Having mastered the first two competencies, Analyst and Proxy, the Product Owner will grow into a professional who supports the team, protects it, and provides it with all the information and other resources it needs to implement the project successfully. Both developers and business executives will respect such POs. Highly competent POs will surely succeed.

JOIN AGILE.LIVE

• Check the nearest certification trainings at Agile.Live: Professional Scrum Product Owner (PSPO), Professional Scrum Master (PSM), Professional Agile Leadership Essentials (PAL-E)
• Connect with Agile.Live on LinkedIn
• Subscribe to Agile.Live Telegram channel
• Subscribe to Agile.Live YouTube channel