When I started working as a ProductOwner, I was not completely aware of how important this role is in a Scrum project. I thought that a good product is primarily defined by the technical skills of the team.
Gradually I realized how much a ProductOwner could influence on the success (respectively, failure) of a project in many different aspects.
During the implementation the team goes into a lot of details and each member works on a particular aspect of the product. Sometimes it is difficult for them to keep the high-level picture in mind and stay focused on it, or take those decisions, which are best for the overall product. The ProductOwner is the one who maintains the product vision all the time and keeps the team focused on achieving it. This is especially important when there are a lot of stakeholders with different, sometimes even contradicting requirements. Without a clear vision, the decision as to what should and what should not be implemented in the product, would be difficult, almost impossible. But when the ProductOwner knows which scenarios the product is supposed to support, prioritizing requirements becomes much easier.
For a successful project, the team needs to be truly and not just formally committed to delivering what they promised. The team should strive for the maximum result and be motivated to increase its velocity with each iteration. Of course, there are a lot of factors for good motivation, but among them is the commitment of the ProductOwner him – or herself. It’s clear that if he or she does not show up at the reviews in the end of the sprint, for example, or during the iteration does not demonstrate any interest in what is going on, the team itself would not be that motivated to give its best and provide the ProductOwner with what he or she required.
ProductOwner is a part of the Scrum team and as such, he/she needs to be engaged and committed to the project even more than others, since he is team’s face to customers.
As a part of the Scrum team, ProductOwner can use its capacity and knowledge for detailing and fine-graining the product backlog items. In my experience, joint approach works very well, especially when it comes to clarifying architectural details. As a ProductOwner I entirely focus on user story definition, while for technical aspects I can use a “think-tank” of architects and senior developers, so that on one hand-side I can prioritize correctly, and on the other hand-side the team can think on the required features in advance and can plan better for the next sprint.
Of course, work with stakeholder is a major part of ProductOwner’s job. Each customer would like to get attention, share problems, be understood by the software vendor, and be provided with the required software. In real life however it is also impossible to satisfy all requests in the required timeframes, because projects typically have limited budget and resources, customers are at least a few, and requirements grow constantly. Therefore, ProductOwner has to be in a continuous dialog with the customers and to prioritize correctly the features that are most important for them in this particular moment, so that they can be provided on time. Also, if there are nice-to-have but not crucial features, and there are not enough resources for them, ProductOwner has to efficiently manage expectations and prepare the customer that those might not be implemented. Transparent status at the end of each iteration combined with a bit more long-term vision from the ProductOwner grow confidence in customers and reduce their pressure on the team or the company. In such open communication, ProductOwner has certain influence on customers and could position successfully features that were not requested by the given customer directly, but are applicable in its scenarios.
To sum up, the ProductOwner’s role is bound to great responsibility – if he/she does not do the job well, even a strong team cannot help the project from failing. At the same time, this responsibility also brings huge influence on project, team, and even customers. Correct utilization of this influence could guarantee success to the team and the overall product.