Bạn viết rất chân thực và trần trụi về hầu như toàn bộ các công ty "product" ở Việt Nam. Cảm ơn bạn đã đưa ra một góc nhìn mà các công ty này đã né tránh không dám thừa nhận.
Cảm ơn bạn đã chia sẻ về một bài viết rất chất lượng và phân tích rất tốt về thực trạng của Product tại Việt Nam. Mình có một số quan điểm cá nhân, mong muốn mở rộng thêm cho bài viết này.
1. “It’s all about the users” → “It’s all about the business requirements”
- Việc ở VN các doanh nghiệp chạy theo dòng tiền, focus vào doanh thu là điều dễ hiểu, vì đơn giản các công ty phụ thuộc nhiều vào KPI, tăng trưởng doanh thu, gọi vốn. Nếu ở role lãnh đạo hoặc nhà đầu tư thì chắc chắn chúng ta sẽ hiểu điều này, cảm giác mỗi tháng trôi qua, nếu không bán được sản phẩm thì chi phí vơi đi liên tục, chi phí R&D, development tiếp tục tăng cao.
- Thật ra một phần văn hoá R&D chưa phổ biến ở VN, quy trình từ discovery đến development thường bị rút ngắn và bỏ qua. Tuy nhiên, nếu không R&D thì rõ ràng sẽ ảnh hưởng về lâu dài, product ko match với thị trường, product ko đủ chiều sâu, không giải quyết được vấn đề.
- Ngoài ra, Business Requirement thật ra nó không nên mâu thuẫn với User Need mà phải bổ trợ cho nhau, này phụ thuộc tư duy của công ty nữa, phải giải quyết được vấn đề người dùng bền vững thì mới đạt được mục tiêu kinh doanh.
- Cái này không chỉ VN mà ngay cả phương tây cũng vậy, mình work nhiều project với Châu Âu, Mỹ thì họ cũng thừa nhận cái này không hoàn hảo nhé, nó phải liên quan tới bối cảnh, chiến lược nữa.
- Politic driven nghe nặng nề nhưng mở rộng ra nó sẽ là vision driven => nếu có chiến lược giỏi thì vẫn sẽ có khả năng để bức phá được, còn data thì sẽ hạn chế tầm nhìn.
- Với lại mình nghĩ data không phải tệ như bạn nói, mình làm 1 project e-commerce, revenue hàng tháng > $500k, sử dụng data là một cái cực kỳ quan trọng với tụi mình, nó mang lại nhiều value và insight, cái quan trọng từ data đó, mình có process ra thành information rồi từ information có extract ra được insight hay không. Tụi mình đã từng có những case dùng data giải quyết được khá nhiều thứ cho client và mang lại giá trị cho user.
- Các team data của shopee, grab hay tiki vẫn rất xịn xò, xử lý và giải quyết rất nhiều vấn đề và từ đó giúp lãnh đạo make decision được.
3. “Fall in love with the problem” → “Fall in love with survival”
- Cái này thấy do văn hoá công ty đổ lỗi qua lại, chứ mình thấy cái này trách nhiệm của cả 2 chứ không phải của riêng một bên.
- Cái này có thể đưa ra công cụ đo lường được như funnel sales, user journey để xác định vấn đề cụ thể nằm ở đâu.
4. “Manage the product” → “Manage stakeholder’s expectation”
- Quan điểm này thì cốt lõi rồi, cuối cùng chúng ta làm product/ project thì phải hướng đến project success nên quan trọng nhất vẫn là stakeholder expectation. Cái này mình hoàn toàn đồng ý với quan điểm của bạn.
5. The “Agile” dilemma (Nan đề Agile)
- Chỗ này, thật ra Agile bạn đang hiểu theo tính lý thuyết, không có Agile nào quy định chúng ta thực hiện sprint trong 2 tuần cả (Thật ra nó là recommend trong Scrum framework), việc thời gian bao nhiêu thì do chúng ta cùng nhau thảo luận và quyết định, mục tiêu giới hạn time-boxed để dễ xác định các task hay user story cần xử lý, giúp dễ dàng breakdown, từ đó sớm review được product.
- Với lại, việc bạn nói không có time nghiên cứu thì trong Scrum có spike, có thể thay đổi cách làm việc lại, add thêm spikes vào để có time research cho feature mới, chứ giờ chưa research mà bay vô làm, xong cuối cùng ko đạt kết quả thì lại tốn thêm sprint sau hoặc lại đi giải quyết technical debt.
- Nếu mô hình Agile không đáp ứng được thì có thể chuyển sang Hybrid, kết hợp giữa Agile và Predictive, quan trọng xác định team nào cần làm gì.
Nhìn chung bài viết của bạn nói lên được khá nhiều vấn đề về lĩnh vực Product ở Việt Nam, tuy nhiên mình cảm thấy nó hơi có góc nhìn chủ quan và chưa đủ yếu tố khách quan. Với có lẽ power của team product bên bạn hơi ít nên nó cũng có thể dẫn đến nhiều vấn đề trên và không thể đưa ra quyết định được. Chủ đề này khá hay, sắp tới mình tính sẽ mời thêm các chuyên gia trong lĩnh vực PM/ PO để seminar và đưa ra góc nhìn đa chiều thử. Cảm ơn bạn rất nhiều!
Bổ sung thêm cho bạn thì thực ra những thực trạng này không chỉ diễn ra ở Việt Nam. Ngay cả PM Leader trên thế giới cũng đang phải suffer, bạn có thể xem thêm ở đây nhé: https://youtu.be/atS060bNpE0?si=jEakVPwytly6LvLq&t=336
Oki c, t cảm ơn nhé. Thra cty t hiện tại cũng giống bài viết, nên t cũng muốn tìm hiểu đây là tình trạng chung của thị trường hay một số loại hình cty nhất định (vd: cty nhỏ, cty start-up…)
Bạn viết rất chân thực và trần trụi về hầu như toàn bộ các công ty "product" ở Việt Nam. Cảm ơn bạn đã đưa ra một góc nhìn mà các công ty này đã né tránh không dám thừa nhận.
Anh Jason đang phản ánh chính xác thực trạng PO ở công ty em luôn ạ.
Mang mác là product nhưng em thấy giống project hơn, nhưng lúc tuyển vào lại yêu cầu mindset về product rất nhiều (?)
Thật sự là không biết nhiều khi công ty có đang cố gắng níu giữ cái gọi là product mindset - cái mà họ ko có không
Cảm ơn bạn đã chia sẻ về một bài viết rất chất lượng và phân tích rất tốt về thực trạng của Product tại Việt Nam. Mình có một số quan điểm cá nhân, mong muốn mở rộng thêm cho bài viết này.
1. “It’s all about the users” → “It’s all about the business requirements”
- Việc ở VN các doanh nghiệp chạy theo dòng tiền, focus vào doanh thu là điều dễ hiểu, vì đơn giản các công ty phụ thuộc nhiều vào KPI, tăng trưởng doanh thu, gọi vốn. Nếu ở role lãnh đạo hoặc nhà đầu tư thì chắc chắn chúng ta sẽ hiểu điều này, cảm giác mỗi tháng trôi qua, nếu không bán được sản phẩm thì chi phí vơi đi liên tục, chi phí R&D, development tiếp tục tăng cao.
- Thật ra một phần văn hoá R&D chưa phổ biến ở VN, quy trình từ discovery đến development thường bị rút ngắn và bỏ qua. Tuy nhiên, nếu không R&D thì rõ ràng sẽ ảnh hưởng về lâu dài, product ko match với thị trường, product ko đủ chiều sâu, không giải quyết được vấn đề.
- Ngoài ra, Business Requirement thật ra nó không nên mâu thuẫn với User Need mà phải bổ trợ cho nhau, này phụ thuộc tư duy của công ty nữa, phải giải quyết được vấn đề người dùng bền vững thì mới đạt được mục tiêu kinh doanh.
2. “Data-driven decision” → “Politic-driven decision”
- Cái này không chỉ VN mà ngay cả phương tây cũng vậy, mình work nhiều project với Châu Âu, Mỹ thì họ cũng thừa nhận cái này không hoàn hảo nhé, nó phải liên quan tới bối cảnh, chiến lược nữa.
- Politic driven nghe nặng nề nhưng mở rộng ra nó sẽ là vision driven => nếu có chiến lược giỏi thì vẫn sẽ có khả năng để bức phá được, còn data thì sẽ hạn chế tầm nhìn.
- Với lại mình nghĩ data không phải tệ như bạn nói, mình làm 1 project e-commerce, revenue hàng tháng > $500k, sử dụng data là một cái cực kỳ quan trọng với tụi mình, nó mang lại nhiều value và insight, cái quan trọng từ data đó, mình có process ra thành information rồi từ information có extract ra được insight hay không. Tụi mình đã từng có những case dùng data giải quyết được khá nhiều thứ cho client và mang lại giá trị cho user.
- Các team data của shopee, grab hay tiki vẫn rất xịn xò, xử lý và giải quyết rất nhiều vấn đề và từ đó giúp lãnh đạo make decision được.
3. “Fall in love with the problem” → “Fall in love with survival”
- Cái này thấy do văn hoá công ty đổ lỗi qua lại, chứ mình thấy cái này trách nhiệm của cả 2 chứ không phải của riêng một bên.
- Cái này có thể đưa ra công cụ đo lường được như funnel sales, user journey để xác định vấn đề cụ thể nằm ở đâu.
4. “Manage the product” → “Manage stakeholder’s expectation”
- Quan điểm này thì cốt lõi rồi, cuối cùng chúng ta làm product/ project thì phải hướng đến project success nên quan trọng nhất vẫn là stakeholder expectation. Cái này mình hoàn toàn đồng ý với quan điểm của bạn.
5. The “Agile” dilemma (Nan đề Agile)
- Chỗ này, thật ra Agile bạn đang hiểu theo tính lý thuyết, không có Agile nào quy định chúng ta thực hiện sprint trong 2 tuần cả (Thật ra nó là recommend trong Scrum framework), việc thời gian bao nhiêu thì do chúng ta cùng nhau thảo luận và quyết định, mục tiêu giới hạn time-boxed để dễ xác định các task hay user story cần xử lý, giúp dễ dàng breakdown, từ đó sớm review được product.
- Với lại, việc bạn nói không có time nghiên cứu thì trong Scrum có spike, có thể thay đổi cách làm việc lại, add thêm spikes vào để có time research cho feature mới, chứ giờ chưa research mà bay vô làm, xong cuối cùng ko đạt kết quả thì lại tốn thêm sprint sau hoặc lại đi giải quyết technical debt.
- Nếu mô hình Agile không đáp ứng được thì có thể chuyển sang Hybrid, kết hợp giữa Agile và Predictive, quan trọng xác định team nào cần làm gì.
Nhìn chung bài viết của bạn nói lên được khá nhiều vấn đề về lĩnh vực Product ở Việt Nam, tuy nhiên mình cảm thấy nó hơi có góc nhìn chủ quan và chưa đủ yếu tố khách quan. Với có lẽ power của team product bên bạn hơi ít nên nó cũng có thể dẫn đến nhiều vấn đề trên và không thể đưa ra quyết định được. Chủ đề này khá hay, sắp tới mình tính sẽ mời thêm các chuyên gia trong lĩnh vực PM/ PO để seminar và đưa ra góc nhìn đa chiều thử. Cảm ơn bạn rất nhiều!
Hoan hô Jason!!! Bài viết anh nghĩ nêu ra được nhiều vấn đề phổ biến mà nhiều Po, PM đang phải chịu đựng.
Nghề chưa kịp phát triển mà AI đang đòi thay thế + các tổ chức đòi cắt sẽ muốn cắt PO 😂😭
Không biết là cắt PO hay là cắt một cái máy vẽ wireframe và thay bằng cái máy khác. Chứ e ko nghĩ họ define được chính xác PO làm gì đâu :D
bài viết hot quá nên xin phép seed thêm bài này có cùng chủ đề với Jason
https://open.substack.com/pub/the1ight/p/product-101-1-nhung-suy-nghi-ve-nganh?r=2f46k&utm_medium=ios
bài viết hay và thực tế quá
Cảm ơn bài viết của b. Tuy nhiên mình muốn hỏi nguồn thông tin để đưa ra những nhận định trong bài viết đến từ những đâu nhỉ?
Bổ sung thêm cho bạn thì thực ra những thực trạng này không chỉ diễn ra ở Việt Nam. Ngay cả PM Leader trên thế giới cũng đang phải suffer, bạn có thể xem thêm ở đây nhé: https://youtu.be/atS060bNpE0?si=jEakVPwytly6LvLq&t=336
Oki c, t cảm ơn nhé. Thra cty t hiện tại cũng giống bài viết, nên t cũng muốn tìm hiểu đây là tình trạng chung của thị trường hay một số loại hình cty nhất định (vd: cty nhỏ, cty start-up…)
Cảm ơn bạn vì đã đọc. Nguồn thông tin như mình đã giải thích xuyên suốt bài viết, nó đến từ chính trải nghiệm của mình