Chuyện nghề 2.2: Đưa ra giải pháp khi chưa xác định được bài toán là một sai lầm

Careerly (C): Cũng như anh chia sẻ, Product Manager (PM) là một công việc linh hoạt và đa dạng đòi hỏi phải giao tiếp với nhiều team khác trong công ty như bên dev hay design. Anh cảm thấy PM nói riêng và team Product nói chung thường gặp những vấn đề gì về giao tiếp?

Phan Nguyên Lập (LP): Cái khó nhất anh thấy các bạn hay gặp phải là chưa xác định được bài toán, khó khăn của người dùng mà đã đưa ra giải pháp trước luôn. Đây cũng là một trong những sai lầm của anh ngày xưa khi anh còn hơi non. Vậy nên mới có chuyện là các bạn designer thì sẽ nghĩ một kiểu, còn các bạn engineer lại có cách suy nghĩ khác. Designer muốn nó phải đẹp, phải hợp lý, phải tiện lợi cho người dùng, còn engineer lại muốn làm vừa đủ đơn giản trước cái đã, giải quyết được vấn đề thôi. Đó mới là 2 phía thôi. Ở ngoài có thêm bên business nhảy vào thì lại là một câu chuyện khác nữa. Các bạn business cũng có những áp lực riêng, có thể là từ sếp ở trên, có thể là từ khách hàng. Khi đó thì họ lại muốn phải chạy như vậy, phải có cái này cái kia. 

Việc làm sao cho các bạn đó phải hiểu nhau là một trong những cái khó khăn của PM. Cách anh giải quyết vấn đề giữa design và engineer là anh sẽ chọn phương án nào đơn giản nhất, mà đồng thời vẫn giữ được cái design hợp lý, tiện lợi với người dùng. Câu chuyện vẫn là người dùng thôi. Khi đưa người dùng vào thì các bạn không dựa vào giải pháp của cá nhân nữa mà là cho một cái gì đó cụ thể. Cái này thì lại đòi hỏi PM phải truyền đạt được đến team user thực sự muốn gì, cần gì, như anh có đề cập trước. Sau này thì anh còn dẫn mấy bạn design, mấy bạn engineer đi theo trao đổi với người dùng vì họ vẫn có tiếng nói hơn. Khi gặp người dùng thì các bạn này cũng không cần nói chuyện, để anh hoặc mấy bạn research nói chuyện cũng được. Ngồi đó nghe và hiểu khó khăn để có thể ứng dụng vào sản phẩm. . 

Sau khi hiểu được người dùng để có thể bớt tập trung vào ý kiến riêng một tí thì câu chuyện tiếp theo sẽ là cái tài chính, tài nguyên và deadline mình có. Dựa vào ba yếu tố đó, ba phía mới cùng ngồi xuống tranh luận với nhau rồi chốt lại build làm sao vừa phải, hình thức ok. Cái đó xong trước thì mới bắt đầu tập trung vào build. Cách anh làm là như vậy.

C: Anh cũng chia sẻ rằng người dùng là một trong những yếu tố rất quan trọng trong product. Anh có thể chia sẻ một số kinh nghiệm thực tế của anh về việc nghiên cứu và thấu hiểu người dùng không? 

LP: Anh nghĩ công việc ở Grab và ZoopCare giúp anh học hỏi về nghiên cứu người dùng rất nhiều. 

Grab có nền móng vững và đầu tư rất tốt về product. Hồi đó, anh có tham gia tổ chức một chương trình cho các bạn PM từ các nước khác sang immersion. Một chuyến immersion trip có nghĩa là mình sẽ đi theo người dùng trong một ngày để xem cách họ làm việc, cách họ sử dụng sản phẩm của mình như nào. Ở đây là các bạn đi theo, ngồi sau các chú tài xế để phỏng vấn trực tiếp tài xế cũng như các nhà hàng. Khi đó thì anh cũng không hỏi nhiều, chủ yếu là các bạn PM người nước ngoài hỏi và anh sẽ dịch lại, nhưng anh cũng có cơ hội được lắng nghe vấn đề của các anh chị tài xế là gì, các điểm thích hay không thích trong sản phẩm của mình, đồng thời nghe cách mà các bạn PM nước ngoài đặt câu hỏi. Đây là một trong những cách giúp mình hiểu thêm được nhiều hơn về user của mình, vì mình tận mắt chứng kiến họ làm việc như thế nào.

