A Product Owner (PO) role can be challenging. POs have many different responsibilities on their plate that highly depend on the context. They need to consider the type of product and its lifecycle stage, as well as the people involved in the product development process. The more variables are in play, the trickier it gets. Today, we will talk about various challenges of a Product Owner and suggest solutions. We hope they will help you avoid unnecessary failures and make apt decisions to remedy the situation.
Recommended reading: Project Manager vs. Product Manager vs. Product Owner
Challenge #1: Stakeholders management
As a Product Owner, your primary responsibility is to maximize the product’s value. But that responsibility requires a lot of cooperation with other teams, customers, and management. Therefore, you will often need to align several stakeholders to make decisions and converge on a single shared understanding of the product. In short: many people, different views and opinions, and you—the Product Owner—who needs to make something clever out of it.
Get comfortable with saying “No”
First, learn to say “No.” Your job involves making choices, so you should be able to decide which idea is worth pursuing and which one is not (or at least not in the coming sprints). Standing your ground and keeping in mind that you cannot please everyone is not easy but necessary. Besides, you would probably prefer to initiate ideas rather than to be someone who constantly agrees to what other stakeholders say.
Group your stakeholders
Second, recognize which stakeholders are more important than the others. The “more important ones” means those stakeholders who are in power to influence your work, or are very interested in it. This approach will help you reduce the “noise” and focus on those individuals whom you need to keep on the same page. If you are new to the organization, you may draw Mendelow’s Matrix to group your stakeholders visually.
A quick guide to how to read the matrix:
- A) High power, low interest (keep satisfied). Aim to put enough effort to keep those stakeholders satisfied, but no need to overdo it.
- B) High power, high interest (manage closely). Aim to become fully engaged with these people; do your best to satisfy them.
- C) Low power, low interest (monitor). There is no need for excessive communication; keep an eye on them as their levels of interest or power could change (i.e., these stakeholders might suddenly move between quadrants).
- D) Low power, high interest (keep informed). Keep those people well-informed; check-up on and talk to them to make sure there are no significant issues that could arise. This group of stakeholders can help you indicate any areas that could be improved or deserve attention.
Challenge #2: Distributed teams
Over the past few years, remote work has become equally a trend and a necessity. Nowadays, agile teams work from different locations spread across the country (or even a globe), which often leaves a Product Owner working separately from his team. And although organizations generally have adapted to the remote mode of work pretty well, the separation of team members still can be a source of challenges for a Product Owner.
Also, virtual contact makes it more difficult for a PO to present and explain their ideas. Certainly, there are online tools for visual communication (e.g., for drawing and moving sticky notes on a virtual board), but they cannot replace face-to-face interactions.
Consequently, Product Owners could face a lack of trust and feedback from the team, miscommunication, misalignment, low engagement, and slow progress. After all, there is a reason why the Agile Manifesto states that “the most efficient and effective method of conveying information to and within a development team is a face-to-face conversation.”
Bring the Agile team together
If you work for a remote-friendly company, forcing people to work on-site is not an option. But it is still possible for you to connect with your co-workers in person. As part of their onboarding process, many organizations recommend new employees spend some time in the office (if possible), to get to know the people and soak in the company culture. Also, they encourage remote workers to work on-site once in a while.
If these two options do not apply to your situation, you can make sure you effectively use remote working tools (e.g., video calls). For the best engagement, ask your teammates to turn on their cameras and share their screens. For instance, sharing your screen when talking about backlog will help your team follow what you are saying.
BigPicture Board module. Left side: Task cards and cross-team dependencies. Right side: Backlog.
Additionally, remote-friendly project management software with features such as @mention and priority assignment will let you not only track progress, but also ensure greater transparency and accountability within the team.
Challenge #3: (Over)working with multiple Scrum Teams
Product Owners often work on several product features, which means they act as POs in more than one team. As a result, they often lack time to devote enough attention to product discovery, strategic work, and the backlog. Overworked POs are often unable to address their team’s questions promptly and slow down the development process.
The state of overwork can also be a repercussion of consecutive meetings, poor company culture (bureaucracy), and a team that misunderstands the role of a PO and the idea of product ownership.
Closer collaboration with the Scrum Master
A large portion of the PO work requires collaboration with other Scrum Team members. It is essential that each member fully understands their role to make the most of their collaboration. Collaboration is especially important for Product Owners and Scrum Masters (SMs) who work in tandem to create an efficient agile environment. These two roles have a few skill sets that overlap, which means that PO and SM can collaborate comfortably as peers. They also share the same goal, which is creating a valuable product through Agile methodologies.
Therefore, the Product Owner and Scrum Master should collaborate closely in several areas, including:
- Backlog refinement and management. A product backlog is the Product Owner’s responsibility. The Scrum Master can support PO with backlog refinement and finding the best techniques for backlog management. When the product backlog is ready, the Scrum Master explains to the Developers what they are going to work on and deliver in the coming sprint (or sprints).
- Team communication and project goals. Scrum Master’s responsibility is to ensure the team understands the sprint goal, objectives, and scope. Good communication, clear goals, and understanding of the product requirements will reduce interrupts and enable you to focus on your work better.
Challenge #4: Ad hoc requests
Ad hoc requests are unscheduled and unexpected. They can result from an unforeseen obstacle or issue (error, miscommunication), and their completion is pretty urgent. Usually, you will end up deviating from your existing schedule and temporarily shifting your focus elsewhere. What is more, completion of an ad hoc request may involve someone else from your team. In such a case, depending on the request complexity, this person may fail to complete their sprint tasks on time.
Assess ad hoc requests
Ad hoc requests are an issue because they typically do not lessen the workload of the person who is supposed to handle it. Quite the contrary. All the workload planned for the sprint remains unchanged. Plus, some ad hoc requests can be tricky—a seemingly simple half-an-hour task may turn into a full-day effort. That is why it is so important to assess the incoming ad hoc requests in terms of urgency, risk, and complexity.
You will need to consider the consequences of postponing or rejecting the ad hoc request, negotiate the deadline, and find out what the requesting person exactly expects. Through your assessment process and communication with the requesting stakeholder, it may turn out that the ad hoc task is not that urgent after all.
Log all ad hoc requests
When you accept the ad hoc request, you should absolutely log it into product management software. In case something goes wrong with the sprint due to the said request, it will be difficult for you to prove transparency or accountability. Logging allows you to have a bird’s-eye-view of everyone’s tasks and keep your finger on your team’s pulse. Moreover, when you add an additional task to the current sprint, you will also need to decide which other tasks to remove to maintain an equal team workload.
Challenge #5: Backlog prioritization
In the Scrum Guide, you will find what a Product Backlog is (an ordered list of what is needed to improve the product) and who is responsible for it (a Product Owner). What is missing is the how (how the Product Owner is supposed to maximize the value of an ordered list). Thus, the backlog prioritization often adds to challenges of the Product Owner and many of them struggle to find the right approach to fulfill their mission. And the mission becomes even more challenging when the PO is surrounded by high-priority items.
User story mapping
There are many approaches to backlog prioritization, but the one we would like to suggest is the user story mapping. It is a very simple technique that allows talking about the user’s journey through your product. You can create a story map to plot the experience for a new product or for an existing product, and at any point in the product development process.
Story mapping helps to focus on the big picture (!) instead of the irrelevant features that will not get you closer to your goals. As such, it makes it clear what is essential to provide a full experience for the users at a given moment. In this situation, prioritization takes place naturally.
However, what is important to keep in mind is that stakeholders might have different views on what is a “priority.” So again, you face a neverending conundrum of balancing stakeholders’ wishes and users’ needs. But what you should keep in mind is that not all the wishes reflect the real user’s needs, and thus, they will have no real business value.
One way to go about this is by focusing on the outcomes. A series of simple questions can help you sort user needs from the stakeholders’ wishes. Start with “why” and proceed with “what” and “who.”
- Why is this problem important for the users?
- What is the problem you want to solve?
- What is the objective of this feature?
- Who will benefit from this feature?
Answers to these questions will help you decide what to build and in what order (priority).
Defining requirements
When you face backlog-related challenges as a Product Owner, turn to your Scrum Master to help you define product requirements. SM will teach you how to break requirements down into small increments that, despite the size, would maintain their functional form. Those incremental functionalities must be small enough to make it possible for your Developers to deliver them in one Sprint. But big and meaningful (functional) enough to hold value for business and customers. Scrum Master can also teach you how to divide and group large requirements (e.g., into Epics).
