4 điều mình nhận ra về ngành Product sau khi bị layoff

Hỉ nộ ái ố, đủ các cung bậc cảm xúc và những insight đắng ngắt khiến mình buộc phải nuốt

“Lay off” đang là một tình trạng chung trong ngành Tech thế giới nói chung và ở Việt Nam nói riêng. Và mình cũng không hề là ngoại lệ, thời điểm nhận được quyết định chấm dứt hợp đồng chính là lúc mình bị hẫng đi một chút.

“Mình chưa đủ tốt sao? Còn điều gì mình chưa làm nhỉ?'“ và hàng loạt những hoài nghi về bản thân xuất hiện trong đầu mình suốt thời gian đó. Ngay lúc này đây khi viết những dòng này, mình đã không còn cảm thấy như vậy nữa. Vì sẽ có những lúc việc bị lay off chẳng hề liên quan gì tới năng lực của bạn cả. Và đây sẽ là 4 điều mà mình đã nghiệm ra sau quá trình làm Product tới giờ ở 1 số các công ty tự nhận là làm Product bài bản ở Việt Nam.

Let’s go!

1. It’s all about the users → It’s all about the business requirements

Với các Product Manager (PM) hay Product Owner (PO), mình tin chắc rằng các bạn đều được học hoặc đã từng nghe về việc cần phải “fall in love” hay nôm na là ăn ngủ với vấn đề của khách hàng, đào sâu và nghiên cứu thật kĩ về những nỗi đau của khách hàng. Từ đó, team sản phẩm có thể tạo ra được những tính năng thật sự giải quyết được đúng nhu cầu của khách hàng.

Nghe thật tuyệt phải không? Nhưng đây sẽ là sự thật nhé:

• Áp lực từ phía BOD với việc FOMO (sợ bị bỏ lỡ) từ thị trường

• Áp lực từ phía Sale với những phàn nàn từ khách hàng

• Mục tiêu của quý đã cam kết về việc delivery tính năng

• Các chỉ số tăng trưởng của business cần phải quan tâm

• Các chỉ số đã cam kết với các đối tác

Và sẽ chẳng còn thời gian để chúng ta, những PM/PO có thể đào sâu và research được về user hay validate được những vấn đề thực sự đáng để giải quyết. Tất cả sẽ đều xoay quanh vấn đề của business thay vì vấn đề của user. Hệ quả sẽ là việc chúng ta tập trung vào giải quyết các requirements (yêu cầu) từ phía business stakeholder. Hoặc nói ngắn gọn là gần như không có giai đoạn nghiên cứu, chỉ có sản xuất giống như 1 công xưởng. Và sản xuất thì tất nhiên chỉ cần đúng thời gian và đúng budget (hoặc thấp hơn thì càng tốt) là được phải không nào.

Còn nếu vẫn muốn làm đúng và đủ như 1 PM/PO thực thụ ư, bạn sẽ khó có thể tồn tại được. Thành thực mà nói thì với thời điểm này, ai cũng muốn giữ được công việc của mình mà thôi.

2. Data driven decision → Politic driven decision

Gần như mọi công ty product hiện tại đều nói về việc phải ra quyết định dựa trên dữ liệu. Cụm từ “Data-driven mindset” là hot keyword mà bất kì JD tuyển dụng nào cũng có thể thấy, từ Marketing cho đến Product,…

Công cụ để đo lường về Product metrics trên thế giới thì cũng rất đa dạng, từ phổ biến và miễn phí như Google analytics (GA4), Clarity hoặc Firebase cho đến trả phí như Mixpanel, Amplitude, Hotjar, Userpilot… Data-driven mindset ở đây có thể hiểu là dựa trên việc chúng ta theo dõi các chỉ số, sau đó tìm ra những điểm bất thường → đưa ra các giả thiết và action để testing và cải thiện. Từ đó chúng ta sẽ tiếp tục cải tiến dựa trên những số liệu được theo dõi đó.

Tuyệt vời chứ, nghe rất đúng lý thuyết mà mình được học phải không? Sự thật ở đây đó là:

Data ở đây chỉ dùng để mang tính chất tham khảo (inform), còn việc ra quyết định phần lớn vẫn sẽ là trò chơi chính trị. Nơi những người có tầm ảnh hưởng lớn (CEO hoặc BOD) sẽ được quyền quyết định hoặc phủ quyết

Quyền quyết định chưa bao giờ nằm trong tay chúng ta, những PM/PO mà phần lớn sẽ nằm ở các business stakeholder. Chúng ta chỉ validate cách thức làm (How), còn việc tại sao làm và làm cái gì (Why, What) gần như rất hiếm khi do team Product được phép quyết định.

Sẽ chẳng có ai biết đến hay nói đến:

• Những Roadmap được làm lại ngay khi đã chốt chỉ sau cuộc meeting với BOD.

• Những feature phải làm ngày đêm để kịp release bất kể vẫn còn bug chỉ bởi Investor demo day đang cận kề

• Những complain không hồi kết từ phía đội Sale và customer với độ ưu tiên lúc nào cũng ở trạng thái ASAP