Để “thấm” hơn thì sau một ngày đi theo người dùng, chiều về văn phòng các bạn có thể recap lại ngay những gì đã học được trong ngày, rồi brainstorm để ra ý tưởng liền. Một điều khác cần lưu ý là sắp xếp thứ tự quan trọng các vấn đề của người dùng và chọn ra vấn đề nào nên giải quyết trước.

Một câu chuyện nữa là Grab có một chức năng là gọi đặt xe miễn phí qua internet, có bảo mật số điện thoại và tên. Tuy nhiên, chất lượng của nó chưa tốt, tài xế không dùng nhiều, nên anh mới được giao nhiệm cải thiện tính ổn định và mở rộng phạm vi trên cả nước. Thế là anh nhờ team training cho các tài xế liên hệ và mời một số tài xế thường xuyên sử dụng chức năng này đến phỏng vấn cùng với bạn PM và engineer phụ trách build chính để tìm hiểu xem tại sao các anh lại thích sử dụng nó và vấn đề các anh gặp phải, vì người dùng nhiều thì cũng sẽ biết rõ vấn đề của nó. Sau đó, bọn anh gom thông số lại, đi test và chốt giải pháp. Kết luận thứ nhất là về mặt backend của dịch vụ, có những điểm mà các bạn engineer sẽ cần phải nâng cấp, fix bug để cải thiện chất lượng. Kết luận thứ hai là có một vấn đề phải nhờ đến team marketing hoặc team operation. Chất lượng gọi qua internet bằng app phụ thuộc vào chất lượng gói cước data, gói data rẻ thì chất lượng cuộc gọi bằng internet tất nhiên sẽ giảm. Anh mới phải nói chuyện với bên Marketing và Operation để xem xét chạy một chương trình hỗ trợ cho tài xế mua được gói cước tốt hơn để họ có trải nghiệm sử dụng tính năng này tốt hơn. Sau khi các giải pháp được duyệt chạy hết Việt Nam, tụi anh có chạy thêm một vòng survey nữa qua app với các anh tài xế thì chất lượng (tính ổn định, đánh giá trải nghiệm) cũng như tần suất sử dụng cải thiện khoảng từ 10-15%. Độ phủ của VN từ đó lên thứ 2, lúc anh rời khỏi Grab vẫn đứng thứ 2 thua Myanmar, lúc trước thì VN chỉ đứng khoảng thứ 6 thứ 7 thôi.

Còn ở bên ZoopCare thì đơn giản hơn, vì ZoopCare làm về chăm sóc sức khỏe cho nên anh đi phỏng vấn từng người. Ngoài phỏng vấn user bên ngoài, anh phỏng vấn cả nội bộ vì chăm sóc sức khỏe thì ai cũng có thể dùng được. Tóm lại thì anh nghĩ cách nhanh và rẻ nhất là đi phỏng vấn, mình có thể lập 1 group để test demo với họ, và nếu có cơ hội nữa thì nên trực tiếp tiếp cận tại nơi làm việc, sử dụng sản phẩm của người dùng theo dõi quan sát họ.

C: Vậy với kinh nghiệm làm qua nhiều công ty từ Unicorn như Grab hay đến những startup nhỏ hơn như là ZoopCare, anh thấy môi trường của hai công ty này có điểm gì khác biệt không?

