Published Saturday, 8:57 a.m. 22 min read

Tôi nghĩ Product Manager không chỉ “quản lý sản phẩm”, mà là người giữ cho sản phẩm không đi lạc khỏi khách hàng

Có một chi tiết làm tôi dừng lại khá lâu khi học về vai trò Product Manager: nếu công ty làm bột giặt, PM không thể chỉ nói chung chung rằng “khách hàng muốn sản phẩm tốt hơn”. Người đó cần hiểu khách hàng thích dạng bột, nước hay viên giặt; họ quan tâm mùi hương tươi mát, giá cụ thể, khả năng tẩy vết bẩn mạnh, hay một yếu tố nào khác. Nghe rất đời thường, nhưng chính sự đời thường đó khiến tôi nhận ra Product Management không phải là một vai trò mơ hồ đứng giữa các phòng ban cho “oai”.

Quan điểm của tôi sau bài học này là: Product Manager là người biến tiếng nói của khách hàng, dữ liệu thị trường và mục tiêu kinh doanh thành một hướng đi đủ rõ để cả tổ chức cùng hành động. PM không nhất thiết tự tay thiết kế, lập trình, bán hàng hay chạy quảng cáo, nhưng họ phải hiểu đủ để kết nối những phần đó lại.

Điều này quan trọng với bất kỳ ai đang tìm hiểu AI PM hoặc Product Management nói chung, vì nếu chỉ nhìn PM như “người viết roadmap” thì rất dễ bỏ qua phần khó nhất: biết sản phẩm nên phục vụ ai, giải quyết vấn đề gì, ưu tiên điều gì, ra mắt khi nào, và học gì từ phản hồi sau đó.

1. Product Manager bắt đầu từ việc lập kế hoạch sản phẩm, không phải từ danh sách tính năng

Điều đầu tiên tôi học được là Product Manager chịu trách nhiệm lớn trong product planning, tức lập kế hoạch cho sản phẩm. Nhưng kế hoạch ở đây không chỉ là “quý này làm tính năng A, quý sau làm tính năng B”. PM cần hiểu nhu cầu khách hàng, nắm được thị trường hiện có gì, thị trường đang đi về đâu, rồi từ đó quyết định sản phẩm nên được phát triển theo hướng nào.

Ví dụ trong bài học có nhắc đến việc khách hàng ngày càng hỏi nhiều hơn về sản phẩm hữu cơ. Nếu là PM trong một công ty hàng tiêu dùng, bạn không thể chỉ nghe thấy chữ “organic” rồi lập tức yêu cầu đội ngũ làm một sản phẩm hữu cơ. Bạn cần tìm hiểu thị trường đã có những loại sản phẩm hữu cơ nào, khách hàng mua vì sức khỏe, vì môi trường, vì thương hiệu hay vì xu hướng, mức giá họ chấp nhận là bao nhiêu, và đối thủ đang định vị sản phẩm ra sao. Từ đó, kế hoạch sản phẩm mới có cơ sở.

Tôi thấy điểm này rất giống việc chuẩn bị mở một quán cà phê nhỏ. Nếu chỉ nói “mọi người thích cà phê ngon” thì chưa đủ. Bạn phải biết khu vực đó có nhiều dân văn phòng hay sinh viên, họ cần cà phê mang đi hay chỗ ngồi làm việc, họ sẵn sàng trả 25.000 hay 60.000 đồng, xung quanh đã có bao nhiêu quán tương tự. Product planning cũng vậy: không thể tách sản phẩm khỏi bối cảnh thị trường và hành vi thật của người dùng.

Một trách nhiệm khác đi cùng lập kế hoạch là quản lý rủi ro. Trong bài học, PM được mô tả là người thiết lập chiến lược sản phẩm, nghiên cứu thị trường, tạo roadmap, ưu tiên tính năng, phối hợp đội nhóm, theo dõi cạnh tranh, ra mắt sản phẩm, thu thập phản hồi và quản lý rủi ro. Tôi hiểu rủi ro ở đây có thể là làm sai nhu cầu, ra mắt quá muộn, định giá không phù hợp, đội kỹ thuật không đủ nguồn lực, hoặc sản phẩm bị đối thủ vượt qua.

Lời khuyên thực tế tôi tự rút ra cho người mới là: nếu muốn học Product Management, đừng bắt đầu bằng việc học cách viết một backlog thật đẹp. Hãy thử chọn một sản phẩm quen thuộc, ví dụ ứng dụng đặt đồ ăn, ví điện tử, app học ngoại ngữ, rồi tự trả lời ba câu hỏi: khách hàng chính là ai, họ đang đau ở đâu, và thị trường đang có lựa chọn thay thế nào. Chỉ bài tập nhỏ đó đã giúp bạn nhìn sản phẩm bớt cảm tính hơn rất nhiều.

