Chuyên gia nói gì về vai trò và kỹ năng của Product Manager

Khoá 1: Product Management: An Introduction · Module 1 · Tổng quan nghề Product Manager

Video 1: Gặp các chuyên gia

Ý chính

• Các chuyên gia trong khoá đến từ nhiều nền tảng khác nhau: phát triển phần mềm, hỗ trợ kỹ thuật, tư vấn, marketing, bán hàng, thiết kế đồ hoạ, vận tải, y tế, cả giảng dạy. Thâm niên từ khoảng 8 đến hơn 25 năm.
• Điểm chung: hầu như không ai vào thẳng nghề PM. Họ đi từ vai trò khác rồi chuyển sang, và mang theo kỹ năng cũ vào việc làm sản phẩm.
• Nhiều người có thêm chứng chỉ về quản lý dự án, Agile, Scrum hoặc cloud.

Bài học áp dụng

Kinh nghiệm hiện tại của bạn (dev, dạy học, vận hành...) không bị bỏ đi khi chuyển sang PM. Hãy liệt kê nó như "góc nhìn" bạn mang vào sản phẩm.

Video 2: Góc nhìn chuyên gia về vai trò PM

Ý chính

• Mục tiêu chính của PM: bảo đảm sản phẩm giao ra đáp ứng đúng nhu cầu khách hàng. PM là người trung gian giữa khách hàng và các nhóm kỹ thuật, marketing.
• Ba trách nhiệm được nhắc nhiều nhất:
  1. Tầm nhìn sản phẩm: hiểu khoảng trống giữa cái thị trường đang có và cái cần có.
  2. Phối hợp: làm việc với mọi bên liên quan và nhóm làm sản phẩm.
  3. Đại diện khách hàng: mang nhu cầu của khách vào nhóm làm sản phẩm.
• PM đứng ở giao điểm của công nghệ, kinh doanh và marketing. Nhiều chuyên gia ví PM như "chất keo" nối khách hàng, đối tác kinh doanh, bán hàng, phát triển và lãnh đạo.
• Về sơ đồ tổ chức, PM thường báo cáo cho giám đốc sản phẩm hoặc giám đốc marketing, và nằm giữa kỹ thuật, UX, marketing, bán hàng.
• Sản phẩm đại diện cho thương hiệu: khách mua sản phẩm vì gắn nó với chất lượng và trải nghiệm của thương hiệu. PM mang trải nghiệm đó tới khách.

Ví dụ

Hãng xe tải: khách không mua "thương hiệu" mà mua chiếc xe, nhưng họ chọn chiếc xe vì tin vào độ bền của thương hiệu. PM xe tải phải giữ cho từng tính năng mới không phá hình ảnh đó.

Tự kiểm tra

• Nêu ba trách nhiệm cốt lõi của PM theo các chuyên gia.
• Vì sao nói PM đứng ở "giao điểm" ba chức năng?

Video 3: Góc nhìn chuyên gia về kỹ năng của PM

Ý chính

• Kỹ năng được nhắc nhiều nhất là giao tiếp (nói và viết): trình bày roadmap, tầm nhìn cho người trong và ngoài công ty, từ nhân viên đến cấp C.
• Các kỹ năng khác:
  • Hiểu kinh doanh: thị trường, công nghệ, khách hàng, năng lực tổ chức.
  • Lấy người dùng làm trung tâm (user-centric): nhìn sản phẩm từ góc nhìn người dùng.
  • Đàm phán: ý tưởng tốt vẫn cần thuyết phục lãnh đạo.
  • Ra quyết định khi dữ liệu còn ít, và xử lý nhanh lượng dữ liệu lớn.
  • Trí tuệ cảm xúc, quản lý thời gian, giải quyết xung đột, lãnh đạo bằng ảnh hưởng.
• Kỹ năng kỹ thuật tuỳ sản phẩm: nghiên cứu người dùng, phân tích dữ liệu và báo cáo, viết user story, làm roadmap, viết yêu cầu rõ ràng cho kỹ sư, dùng công cụ cộng tác (Teams, Slack, Trello, Jira...). Nên hiểu quy trình của từng bộ phận: kỹ thuật, marketing, bán hàng, tài chính.
• Học liên tục để theo kịp thị trường.

Ví dụ

PM của ứng dụng di động không cần tự code, nhưng nên hiểu app được phát triển thế nào để biết một yêu cầu tốn bao nhiêu công sức. PM của sản phẩm DevOps nên hình dung ngày làm việc của một lập trình viên.

Tự kiểm tra

• Kỹ năng nào được xem là quan trọng nhất và vì sao?
• Một PM nên biết gì về bộ phận bán hàng và tài chính?

Video 4: Góc nhìn của một lãnh đạo cấp cao (phần 1)

Ý chính

• PM hợp với người thích giải quyết vấn đề và sáng tạo giải pháp, nhất là ở ngành công nghệ nơi công nghệ mới liên tục xuất hiện.
• PM giống như CEO của một nhóm dịch vụ: chịu trách nhiệm toàn bộ vòng đời sản phẩm, từ ý tưởng đến sau bán hàng, kể cả việc khách có hài lòng hay không.
• Con đường vào nghề không thẳng: người trong video đi từ marketing, từng làm bán hàng, thiết kế, phát triển, nên có sự đồng cảm với nhiều vai trò. Điều này giúp PM tác động đến các nhóm khác.
• Hai lời khuyên cho người mới:
  1. Luôn tò mò và lắng nghe nỗi đau của người dùng, đừng chỉ nghe họ nói muốn gì. Câu chuyện nổi tiếng: khách nói muốn "con ngựa nhanh hơn", thực chất cần phương tiện đi nhanh hơn.
  2. Đừng tin vội, hãy kiểm chứng. Tự truy cập dashboard, tự kéo dữ liệu, hiểu dữ liệu đến từ đâu thay vì nhận con số của người khác.

Ví dụ

Trưởng nhóm báo "70% người dùng bỏ ở bước thanh toán". PM không dùng ngay con số đó, mà vào công cụ phân tích xem 70% tính trên tập người dùng nào, khoảng thời gian nào, rồi mới đề xuất sửa.

Tự kiểm tra

• Vì sao nên lắng nghe "nỗi đau" thay vì yêu cầu bề mặt?
• Bạn sẽ kiểm chứng một con số thống kê bằng cách nào?