Một ngày bình thường của Product Manager diễn ra như thế nào?
Không ngạc nhiên khi meeting là công việc hằng ngày của rất nhiều product manager, phản ánh tầm quan trọng thật sự trong công việc của vị trí này.
Một ngày làm việc thường ngày của một Product Manager phụ thuộc vào giai đoạn phát triển sản phẩm của họ. Nhìn chung, một Product Manager thường làm việc ở 1 trong 3 giai đoạn sau: Nghiên Cứu, Lên Kế Hoạch và Thực Hiện.
Sự kiện được diễn ra vào ngày 20 tháng 07 năm 2019 tại UP Coworking Space, Lầu 24, Toà Nhà Deutsches Haus, số 33 Lê Duẩn, Quận 1, Thành Phố Hồ Chí Minh.
(Translating) Mr. Anthony Thong Do, Product Manager @Holistics, a full-stack data-analytics platform. After dropping out of university, he joined a few companies (Microsoft, Gameloft, e27.co,etc) on different positions such as Developer, Product Designer, Product Analyst, Marketer, etc. He did a lot of different things before finding out that his actual passion is building product.
Besides, he also is Co-founder and Product Manager for gannha.com – a location-based platform for commerce marketing. His portfolio is comprised of impressive and interesting products including dbdiagram.co – a database designer built for #analysts and #developers, which was featured in his past talk on How We Grew a Product to 50K+ Devs Worldwide with $0 Marketing.
Download here. (Uploading)
Video Keynote. (Uploading)
Q&A Session. (Uploading)
Mở đầu buổi nói chuyện, anh Anthony Thong Do - diễn giả của sự kiện - đã chia sẻ ngắn gọn về sự nghiệp của mình. Anh bắt đầu thiết kế websites vào năm 2010. Sau đó, anh đã trải qua nhiều công việc đa dạng từ sales đến marketing và sau đó quay trở lại làm product. Anh đã làm ở Gameloft, E27, sáng lập KreLab, gannha.com và làm nhiều sản phẩm từ game đến app đọc truyện. Cuối cùng, anh đang làm Product Manager ở Holistics.
Profile của anh vô cùng đa dạng. Trong quá trình đó, anh nhận ra đam mê thật sự của mình là build product và quyết định trở thành một PM. Theo anh, không nhất thiết phải thành lập công ty, làm quản lý hay CEO mới có thể tạo giá trị cho khách hàng.
Anh cũng chia sẻ thêm là mình trở thành PM không qua một trường lớp đào tạo nào, chủ yếu nhờ vào kinh nghiệm và quan sát của bản thân. Không có một con đường thẳng nào dẫn đến vai trò PM - bạn không thể vừa tốt nghiệp hoặc vừa đi làm là đã trở thành PM.
Tuy chủ đề hôm nay - Daily Life of A PM - sẽ khác nhau rất nhiều tùy vào vai trò của người PM lẫn tính chất của product, anh Anthony Thong Do đã chia sẻ 9+2 điều anh quan tâm nhất khi là một PM.
Do những chia sẻ của anh mang tính cá nhân với vai trò là một PM của Holistics, anh đã giới thiệu sơ qua về Holistics để khán giả nắm được bối cảnh.
Holistics là một dịch vụ B2B cung cấp BI platform cho các công ty. Dịch vụ này giúp thu thập data từ nhiều nguồn khác nhau lại một chỗ để người dùng có thể trích xuất, phân tích dữ liệu dễ dàng hơn. Nhờ đó, bất kỳ ai trong team (ví dụ như sales hay marketing) có thể tự xử lý data và xây dashboard cho mình, thúc đẩy sự trao quyền và sự phát triển của văn hóa data-driven.
Công việc đầu tiên của một PM là phải hiểu tại sao. Bạn đang làm sản phẩm cho ai? Bạn đang giải quyết vấn đề giúp ai?
PM phải hiểu rõ khách hàng đang gặp vấn đề gì và mình có thể làm gì để giúp họ giải quyết vấn đề đó, từ đó mới tạo nên nền tảng cho sản phẩm. Ví dụ, khi business user muốn tìm insight, data analyst phải lục tìm trong một mớ hỗn độn và mất rất nhiều thời gian. Hiểu được điều đó, Holistics đã giúp họ giải quyết vấn đề này bằng cách cung cấp một dịch vụ giúp sắp xếp data gọn gàng hơn, giúp khách hàng tìm insight nhanh hơn.
Việc hiểu khách hàng, hiểu vấn đề cũng giúp công ty của bạn mang đúng sản phẩm đến đúng đối tượng. Mỗi đối tượng khác nhau có nhu cầu khác nhau. Ví dụ, CEO cần một view đơn giản, trực quan để họ dễ dàng nhìn tổng quan và ra quyết định. Ngược lại, data analyst cần một cái nhìn phức tạp và chi tiết hơn. Do đó, sản phẩm cung cấp đến từng đối tượng sẽ không giống nhau.
Nói ngắn gọn thì PM phải có sự thấu cảm với khách hàng. Họ phải trải nghiệm, hiểu và cảm nhận đời sống của khách hàng thì mới tìm ra pain point của họ. Ví dụ, làm thế nào để thiết kế thang máy cho người mù? Những người sáng mắt thì khó mà hiểu hết những khó khăn của người mù khi đi thang máy, nên PM phải tìm cách đặt mình vào hoàn cảnh của họ để thấu hiểu những điều đó.
Do đó, tất cả mọi người ở Holistics phải dùng Holistics để hiểu khách hàng. Nhưng chỉ vậy thôi chưa đủ, vì mỗi người lại có những vấn đề nhỏ khác nhau và team không thể cover mọi thứ. Thế nên, PM buộc phải...
Chỉ data thôi là không bao giờ đủ để hiểu rõ khách hàng. Ví dụ, Holistics vừa tung ra một tính năng mới nhưng không ai dùng cả. Nhìn vào data, ta chỉ biết là không ai dùng tính năng mới này nhưng không biết tại sao họ lại không dùng. PM buộc phải gặp trực tiếp khách hàng và nói chuyện với họ để tìm ra vấn đề. Từ đó, team hiểu ra rằng khách hàng không dùng vì họ không biết cách dùng, nên team đã đi đến từng công ty để hướng dẫn khách hàng cách dùng tính năng mới này.
Ta phải tận dụng mọi channel để thu thập feedback từ khách hàng. Nhưng hãy nhớ rằng: lắng nghe vấn đề của họ nhưng đừng hỏi họ cách giải quyết. Khách hàng có góc nhìn khác và thiếu kinh nghiệm về product nên những biện pháp họ đưa ra thường không giúp ta giải quyết vấn đề. Hãy chỉ lắng nghe vấn đề từ họ.
Don’t reinvent the wheel - đừng xây lại từ đầu khi nó đã có sẵn rồi. Hãy học từ đối thủ, từ cả những cái hay lẫn những cái dở của họ. Tuy nhiên cũng không nên quá lạm dụng điều này vì có nhiều thứ đối thủ làm không đúng hoặc không phù hợp với chiến lược công ty. Đừng theo chân họ mà phải suy nghĩ kỹ xem việc đó có thực sự tạo giá trị cho khách hàng của công ty và phù hợp với những nguyên tắc của công ty hay không.
Product của bạn mang lại những cảm xúc gì cho khách hàng khi họ sử dụng nó? Ví dụ, Holistics mang lại cảm giác được trao quyền cho người sử dụng. Bất kỳ ai cũng có thể tự phân tích data và ra quyết định. Hãy đề ra những nguyên tắc cụ thể và theo sát chúng để tránh sa vào trò chơi của đối thủ.
PM thường nhận request từ nhiều bộ phận khác nhau mỗi khi họ có ý tưởng cho một tính năng mới nào đó mà theo họ là thú vị, hữu ích. Tuy nhiên, PM phải tập cách nói Không hoặc ít nhất là phải giữ chữ Không đó thành câu trả lời mặc định trong đầu. Đừng nghĩ rằng đó chỉ là một tính năng nhỏ mà đồng ý ngay vì nó có thể kéo theo nhiều hệ lụy phức tạp sau này. Hãy luôn cân nhắc những câu hỏi như: Tại sao mình phải làm cái này? Nó có phù hợp với chiến lược công ty không? Nó có giúp ích gì cho user của mình không?... cho đến khi không còn lý do nào để từ chối được nữa.
Một ví dụ nhỏ để thấy một tính năng tưởng chừng đơn giản lại chẳng hề đơn giản tí nào: Holistics cân nhắc việc giới hạn số ký tự cho một product review ở 140 ký tự. Nghe thì có vẻ dễ dàng nhưng thật ra phải cân nhắc rất nhiều thứ, chẳng hạn như mình nên để word count ra sao, làm thế nào khi khách hàng vượt quá số ký tự cho phép, phải soạn văn bản như thế nào để thông báo cho khách hàng,...
Khách hàng không quan tâm đến những phần technical của sản phẩm, họ chỉ quan tâm đến việc sản phẩm đó giúp ích được gì cho họ. Thế nên, hãy nói thật dễ hiểu và đảm bảo khách hàng nhận ra giá trị của sản phẩm.
Ví dụ, khi tung ra 1 tính năng nào đó, bạn phải đưa được tính năng đó đến người dùng thông qua nhiều kênh (thông báo, in-app reminder, văn bản hướng dẫn, blog post,...) chứ không phải cứ tung ra rồi để đấy và họ sẽ tự dùng. Bạn phải liên tục nhắc nhở, hướng dẫn cho đến khi chắc rằng khách hàng đã hiểu và dùng tính năng mới rồi.
Bạn phải đặt ra những tiêu chí để đo lường thành công của sản phẩm. Tại sao khách hàng không dùng tính năng này? Tại sao conversion rate lại thấp như vậy? Nên có những tiêu chuẩn nhất định để bạn có thể đánh giá hiệu quả, tìm insight và học hỏi để tiến bộ hơn.
Nếu chỉ truyền đạt qua lời nói, mỗi người sẽ lý giải khác nhau. Thêm vào đó, PM là người kết nối giữa các team (marketing, dev,...) nên càng cần chú ý đến sự rõ ràng, nhất quán trong giao tiếp. Việc viết lại mọi thứ sẽ giúp bạn tiết kiệm thời gian, không cần nói lại từ đầu mỗi khi có người mới gia nhập cuộc hội thoại. Tất cả sẽ được minh bạch, rõ ràng và chắc chắn.
Một product doc thường có những phần sau:
Bản thân bạn cũng là một sản phẩm. Nếu bạn không thể quản lý bản thân cho tử tế thì bạn sẽ chẳng quản lý được cái gì cả.
PM là một generalist, tức PM phải biết nhiều skill (ví dụ như làm sao để giao tiếp với khách hàng, viết content, hiểu operation, hiểu tech,...). Thế nên, PM phải không ngừng học hỏi và bổ sung kiến thức mới cho mình.
Conclusion (ảnh slide)
Trong phần Q&A, anh cũng đã đưa ra nhiều quan điểm thú vị.
- - -
-
Software Engineer - Frontend - Backend - QA / QC
iOS - Android - DevOps - Project Management - Product Manager
-