2. “Voice of Customer” là kỹ năng nghe có cấu trúc, không phải nghe cho có

Một ý tôi thấy rất quan trọng là Product Manager phải học cách nghĩ như khách hàng và lắng nghe voice of customer, tức tiếng nói của khách hàng. Nhưng “nghe khách hàng” không có nghĩa là khách hàng nói gì thì làm y nguyên như vậy. Theo tôi hiểu, PM cần chuyển những lời nói, hành vi và dữ liệu rời rạc thành nhu cầu có thể hành động.

Ví dụ bột giặt trong bài học rất dễ hiểu. Một khách hàng có thể nói: “Tôi muốn loại giặt sạch hơn.” Nhưng “sạch hơn” có thể nghĩa là tẩy vết dầu mỡ tốt hơn, giữ màu áo tốt hơn, khử mùi mồ hôi tốt hơn, hay ít để lại cặn trên quần áo hơn. Người khác có thể ưu tiên giá rẻ, người khác lại muốn mùi thơm lâu. Nếu PM không đào sâu, đội sản phẩm có thể tối ưu sai thứ.

Các cách thu thập tiếng nói khách hàng cũng rất đa dạng: PM có thể tương tác trực tiếp với khách hàng, phân tích dữ liệu khảo sát, tổ chức focus group, phỏng vấn, hoặc dùng các nguồn dữ liệu khác. Điểm tôi thích ở đây là bài học không đóng khung PM trong một kiểu dữ liệu duy nhất. Có lúc bạn cần số liệu rộng từ survey, có lúc cần lắng nghe sâu qua phỏng vấn, có lúc cần quan sát hành vi thật để xem người dùng làm gì chứ không chỉ nói gì.

Tuy nhiên, tôi cũng muốn đặt một phản biện nhẹ: khách hàng không phải lúc nào cũng biết chính xác giải pháp họ cần. Họ biết rất rõ nỗi khó chịu của mình, nhưng giải pháp có thể cần PM và đội ngũ sản phẩm khám phá thêm. Ví dụ một người dùng app học tiếng Anh có thể nói “tôi muốn thêm nhiều bài học hơn”, nhưng vấn đề thật có thể là họ không duy trì được thói quen học, không thấy tiến bộ, hoặc bài học hiện tại quá dài. Nếu chỉ thêm bài học, sản phẩm có thể phình to nhưng không giải quyết đúng vấn đề.

Với người mới, tôi nghĩ có một bài tập đơn giản: lần tới khi bạn nghe ai đó than phiền về một sản phẩm, đừng vội nghĩ cách sửa. Hãy hỏi thêm: “Điều gì làm bạn khó chịu nhất?”, “Bạn gặp chuyện đó trong tình huống nào?”, “Bạn đang dùng cách nào để xử lý tạm?”, “Nếu chỉ được cải thiện một thứ, bạn chọn gì?”. Đây là cách luyện tư duy customer-centric rất thực tế.

3. PM là người kết nối nhiều nhóm, nên phải biết thương lượng giữa các nhu cầu khác nhau

Một phần làm tôi thấy vai trò PM khó hơn tưởng tượng là họ không chỉ làm việc với khách hàng bên ngoài. Có nhiều loại sản phẩm và bối cảnh khác nhau: PM có thể phụ trách nền tảng hoặc dịch vụ IT, sản phẩm nội bộ dùng trong chính tổ chức, sản phẩm bên ngoài dành cho khách hàng, sản phẩm gắn chặt với marketing, hoặc các dịch vụ sau bán hàng như aftermarket services.

Điều này có nghĩa là “khách hàng” của PM không phải lúc nào cũng là người mua cuối cùng. Nếu sản phẩm là một dashboard nội bộ cho đội sales, khách hàng có thể là nhân viên sales, quản lý kinh doanh, đội vận hành và cả ban lãnh đạo. Mỗi nhóm sẽ có nhu cầu khác nhau. Sales muốn nhập liệu nhanh, marketing muốn dữ liệu phân khúc rõ hơn, advertising muốn đo hiệu quả chiến dịch, còn quản lý muốn báo cáo tổng hợp. PM phải thu thập, phân tích dữ liệu rồi tìm hướng đi chung.

