Mỗi hoàn cảnh vận dụng phương pháp Scrum tồn tại trong bối cảnh riêng của văn hóa công ty, năng lực cá nhân và team, lực lượng cạnh tranh v.v… Bối cảnh này ảnh hưởng lớn đến vai trò của Product Owner được thực hiện ở các công ty khác nhau. Vì vậy thay vì cung cấp một checklist trách nhiệm của Product Owner, tôi thấy hữu ích hơn khi nghĩ về hai điều mà Product Owner cung cấp cho Team: tầm nhìn và các ranh giới.

Cung cấp tầm nhìn (vision)

Trách nhiệm của Product Owner liên quan đến việc thiết lập và truyền đạt tầm nhìn cho sản phẩm. Các team tốt nhất là những người có niềm đam mê được thúc đẩy bởi một tầm nhìn hấp dẫn được chia sẻ nhờ Product Owner. Chúng ta sẽ bán sản phẩm cho ai? Sản phẩm của chúng ta có gì độc đáo? Đối thủ của chúng ta đang làm gì? Sản phẩm của chúng ta sẽ phát triển theo thời gian như thế nào? Tất nhiên, các câu hỏi khác nhau đối với một ứng dụng hoặc dịch vụ cần được gửi tới một nhóm người dùng nội bộ khác nhau, nhưng có một tầm nhìn chung rất quan trọng để thúc đẩy  team và tạo ra một kết nối lâu dài giữa những người phát triển sản phẩm và những người sử dụng nó.

Ngoài tầm nhìn rõ ràng, Product Owner phải giải thích sáng tỏ tầm nhìn đó cho team. Product Owner thực hiện việc này thông qua việc tạo, duy trì và sắp xếp thứ tự ưu tiên product backlog. Trên thực tế có nhiều sự bất đồng giữa các team khác nhau và các ScrumMaster về việc liệu Product Owner có nhất thiêt phải là người thực sự viết ra product backlog. Quan điểm cá nhân của tôi là ai viết product backlog không quan trọng. Điều quan trọng là Product Owner phải là người đảm bảo rằng Product backlog được viết ra. Nếu Product Owner ủy thác việc này cho một business analyst (BA) và BA bỏ sót một số yêu cầu và không viết được product backlog thì Product Owner vẫn chịu trách nhiệm cuối cùng.

Ngoài việc đảm bảo product backlog, Product Owner cung cấp thêm chi tiết vào tầm nhìn bằng cách trả lời các câu hỏi mà các thành viên trong team đặt ra: “Bạn có muốn phần mềm hoạt động theo cách này không?”, “ Ý của bạn là gì khi bạn nói như vậy?”. Mặc dù Product Owner có thể ủy quyền hoặc phân công việc trả lời những câu hỏi này cho người khác, Product Owner không thể ủy thác trách nhiệm của chính mình. Product Owner có thể nói với team rằng: “Hãy thảo luận với Nirav nếu bạn có những câu hỏi về các tính năng của shopping cart và phương pháp thanh toán nên hoạt động”. Nhưng khi Nirav không phản hồi hoặc phản hồi không thỏa đáng, Product Owner phải trực tiếp trả lời câu hỏi của team, tìm hiểu lý do tại sao Nirav không giúp ích cho team, và chỉ định một người khác hoặc tìm một giải pháp khác để trả lời các câu hỏi của team.

Cung cấp ranh giới (boundaries)

Tầm nhìn và ranh giới có thể được coi là các khía cạnh cạnh tranh nhau của dự án. Tầm nhìn cho thấy cái mà sản phẩm có thể trở thành. Ranh giới mô tả điều kiện ràng buộc thực tế trong đó tầm nhìn phải được hiện thực hóa. Ranh giới được cung cấp bởi Product Owner và thường ở dạng ràng buộc, chẳng hạn như:

