Những kỳ vọng về mặt giao tiếp trong việc quản lý sản phẩm
Gần đây mình đọc lại hai bài của anh Thiện, 1 người anh trong circle của mình, về Stakeholder Manageemnt và về chữ “Owner”. Tinh thần chung khá rõ: Product Owner phải “own” nhiều thứ, và là người đứng mũi chịu sào cho sự thành bại của sản phẩm.
Trong đó anh Thiện có chia sẻ một hình minh hoạ về vai trò Product Manager, cho thấy PM nằm ở giao điểm của rất nhiều luồng: business, tech, design, vận hành…
Mình thấy đồng cảm, như mình đã có chia sẻ trong bài Kĩ năng "Cầm kì thi hoạ" khi vận hành team Product: Khi vận hành một team Product, PM cần một dải skill tương đối rộng, từ problem solving ở tầng chiến lược, đến technical, business, và thậm chí cả các nghiệp vụ như kế toán, pháp lý nếu sản phẩm chạm tới những mảng đó.
Chữ “Owner” trong Product Owner nghe rất đã. Nó gợi lên cảm giác trách nhiệm, quyền lực, và sự dẫn dắt. Nhưng càng làm lâu, mình càng thấy nếu không bóc tách kỹ, chữ này rất dễ trở thành một khẩu hiệu hơn là một trách nhiệm cụ thể.
- Không ai yêu cầu PM code giỏi nhất team.
- Không ai yêu cầu PM viết legal chuẩn từng câu chữ.
- Không ai yêu cầu PM trực support hay tự tay chạy deal.
Sau một thời gian quan sát các bạn junior PM, và nhìn lại chính mình hồi mới làm Product, mình nhận ra phần lớn những thứ bị xem là “PM chưa đạt kỳ vọng” thực ra không nằm ở chiến lược cao siêu nào cả.
Một trong những kỳ vọng lớn của PM nằm ở communication. Không phải communication theo nghĩa nói nhiều hay viết nhiều tài liệu, mà là khả năng tạo ra sự rõ ràng trong một hệ thống có nhiều bên liên quan và nhiều tầng trừu tượng khác nhau.
Với mục tiêu là nâng cấp suất ăn cho các bạn độc giả ^^ -> Trong bài này mình sẽ tập trung vào những expectation và responsibility của product management, mình sẽ xoay quanh kỳ vọng thực tế mình quan sát được ở các nơi mình từng làm, chứ không tập trung phiên bản "Lý tưởng hoá" của Product Manager, như được viết ở trong sách.
Một team không có PM
Nếu gỡ Product Manager ra khỏi team, điều gì bắt đầu biến mất? Backlog vẫn còn đó. Dev vẫn code. Business vẫn bán hàng.
Nhưng rất nhanh, một thứ bắt đầu mờ đi: sự rõ ràng về hướng đi.
Thiếu sự rõ ràng về quan điểm & định hướng sản phẩm
Team có thể build rất nhiều thứ, nhưng không ai thật sự biết mình đang tiến về đâu. Roadmap nhìn thì đầy task, nhưng nếu hỏi “theme năm sau là gì?” hoặc “vấn đề lớn nhất của product hiện tại là gì?”, thì câu trả lời thường không rõ ràng lắm.
Một symptom mình từng thấy khá nhiều là: dev chủ yếu fix bug và làm small improvement, còn business thì liên tục đưa task ad-hoc.
Khi không có theme rõ ràng cho năm tới, hoặc không có một câu chuyện đủ rõ về vấn đề hiện hữu của product, hệ thống sẽ tự động rơi vào mode tối ưu cục bộ. Dev tối ưu cái gì nhìn thấy rõ nhất: bug, performance, UI nhỏ. Business tối ưu cái gì có cơ hội gần nhất: request từ khách A, deal từ đối tác B. Không ai làm sai, nhưng cả hệ thống thiếu một hướng chung.
Ở lớp này, PM không phải là người nghĩ ra idea hay nhất, mà là người giữ cho mọi người nhớ: rốt cuộc mình đang giải quyết vấn đề gì? Theme của quý / năm này là gì? Những việc mình đang làm có đang thu hẹp khoảng cách đó không, hay chỉ đang giữ cho product “không bị vỡ”?
Thiếu sự rõ ràng về tiến độ và trade-off
Khi bị hỏi “bao giờ xong?”, câu trả lời thường là còn phụ thuộc, còn đang estimate, còn phải align thêm. Nghe thì hợp lý, vì đúng là có nhiều biến số. Nhưng nếu timeline luôn treo, nghĩa là không ai đang chịu trách nhiệm tạo một timeline cho dự án.
- Mình đã đi qua những quyết định nào và có những trade off gì?
- Có những milestones nào?
- Khi nào sẽ xong các milestones này?
Business không dám commit với khách hàng. Ops không chuẩn bị launch. Dev không biết nên tối ưu cho tốc độ hay chất lượng. Cả team vận hành trong một vùng xám. Sau này mình mới hiểu timeline không phải là lời hứa tuyệt đối, mà là một giả định có trách nhiệm.
Khi mình nói “với scope này, X tuần; nếu thêm Y thì sẽ trễ Z”, mình không chỉ chốt deadline, mình đang buộc hệ thống nhìn rõ trade-off của mình. Sự rõ ràng ở đây không loại bỏ rủi ro, nhưng nó giúp cả tổ chức biết mình đang đánh đổi điều gì để đổi lấy điều gì.
Thiếu sự rõ ràng về rủi ro và tác động hệ thống
Lớp cuối cùng, và cũng là lớp khó nhất, là sự rõ ràng về rủi ro và tác động hệ thống. Junior PM thường nhìn rủi ro ở tầng feature: có bug không, có trễ timeline không. Nhưng làm lâu hơn, mình bắt đầu thấy rủi ro thực sự thường nằm ở những liên kết.
Một thay đổi về pricing không chỉ là đổi công thức tính tiền, mà có thể kéo theo thay đổi trong cách sales kể câu chuyện, cách legal viết điều khoản, cách BI đọc số liệu, và cách support giải thích với khách hàng.
Nếu PM chỉ communicate ở mức “tăng giá từ ngày X”, thì tổ chức sẽ phản ứng khi sự cố đã xảy ra. PM không cần tự tay giải quyết mọi thứ, nhưng PM được kỳ vọng phải nhìn thấy các liên kết đủ sớm để đưa lên bàn. Khi mình không nhìn thấy rủi ro lan truyền, hệ thống vẫn vận hành, nhưng vận hành trong trạng thái bị động và dễ bất ngờ.
Một số practice mình đang làm
Sau vài năm loay hoay, mình bắt đầu hình thành một số động tác sau cụ thể để giữ bốn lớp rõ ràng này khi làm bất kỳ dự án / quản lý product nào:
- (1) Xác định đúng các stakeholders liên quan ở giai đoạn đầu của dự án
- (2) Xác định hiện trạng và mục tiêu của sản phẩm nói chung và dự án nói riêng
- (3) "Điểm mặt" các rủi ro ảnh hưởng về mặt hệ thống
- (4) Truyền tải outcome càng sớm càng tốt tới các bộ phận liên quan
- (5) Quản lý và đốc thúc việc triển khai