Trong bài học có nhấn mạnh rằng PM có thể phải đàm phán và hợp nhất nhu cầu của nhiều khách hàng nội bộ. Tôi thấy đây là kỹ năng rất “người” trong Product Management. Một sản phẩm không thể làm hài lòng tất cả mọi người cùng lúc, nhất là khi nguồn lực có hạn. Vì vậy, PM cần biết ưu tiên tính năng, giải thích lý do, và giúp các bên hiểu vì sao một số việc nên làm trước, một số việc phải để sau.

Ví dụ tự nghĩ: một công ty muốn xây hệ thống quản lý khách hàng nội bộ. Đội sales muốn tính năng nhắc lịch gọi lại, đội marketing muốn tự động gắn tag khách hàng, đội chăm sóc khách hàng muốn xem lịch sử khiếu nại, còn đội kỹ thuật nói chỉ đủ thời gian làm hai tính năng trong tháng này. Nếu PM chỉ chuyển tiếp yêu cầu từ bên này sang bên kia, mọi thứ sẽ rối. PM cần xem mục tiêu hiện tại là tăng doanh thu, giảm churn hay cải thiện năng suất, rồi ưu tiên theo tác động thực tế.

Lời khuyên tôi thấy hữu ích cho người mới là: hãy tập nói về sản phẩm bằng ngôn ngữ của nhiều bên. Với kỹ thuật, bạn cần rõ ràng về yêu cầu và ràng buộc. Với marketing, bạn cần hiểu định vị và thông điệp. Với sales, bạn cần hiểu lý do khách mua hoặc không mua. Với lãnh đạo, bạn cần kết nối sản phẩm với mục tiêu kinh doanh. PM không cần giỏi nhất ở mọi chuyên môn, nhưng cần đủ hiểu để không làm đứt mạch giao tiếp giữa các nhóm.

4. Roadmap là lời hứa có suy nghĩ, không phải lịch trình trang trí

Bài học nói rằng Product Manager thường là point person cho sản phẩm, tức người chịu trách nhiệm chính và “sở hữu” sản phẩm theo nghĩa định hướng. Sau khi phát triển tầm nhìn, PM phải giới thiệu sản phẩm và làm cho phần còn lại của tổ chức hiểu sản phẩm đó. Đây là chỗ tôi thấy khái niệm “product owner” trong bài học rất đáng chú ý: sở hữu không phải là ôm hết việc, mà là chịu trách nhiệm giữ cho sản phẩm có hướng đi nhất quán.

Roadmap là công cụ trung tâm trong việc đó. Roadmap không chỉ trả lời “làm gì”, mà còn cần trả lời: sản phẩm là gì, vì sao nó quan trọng, sẽ được ra mắt như thế nào, khi nào ra mắt, và ra mắt cho ai. Nếu thiếu những câu hỏi này, roadmap rất dễ biến thành một bảng danh sách tính năng được sắp theo tháng nhưng không có logic chiến lược.

Ví dụ Tony trong bài học là Product Manager ở công ty sản xuất chip xử lý máy tính. Tony theo dõi sự thay đổi trong nhu cầu khách hàng và biết đối thủ đang làm gì. Nếu đối thủ tung ra chip giá thấp hơn hoặc tốc độ cao hơn, Tony cần thu thập dữ liệu đó và chia sẻ với marketing, engineering, IT và các nhóm liên quan để cải thiện sản phẩm hiện tại hoặc phát triển sản phẩm mới. Trách nhiệm của Tony không chỉ là “biết thông tin đối thủ”, mà là biến thông tin đó thành hành động trong vòng đời sản phẩm.

Ở đây có nhiều trách nhiệm được nối lại với nhau: theo dõi cạnh tranh, truyền đạt dữ liệu, phối hợp đội ngũ đa chức năng, cải tiến hoặc phát triển sản phẩm, quản lý lifecycle, và chuẩn bị launch. Sau khi sản phẩm ra mắt, PM còn phải thu thập phản hồi từ thị trường để xem giả định ban đầu có đúng không. Nếu phản hồi cho thấy khách hàng không quan tâm đến tốc độ cao hơn mà quan tâm đến tiết kiệm điện, roadmap tiếp theo phải phản ánh điều đó.

PM cũng có thể làm việc với lãnh đạo cấp cao để quảng bá sản phẩm trong nội bộ và advocate cho những nhu cầu còn thiếu. Ví dụ nếu PM biết đối thủ đang cải thiện sản phẩm để đáp ứng nhu cầu khách hàng tốt hơn, PM cần đưa thông tin đó lên đúng nơi, trình bày khoảng cách hiện tại, và đề xuất hướng cải thiện. Tôi nghĩ đây là một phần dễ bị đánh giá thấp: PM phải biết bảo vệ nhu cầu của sản phẩm và khách hàng trước những ưu tiên cạnh tranh trong tổ chức.

