How do we become a good product owner?

Identifying internal motivations for becoming a product owner

This article aims to answer only one question: “What should I know before working in the product owner role?”

Let’s put it this way: if you want to be a product owner (PO), your answer to the following questions should be yes:

Do you like talking to people?
Are you not afraid of conflict?
Do you enjoy leading meetings?
Do you enjoy listening more than talking?
Do you like negotiating?
Can you make decisions at any time?

If your answer to all of these questions is yes, becoming a product owner will be an excellent, enjoyable adventure. If you answered no to some of them, you should reflect a little or change yourself.

I want to share principles you need to know if you intend to become a product owner. I will not talk about theory; I will share what I have learned over the last eight years as a product owner.

/en/product-skills/7-skills-for-product-management/

If you want information about PO theory, you can get it from the Scrum Guide. I have also written articles on “what a product owner is not” and “what skills a product owner should have”; look at them if you want to examine this role more deeply.

Do you like talking to people?

If you intend to become a product owner, be ready to talk to many people about many different areas. That is why I asked: do you like talking to people? Your answer should be yes; otherwise you will become more distressed every day. A few examples of people you will talk to if you become a product owner:

Sponsor: they provide the reason, goals, and budget. Product owners must be 100% aligned with them. There is no room for doubt.
End users / customers: you need to know what they do, and what their pains, hopes, and expectations are. Product owners must empathize with them.
Developers: product owners must explain the problems they want to solve and why they matter, and they must be careful not to cross the dangerous line of “how,” which is the development team’s responsibility. Believe me, you do not need to cross that line.
Scrum Master / agile coach: product owners, together with them, are servant leaders of the team. So you need to stay in constant contact and work in a way that benefits from agile frameworks.
UX & UI (user interface and user experience): understanding customers and their problems requires close collaboration among UX, UI, and the PO. They must be transparent with each other; otherwise you produce a product nobody likes.
QA (quality analysis): how is product quality assured? By talking with QA and aligning ideas, important product points, failure factors, and so on with them.
C-level: most of the time the product owner is in exchange with people above them in the company, and there is no doubt about that. Product owners must be brave and challenge them to ensure the best product quality.
Customer service: what do customers complain about? The best team to answer that is customer service. So product owners often exchange views with them.

You must be able to communicate very well and put the right message, at the right moment, in the right format, in front of the right audience. That is a big challenge, but when you are a product owner it is your everyday work.

P.S.: this list can be larger, but I think you get the point.

/en/product-discovery/4-step-to-produce-product/

Are you not afraid of conflict?

I start with this question: how comfortable are you challenging people and being challenged? The truth is that a product owner’s life is constant conflict. Without it we will not reach anything of value, and the role will be boring.

We want the best for our customers, so we must challenge and also be challenged. We can discover the best approaches only collaboratively, which means stating opinions clearly, and there will always be different views that lead to conflict. Here is a sentence I like on this topic:

“Fear of conflict—teams that trust each other are not afraid of passionate dialogue around topics and decisions that matter to the organization’s success. They do not hesitate to disagree with one another, challenge, and question others, because all of that leads to finding the best answers, discovering the truth, and making excellent decisions.” — Patrick Lencioni

In the book The Five Dysfunctions of a Team, Patrick Lencioni discusses this; I recommend you read that post.

A list of conflicts you will always face:

Challenging stakeholders: there is a large list of wishes from different people. So as a PO you must know what is important for the business, which means you have to challenge everyone. Unfortunately I have to tell you that people hate being challenged, even though you must do it.

Once a senior manager told me: “I don’t want an explanation; I want the work done.” I told him that if we do not know the reason we cannot do the work well. After that he decided to share the reason with us, and we were able to find a better option for solving the problem.

Challenging the tech lead: this is hard, but try to understand the obstacles. The tech lead wants you to prioritize technical topics. Your job is to find out why, why it matters for the business, and what happens if it is not prioritized. In short, you need deeper conversations about finding a balance between technology and business.
Good enough: when is the product ready? UX, UI, the development team, and others have different views. So welcome to another conflict. The decision is the PO’s, but you must be able to bring everyone along and make the best decision for the product.
Top-down: this is a classic. Someone comes to you and asks you to do something right now because it is “urgent” and “priority one” (I love those words). No matter who you are talking to, you must challenge them because you own the product vision.

These were only a few examples, but I think you see that a PO’s life is never boring.

Do you enjoy leading meetings?

In the product owner role you will probably have to attend many meetings every day. In most of them you will have to take the lead. You need to feel comfortable with that, because it is part of a product owner’s life.

In meetings you must be careful about defining the following:

