Bài này tôi có vài đúc kết về công việc hàng ngày của Product Owner kinh nghiệm của tôi và các bạn bè trong ngành. Mục đích là nhằm cung cấp thêm góc nhìn cho các bạn quan tâm và cần tìm hiểu thêm về công việc này.

Cá nhân tôi tự thấy may mắn khi từng trải qua các công ty có tính chất và lĩnh vực khá đa dạng như Software Outsourcing (Gia công phần mềm), Nông nghiệp (Agritech), Quản lý nhân lực (HRM), Du lịch (TravelTech), Thương mại điện tử (E-Commerce), Giáo dục (EdTech), Game. Mặc dù chức danh có thể thay đổi nhưng vai trò và nhiệm vụ của một Product Owner (PO) vẫn chiếm khá nhiều thời gian trong những gì tôi làm.

Tôi sẽ chia các công việc theo tần suất: Hàng ngày (Daily), Hàng tuần (Weekly)/Mỗi hai tuần (Bi-Weekly), Hàng quý (Quarterly) để mọi người dễ hình dung.

Daily

Các đầu việc diễn ra hàng ngày của PO không khác nhiều so với các thành viên khác của Development team (nhóm phát triển).

• Cập nhật tiến độ công việc hàng ngày với đồng đội: thường diễn ra vào buổi Daily Stand-up (buổi họp nhanh kéo dài tối đa 15 phút đầu ngày để mỗi người cập nhật: Hôm qua làm gì? Hôm nay làm gì? Vấn đề phát sinh cần được hỗ trợ)
• Tham gia các cuộc họp đã lên lịch định kỳ hoặc không định kỳ với Development team, Stakeholders (Các bên liên quan có ảnh hưởng đến dự án), Users (Người dùng sản phẩm) hoặc Clients (Khách hàng).
• Tham gia thảo luận các vấn đề liên quan đến công việc trên các ứng dụng chat nhóm như Slack/Discord/Skype.
• Giải quyết các Ad-hoc Tasks (Các công việc đặc biệt, phát sinh không có kế hoạch nhưng quan trọng). Có thể là bổ sung trường hợp thiếu sót trong Product Requirement Document (Bản mô tả sản phẩm) để bạn Developer tiếp tục coding hay là cùng team điều tra nguyên nhân của một Bug (lỗi phần mềm ảnh hưởng đến việc sử dụng của người dùng) quan trọng.

Weekly/Bi-Weekly (theo Sprint)

Các team làm sản phẩm (không làm việc theo dự án kiểu Waterfall) thường áp dụng mô hình Scrum để chia công việc theo từng Sprint, mỗi Sprint sẽ kéo dài theo chu kỳ 1 hoặc 2 tuần và cứ thế lặp lại. Ưu điểm của mô hình này là có thể nhanh chóng phát hành sản phẩm đến tay người dùng (hoặc khách hàng) để nhanh chóng lấy đánh giá cho lần cải tiến tiếp theo.

Trong mỗi Sprint, PO sẽ thực hiện các công việc:

