Product Management cơ bản 3: Product management là gì? - phần 1

Bài viết gốc: https://simpleproductmind.com/product-management-co-ban-3-product-management-la-gi-phan-1/

Ở 2 bài trước, chúng ta đã thảo luận về định nghĩa của một sản phẩm công nghệ, team làm ra sản phẩm gồm những ai. Hy vọng các bài viết trước giúp bạn có cái nhìn sơ bộ về công việc làm sản phẩm công nghệ, nếu bạn chưa đọc thì có thể đọc lại tại đây.

Product managment cơ bản 1: Sản phẩm công nghệ là gì?

Product management cơ bản 2: Product team

Bài này sẽ là về câu hỏi đơn giản nhất, thẳng thắng nhất Product management là gì?

Bạn sẽ quản lý cái gì?

Khi bạn apply vào một vị trí làm sản phẩm, tuỳ thuộc vào công ty mà sẽ có các title khác nhau dành cho bạn, ví dụ như: Product Executive, Product Specialist, Product Owner, Product Manager… Rất nhiều title, lý do là bởi công việc Product Management vẫn còn khá mới nên chưa có một title thống nhất, bạn đừng quá hoảng loạn, tất cả đều là làm Product Management cả.

Product Management – Quản lý sản phẩm ( không biết dịch ra tiếng Việt nó còn nguyên nghĩa không nữa ), bạn thấy một chữ “quản lý” trong đó, vậy thì quản lý là quản lý ai? Quản lý Designer, Developer, hay ai khác? Câu trả lời là bạn không quản lý ai cả, bạn quản lý Sản Phẩm chứ không quản lý những người làm ra sản phẩm.

Khi bạn quản lý một thứ gì đó, có nghĩa là bạn chịu trách nhiệm hoàn toàn cho thứ mà mình quản lý. Trong trường hợp của chúng ta là quản lý sản phẩm, như vậy bạn sẽ là người chịu hoàn toàn trách nhiệm cho sự thành công của sản phẩm. Nói như thế không phải bạn sẽ là người đứng mũi chịu sào cho toàn bộ sản phẩm, thông thường, mỗi sản phẩm sẽ gồm nhiều Product Owner/Specialist, mỗi người sẽ đảm nhiệm một phần của sản phẩm. Giả sử, mình chia Tinder thành 3 mảng chính: Feeds – trải nghiệm lướt feed tìm người tương hợp, Tương tác sau Match – trải nghiệm sau khi Match nhau, và VIP. Bạn là Product Owner được giao cho phần Tương tác sau Match, như vậy bạn sẽ là người chịu hoàn toàn trách nhiệm cho sự thành công của phần Tương tác sau Match – nhớ là Hoàn Toàn, dù ít hay nhiều.

Clear nhé, Product Management là quản lý thành bại của sản phẩm/nhóm tính năng, dựa vào nguồn lực từ team chứ không quản lý team.

Một sản phẩm được sinh ra để làm gì?

Lượt một vòng Internet với câu hỏi “What is Product Management?”, bạn sẽ quen dần với cái diagram ở trên. Vòng tròn giao điểm giữa UX – Technology – Business là một mô tả kinh điển cho công việc làm Product Management, tuy nhiên, từ kinh nghiệm của mình thì lý thuyết suông sẽ không giúp gì cho người mới tìm hiểu công việc này cả. Vì vậy ở blog này mình sẽ chỉ kể về những kiến thức mình đúc kết được, những thứ mình mắt thấy tai nghe trong môi trường sản phẩm ở Việt Nam mà thôi.

Để hiểu rõ công việc làm Product, trước tiên phải hiểu rõ một product được sinh ra để làm gì? Cái này ình nhắc lại từ bài trước thôi.

Một product được tạo ra để giúp tập user của nó giải quyết được các vấn đề của họ theo một cách hết sức tuyệt vời, từ đó đem lại giá trị cho doanh nghiệp.

Tách định nghĩa ở trên ra, chúng ta sẽ được 3 phần quan trọng nhất:

1. Giải quyết vấn đề cho user
2. Giải quyết theo một cách tuyệt vời
3. Đem lại giá trị ( tiền bạc, danh tiếng…) cho doanh nghiệp

Ví dụ:

1. Vấn đề users: Tính năng “Tìm quanh đây” của Zalo giải quyết vấn đề kết nối với những người xung quanh cho user của Zalo
2. Trải nghiệm: Theo một cách khá tuyệt vời, đơn giản đến tuyệt vời, chỉ vài thao tác là bạn đã có thể làm quen với một người bạn ở kế bên.
3. Giá trị cho doanh nghiệp: Tính năng này cực kì Viral, đem lại một lượng lớn users cho Zalo.

