The journey from a project-based approach to a product-centric paradigm requires not only a shift in methodology but also in leadership roles.
Standing at the helm of this transformation is the Product Owner, a role that is pivotal to any Agile framework. As the key stakeholder, the Product Owner bridges the gap between the development team and the end users, ensuring the product vision is executed to perfection.
In this exploration of the role of a Product Owner, we'll shed light on why it's not just another cog in the wheel, but an essential instrument in any project-to-product transformation.
They shape the product backlog, prioritize tasks, and create a shared understanding of the product vision among the team. Simply put, the Product Owner is the heartbeat of the transformation, fueling it with direction, focus, and clarity.
ADAPT Methodology® is a unique Digital Product Development framework to change traditional project-centric companies toward product-led companies!
Society changed and leaders need support in the way how they lead and design their digital product organizations, that is the reason why the ADAPT Methodology® was created, but now let’s get a deep dive into What Is Product Owner.
There are many roles on a Scrum Team. One role, the Agile Product Owner (PO), is responsible for managing the product backlog to achieve the team’s desired outcome. The PO’s role is significant when it comes to quality. This is the only member of the team that is empowered to accept any story as it is.
For most companies switching to the Agile process, the PO role is a new and critical one. Most companies hire a full-time Product Owner to support the Agile Team. The PO’s relationships and responsibilities are not only significant but extend beyond the local team. They also work with the rest of the Project Management team, customers, and stakeholders.
The product owner is a leader; typically, someone with a background in marketing, or project management, or is knowledgeable about the marketplace and its users. They must also have a clear understanding of the competition and future trends of the domain and type of systems being developed.
The product owner’s role was initially created to address the challenges that many Scrum Teams faced. Many teams had difficulty choosing what direction to take. This resulted in the team having conflicting directions, multiple directions, or no direction at all.
The product owner spends a lot of time with the team, clarifying the product backlog items and deciding which items to do, based on the product’s specifics.
It can be challenging for someone to do the job of the product owner. They must make all the decisions about the product, know the business’s needs for the product, and spend considerable time with the Scrum Team.
Because of the amount of work involved, the responsibilities are often divided equally between many team members. Companies are starting to use a valued team to handle the workload. If you, as a business owner, decide to use this approach, you need to appoint a single decision-maker.
The ideal ratio for Product Owner to Scrum Team is 1:1 - one Product Owner to one Scrum Team. The ratio becomes violated if more than one team is working on the same product simultaneously. The product owner ends up working with multiple teams.
The problem with this model is that one team is often ignored by the PO.
If the product owner has too many responsibilities, they are not readily available for the Scrum Team. This can cause many problems and delays for the team because they cannot get their questions answered or decisions made promptly. This is known as an absentee product owner.
Teams that find themselves needing a product owner more than what the PO can deliver, can appoint a proxy product owner. The proxy owner can be appointed by either the current product owner or the team.
However, many teams do not like this approach because the product owner can override the proxy’s decisions at any time. Often, the actual PO will override the proxy at a time that is most inconvenient for the team.
The roles and responsibilities can vary from one to the other depending on the product and development environment, but there are many common factors for each position. Each PO owns all the responsibilities, but they should collaborate with their team and delegate the workload according to the team’s needs.
There are seven common responsibilities of every Product Owner:
The Product Owner is responsible for setting the goals and creating the team’s vision. The vision needs to be communicated with everyone involved in the project including the Scrum Team, the stakeholders, and the project management team. The vision is used to prioritize and direct the team’s decisions.
The Product Owner generates and manages the list of jobs needed to be done by the Scrum Team. They must write the product backlog items and the acceptance criteria for each, then order the work to ensure the product vision is met.
The product backlog must be made visible so everyone involved with the team can see it. This way, the product owner can optimize work performance and make sure the stakeholders clearly understand the strategy and developmental roadmap.
The backlog is a living source that is continually updated. The backlog shows all the work to be completed during the development. It is used to make sure the team always completes the most important tasks iteratively and incrementally.
The product owner is responsible for providing the best return on investment. They are accountable for all economic decision-making during the sprint’s release and product level. The iron triangle of scope – budget, time, and quality – can be adjusted according to need. The cost and benefit of each product backlog can also be used to determine the order of the work.
The product owner must involve the scrum team. They must share the organization’s vision, answer the team’s questions, and listen to suggestions about adding, deleting, changing, or improving the user’s goal. The product owner motivates the team and seeks feedback.
The product owner also defines the boundaries and constraints to achieve the goals. Constraints must be attainable. They can include deadline completion dates, cost limitations, memory limits, and speed minimums.
The PO must be careful not to set unrealistic or technically impossible goals. If some unrealistic goals are submitted, good communication between the user, the user’s representative, and the Scrum Team is key to early detection.
Prioritizing tasks during the sprint is also important to realize the team's goals. Teams first work on the most important segments. When they are completed, they can release those segments to the user or customer. Segmenting jobs can create higher product values and positive ROI results. This can also help get parts of the product on the market sooner.
Projects can last a long time; therefore, all feedback is important. Whether good or bad, feedback usually means altering, eliminating, or adding goals to the project. Because the changes are made while the project is already in progress, the costs will be less than if the project was already finished.
The product owner plays an important role in developing events such as the plans, refinement, reviews, and retrospectives of the sprint and daily scrums.
They work with the stakeholders during the planning activities to determine what steps and content need to be taken to deliver the next iteration, release, or product level and the next iteration.
During the weekly refinement sessions, the PO works with the Scrum Team to define, elaborate, estimate, order, and delete product backlog items.
They collaborate with the team to determine the next actions needed to improve the work. During the sprint, the PO works with the Scrum Team; answering questions and accepting completed product backlogs.
However, the product owner is the only one with the authority to add or remove work, cancel the sprint, or stop the development of the project. They can attend daily scrums to coordinate and collaborate with the team on the work being done in the sprint.
Product Owners share five common characteristics:
The product owner is fully engaged in the project. They work with the Scrum Team daily; answer questions, and are readily available when issues arise that could delay the project.
The organization empowers the product owner to make decisions and be accountable for their decisions. All decisions must be made at the product level to maintain the speed of development. The organization must be careful not to overrule the product owner, or run the risk of the team bypassing the company’s hierarchy.
The product owner must answer the team’s questions promptly and authoritatively. Delays can prevent the work from being completed on time. Reversing previous decisions will create a lack of trust.
The product owner is in the best role to make decisions based on customer knowledge and stakeholder support.
The product owner understands the target customer’s needs. They have the strong business knowledge to lead the team’s product development while coordinating with all the stakeholders. They have a strong support network within the organization and can develop good relationships with customers and party suppliers.
The PO must be an excellent communicator, collaborator, and “people person”. They can share their vision, align people, focus their efforts, and motivate the team. Their high emotional intelligence helps them collaborate and steer product development to a successful conclusion.
Product owners are not just administrators, but customer delighters as well. While it is important to listen to the stakeholders and change the backlog accordingly, it is also important to listen to the customer and discover their needs.
Great product owners do more than just follow the mechanics of adding a user story into a product backlog before sending it to the developers. They think about ways to transform the story into a product feature that delights the user.
For example, let’s say a backlog item for a ridesharing company is to send the users an email receipt. Is the user busy? Do they need to create an Excel expense report for the receipt? Is there additional information - payment method, document options, pick-up or drop-off location, distance – that would be helpful? A great product owner would look at the broader picture.
To be honest, while the role of the Product Owner is to be done by one person in the Scrum framework, one person can’t manage everything. If the work starts to falter, many teams will create an additional, parallel role. For example, teams might also add a technical product owner to compensate for the product owner who does not see themselves as a leader.
Teams must delegate and build a helpful informal team if they want to survive and thrive. Wait, does that sound like a Scrum Team? Yes and no. You can choose to include a Scrum Master and various Scrum Team members if you want. But a separate, informal product owner team will help you with various responsibilities, especially if you are not an expert in certain areas.
There is nothing wrong with saying you are a developer too. In Scrum, teams get caught up in delegating roles. While it helps teach Scrum, it is not always helpful. The roles can easily become so overstated, that it moves the focus away from the value of delivery regarding who does what.
As a product owner, it is easy to think “I own the product backlog. I own the user stories. I give them to the Scrum Team and they develop them.” This may be true, but you are still part of a team; not just the team leader.
The entire team delivers value. When you see your role as a member of the team, guiding the rest of the members in what should be built, your collaboration with others will be healthier.
While you are a developer, you are also a knowledge broker. You may represent the product backlog, and act as the interface between the Scrum Team and stakeholders, but that does not mean you are an expert on the product. If developers are writing code, they might not get far by talking to you.
Instead, they should be talking to the experts: the stakeholders who represent the users. Part of your job is collaborating and empowering the developers by finding the right experts to talk to. If those discussions result in change requirements, you should be kept informed. If that is not feasible, put the developers in charge so they can get the needed information.
Anyone who cannot handle conflict should not be a product owner. In product development, you will deal with inherent, conflict-filled situations, especially when people are fighting over resources and politics. Having strong conflict resolution skills is important to stop disputes from escalating.
Product owners must be courageous, confident, and capable of handling situations when they get difficult. And you should know, that you usually must go through some conflict to reach a solution. Knowing how to mediate and collaborate will minimize the negative.
No matter how good you are at conflict resolution, at some point, you will have to escalate a situation up the chain of command. Escalation is not related to petty squabbles, it is the feedback that management has given regarding conflicting goals. For example, if two stakeholders have assigned the same team with two different tasks that do not fit together, you have conflict.
The best product owners already have conflict escalation mechanisms ready. While you will undoubtedly try to resolve conflicts the best you can with the stakeholders, you will still need the skills to go up and down the management chain. Instead of waiting for a crisis to come, you should build and test your escalation plan beforehand. You can do this by looking for opportunities to escalate small, applicable interactions quickly so you will master the skills.
By the time the big issues happen, you will be ready and comfortable to deal with it. There are numerous skills that you can cultivate as a product owner. But these seven qualities will give you a leading edge in your role.
One of the first challenges companies face when transforming to Agile is understanding the new roles that are needed to support their initiative. The product owner role is the most critical, yet newest concept for companies to understand. A common question companies often ask is: “What makes this Product Owner role different from an Agile Business Analyst?” The differences between the two roles are important. Understanding these differences is critical to your success.
A Product Owner’s role is the amalgamation of multiple roles – business representative, business analyst, project manager, and other roles. The roles are combined into one to support the Scrum approach. It is designed to provide a certain level of accountability that otherwise does not exist.
Because it is a new role, it is important to identify the people who have the potential to develop the needed skills to do the job. I recommend you choose someone from the business end, not the IT end to fill the role. You should pick someone who can be coached on writing stories and defining the acceptance criteria.
You also want to choose someone who has the support and understanding from management that the commitment required for the role is far greater than anything they have ever experienced previously. I would also like to recommend that the manager offload a lot of the person’s existing responsibilities to other staff.
So, why train a Product Owner to write stories and define the acceptance criteria when you already have a Business Analyst who has the same skills? The answer is accountability. When a business resource owns the content from each sprint, there is no one to play the blame game, so there is less friction between the IT and Project Managers.
Developing a role, the is responsible for accepting the stories, no one in IT has the authority to accept the stories. Only the business itself can decide if the completed work is acceptable and fits the purpose.
In Scrum, only one person is responsible for defining and accepting stories. And I cannot stress enough the importance of not dividing up those responsibilities.
Along with accountability, communication is also important. When the product owner has come from the business, there is a better chance that the communication between the Product Owners and Product Managers will be more natural and fluid.
This will make it easier for the team to solve problems while keeping aligned with the business goals. There will also be fewer surprises during the sprint demonstrations.
A Product Owner can literally “sit” with the Scrum Team and then effectively report to the Product Manager; bridging the gap between the business and IT departments.
When the company is working with both the Product Owner and Agile Business Analysts, they can take a holistic perspective on problem-solving.
The Product Owner provides a user focus approach while the Business Analyst uses a system focus. The product owner finds out what the user wants, and then decides on the best way to provide the best value, while the Business Analyst identifies the cases, error conditions, dependencies, and impacts on other areas of the system or other systems.
There is no doubt that the Business Analyst provides great value to the team, but the Product Owner must retain exclusive rights to accepting stories and managing priorities to maintain accountability.
Because the Product Owner is a new role for many organizations, we recommend that you identify individuals who have the attributes needed for the role.
They include strong communication skills, good business sense, quick decision-making abilities, a technical foundation, and, most importantly, someone who can develop a level of trust from both the team and the Product Management.
Once you have identified the right person, I recommend sending the candidate for up-front training, tool training, and ongoing coaching.
For this new role to succeed, the entire organization must respect the Product Owner’s decisions. All decisions should be visible in the content and product backlog orders.
I hope this post showed you the clear responsibilities and skills of a Product Owner.
We enable leaders to become highly valued and recognized to make an impact on the World by helping them to design Digital Product Companies that will thrive and nourish in the Digital Age, we do this by applying our own ADAPT Methodology®.