Product Owner thực chiến làm gì?

Trong chuỗi giá trị ITIL 4, chữ Product Owner (PO) lại được nhắc nhiều. Làm dịch vụ, hay là gì thì cuối cùng Product của Software là thứ thể hiện giá trị với chủ doanh nghiệp, các bộ phận, và người dùng rõ nhất. Trong các cơ quan Nhà nước, vai trò Product Owner khá mờ nhạt do cấu trúc phòng ban phức tạp, liên quan đến các yếu tố chính trị. Tuy vậy trong bất cứ tổ chức nào vẫn phải cần xác định rõ hơn vai trò của PO, hay nói một cách dân dã thì PO là người "chốt". Nếu không có người chốt thì dự án rất khó "trôi", trái lại dự án sẽ đi "lòng vòng" và mỗi lần như vậy gặp tình huống "đẽo cày giữa đường".

PO làm gì? Đâu là việc quan trọng của PO? Một câu hỏi nghe có vẻ đơn giản nhưng để người đảm nhận vai trò này thì cũng “không đơn giản” tí nào. Hãy thử phân tích các "keyword" sau (giữ nguyên tiếng Anh để thấu hiểu rõ thông điệp truyền tải):

* Demand & Insight: PO cần nắm rõ về "Demand" đến từ đâu. Nhưng trước đó cần biết ai là người bỏ tiền, ai là người xài sản phẩm, ai là người tham gia chuỗi công việc mua sản phẩm. "Insight" của họ là gì?. Ví dụ: Sáng nay bà xã nói “bố bỉm sữa” đi mua bỉm cho con. Mỗi trong câu nói đó bà xã đã quyết loại bỉm nào rồi. Bố bỉm sữa không có cơ hội quyết. Đứa xài bỉm là thằng nhóc con ở nhà. Bố bỉm sữa chỉ quan tâm đến sự niềm nở của cô gái bán hàng, sự thuận tiện trong việc thanh toán và giá cả phải chăng. Thế đó, có 3 đối tượng thôi đã rối rối rồi. Nhưng đó là công việc thú vị cho người làm sản phẩm bỉm. Nói bỉm cho dễ hiểu, thực tế thì Software vốn dĩ trừu tượng và bị "thần thánh" hoá quá, thành thử khó hiểu.

* Engagement & Plan: Khi xác định được đối tượng, thì cần tương tác, tạo ảnh hưởng như thế nào để xác định nhu cầu thật sự. Rất khó khăn phải không, đặc biệt với các sản phẩm mới. Nhưng đó là việc quan trọng số một của PO. Rồi làm plan để “ép – cứ nghĩ đến việc ép xung cho dễ hiểu” những kỹ sư tạo ra sản phẩm để thoả mãn nhu cầu thật nhanh và phát hiện ra sai lầm cũng thật nhanh theo cách như vậy, còn gọi là chiến thuật "Fail fast, fail cheap, fail forward". Sau đó lại plan để test thử xem có thật sự đối tượng có “thoả mãn” không? (còn gọi là A/B test). Sẽ có những hôm cô bán bỉm mời chào một dòng bỉm mới ghé cửa hàng. Có một điều cô đang chào chưa đúng đối tượng. Bố bỉm sữa có quyền quyết vụ mua bỉm đâu? Nhưng bố bỉm sữa biết rằng cô ấy đang thực hiện plan test thử thị trường về dòng sản phẩm có tính năng mới.

* Metric & Improve: Đo lường là việc bắt buộc phải làm khi làm sản phẩm. Bởi nếu không đo thì PO sẽ không biết gì về phản ứng của thị trường về sản phẩm đang tung ra. Và cũng không giải thích tại sao doanh số của “Sales” tăng lên (tích cực), hoặc giảm xuống (tiêu cực). Phải đo đạc, lượng hóa thì mới biết cải tiến ở đâu. Làm product có khác biệt là như vậy.

Quay lại vụ bỉm sữa. Các PO họ đã đưa ra kế hoạch đo hiệu quả của marketing thông qua điểm bán bỉm. Bố bỉm sữa từ chối dùng mới sản phẩm bỉm mới cũng là cách phản hồi gắn liền với chỉ số đo lường. Từ đó có những điểm cải tiến phù hợp với insight của khách hàng mục tiêu.

Đọc đến đây nhiều "Sếp" làm Product thốt lên “Sao bạn PO nhà mình chưa làm những điều này?”. Sự thật thì số lượng PO xem những điểm trên và thực hành có rất ít trên thị trường. Đa phần PO nghĩ đến các keyword khác kiểu như: “Viết Requirement Specs”, “Viết User Story”, “Mockup”, “Prototype”, “KPI”, “Change Management”,… Những việc chi tiết dẫn nguồn từ những việc quan trọng mà bố Bỉm sữa nói ở trên.
Một ông bố Bỉm sữa ngồi review kịch bản đào tạo cho Product Owner Thực Chiến cho hay.