• Tôi cần sản phẩm ra mắt vào tháng Sáu.
• Chúng ta cần giảm một nửa chi phí đơn giá.
• Dự án cần chạy với tốc độ gấp đôi.
• Ứng dụng chỉ có thể sử dụng một nửa bộ nhớ so với phiên bản hiện tại.

Thông thường khi tôi nói với các team rằng Product Owner được phép ra chỉ đạo cho những thứ kể trên, đặc biệt là due date, tôi đã gặp phải những phản ứng giận dữ của team. “Không thể nào, ước lượng  tiến độ công việc là hoàn toàn tùy thuộc vào team chứ. Tất cả những gì Product Owner làm chỉ đơn thuần là sắp xếp thứ tự ưu tiên công việc dự án”. Mặc dù những tuyên bố như thế là đúng nhưng Product Owner cũng chịu trách nhiệm xác định ranh giới sẽ quyết định sự thành công của sản phẩm.

Hầu hết các thành viên có kinh nghiệm trong Scrum team sẽ dễ dàng đồng ý rằng Product Owner có quyền tuyên bố: “Chúng ta cần phát triển ít nhất là các yêu cầu chức năng từ số 1 đến số 8 của product backlog, nếu không thì sản phẩm của chúng ta không thể phát hành cho khách hàng.” Nhưng nhiều người trong số họ chống lại khi Product Owner đưa ra tuyên bố tương tự về thời hạn hoàn thành!

Nhưng hãy xem Takeuchi và Nonaka đã nói gì trong nghiên cứu của họ về sáu đội hình thành nên nền tảng của Scrum và là chủ đề của bài báo đầu tiên về Scrum vào năm 1986. Quản lý cấp cao của Fuji-Xerox đã yêu cầu một máy photocopy hoàn toàn khác biệt và đã cho team dự án FX-3500 hai năm để đưa ra một cỗ máy có thể được sản xuất với chi phí chỉ bằng một nửa so với dòng cao cấp của công ty và vẫn có hiệu năng hoạt động tốt như vậy.

Ở đây, chúng ta rõ ràng có một team dự án đối mặt một vấn đề đầy thách thức: làm ra sản phẩm có hiệu suất của máy photocopy tốt nhất mà công ty có, nhưng chỉ với một nửa chi phí và một thời hạn 2 năm để giải quyết vấn đề. Product Owner sẽ sai khi anh ta ràng buộc quá mức một vấn đề đến mức team không thể đưa ra giải pháp khả thi cho vấn đề cần giải quyết. Nếu ban quản lý Fuji-Xerox, đưa ra cho team dự án vấn đề tương tự nhưng chỉ có một tháng để giải quyết, team sẽ thấy sự vô nghĩa trong tình huống đó và thậm chí không muốn thử nghiên cứu giải pháp. Vấn đề như được trình bày ở đã khiến team có khá nhiều thời gian để tìm giải pháp.

Một phần công việc của Product Owner, công việc mang tính nghệ thuật nhiều hơn khoa học, là cung cấp đủ ranh giới xung quanh dự án để team có động lực giải quyết vấn đề khó khăn được đặt ra nhưng không áp đặt quá nhiều ranh giới khiến việc giải quyết vấn đề trở nên bất khả thi. Khi động não tìm giải pháp cho một vấn đề thách thức, lời khuyên phổ biến là hãy nghĩ “outside the box.” – đứng từ ngoài nhìn vào. Tuy nhiên, có bằng chứng cho thấy các giải pháp tốt hơn xuất hiện dễ dàng hơn từ suy nghĩ “inside the box.”, miễn là hộp được đóng khung đúng cách. Ranh giới cho hộp mới đó được xác định bởi các ràng buộc quan trọng nhất đối với doanh nghiệp, có thể liên quan đến những thứ như danh sách các chức năng tối thiểu phải thỏa mãn, hiệu suất hoạt động sản phẩm nhanh hơn đáng kể, giảm tiêu thụ tài nguyên và trong một số trường hợp là ngày ra mắt sản phẩm.