Which meetings should be accepted: you are invited to many meetings, and it is your job to decide which ones you attend and which you do not. You must make your priorities clear; otherwise you will spend most of your time in meeting rooms.
Who should attend meetings: when you organize gatherings, make sure only the right people are there, and that you do not waste other people’s time. One trap you usually fall into is inviting too many people and holding a meeting that leads to another meeting because no decision has been made yet.
How long the meeting should be: it seems obvious, but product owners usually schedule 60 minutes by default even if there is not enough to talk about, which is dangerous because they may drift from the meeting’s purpose and time is wasted. Shorter, more precise meetings are better than longer meetings that lead to nothing. A good rule is 45 minutes.
What decisions should be made during the meeting: we must be prepared for the meeting. Sending a blank invitation is not a good option; you should plan the end of the meeting in your mind—imagine the outcome and build the plan from there.

“The bitter truth is that bad meetings almost always lead to bad decisions, so the best prescription is moderation.”

Patrick Lencioni, Death by Meeting

Some of the meetings a product owner will lead:

Backlog refinement: the product owner must introduce the problems to be solved and prepare PBIs (product backlog items) for prioritization. The challenge here is not to fall into endless technical discussions.
Sprint planning: as product owner you must have a precise definition of the “sprint goal” and commit with the team to what you will do in the next interaction.
Brainstorming: there are many opportunities to discover and reflect on new views, and brainstorming is one of them; you can use it to get as many ideas as possible.
User story mapping: when you want to build a new product it is better to think from the customer’s point of view and then define the required features. After that you can specify the product release.

These are only a few examples among many.

Do you listen more than you talk?

At this stage of the article you see that a product owner interacts a lot with different people. An important question is: are you a good listener? As a product owner you must listen more than you speak.

I have learned that I must draw conclusions faster than I used to. When I improved how I ask questions, I got better results. Why should you ask questions? Because product owners can uncover unknowns. A few examples:

Why is it impossible: you will often hear from the development team that “this is impossible.” Your job is to learn more and ask questions to discover the reason. For example you can ask, “What obstacles led you to that conclusion?”
What are customers’ real needs: there are always many wishes, but the point is what customers need. Finding those needs is not easy, but by investigating you will understand the reason better—for example, “What benefits do you expect from this feature?”, “What problems do you want to solve with this?”
Why is something so urgent: whenever a problem comes up, people come to you and say “this must be done immediately.” If you take all of that as real, you should become a firefighter, not a product owner. By asking challenging questions you get to the point, for example, “Why is this issue urgent from your point of view?”, “What happens if we do nothing?”

To listen more than we talk we must ask powerful questions. If you are not doing that, start as soon as you can if you want to be a product owner.

Do you like negotiating?

I assume you know that negotiation is part of your everyday work, so if you do not like negotiating you will have a hard time as a product owner.

First you must know that negotiation does not mean your opinion has to win. You must act so that the best result for the product is reached. The goal is collaboration, so negotiate in a way that you work with everyone and your ideas sit above others. If you think you have to win the negotiation, I am sorry to tell you that you have already lost.

Backlog refinement: to refine the PBIs (product backlog items) you want to work on, you will have to negotiate with the team again and again, because they will challenge you and say they do not want to do this work because the team believes it is dangerous for the product’s health. So you must negotiate with them to reach a better result.
Roadmap planning: whenever you want to plan the roadmap there are many topics and everyone wants to prioritize something, but capacity is limited. That means you must negotiate with everyone and make commitments. In short you must listen to everyone and negotiate what is acceptable and what is not.
Technical work: the development team wants you to do fixes, updates, and research. If you say yes to all of them there is no benefit for the business, and if you say no to all of them the team becomes demotivated. So you must negotiate to reach a balance. The team must feel heard, and you must agree with them on what is best for the product.

There will be many negotiations, and the good news is that there are many techniques you can learn. I suggest you read the following articles:

This FBI hostage tactic will make you a better leader
The best negotiation tactics I have seen in practice

Can you make decisions at any time?

One of the most challenging aspects of the product owner role is that you must always be ready to decide. As a product owner you have to make decisions every day. There will be simple decisions and hard ones, and the most important thing is that you must be ready to decide.

“It is better to make a wrong decision than to get used to indecision. If indecision has become a habit, you certainly cannot act, and action is the foundation of success…. If you think about it too much, you never make a decision to progress and create change.”

- Richard Branson

Some of the decisions you will need to make in the future:

Release date: the development team and the business expect you to define the release process, at what intervals it happens, when the product is released, and how communication will work.
Development options: there will often be times when the team finds several options for a particular feature. They look at you and ask, “Which way should we go?” and until you decide the team will not move, because they expect you to take responsibility—you are the product owner.
What the priority is: from the large list of product backlog items, which one is the priority in the end? You must lead the team so that business value is maximized.
When a feature is ready to release: the development team presents the result of their work and you decide when it is ready to release. Again, until you decide the team waits and will not move, so be careful not to become a bottleneck.

If you want to learn more about the product owner role, I have written an article on the essential skills this person should have.

I hope what I shared here helps you know the essential information about being a product owner before you become one.

Source

https://uxdesign.cc/are-you-sure-that-you-want-to-be-a-product-owner-391b45bb4b54

Introduction to The Product Manager’s Survival Guide What makes you a great product manager?