Dường như Data ở đây chỉ là để validate cho những ý kiến đã được đưa ra chứ không phải là để tìm kiếm những ý tưởng mới.

Vậy đó, Data-driven decision - quyết định dựa trên dữ liệu là một thứ mà đến giờ mình vẫn chưa thấy ở đâu làm đúng được như vậy cả (và hi vọng công ty tiếp theo của mình sẽ khác).

3. Fall in love with the problem → Fall in love with survival

“Team Product sẽ luôn phải follow Business vì nếu Business không tốt, không bán được sản phẩm thì Product sinh ra để làm gì?” - CPO/line-manager cũ của mình

Cũng có lý nhỉ, vì đúng là nếu như Business không tốt, không bán được sản phẩm thì Product có phát triển cũng đâu có nghĩa lý gì. Nhưng đấy là một sự đánh tráo khái niệm rất rõ ràng. Để mình làm rõ lại mệnh đề trên nhé:

Sale thất bại trong việc tư vấn giải pháp dành cho khách hàng nhằm giải quyết vấn đề của họ => Vấn đề nằm ở team Product?

Đồng thời, theo ý của sếp mình, việc Product phải follow business sẽ giống như việc team Product khoán hoàn toàn việc:

• Giải quyết vấn đề nào?

• Vấn đề đó có đem lại được giá trị cho business không?

• Xây dựng giải pháp nào đó để giải quyết vấn đề đó?

Về mặt cơ bản, team Product quẳng hoàn toàn chiếc vô-lăng trong việc xây dựng sản phẩm/tính năng nhằm đem lại giá trị cho người dùng cho phía Business. Và việc “fall in love” với vấn đề có vẻ như chỉ tồn tại trong lý thuyết, tất cả những gì team sản phẩm và những PM/PO đáng thương tập trung làm đó là cố gắng sống sót và làm hài lòng những bộ phận có tiếng nói bên mảng Business.

Ghi nhận những complain từ phía các team Sale và Marketing, những cuộc meeting kéo dài và gần như kín tuần chỉ để thảo luận về những vấn đề mà mình không hề được cân nhắc ý kiến đóng góp. Đó chính là vòng lặp không hồi kết mà các PM/PO như chúng ta đều không hề lường trước và phải chịu đựng nó hàng ngày.

4. Manage the product → Manage stakeholder’s expectation

Dù với danh nghĩa là một Product manager hay Product owner, công việc của chúng ta chưa bao giờ là quản lí sản phẩm. Không chỉ đơn thuần là gặp gỡ khách hàng, tham khảo ý kiến từ các phòng ban liên quan, chuẩn bị kế hoạch cho Sprint cũng như chi tiết Backlog. Một thứ rất quan trọng mà không hề có một trường lớp hay khoá học nào dạy đó chính là: Kiểm soát kỳ vọng của các Stakeholder.

• Một tính năng bị khách hàng phàn nàn và Sale luôn kì vọng sẽ fix ngay lập tức

• Một phiên bản Mobile app đáng ra cần chuẩn bị 6 tháng nhưng “cái này đơn giản mà, làm trong 2 tháng đi em” từ phía CEO

• Một chương trình reward loyalty mất tới 4 sprint để hoàn thành nhưng cuối cùng không dùng đến vì Marketing team cho rằng không đủ hấp dẫn

Và còn rất nhiều những trường hợp trời ơi đất hỡi nữa xảy ra xoay quanh việc chúng ta chỉ tập trung cho việc delivery sản phẩm mà không hề kiểm soát được kì vọng của các Stakeholder liên quan. Và kĩ năng này khó ở chỗ nó không hề có một framework hay tips trick nào để có thể áp dụng cả. Trải qua → rút kinh nghiệm và tiếp tục cải thiện dần là cách mình đã và đang vượt qua những vấn đề này.

Với các PM đang mới chuyển ngành hoặc vào nghề. Công việc quản trị sản phẩm này sẽ là:

• 20% vấn đề của người dùng

• 30% vấn đề chính trị nội bộ (internal politic)

• 50% quản lý kỳ vọng của các Stakeholder

Vậy nguyên nhân do đâu?

Để nói về thực trạng này nguyên nhân từ đâu thì mình chắc chắc không đủ kiến thức cũng như kinh nghiệm để có thể đánh giá. Nhưng với quan điểm của mình, hiện tại sẽ có một số những tác nhân như sau:

The two-hat syndrome (kiêm nhiệm nhiều vị trí)

Các anh em PM/PO mà mình quen biết thường phải đối mặt với một tình trạng chung đó là:

• Thường xuyên phải đảm nhiệm vai trò của một UX designer (vẽ wireframe hay thậm chí là cả prototype). Lí do ư? Đội design đang quá tải, tính năng này cần gấp và rất nhiều những lí do trên trời khác

• Kiêm nhiệm cả việc quản lí tiến độ dự án (Product manager và Project manager là 2 vị trí có trách nhiệm khác nhau hoàn toàn)

• Vừa phải keep track việc sản phẩm theo đúng hướng về business (vĩ mô) nhưng vừa bị đòi hỏi phải ngay lập tức trả được những thứ rất vi mô như button, màu sắc hay những bug nhỏ