LP: Có thể nói sự khác nhau giữa một startup thực sự (một công ty vừa mới khởi nghiệp) và một startup đã đạt mức tăng trưởng rất nhanh như Grab là quy trình và cấu trúc của các team trong đó. Theo anh thì điều anh thích về Grab là mỗi team đều có công việc riêng và họ biết nhiệm vụ của mình là gì, họ biết scope (phạm vi công việc) của họ là tới mức nào, mặc dù tinh thần của họ vẫn là tinh thần startup sẵn sàng chạy, test sản phẩm mới, fail thì thử qua cái mới liền. Về quy trình và cấu trúc team thì họ rất rõ ràng và nguyên tắc.

Còn các công ty mới startup như ZoopCare thì không cần cấu trúc quá rõ ràng, không cần phải qua sếp này sếp nọ, cần cái gì là làm việc thẳng với Founder, CEO luôn. Đó là sự khác biệt, có thể làm việc skip level, mọi người flat (ngang bằng) với nhau. Còn về quy trình thì startup không cần nhiều quy trình, linh động làm nhiều thứ, và không phải mình chỉ làm trong scope của mình, giới hạn trong nhiệm vụ của mình. Ví dụ như hồi anh làm ở ZoopCare và cả công ty bây giờ cũng vậy, dù nói là làm PM nhưng thực sự là có cái gì cần làm tốt hơn, cái gì có thể hỗ trợ được team là nhảy vào làm, miễn nói trước với sếp một câu là để em làm cái này cái. Khác nhau là ở chỗ đó, quy trình và cấu trúc của team.

C: Anh cảm thấy điều gì về Product đã khiến anh đam mê và gắn bó với công việc này?

LP: Anh nghĩ cái này thứ nhất, với cá nhân anh thì hồi trước có một thời gian anh không biết mình thích, mình giỏi cái gì, tới lúc mà khám phá được cái vị trí product này thì khá là hợp với hướng đi career của anh vì cái gì cũng đụng vô, ở giữa nên cái gì cũng vô làm. Cái thứ hai là tính anh cũng thích giúp người khác, thích làm cho người khác vui, nên làm product khá là hợp. Khi mình deliver sản phẩm mình làm cùng team cho người dùng và mang lại giá trị cho họ thì cũng có niềm tự hào trong đó. Nói chung đó là những giá trị khiến anh yêu thích công việc này.

C: Cảm ơn anh vì đã đồng ý tham gia buổi phỏng vấn hôm nay và những chia sẻ vô cùng giá trị của anh. Careerly xin chúc anh nhiều sức khỏe và thành công.

Bạn hỏi PM trả lời: Q&A cùng độc giả bản tin

Phần này gồm những câu trả lời từ anh Phan Nguyên Lập cho một số câu hỏi do độc giả của bản tin gửi đến. Để có cơ hội tham gia đặt câu hỏi cho các khách mời trong tương lai, hãy đăng ký nhận bản tin Product Management đầu tiên tại Việt Nam từ Careerly tại: http://try.careerly.vn/it-people/

Q: Anh nghĩ nên chọn công ty quy mô thế nào để bắt đầu làm việc trong ngành này ạ? VD: startup, agency, product, công ty local, công ty global.. Cảm ơn anh đã dành thời gian ạ.

A: Thật sự không có câu trả lời nào chính xác nhất, vì có rất nhiều yếu tố ảnh hưởng việc mình bắt đầu vai trò Product Manager ở công ty như thế nào. Anh có thể chia sẻ kinh nghiệm của anh. Với anh thì các bạn nên bắt đầu thử sức bằng cách làm việc ở công ty global với product và business đang ổn định và đang tiếp tục phát triển. Lý do là vì mình có thể học được cách suy nghĩ và làm việc từ nhiều văn hóa khác nhau ở công ty global, học được quy trình và tổ chức của sản phẩm đã có người dùng và market fit, học được cách tiếp cận và tìm hiểu users. Các kiến thức và kỹ năng này sẽ giúp trau dồi kỹ năng và kinh nghiệm phát triển định hướng sản phẩm. Từ đó các bạn có thể bước đến giai đoạn kế tiếp là đảm nhận vai trò PM ở công ty startup. Startup lợi thế nhất là bắt đầu với blank canvas, vì vậy chúng ta có thể áp dụng được những gì đã học trong thực tế để tiếp tục cải thiện. Câu trả lời của anh chỉ là một nguồn thông tin để các bạn tham khảo thêm, chính các bạn là người quyết định sẽ học gì và áp dụng gì để phát triển sự nghiệp PM của mình.