• Lên mục tiêu và kế hoạch cho Sprint tiếp theo: Thường dưới dạng Sprint Objectives, Product Roadmap, Epic.
• Chuẩn bị Product Backlog cho Sprint tiếp theo. Bao gồm: Đánh giá mức độ ưu tiên; tính khả thi của các Backlog Items (Vấn đề, Ý tưởng, Giải pháp, Yêu cầu).
• Hoàn thiện các mô tả yêu cầu tính năng (Product Requirement Documents (PRDs) hoặc User Stories) đã lên kế hoạch. Ở bước này PO sẽ làm việc với User Experience Researcher (UXR) để lấy thêm insights từ người dùng (Pains, Gains, Needs,…), xác nhận các giả thiết (Hypothesis), hoặc tìm cách đánh giá các bản Prototype (bản thử nghiệm); làm việc với User Experience Designer (UXD) để thiết kế tính năng có trải nghiệm tốt nhất dưới dạng User Flow/Wireframe; nếu PO làm cả phần việc của UXD thì PO cũng sẽ làm việc với UI Designer để biến các bản Wireframe thành các thiết kế có bố cục, phân cấp, màu sắc,… có thể handoff cho Developer tiến hành coding giao diện. Và nhiều vị trí chuyên môn khác để đảm bảo tính năng được hoàn thiện yêu cầu trước khi chuyển sang Developer để tiến hành hiện thực hoá.
• Ở bước trên, nếu chỉ gửi cho Developer file UI Design (ví dụ: Figma file, Sketch file) thôi thì chưa đủ. Có nhiều tính năng có User Flow và yêu cầu phức tạp, PO sẽ có buổi Backlog Grooming để giải thích về PRDs/User Stories cho Developers. Đảm bảo rằng các Developers hiểu rõ tại sao cần làm tính năng này, luồng đi của người dùng, các trường hợp xảy ra và cách xử lý mỗi trường hợp, các điều kiện,… giúp Developers đánh giá Feasibility, Constraint và Effort.
• Theo dõi các chỉ số về sản phẩm: Thông qua các công cụ tracking (vd: Firebase Analysis, Appflyer, Amplitude,…) để đánh giá mức độ hiệu quả của các tính năng sau khi triển khai, phẩn hồi và xử lý các vấn đề quan trọng kịp thời.
• Liên lục lấy phản hồi từ người dùng: Thông qua các buổi phỏng vấn, khảo sát hoặc phản hồi qua các kênh liên lạc (Contact Form, Email, Live chat, Bug Report, Social Media, Store Review,…) để có thêm thông tin cho việc đánh giá và cải tiến sản phẩm, giải quyết các vấn đề tiềm năng, nâng cao trải nghiệm người dùng.

Quarterly

• Cùng với các cấp cao hơn (ví dụ: Product Manager, Business Owner, CEO) đánh giá lại các kết quả đạt được trong quý, về Objectives và Key Results đã đề ra, các Milestones đã hoàn thành. Đánh giá các điểm đã làm tốt, các điểm làm chưa tốt, những khó khăn để rút ra các bài học cho giai đoạn tiếp theo.
• Làm việc với Product Manager/Business Owner, CEO, Stakeholders và Development team để đánh giá lại mục tiêu dài hạn, xác định mục tiêu ngắn hạn, nguồn lực, sản phẩm và nhiều thông tin khác để lên kế hoạch phát triển cho giai đoạn tiếp theo dưới dạng Objectives – Key Results – Action Plans hoặc Product Roadmaps.

Và rất nhiều công việc “không tên”

Trong nhóm phát triển sản phẩm, PO như một chất keo kết dính mọi người, tháo gỡ các khó khăn và đảm bảo rằng cả nhóm sẽ cùng đi đến được các mục tiêu đề ra (điều này không đồng nghĩa với việc PO là người quản lý nhóm phát triển). Chính vì vậy, sẽ có nhiều lúc PO đảm nhận nhiều công việc “không tên” hay kiệm nhiệm nhiều vai trò đồng thời.

Việc này có cái hại và cái lợi, đôi khi gây ra rất nhiều áp lực nhưng chính là cơ hội để PO xây dựng nền tảng theo T-Shape Skillset và phát triển lên các vị trí cao hơn như Product Manager.

Nhìn chung, công việc của PO ở các công ty khác nhau rất nhiều do phụ thuộc vào tính chất công ty, thị trường, tính chất sản phẩm, các đồng nghiệp và rất nhiều yếu tố khác. Khi ứng tuyển công việc có chức danh (Job title) là “Product Owner” hay các công việc có tính chất tương tự, điều cần làm là giành thời gian tìm hiểu thêm về công ty và quy trình làm việc ở đó; sản phẩm đang giải quyết vấn đề gì, cho ai và ở giai đoạn nào; các đồng đội tương lai họ là ai và có ưu nhược điểm gì; các đầu mục công việc cần làm; các bài toán cần giải quyết để có sự hình dung và chuẩn bị tốt nhất trước khi tham gia.