Việc kiêm nhiệm và đội quá nhiều chiếc mũ (2 với mình có lẽ vẫn chỉ là số ít) khiến cho tình trạng quá tải, burn-out và stress trong chính công việc mà mình từng rất yêu thích là vấn đề phổ biến trong ngành Product này nói chung.

The “Agile” dilemma (Nan đề Agile)

Agile chắc cũng không còn xa lạ gì với giới Product nói chung nữa, gần như mọi công ty làm sản phẩm (và thậm chí là cả outsource) đều đã và đang áp dụng Agile và Scrum như một quy trình làm việc chuẩn.

Agile về mặt lý thuyết sẽ gồm 4 điểm chính bao gồm:

1. Vòng đời triển khai ngắn với việc thu thập feedback từ người dùng thường xuyên

2. Phát triển với một tốc độ có thể duy trì lâu dài (không quá gấp nhưng không cũng không chậm)

3. Có khả năng thích nghi và thay đổi dựa trên phản hồi của người dùng một cách dễ dàng và nhanh chóng

4. Luôn luôn hướng tới sự đơn giản

Đây chính là nền móng cho cách làm việc của mọi công ty Product hiện nay. Yếu tố nằm ở việc thu thập feedback người dùng liên tục và thay đổi nhanh chóng theo thị trường.

Thế nhưng nếu như đã làm việc theo Agile thì tại các PM/PO vẫn phải sufferring và burn-out trong công việc của mình như vậy?

Đây là những nghịch lí khiến cho việc triển khai Agile ở các công ty Product với mình trở thành một nan đề (Dilemma):

• Ngay cả với vòng đời triển khai sản phẩm ngắn hơn với nhiều customer feedback hơn, business stakeholder vẫn sẽ kiên quyết muốn triển khai theo ý kiến ban đầu của họ.

• Một sprint được diễn ra trong 2 tuần (thay vì kéo dài hơn như 1 tháng hay 3 tuần) dẫn tới sự bất khả thi trong việc tìm kiếm và nghiên cứu những thứ mới. Mọi thứ chỉ xoay quanh việc làm thế nào để ra mắt tính năng kịp khi sprint kết thúc.

• Sự linh hoạt trong Agile gần như không thể thực hiện khi toàn bộ các bộ phận còn lại trong công ty vẫn vận hành theo dạng “Project base”. Vậy Project base là như thế nào?

  • Mọi hoạt động nghiên cứu và tìm hiểu thị trường hoặc sẽ được giao cho 1 Agency research ở bên ngoài theo dạng Project (nghiên cứu theo yêu cầu, thường là một lần) hoặc sẽ được triển khai trong một thời gian ngắn từ vài tuần đến một tháng bởi PM/PO.

  • Business stakeholder sẽ đưa ra định hướng về việc sẽ làm gì và tại sao, team Product sẽ dựa vào đó xây Roadmap cũng như xác định cách thức triển khai.

  • Roadmap thường sẽ được chốt bởi Business stakeholder cùng với phần phân chia ngân sách (Budget allocation) thường vào khoảng cuối Q4 hằng năm.

• Ngay cả khi xảy ra biến số và mọi thứ không theo kế hoạch, team sản phẩm vẫn được kì vọng phải deliver được sản phẩm theo timeline và đúng (hoặc thấp hơn) ngân sách

• Usability testing thường được triển khai sau khi mọi thứ đã hoàn thành và release dẫn tới việc không phát hiện được các bug/issue ẩn mà khi QA testing bị sót. Kết cục dẫn tới việc phải có task hotfix hoặc fix bug trong sprint tiếp theo khiến cho kế hoạch ngày càng bị kéo dài

Và quan trọng nhất, team sản phẩm sẽ luôn bị đánh giá bởi những gì họ delivered (thời hạn, ngân sách…) thay vì việc có ai sử dụng sản phẩm không hoặc tính năng/sản phẩm đó có tạo ra được giá trị cho khách hàng hay không

Tạm kết

Mình không nghĩ sẽ có giải pháp cho việc này đâu bởi thực tế thường các PM/PO sẽ không phải là người có quyền quyết định mà sẽ là những stakeholder với quyền lực và tầm ảnh hưởng cao hơn (bạn biết là ai mà phải không).

Với mình sẽ luôn luôn có 2 lựa chọn:

• Thoả hiệp và chấp nhận đi theo những thứ ở trên. Thích nghi và chờ đến lúc mình có quyền lực đủ để thay đổi.

• Dũng cảm hơn, nói chuyện trực tiếp và thẳng thắn với những người liên quan và có khả năng quyết định để xem mọi thứ sẽ diễn ra như thế nào.

Mình có đọc được trên Thread một thread nói về việc 1 người sếp nước ngoài nói các công ty ở VN không biết làm Product và tư tưởng outsource đã ăn sâu bén rễ quá lâu rồi. Nghe tự ái chứ, nhưng mọi thứ đều có lí do của nó.

Hi vọng các PM/PO hiện tại và tương lai hãy luôn có một trái tim nóng và một cái đầu lạnh. Bởi ngành Product này không hề màu hồng đâu.