Bây giờ nhìn lại cái vòng tròn UX – Technology – Business ở hình phía trên, Product Management chính là việc bạn ứng dụng các mảng kiến thức khác nhau quan đến UX, Technology, Business…, kết hợp với đồng đội ( Designer, Developer, Marketer…) để giải quyết 3 ý mình mới kể ở trên.

Nhìn 3 ý trên theo một cách tổng quát hơn, bạn sẽ thấy nó chia công việc của một người làm Product thành 2 giai đoạn chính:

• Problem Space: đây là giai đoạn bạn cố gắng tìm ra vấn đề của user để giải quyết, rõ ràng để giải quyết vấn đề thì bạn cần phải biết vấn đề là gì đúng không?
• Solution Space: đây là giai đoạn bạn cùng với team thiết kế, xây dựng solution giải quyết vấn đề của user theo một cách tuyệt vời, đồng thời đem lại giá trị cho công ty. Bạn sẽ lặp đi lặp lại 2 giai đoạn này cho đến khi sản phẩm đi hết vòng đời của nó, hoặc bạn nghỉ. Mỗi lần lặp lại thường sẽ được gọi là một Sprint.

Sprint là một thuật ngữ trong Agile Methodology, đại ý là trong một sprint kéo dài khoảng 2-4 tuần thì Product Team sẽ release một cải tiến mới tới users.

• Agile Methodology là một phương pháp luận hiện đại gồm một số nguyên tắc cơ bản hướng tới việc sản xuất phần mềm nhanh chóng, tiết kiệm chi phí. * Release có nghĩa là cập nhật một phiên bản update cho sản phẩm

Problem Space

Ok, bạn đi khá xa rồi đấy. Có một sự thật, khi trở thành một người làm Product, bạn sẽ là người bắt đầu. Thường thì bạn sẽ có một vài idea, ý niệm, định hướng từ lãnh đạo đưa xuống, sau đó bạn sẽ là người phải trả lời “Làm gì bây giờ?” Thử xem hình ở dưới nhé, mình có chú thích bắt đầu đọc từ đâu.

Vì bài này vẫn đang là bài giới thiệu nên mình sẽ không đi sâu vào các kỹ thuật, phương pháp mà chỉ cố gắng mô tả giúp bạn nắm được các ý tưởng cơ bản mà thôi.

Tưởng tượng bạn là Product Owner cho mảng Tương tác sau Match của Tinder, Sprint mới sẽ bắt đầu sau 2 tuần nữa. Câu hỏi bây giờ là “Sản phẩm cần cải tiến điều gì?” hoặc cụ thể hơn là “Bạn sẽ cùng team làm tính năng gì để cải tiến sản phẩm?”.

Rõ ràng ta không thể tự nhiên nghĩ ra một tính năng cool ngầu từ trên trời rơi xuống rồi. Thứ duy nhất giúp được bạn lúc này là Thông tin/dữ liệu ( và cái đầu ). Thông tin sẽ đến từ 3 nguồn chính ứng với 3 bước 1.1, 1.2, 1.3 trong hình:

1. Từ Thị trường, thị trường bao gồm một vài yếu tố:

• Quan trọng nhất là users của bạn, bạn cần hiểu users cần gì, muốn gì với sản phẩm? Hiện tại có gì làm họ chưa hài lòng hay không?… Bạn làm điều này sử dụng một số kỹ thuật khác nhau mà mình sẽ nói cụ thể ở các bài sau.
• Thứ 2 cũng quan trọng không kém đó là các đối thủ trong thời gian này có động tĩnh gì hay không? Đối thủ có release tính năng nào hay ho gần đây hay không?…

2. Từ các cấp lãnh đạo: đừng bao giờ bỏ qua nguồn thông tin này, thông thường các sếp, Stakeholders sẽ có những kỳ vọng cụ thể khác nhau cho sản phẩm trong từng giai đoạn. Bạn sẽ không muốn bơi ngược dòng.
3. Từ thông tin nội bộ:

• Data tình hình hoạt động của sản phẩm, ví dụ cách đây 5 tháng bạn có làm một tính năng, tính năng đó hiện nay có hiệu quả hay không? Các tính năng hiện tại có gì bất ổn hay không?…
• Thông tin từ các team liên quan như Marketing, Content…

Sau khi trao đổi qua lại, thông tin rõ ràng thông suốt. Lúc này bạn sẽ là người quyết định làm tính năng gì để cải tiến sản phẩm. Bạn đem yêu cầu này ra bàn bạc với team – tiến vào quá trình Solution Space.

Tạm kết

Ở phần 1 của bài này, hy vọng mình giúp bạn có được một góc nhìn rộng mở hơn về Product Management. Ở phần 2, mình sẽ tiếp tục với quá trình còn lại là “Solution Space” – nơi bạn cùng với team giải quyết vấn đề đã tìm được ở Problem Space.

Take care, my friend!