Responsibilities and Skills

The Product Owner is responsible for the vision that motivates the project. If that vision is to deliver an artificial intelligence system that will authorize medical expenditures for a health insurance company or deliver a revised website, the Product Owner is the one responsible for articulating that vision and ensuring that is successfully delivered by the project team. It is a full-time position that bears the responsibility for the entire project's outcome. As such, the Product Owner is fully responsible for the work that must be done from beginning to end.

To deliver that vision the product owner must take on several responsibilities over the life cycle of the project.

• Vision statement

• Scope

• Needs and wants

• Financial responsibility

• Engagement in the planning process

• Defining "Done"

• Stakeholder collaboration

Vision

The product owner is the individual working together with the management who defines the benefits that the project will deliver to customers and end users. These benefits are summarized in the vision statement. It defines the purpose, objective, benefits and, most importantly, the value that will be received by the end user, client or customer. The vision statement does not need to be long. In fact a short statement is preferable. At a minimum, it needs to identify the customers or end users, why they need the product and how they will use it.

Scope

The vision shapes the scope of the project. It determines what will and what will not be delivered by the project. Because it sets boundaries on the project, scope affects budgets, schedule and quality. Decisions that affect scope are the responsibility of the product owner. for example, when it is discovered that a competitor has just introduced a new feature, it may be necessary to add that feature to the product backlog even if it increases the scope and delays the schedule by several weeks. consider that a customer is not pleased with the length of time it will take to complete the development of one feature. It may be necessary to increase the resources assigned to that feature while eliminating one or more features that may not be considered to have a high priority. Again, scope changes. In both examples, it is the product owner's decision.

Needs and Wants

Scope response to the customers or end users needs. However, their needs often get confused with wants. A need is essential a want is not. It is the product owner who must separate them and negotiate with the customer to accept an outcome that may not meet all their wants, but does meet all or most of their needs. consider that you are likely to walk into an auto dealership with a need: purchase a car that will provide basic transportation. So, you look at those cars at the low end of the price spectrum with few extra features. After wandering around the showroom for 10 minutes, a car with many more features captures your attention. One hour later you are signing a contract for the nicer car and the much higher monthly payments. You have confused needs with wants! The same is true whether you buy sunglasses, a new computer or a new electric bike. Once often become confused with needs. In scrum, it is the product owner's job to separate the two.

Financial Responsibility

The Product Owner takes an active role in managing and controlling costs associated with a project. Budgets must be established and information systems made accessible, so they can compare actual and budget costs across the life cycle of the project. It is not enough to just monitor costs. The product manager must also have the authority to initiate action when actual costs exceed budgeted costs. First, they must find the root cause behind these differences and then take the steps necessary to correct the situation. Perhaps, and even greater issue is the occasional necessity to pull the plug on a feature because it may no longer add customer value, or even to pull the plug on the entire project because it's success in the marketplace is no longer assured.

Ensuring that benefits exceed costs

Every project must face a basic financial hurdle: project benefits must exceed project costs. this means that, at the early stages of project planning, it may be necessary to estimate both parameters. At these early stages, general estimates are usually sufficient. once these estimates are made, they are compared using a benefits cost ratio, where the benefits are divided by the cost. As long as the ratio is greater than one, the project is a candidate for approval. Projects with a ratio of less than one are almost always rejected. For example, a new website is estimated to cost $130,000. It will be used for 2 years and, over that time, it's benefits in terms of increased profits are estimated to be $400,000. The benefit cost ratio is $400,000 / $130,000 or $3.07. since it is greater than one, the project is a candidate for approval.

The Planning Process

Product Backlog

once the project passes financial hurdles and is approved, developing the product backlog is perhaps one of the most important steps in the planning process. Furthermore, it is one of the most important responsibilities of the product owner. As you know, the backlog identifies the features that must be delivered by the project team. It reflects project scope. here, the product owner must make sure that the necessary features are included and that the priorities that are set reflect the wisdom of those involved in the project.

of equal importance is to ensure that the project team can realistically deliver the features included in the product backlog and deliver them within established time and budget constraints.

Grooming

Another responsibility of the Product Owner is to collaborate with the team when the product backlog must be groomed. Grooming involves adding, eliminating, or refining features in the Product Backlog.

Grooming involves several essential activities:

• Adding product backlog items

• Revising the estimates for these items

• Refining product backlog items

• Reprioritizing product backlog items

• Deleting product backlog items

Defining "Done"

It is important for the product owner, scrum master, and the project team to share a clear understanding of what it is meant when it is concluded that the work undertaken during a sprint is done. they must establish the criteria that will be used in confirming that the features, functions, or requirements have been met. Vague or ambiguous criteria will lead to vague or ambiguous definitions of done. When this happens, the quality of the work released by a team may not meet product objectives or quality control standards. This can have significant repercussions for downstream sprints and the product that is delivered to customers or end users. Since the product owner is primarily responsible for delivering the vision, it is that individual who must ensure a clear definition of done.

An example of done

consider a project approved by an insurance company to speed the average time required to process a claim. One of the features of the new system is to separate those claims that can be resolved quickly from those that require a more extensive review. The separation of those claims will be done by an information processing system that relies on artificial intelligence. Designing the artificial intelligence piece is currently underway, but what criteria will be used to determine when this piece is done? To make this determination, the team will carefully review the logic followed by the AI system, then submit a large group of claims to the system and confirm that the decisions made for those claims would be the same made by those by a subject matter expert. by agreeing on this validation process the team has clarified the meaning of done.

Stakeholder Collaboration

The Product Owner remains engaged with stakeholders over the life cycle of the project. They must continually reaffirm that they are aware of the project status and its progress towards the final deliverable. Further, they must engage with stakeholders during the sprint review. this is in contrast with the waterfall approach, where customers are typically only engaged at the beginning of the process to express their needs and at the end of the process when the results of the project are delivered.

The consequences of when stakeholders involvement are neglected are often considerable. Consider the situation in software development, where a functional area of the business, such as marketing, makes a request to the information technology group to provide routine reports that highlight the products that different groups of customers are likely to purchase. For example, the types of pants, tops, and shoes likely to be purchased by professional women between the ages of 25 and 35.

Consider that after this vision is delivered to the IT group, there is very little, if any interaction with the customer. When completed, the software is delivered to the customer. The customer is surprised. The deliverable fails to meet their expectations. They had a product in their mind that bears little resemblance to what the IT group delivered. The software works, but the application is a failure.

But, when the project follows the principles of scrum, engagement over the lifecycle of the project remains reasonably constant. of course this engagement may vary depending upon the nature of the work that needs to be done, but in general customer engagement will be at a level not limited to the beginning and end of a project.

Product Owner Skills

Because the Product Owner takes a central role in the project, it is important for that person to have the skills necessary to work with a broad range of people, from the scrum master and project team to management, and then to customers, clients and end users.  The Product Owner must be comfortable working with a self-directed and self-managed team. And the product owner must be skilled in working with groups to reach consensus and resolve conflicts through negotiation.