Q: Anh có thể chia sẻ thêm về quy trình để tạo nên một sản phẩm công nghệ không ạ?

A: Quy trình tạo nên một sản phẩm công nghệ có thể tùy thuộc vào loại hình sản phẩm và độ phức tạp, nhưng anh có thể tóm tắt điểm chung theo kinh nghiệm của bản thân như sau:

1. Market research for product and business opportunities
2. User research to explore user problems, pain points, or needs to match with hypothesized business and product opportunities
3. Identify possible solutions and build minimal prototype to test product acceptance and market fit
4. Repeat step 3 within reasonable timeline to get the most sticky solutions
5. Build up product increments and release for continuous feedback
6. Analyze data and real user feedback to decide on next phase for that product

Q: Em nghĩ PM thì cũng cần biết code một tí, theo anh thì mình nên biết code đến chừng nào là đủ ạ?
A: Vì background của anh đã không xuất phát từ công nghệ 100% nên câu trả lời của anh sẽ là tùy vào trường hợp. Với các sản phẩm nặng về tính công nghệ và có đối tượng người dùng là kỹ sư, lập trình viên thì đòi hỏi PM phải có kiến thức và kinh nghiệm về code, để hiểu được nhu cầu của người dùng.

Nói chung thì anh thấy PM vẫn cần kiến thức về công nghệ, ít nhất để hiểu được sản phẩm hoạt động như thế nào từ phía hệ thống và để giao tiếp khi làm việc với đội ngũ kĩ thuật, đặc biệt là khi các bạn đưa ra giải pháp để lựa chọn. Khi hiểu được ở mức cần thiết về công nghệ, PM sẽ phân tích nhanh được liệu các giải pháp đó có tương thích với mục tiêu của sản phẩm cho người dùng hay không.

Về kỹ năng công nghệ thì anh nghĩ PM có thể học SQL để tự chiết xuất dữ liệu cần phân tích. Thêm vào đó là kỹ năng tạo custom report trên các tools thông dụng như Excel, Google Sheet, và các analytics tools.

Q: Theo em được biết thì PM khi đưa ra quyết định thì cần dữ liệu khá nhiều, anh có thể chia sẻ các công cụ và phương pháp nào để đo lường và sử dụng dữ liệu không?

A: Theo kinh nghiệm đến giờ của anh thì việc PM đúng là cần data, và data sẽ phục vụ chính cho việc tăng độ tự tin với giả thuyết của mình để từ đó đưa ra quyết định. Ngoài data thì PM cần thêm cảm tính, kinh nghiệm và niềm tin về hướng đi của sản phẩm nữa.

Một số công cụ mà PM có thể sử dụng cho data analysis và insights là:

• Report từ product analytics tools (Google Analytics, Amplitude, Mixpanel, etc.)
• Kết quả survey khi nói chuyện với users và các review online nếu đó là mobile app. Các bạn chỉ cần tổng hợp thành một file spreadsheet để phân tích số liệu.
• Nhận xét (feedback) từ các team về sản phẩm (Customer Supoprt, Operations, Marketing, etc.). Có thể là 1 file đơn giản spreadsheet với các feedback đã được tổng hợp thành các hạng mục (categories)

Về phương pháp thì có thể nói chung như sau:

• Xác nhận các câu hỏi mình sẽ cần trả lời để biết được chất lượng sản phẩm thế nào
• Từ đó sử dụng các metrics frameworks để xác định chính xác metrics nào mình cần để trả lời câu hỏi đó
• Khi đã có danh sách các metrics cần đo lương thì làm việc chặt chẽ với đội ngũ kĩ sư (dev/engineers) và product/data analyst để biết được sẽ track các sự kiện hoặc tương tác (events) gì trong sản phẩm để tính toán được các metrics đó
• Sau khi có được danh sách events để track thì đội ngũ kĩ thuật sẽ gán vào sản phẩm và sẵn sàng cho user
• Đến khi có data thì sẽ có vài cách phân tích thông dụng như sau là funnel analysis, behavior analysis, event analysis, và cohort analysis

Q: Anh có khuyên là nên trau dồi một trong ba mảng là tư duy logic, công nghệ và sáng tạo. Anh có thể chia sẻ thêm một số bí quyết để trau dồi mảng sáng tạo không ạ? Vì em thấy sáng tạo kiểu thiên về bẩm sinh hơn.

A: Anh đồng ý là có năng khiếu về sáng tạo sẽ rất hữu ích, nhưng anh cũng đồng ý với câu nói của Natasha Tsakos “Creativty is not a gift, it’s a mindset that you practice.” Vì vậy, việc trau dồi là quan trọng nhất để tiếp tục phát triển creative mindset.

Một số cách có thể giúp mọi người practice creative mindset:

• Lắng nghe, nhận xét và đánh giá những ý kiến khác với cách suy nghĩ của mình. Hạn chế việc từ chối ngay lập tức, mà hãy dừng lại và suy nghĩ để hiểu được vì sao người đó lại có ý kiến đó.
• Đọc và học hỏi về những thứ mà mình chưa làm bao giờ. Ví dụ những bài viết hay sách về các chủ đề hoàn mới với mọi người. Từ đó, suy nghĩ thêm và liên hệ những kiến thức mới học với kiến thức hiện có.
• Dành ít thời gian trong ngày để làm việc sáng tạo, ví dụ như doodle, sketching, mindmapping. Ngoài ra các bạn có thể tập viết xuống các ý tưởng hoặc suy nghĩ trong đầu để rèn luyện thêm khả năng viết. Mỗi người sẽ có một khoảng thời gian tối ưu trong ngày khi đầu óc thoải mái và hoạt động tốt nhất, các bạn nên xác định được khung thời gian này để làm những việc mình muốn cải thiện như công việc sáng tạo.
• Kiên trì rèn luyện để việc sáng tạo trở thành thói quen. Khi đã có thói quen sáng tạo thì lối nghĩ của các bạn cũng trở nên sáng tạo.

Q: Đọc chia sẻ về 1 ngày của anh thì em thấy công việc PM khá nhiều task, anh có thể cho em vài bí kíp để quản lý thời gian tốt không?

A: Một PM sẽ có nhiều tasks khác nhau trong ngày. Kinh nghiệm của bản thân anh đến lúc này:

• Chia tasks ra làm 2 loại chính: deep work và routine work
• Kiểm tra trước cả tuần sẽ có các cuộc họp gì và những task gì cần phải làm xong vào thời điểm nào trong tuần. Đó là deep work tasks
• Bắt đầu mỗi ngày thì xác định rõ trong ngày sẽ làm xong ít nhất 1 task quan trọng nhất. Đây là task nếu không làm xong sẽ có ảnh hưởng đến các ngày hôm sau
• Phần thời gian còn lại trong ngày có thể để dành làm routine work. Đây là các task có thể để qua ngày hôm sau làm tiếp
• Nói “Không” khi có thể với các task không liên quan nhiều đến mục tiêu của ngày và của tuần. Các bạn có thể nghiên cứu thêm về “task prioritization frameworks” để biết thêm các lựa chọn nào phù hợp nhất với bản thân để sử dụng

Q: Theo anh thì một product tốt với anh là như thế nào?

A: Đối với anh thì một product tốt sẽ giúp anh giải quyết những nhu cầu hay vấn đề mà anh đang có. Và tốt hơn nữa là anh chưa nghĩ đến sẽ có. Quan trọng nhất là product đó sẽ trở thành 1 phần trong cuộc sống của anh khi nhu cầu đó xuất hiện, product đó sẽ là thứ đầu tiên anh nghĩ đến.