Một cách thực hành cho người mới là thử viết roadmap một trang cho một sản phẩm bạn thích. Đừng bắt đầu bằng timeline. Hãy bắt đầu bằng năm dòng: người dùng mục tiêu là ai, vấn đề chính là gì, mục tiêu kinh doanh là gì, ba ưu tiên lớn nhất là gì, và điều gì sẽ không làm trong giai đoạn này. Câu “không làm gì” đôi khi giúp roadmap rõ hơn cả danh sách “sẽ làm gì”.

5. Persona giúp tôi nhớ rằng “người dùng” không phải một đám đông vô danh

Phần về persona là phần tôi thấy dễ áp dụng nhất khi tự học. Product Manager dùng persona để xây dựng hình ảnh về một người dùng điển hình của sản phẩm. Persona không phải là một nhân vật bịa ra cho vui, mà là cách tổng hợp dữ liệu để hiểu khách hàng có đặc điểm gì, mục tiêu gì, kỹ năng ra sao, họ coi trọng tính năng nào, điều gì khiến họ không hài lòng, và họ đang cố đạt được điều gì.

Một persona tốt có thể bao gồm nơi sống, tuổi, nghề nghiệp, mục tiêu, ước mơ, trình độ kỹ năng, tính cách, các tính năng quan trọng với họ và những yếu tố không đáp ứng được kỳ vọng của họ. Để tạo persona, PM nên dựa vào dữ liệu từ khảo sát, focus group, phỏng vấn và các nguồn khác, sau đó phân loại dữ liệu thành các nhóm có ý nghĩa. Điểm quan trọng với tôi là persona nên dựa trên dữ liệu, không chỉ dựa trên tưởng tượng của đội sản phẩm.

Ví dụ trong bài học là Jimmy: một nam giới 25 tuổi, sống ở Los Angeles, làm IT professional, thường về hạng ba hoặc hạng tư trong các cuộc thi cờ vua. Mục tiêu của Jimmy là trở thành người chơi cờ giỏi nhất trong league của mình. Thử thách của anh ấy là giải đấu rất cạnh tranh, anh ấy luyện tập nhiều nhưng chưa tìm được chiến lược tốt hơn để giành chức vô địch. Một bias tiềm năng là Jimmy có thể nghĩ sản phẩm của chúng ta phù hợp với chiến lược dài hạn hơn là tạo lợi thế trước mắt.

Tôi thích ví dụ này vì nó cho thấy persona không chỉ là “nam, 25 tuổi, làm IT”. Phần đáng giá nằm ở mục tiêu, nỗi đau, bối cảnh cạnh tranh và thiên kiến khi nhìn sản phẩm. Nếu sản phẩm là một công cụ luyện cờ, Jimmy có thể cần phân tích ván đấu, gợi ý chiến thuật, bài tập theo điểm yếu, hoặc lộ trình luyện tập trước giải.

Lời khuyên của tôi cho bạn nếu mới học persona: hãy tránh tạo persona quá bóng bẩy nhưng rỗng. Một persona có ảnh đại diện đẹp, tên nghe hay, nhưng không giúp ra quyết định sản phẩm thì chưa đủ. Hãy tự hỏi: “Nếu nhìn persona này, tôi có biết nên ưu tiên tính năng nào hơn không?”, “Tôi có biết thông điệp nào sẽ thuyết phục họ không?”, “Tôi có biết điều gì có thể làm họ thất vọng không?”. Nếu câu trả lời là không, persona cần thêm dữ liệu hoặc cần được viết lại cụ thể hơn.

Điều tôi rút ra: PM giữ sản phẩm gần với thực tế

Sau khi học xong phần này, tôi thấy Product Manager không phải là người có câu trả lời cho mọi thứ. Đúng hơn, PM là người liên tục đặt câu hỏi đúng: khách hàng cần gì, thị trường đang thay đổi ra sao, đối thủ đang làm gì, đội ngũ có thể xây gì, điều gì nên ưu tiên, sản phẩm sẽ ra mắt cho ai, và phản hồi sau khi ra mắt nói gì về giả định ban đầu.

Tôi cũng nghĩ PM là vai trò rất phù hợp với những ai thích đứng ở giao điểm giữa con người, dữ liệu, công nghệ và kinh doanh. Nhưng sự hấp dẫn đó đi kèm trách nhiệm: không được yêu sản phẩm đến mức quên khách hàng, không được nghe khách hàng một cách hời hợt, và không được biến roadmap thành danh sách mong muốn thiếu trọng tâm.

#Aggregation