Ảnh Austin Distel từ Unsplash
Lý tưởng thì, PM giao tiếp với tiếng nói của khách hàng bằng cách đặt được thành công về khách hàng và thị trường. Còn một vai trò khác gọi là PO. Người này tạo ra, theo dõi và phân loại ưu tiên các backlog, tạo ra các user stories triển khai được cho đội phát triển (dev team), tham gia các cuộc họp scrum daily meeting, trả lời các câu hỏi của dev như một người đại diện cho khách hàng/người dùng, chấp nhận các user stories hoàn thiện để đảm bảo chức năng hoạt động đúng, tham gia các buổi retrospectives lặp đi lặp lại.
NHƯNG! Không phải công ty nào cũng được tổ chức như vậy. Một vài công ty chỉ có vị trí PM, một số khác chỉ có PO. Trong các công ty lớn, PM đứng ở level cao hơn PO và hoạt động như đầu mối kết nối giữa đội trong nhà và thế giới bên ngoài. Rất khó để vạch ra ranh giới giữa hai vị trí hoặc công việc này. Để hiểu rõ hơn, cần đi qua trách nhiệm của từng người.
PM
Khi đội kĩ sư (engineering team) của công ty có hơn 20 người, nhiều công ty đã chia vai trò của product ra làm hai. Trong hoàn cảnh đó, PM là người chịu trách nghiệm nghiên cứu thị trường, xác định khách hàng, nói chuyện với khách hàng, quản lý và dự đoán tầm nhìn dài hạn của công ty, giao tiếp với các stakeholder bên ngoài, v.v. Một số người mô tả PM là CEO của sản phẩm phần lớn dựa trên mặt tiền tuyến của công việc này.
Nếu phải mô tả PM trong vài từ, những từ sau đây sẽ đúng :
- Người truyền bá và bảo vệ sản phẩm
- Tầm nhìn sản phẩm
- Chuyên gia nghiên cứu thị trường
- Giao tiếp với các stakeholder nội bộ và bên ngoài
PM là người chị trách nhiệm đưa ra chiến lược sản phẩm và theo dõi toàn bộ vòng đời sản phẩm từ nghiên cứu thị trường, phát triển khách hàng tới hỗ trợ marketing và sales. Điều đó giúp PM có cách tiếp cận tổng thể và từ trên cao đối với sản phẩm hơn bất kì người nào khác.
"Thế nên một số người làm sản phẩm gọi họ là bố mẹ đẻ của sản phẩm đó"
PO
PO tham gia với vai trò hậu phương bằng cách thiết lập user stories, quản lý backlog, nói chuyện với đội phát triển về yêu cầu, xây dựng quy trình sản phẩm, tham gia các buổi họp agile, giao tiếp với PM để xác định lộ trình sản phẩm và giúp họ xây dựng roadmap/tầm nhìn. Nói một cách khác, PO làm tất cả các bài tập về nhà cần phải làm. Họ có thể được coi là COO của công ty.
Theo Scrum framework, PO làm những việc sau:
- Định nghĩa product backlog và tạo ra những user stories có thể triển khai
- Phân loại ưu tiên phát triển
- Đưa vấn đề của khách hàng vào các user stories
"Vì thế điểm khác biệt giữa PM và PO là PM ra ngoài nghiên cứu thị trường, gặp khách hàng tiềm năng và tổng hợp phản hồi. PO ở nhà liên hệ ngay lập tức với đội phát triển và đảm bảo mọi quy trình sản phẩm được triển khai chính xác."
PO là tiếng nói của khách hàng đối với Scrum team. Nó giúp dev có câu trả lời một cách nhanh chóng. Ngoài ra, sự xuất hiện cũng phân biệt rõ giữa PO và PM. PO cần ngồi sát đội phát triển bất cứ khi nào họ cần PO. Trong khi đó, PM không cần tham gia quá nhiều vào những vấn đề kĩ thuật vì công việc của họ thiên về tầm nhìn lớn hơn.
RỒI SAO?
Theo ý tôi, PM và PO có thể là một nếu công ty còn nhỏ và đang đi những bước đầu tiên trong việc tạo ra sản phẩm.
Ý tôi là, ngay khi bắt đầu, một startup có thể chỉ cần một PM làm việc trực tiếp với dev team và các stakeholder bên ngoài cùng lúc.
Nhưng khi startup phát triển và sản phẩm ngày càng lớn hơn, vai trò của người làm sản phẩm có thể được chia làm 2,3,4 thậm chí nhiều người hơn. Các công ty lớn hơn cần nhiều người chịu trách nhiệm sản phẩm hơn. Cũng có những công ty với vài PO cho những tính năng riêng biệt. Điều này cho phép PM tập trung nhiều hơn vào tầm nhìn dài hạn.
Bạn có thể nói là vị trí PM và PO đôi khi trùng nhau. Đúng là vậy, luôn có sự trùng nhau giữa các hoạt động chiến lược của PM và hoạt động cụ thể của PO. Điều này chỉ ra sự cần thiết trong việc phối hợp và giao tiếp của những người này. Quyết định cụ thể cần phản ánh được chiến lược tổng thể và chiến lược tổng thể nói chung phải tác động tới hoàn cảnh mà đội phát triển đang phải đối mặt. Vậy nên dù có bao nhiêu PO cho mỗi sản phẩm cụ thể thì họ cũng cần giao tiếp với PM để hiểu ý nhau.
Tôi muốn nói rằng các công ty lớn hay startup nhỏ đều phải linh hoạt khi giao các việc product này. Và việc chia nhỏ phải dựa trên nhu cầu thực tế. Ví dụ, nếu team nhỏ thì đâu cần một Scrum master riêng biệt, team leader có thể làm việc này. Nhưng nếu có sự thiếu hụt kĩ năng cần thiết (ví dụ giao tiếp không tốt) thì PO có thể làm việc với team để giao tiếp với nhu cầu của stakeholder.