Anh có 2 ví dụ điển hình nhất: Grab và SimpleNote. Grab anh sử dụng mỗi khi cần đặt xe, đặt đồ và gửi đồ – đây là những nhu cầu cần thiết trong cuộc sống của anh. SimpleNote khi anh cần lưu lại những ghi chú quan trọng. Anh dùng nhiều note apps khác nhau nhưng SimpleNote luôn được anh dùng vì đáp ứng được nhu cầu: ghi chú nhanh, UI đơn giản và tính bảo mật cao.

Q: Anh đang dùng những công cụ, phương pháp nào để track performance của một product?

A: Về công cụ thì anh có thể giới thiệu Google Analytics là tool là tool miễn phí để dùng. Khi số lượng users của sản phẩm đã tăng lên nhiều (có thể dựa vào Daily Active User và Monthly Active User để quyết định) thì có thể chuyển sang các tool khá nổi tiếng trên thị trường như Mixpanel, Amplitude, etc.

Theo anh thì để chọn được tool, có một số yếu tố sau cần cân nhắc kỹ:

• Budget: How much are we willing to pay vs build our own?
• Data ownership: How much does the provider own the user data?
• Security: How does the provider ensure security of their tools?
• Technical implementation: How easy it is for dev team to set the tool up for use?
• Customizatiom: How much does the tool allow self-serve data query or custom report building and other options?

Về phương pháp thì có 2 product metric frameworks có thể sử dụng. Lưu ý rằng các metrics ở đây thực sự có thể hiểu như theme để chung ta định nghĩa được metrics cần thiết trong sản phẩm để có câu trả lời cho các themes đó:

HEART framework by Google

• Happiness
• Engagement
• Adoption
• Retention
• Task success

Pirate framework i.e. AARRR

• Acquisition
• Activaiton
• Retention
• Revenue
• Referral

Q: Em muốn hỏi thêm về process và best practice của interview user ạ.

A: Anh sử dụng 2 frameworks để interview users. Cái đầu tiên thì thông dụng hơn và cái thứ hai thì advanced hơn: Problem and Solution interview, và Jobs to be done interview

Về best practices thì anh có thể chia sẻ vài điểm dựa trên kinh nghiệm bản than:

• Xác định được đối tượng user mình sẽ interview là ai. Các thông tin cơ bản về họ như độ tuổi, giới tính, nghề nghiệp, sở thích, etc… Việc này sẽ tang độ chính xác của nhóm users mà mình tìm được để phỏng vấn.
• Soạn câu hỏi theo chủ đề mà mình muốn hỏi users. Không nên sử dụng nhiều thể loại câu hỏi Yes/No mà nên hỏi câu hỏi mở (open questions) để khuyến khích users chia sẻ thêm chi tiết.
• Nghĩ về kịch bản và hướng đi của các câu hỏi cho users để từ đó họ chia sẻ thêm thông tin. Không nhất thiết phải hỏi cho đủ số lượng câu hỏi, bởi vì thông tin chia sẻ của users khả năng cao là sẽ giúp chung ta trả lời các câu hỏi khác
• Nên có 2 người khi interview: 1 người hỏi và 1 người take notes. Nếu được thì xin sự đồng ý để ghi âm.
• Lắng nghe nhiều hơn là hỏi. Khi đến thời điểm user đã chia sẻ hết thì có thể hỏi câu kế tiếp. Câu kế tiếp phụ thuộc vào câu trả lời trước đó sẽ thuộc về topic gì và theme gì.
• Sẵn sàng dẫn dắt users vào đúng theme và topic trong buổi interview. Nhất là khi users đi rời khỏi các chủ đề cần tìm hiểu. Với anh thì anh sẽ nhắc lại chủ đề anh cần hỏi và đặt ra câu hỏi đó lại để user trả lời. Việc quan trọng là không nên cắt ngang user giữa chừng mà đợi khi họ vừa hết ý để giữ flow của buổi interview.