Điểm khác nhau giữa Product Manager và Product Owner là gì ?

Ở Việt Nam, Product Owner/Manager/Specialist/Executive… không phải là những chức danh “chuẩn” tương ứng với từng nấc thang trong một nhánh nghề nghiệp. Chúng sẽ thay đổi tùy theo cấu trúc công ty, cũng như quy mô dự án.

Product Manager và Product Owner khác nhau về phạm vi, tính chất công việc:

Product Manager là người giải quyết những vấn đề mang tính chất tổng quan, chiến lược của sản phẩm. Ví dụ như tầm nhìn, định vị sản phẩm trong thị trường, làm product roadmap .v.v…

Product Owner là người giải quyết những vấn đề thực tế của user khi sử dụng sản phẩm. Từ đó vận hành/cải tiến sản phẩm nhằm đạt được KPI kinh doanh của công ty.

Product Owner có thể coi là “Product Manager” của một/vài sản phẩm nhỏ nằm trong sản phẩm lớn.

Vậy những công việc của Product Owner là gì?

Theo dõi “sức khỏe” của sản phẩm thông qua số liệu/phản hồi của user. Từ đó tìm ra các vấn đề cần sửa chữa/cải tiến.
Làm user research, bao gồm cả phỏng vấn trực tiếp user, để chắc chắn những vấn đề nêu trên thực sự là vấn đề (không phải phỏng đoán).
Đưa ra giải pháp. Kết hợp với UX Designer để vẽ wireframe, với UI Designer để “khoác áo” cho thiết kế. Làm specifications để diễn giải thiết kế cho đội ngũ phát triển (dev, QA).
Lên timeline và kế hoạch release. Tùy vào quy mô của tính năng sản phẩm mà có thể chia làm nhiều giai đoạn release nhỏ.
Sau khi release, tiếp tục theo dõi các chỉ số, và lặp lại quy trình nói trên.

Bạn có thể tham khảo thêm vai trò của Product Owner là gì trong quy trình Scrum minh họa sau:

4 nguyên tắc quan trọng nhất khi phát triển sản phẩm

1. Đề cao sự rõ ràng (clear, but not fancy).

Nghĩa là sản phẩm phải đơn giản, dễ hiểu, dễ sử dụng và đúng mong đợi của user. Thay vì đẹp nhưng rắc rối, khó hiểu, khó dùng.

2. Mọi quyết định phải dựa trên số liệu (data driven).

Người làm product đôi khi mắc bệnh “áp đặt”. Nghĩa là thiết kế sản phẩm dựa trên mong muốn/ý thích của cá nhân chứ không phải nhu cầu thực tế của user. Cho nên, nguyên tắc tối quan trọng trong phát triển sản phẩm là:

Ý tưởng phải xuất phát từ thực tế nghiên cứu thị trường, phân tích dữ liệu.
Sau đó, phải phản biện ý tưởng một lần nữa thông qua nghiên cứu, phỏng vấn trực tiếp user. Từ đó, chứng minh ý tưởng đó thực sự là một vấn đề cần giải quyết, chứ không phải chỉ là một giả thuyết/suy đoán.

3. Thiết kế cho mọi người, nhưng TẬP TRUNG vào đối tượng trung cấp (intermediates).

Nếu hướng đến người dùng sơ cấp (beginner), thì sản phẩm dễ khiến người dùng trung/ cao cấp (intermediates/experts) cảm thấy nhàm chán, bị làm phiền.

Ngược lại, thiết kế đặt experts làm trọng tâm sẽ khiến beginner khó hiểu, khó sử dụng.

Cho nên, mục tiêu của người thiết kế sản phẩm là hướng đến intermediates. Đồng thời hỗ trợ beginner dần chuyển sang nhóm intermediates/experts.

4. PO phải biết “thông cảm” với user.

Bởi vì mình là người làm ra sản phẩm nên với mình thì mọi thứ có thể rất đơn giản rõ ràng. Nhưng không có nghĩa user cũng cảm thấy như vậy. Có một phương pháp được nhiều doanh nghiệp toàn cầu, như Apple, Google, Uber và Facebook áp dụng để phát triển năng lực phát triển sản phẩm. Đó chính là phương pháp Design Thinking - tư duy thiết kế.

Design Thinking là quá trình tư duy nhằm tiếp cận và giải quyết vấn đề dựa trên tư duy hình ảnh để hữu hình hóa giải pháp. Cho dù vấn đề đơn giản hay phức tạp, đặc biệt là các vấn đề trừu tượng, khó dự tính trong tương lai, Design Thinking vẫn giúp bạn giải quyết được bằng cách hiểu sâu các vấn đề liên quan đến con người, cách tiếp cận thực tế bằng tư duy hình ảnh và các phương thức kiểm tra.

Xem thêm: https://tigosoftware.com/lean-design-thinking-innovation