[Product 101 - #2] - Những sự thật phũ phàng của nghề Product tại Việt Nam

Chúng ta tồn tại để phục vụ người dùng, dù cho tất cả các thế lực khác đều muốn chống lại họ

Xin chào các bạn,

Ở kỳ trước, các bạn đã được mình chia sẻ những cái được và chưa được của nghề Product.

Để không nhắc lại, mời bạn đọc phần cuối ở post 👇

Trong đoạn cuối, mình đã nói một chút về những cái chưa được. Phần đó đáng ra sẽ viết vào kỳ này nhưng mình đã quyết định nhá hàng trước.

Để recap lại, thì có vẻ nhiều người đã đồng ý với mình trong bài (theo cuối survey), đấy là nhiều nơi ép Product nhả việc theo Agile và tập trung vào xây Feature thay vì tìm hiểu nghiên cứu, cũng như bắt ép dân làm Product phải kiêm nhiệm nhiều việc đáng ra cần một bộ phận khác hỗ trợ (Design, Project Management, Data Analyst, User Research,....), cùng với việc bắt document như outsource dù muốn theo Agile khiến cho việc Delivery Sản Phẩm chiếm phần lớn thời gian, thay vì Discovery.

Trong kỳ này, mình sẽ đi sâu hơn vào những khó khăn, tình huống gặp phải mà chính những cơ chế trên đã cản trở để các PO có thể làm nghề và phát triển lên một tầm cao hơn.

Làm quen và chứng minh

Người làm sản phẩm luôn phải chịu một áp lực lớn, vì công ty và tổ chức bỏ tiền ra thuê họ về và sắp xếp cả một bộ máy xoay quanh họ. Những gì làm ra là công sức của rất nhiều con người, và qua mỗi vòng đời, công việc làm sản phẩm lại thay đổi và có những cái gì đó mới, không bao giờ dứt.

Đọc thêm 👇

Chính vì thế, hãy chuẩn bị tinh thần bạn phải đối mặt với muôn vàn khó khăn khi nhận việc, và việc vượt qua những bài test interviews tưởng khù khoằm và khó nhằn cũng chỉ là những thử thách chào hỏi ban đầu.

Khi mới vào công ty, hai tháng thử việc sẽ giúp bạn hiểu, học hỏi và chứng minh bạn phù hợp với văn hoá ở đây. Bạn vừa phải học hỏi (vì bạn không biết gì), nhưng cũng có áp lực chứng minh (nếu bạn không biết gì thật thì người ta thuê bạn làm gì).

Người ta thuê bạn để giúp đỡ công ty, nhưng bạn thì đang thực sự rất cần được giúp đỡ.

Bạn cần phải nhanh chóng quan sát và biết được các bộ máy ở đây làm việc ra sao như thế nào, cũng như những ai là những người có thể quyết định đánh giá bạn.

Trong những giai đoạn đầu, có một số tình huống sau đây rất dễ khiến bạn tạch:

- Bạn không làm việc được với Lead Engineer

- Bạn không chứng minh được giá trị với các stakeholders

- Bạn không tìm ra được vấn đề để fit mình vào hệ thống

- Bạn bị số đông đánh giá là không phù hợp văn hoá.

Văn hoá doanh nghiệp và onboarding cũng vô cùng quan trọng. Nhiều tổ chức họ tuyển PO về và expect PO tự bơi, cùng lúc đó dò xét xem PO này là người thế nào, có hợp với mình hay không.

Nhiều khi, tổ chức không có tài liệu, và các nhân sự cũ không chịu hợp tác với người mới, khiến cho bạn muôn vàn khó khăn. Chưa kể, người phụ trách Onboard bạn cũng không biết giao task cũng như hỗ trợ bạn gặp gỡ và kết nối với các đầu mối liên quan để bạn làm việc.

Có thể nói, khi gặp tình huống này là một red-flag, bạn đã được set-up to fail. Hãy cố gắng tìm hiểu người phỏng vấn bạn và xem họ có thể đỡ đầu giúp bạn không. Hãy tìm người thực sự đang cần tuyển người để làm việc, chứ không phải để đổ trách nhiệm.

Bạn sẽ không thể vượt qua được những tháng ngày đầu tiên nếu không có những đồng minh giúp đỡ, cả từ trên và dưới.

Áp lực và kỳ vọng

Cứ cho là bạn đã chứng minh được với tổ chức là bạn có giá trị, làm được những tính năng đầu tiên, giải quyết được một số vấn đề nhức nhối, etc,...

Chào mừng bạn đến với tầng thứ 2: quản lý kỳ vọng.

Nếu như ban đầu, việc của bạn là say Yes, biến mọi thứ không thể thành có thể, thì giai đoạn sau, bạn cần phải học dần cách Say No.

Đọc thêm bài của Jason 👇

Quản trị kỳ vọng khi làm PM/PO, khó hay dễ?

Mình rất vui vì bài 1 của mình đã giúp Jason có cảm hứng, và bài 2 của Jason tạo cảm hứng cho mình.

Việc có được 1 PO chính thức sẽ khiến cho công việc dần dần đổ dần xuống bạn. Feature factory dù tệ nhưng bạn sẽ chết nếu bạn định xây tất cả trong một ngày (đến Roma còn không được xây như vậy).

Hãy thiết lập cho bạn một ranh giới hợp lý, vì cách để nuốt một con voi là ăn từng miếng một, chứ không phải là nhét hết vào bụng.

Kỳ vọng là một thứ nguy hiểm. Nó gieo hy vọng cho tổ chức về năng lực của bạn, và cũng chính nó là thứ giết chết niềm tin vào bạn.

Việc bạn làm được một hai tính năng đầu không phải là cơ sở để nhân nó lên với số lượng tính năng cần làm trong quý tới. Mỗi tính năng có một câu chuyện và logic đằng sau, điều nguy hiểm nhất đấy là cứ làm theo đơn đặt hàng mà không cần suy nghĩ.

Kỳ vọng thời gian

Và chính việc nhầm lẫn giữa project management và product management khiến tổ chức muốn nhìn thấy bạn ship feature đúng kỳ vọng estimate, thay vì việc đánh giá sản phẩm có tiềm năng để theo đuổi hay không.

Làm trong ngành lâu năm, mình khẳng định với bạn 100% là mọi estimate của dev chỉ là chém gió (chính xác super tương đối). Nếu để chắc chắn, họ sẽ add thêm thời gian để họ có thể vừa chill vừa làm. Nếu cái nào cũng thế, thì feature đáng ra cần làm nhanh để test thì sẽ làm siêu lâu.

Là non-tech PO, bạn sẽ không bao giờ biết chính xác integrity của một lập trình viên (developer - gọi là dev) ngay từ đầu, mà chỉ có thể chọn cách tin họ.

Và nếu là một tính năng càng mới, càng khó để có thể estimate chính xác.

Và nếu tính năng càng quen, thời gian càng nhanh, và thậm chí có thể không cần làm vì code luôn có cơ chế tự lặp lại nếu biết cách tổ chức.

Thành ra, việc dùng PO để khống chế dev vô tình biến PO thành con tin của dev. PO chỉ có thể push dev chạy theo những gì họ đã hứa, chứ không thể ép họ chạy nhanh hơn tốc độ tối đa cần có.

Cách duy nhất làm được việc này đấy là xây dựng văn hoá ownership. Chính bản thân dev muốn làm nhanh vì dev muốn mang sản phẩm đến tay người dùng nhanh hơn để verify được logic đưa ra từ ban đầu.

Điều này đòi hỏi công ty phải có văn hoá làm sản phẩm, trao quyền và khuyến khích dev tự giác và take ownership. Developer cần được tham gia cùng vào khâu discovery, thay vì việc chỉ ngồi chờ requirement và vặn vẹo xem nó có xây được hay không.

Khổ nỗi, nhiều bên coi việc đi họp nghe yêu cầu là việc của PO, dev chỉ muốn ngồi viết code chứ không coi việc nghe người dùng kể chuyện là vấn đề của họ.

Và tư duy này bản chất vẫn là tư duy outsource, làm theo yêu cầu chứ không đủ sâu để hiểu về business.

Vì sao dev cần hiểu business? Nhiều người chắc hẳn sẽ nghĩ tôi nực cười 😂.

Dev cần hiểu sâu sắc mình đang xây cái gì cho ai để làm gì, và đưa ra phương án giải pháp. Đó chính là business!!!!

PO là người hỗ trợ dev làm việc đó tốt hơn vì mình dev khó có đủ thời gian làm việc đó.

Nhưng không đủ thời gian không có nghĩa là dev không có trách nhiệm làm việc đó. 100% dev giỏi đáng tin cậy là vì họ hiểu business cần gì, thay vì requirement viết gì.

Khi thấy một feature được ra đời chậm, đấy là do cả team đang cần phối hợp với nhau để có thể làm theo đúng một nhịp độ chính xác theo yêu cầu.

Tuy nhiên, ra đời nhanh hay chậm không quan trọng bằng kết quả của feature đó. Nhiều người không hiểu việc này, họ chỉ muốn đánh giá feature đã lên chưa, chậm hai ba ngày rồi, nhưng không quan tâm đến việc có cả một đống vấn đề cần xử lý đằng sau để đáp ứng những kỳ vọng khác trọng yếu hơn...

Kỳ vọng về kết quả

Khi một PO đủ tín, PO đó sẽ chịu trách nhiệm về đề xuất trong roadmap, có một số quyết định quan trọng, và nếu không đáp ứng được, PO có thể sẽ bị ..mất uy tín.

Bạn dành nhiều thời gian phấn đấu, thuyết phục stakeholder tin vào ý tưởng của bạn, và rồi số liệu không biến động theo ý tưởng đó, bạn phải chịu trách nhiệm. Nghe hợp lý đúng không?

Chính cái thứ tư duy này đã khiến cho nhiều nơi làm Product như một cái bẫy kỳ vọng sẵn sàng sập xuống các PO ngây thơ hăng máu muốn chứng tỏ bản lĩnh.

Một trong những nguyên tắc mà dân làm sản phẩm lâu năm đều biết, đấy là:

Làm sản phẩm đừng có nghĩ làm để chứng minh mình đúng, mà hãy luôn chuẩn bị là mình có thể sai.

Mục đích làm Lean là để ship nhanh, sai nhanh và sửa từ đó.

Một tổ chức quy kết sai lầm cho cá nhân là một tổ chức không thể lớn mạnh. Mọi thành công lớn đều cần phải học từ những thất bại nhỏ.

Mọi yêu cầu đều là một giả định được đưa ra và cần thực tế chứng minh.

Thực tế chứng minh sai, thì mình học hỏi từ nó để thay đổi và làm lại tiếp.

Có một sự cân bằng tinh tế và nghệ thuật giữa hai việc: 01/ làm nhanh để thử nghiệm sai, và 02/ làm đầy đủ trọn vẹn để có thể thử nghiệm.

PO là người luôn phải nhảy múa giữa hai thái cực này. Khi nào thì nên chấp nhận xong, khi nào thì nên dừng lại sửa thêm hẵng release.

Bạn không release đủ nhanh, bạn bị đánh giá không quản lý project hiệu quả. Bạn release quá nhanh, sản phẩm cẩu thả sẽ khiến kỳ vọng đi xuống.

Sản phẩm phải đủ tốt để bạn học được insights gì đó để bước tiếp, thay vì chứng minh nó không đáp ứng kỳ vọng của các nhà đầu tư đằng sau bạn.

Và việc bạn liên tục đáp ứng tốt nhiều kỳ vọng không tưởng, sẽ khiến bạn dễ làm nạn nhân của một kỳ vọng không tưởng khác, vì người khác sẽ luôn nghĩ những gì bạn đang làm là bình thường.

Và với nhiều người, chỉ một lần sai thôi, là uy tín của bạn đã mất rồi.

Làm PO không được sai, nhưng không sai thì làm sao thử nghiệm để mà lớn được?

Con dê tế thần

Đây là tình huống rất nhiều PO gặp phải trong nghề nghiệp.

Một stakeholder, một ai đó có quyền lực hơn bạn, biết nhiều thông tin hơn bạn, có nhiều mối quan hệ và ảnh hưởng hơn bạn, tích cực lobby và ủng hộ bạn làm một tính năng nào đó.

Thỉnh thoảng, họ nhiệt tình đến mức thậm chí sẵn sàng cản trở bạn nếu bạn không làm đúng ý họ 😂.

Họ là đồng minh thân cận nhất muốn bạn thành công. Bạn cần họ để bạn thành công.

Đọc thêm 👇

Nhưng khi bạn thất bại (đúng hơn là không đáp ứng kỳ vọng), thay vì cùng nhận trách nhiệm với bạn, họ cho rằng đấy là vấn đề của bạn và mọi việc là do lỗi của bạn : PO không đủ tốt.

Phần lớn không ai muốn đi backup người thất bại cả, bạn sẽ thấy vô cùng cô đơn.

Trình độ và mức trưởng thành của các mentor sẽ lộ diện lúc này.

Bạn có thể thấy tồi tệ vì mình mắc sai lầm. Nhưng cỗ máy và cơ chế vòng lặp kiểu này, thì một cá nhân mắc sai lầm chỉ là chuyện sớm hay muộn mà thôi.

Và trước những kỳ vọng vô lý, thì sai lầm đầu tiên đấy chính là việc bạn đã chiều theo kỳ vọng đó quá dễ dàng.

Sai lầm thứ hai đấy chính là việc bạn không nhận ra mình đã bị thao túng, và trở thành con rối trong tay những người khác, chịu toàn bộ trách nhiệm cho vấn đề của người khác.

Mời bạn nghe câu chuyện về Tào Tháo sau đây:

Tào Tháo đem binh đánh Viên Thuật, tướng của Viên Thuật là Lý Phong đóng cửa thành không ra. Tào Tháo phải đóng binh tại đấy hơn một tháng, quân đội đến 17 muôn, mỗi ngày tổn phí lương thực rất nhiều.

Bộ hạ là Vương Cấu vào bẩm với Tào Tháo về việc thiếu lương, Tào Tháo bảo:

- Vậy phải lấy hộc nhỏ (giảm suất ăn) phát cho chúng nó đặng quyền đỡ mà cứu khi cấp.

Vương Cấu thưa:

- Như quân sĩ oán trách thì tính làm sao?

- Chừng ấy ta có chước khác.

Vương Cấu y lệnh lấy hộc nhỏ phân phát. Tào Tháo lén cho người thám thính các trại thì nghe quân sĩ oán trách cho là họ bị Tào Tháo khinh bỉ. Tào Tháo hay được tin ấy, đòi Vương Cấu vào, bảo:

- Ta muốn mượn ngươi một vật để trấn tĩnh lòng của chúng quân. Xin ngươi chớ từ.

Vương Cấu hỏi:

- Thừa tướng muốn dùng vật gì?

- Ta muốn mượn cái thủ cấp của ngươi.

Vương Cấu cả kinh, thưa:

- Tôi là người vô tội.

Tào Tháo bảo:

- Nếu chẳng giết ngươi thì lòng dân sinh biến. Nếu ngươi thác rồi ta sẽ nuôi vợ con ngươi đến mãn đời. Xin ngươi đừng lo.

Vương Cấu muốn nói nữa, thì Tào Tháo đã khiến quân đao phủ dẫn ra ngoài cửa mà xử tử. Tào Tháo lại truyền bêu đầu Vương Cấu lên và truyền rao rằng:

“Vương Cấu lấy hộc nhỏ phát lương, gian trộm của quan nên theo quan pháp mà trừng trị”.

Từ ấy lòng quân mới hết thán oán. Và ngay hôm sau, Tào Tháo truyền lệnh cho các tướng phá thành. Nếu trong ba ngày mà phá không được thành thì Tào Tháo sẽ xử tử hết.

Thế rồi Tào Tháo bản thân đến bên thành, đốc quân khiêng đất, lăn đá lấp hào để trèo lên thành. Quân ở trên thành bắn xuống như mưa. Có hai tên tướng của Tào Tháo sợ chết muốn trở ra. Tào Tháo vung gươm chém chết tại chỗ, rồi bản thân bưng đất lấp hào.

Quân sĩ thấy thế đều đua nhau tiến lên trước. Quân trên thành ngăn trở không lại. Quân của Tào Tháo nhảy lên thành, chặt khoá phá cửa cho cả đội đều xông vào.

Kết quả Tào Tháo chiếm được thành.

Qua câu chuyện trên, bạn sẽ thấy mình quen thuộc như thế nào. Quá trình vất vả làm Product Delivery luôn là nơi có ẩn chứa nhiều những mâu thuẫn, và quân sĩ cùng bạn cày ngày cày đêm để làm những thứ không đáp ứng kỳ vọng.

Nếu bạn là lý do có những feature đó, thì cô lập bạn ra và đóng cửa các features vừa có tác dụng cắt giảm chi phí, lại còn đắc nhân tâm và đẹp lòng quân.

Bản chất của người làm Product tốt, đấy là việc người đó Care.

Từ Care còn hơn cả quan tâm, nó đòi hỏi một sự bám đuổi đầy trách nhiệm, của cả lý trí lẫn trái tim, để khiến sản phẩm thực sự phục vụ người dùng lẫn doanh nghiệp, thay vì lý trí của một ai đó.

Và với những người càng có trách nhiệm, thì việc nhận trách nhiệm càng trở thành thói quen, càng dễ bị thao túng.

Chẳng trách mà nhiều PO gặp vấn đề về lòng tin, trầm cảm, mất niềm tin với đồng nghiệp và cuộc sống.

Họ đã phải đóng vai người hùng trong thời gian quá dài, để rồi một ngày bị tế sống như một kẻ phản diện.

Và họ phải quên đi những trải nghiệm này để đặt niềm tin vào những chỗ mới rất dễ đưa họ vào những vòng lặp tương tự.

Họ phải đấu tranh để từ care, không tự diễn biến thành don't care, để còn care again.

Vĩ thanh

Nghề Product không hoàn hảo. Tại Việt Nam, nó vẫn còn đang phát triển. Những kỳ vọng vẫn còn nhiều chỗ vô lý.

Ngành phần mềm chúng ta đa phần đến từ văn hoá Outsource, gia công theo yêu cầu của nước khác. Trong chuỗi cung ứng, chúng ta được dính vào phần có hàm lượng suy nghĩ thấp hơn, vì lao động của chúng ta rẻ hơn.

Giờ ta được khoác lớp vỏ làm sản phẩm, muốn sáng tạo, muốn Agile, muốn Design Thinking. Nhưng nguyên tắc của nó, tư duy sản phẩm,.. là những thứ không trường lớp nào đào tạo.

Các framework lý thuyết được dạy nhiều vô kể, dù chúng nhiều khi đánh lẫn nhau.

Chẳng hạn Design Thinking có khâu ideate, rồi prototype. Xin hỏi với Agile, thì phải chăng sản phẩm release chính là prototype để validate users? (prototype = product itself)

Và validate là gì, nếu users không dùng thì đấy chính là insights còn gì nữa?

Thay vì phải ăn mừng để có cơ sở cải tiến, tại sao nhiều bên lại coi đấy là lỗi của người làm sản phẩm?

Và ideation nên là hoạt động tập thể của bộ ba Developer, Product và Designer, chứ không phải là mớ tài liệu được viết vội vàng sau cuộc họp với một bác sếp nào đó rất háo hức muốn ý tưởng của mình được thực thi.

Và để validate users được thường xuyên, nhanh và rẻ, các công ty nên chuẩn bị budget để nuôi một đội User Research, và có cách để kiểm thử phần này.

Liệu đã mấy công ty trang bị đủ những nhân sự như vậy?

Hay việc đơn giản nhất là quăng cho một PO nhận đủ các việc, và tế sống họ sau một thời gian burnt out để tuyển một nhân sự khác phù hợp hơn.

Vòng lặp này liên tục tiếp diễn, kẻ sống sót có khi từng là PO, may mắn bước ra khỏi vòng tròn hiến tế, và có thể ngồi một chỗ an toàn đánh giá năng lực của các PO.

Liệu họ sẽ tiếp tục vòng tròn này, hay sẽ tạo ra một bộ máy khác tốt hơn.

Vai trò của PO Lead, hay VP of Product, trong việc thiết kế một văn hoá xây dựng là vô cùng quan trọng: họ muốn các PO phát triển hay là bới lỗi và trảm.

Đến Gia Cát Lượng cũng cần có Lưu Bị nâng đỡ, nhưng người này có thực sự là Lưu Bị, hay bản chất là Tào Tháo ?

Đọc đến đây mà thấy cuộc đời đen tối quá, thì sorry bạn nhé. Rất có thể đâu đó nó không như vậy, nếu bạn may mắn.

Mình rất mong các tổ chức có thể đọc được bài này, để có thể thay đổi và tạo điều kiện hỗ trợ giúp đỡ hơn cho những người làm Product.

Bản thân những người làm Sản Phẩm đã có rất nhiều trách nhiệm, họ dẫn dắt tất cả đi ngược dòng.

Chê thì dễ, nhưng làm thì mới khó.

Phá đi thì dễ, xây nên mới khó.

Bạn có thể trả tiền cho một người, nhưng không thể ép người ta Care.

Cái đó là phẩm chất lao động đáng quý, cần được trân trọng của bất kỳ ai trong tổ chức, không chỉ những người làm Product.

Mong cho các bạn Product không hoàn toàn mất niềm tin vào nghề, để vẫn còn vững bước mà care đến người dùng.

Vì tựu trung lại, chúng ta tồn tại để phục vụ người dùng, dù cho tất cả các thế lực khác đều muốn chống lại họ