[Product 101 - #1] - Những suy nghĩ về ngành Product Management cho người mới bắt đầu

Một bài mở đầu về một trong những nghề thú vị nhất của ngành Công nghệ, mà theo mình chẳng khác gì nghề huấn luyện viên bóng đá cả

Xin chào các độc giả của The1ight!

Nếu các bạn đang đọc những dòng này, thì đây là bài viết đầu tiên của mình kể từ năm mới Ất Tỵ.

Mình đã dự định viết về nghề này từ lâu, nhưng cuộc sống lôi kéo mình quá nên mình đã trì hoãn chủ đề lớn này trong nhiều tháng. Năm mới, mình quyết tâm sẽ mở hộp về ngành với nhiều bài viết sâu hơn về nghề. Đã đến lúc mình cần nuốt con cóc lớn này, thay vì cứ bối rối vì có quá nhiều chủ đề để viết trong đó.

Nếu các bạn sẽ tò mò vì sao mình lại muốn viết về chủ đề này trong vô vàn chủ đề mình có thể viết (bạn có thể nhìn thấy từ list các chủ đề mình đã viết), thì đây là một số những lý do của mình:

- Mình đã làm nghề Product được gần 10 năm (đúng hơn là gần 9 năm, làm tròn từ tháng 7 năm 2016 😂), từ thời kỳ mà thị trường ở Hà Nội nhiều nơi còn chưa biết đến vai trò của Product Owner. Khi mình vào nghề, Momo còn chưa liên kết được với CGV, và chưa có ai làm nghề này ở đó cả. VinID lúc đó còn mới chỉ là một cái thẻ thành viên.

- Mình đã nhận lại được quá nhiều từ nghề này, kể cả niềm vui lẫn nỗi buồn. Nghề Product cho mình một sự gắn bó sâu sắc mà mình hiểu thế nào là nghiệp, là nghề chọn người. Từ một kẻ lạc lối, không biết mình muốn làm gì của hơn 10 năm trước, đến việc mình đã có thể tự tin nuôi gia đình nhỏ của mình, có một sự nghiệp nhất định trong nghề, và có thể mỉm cười khi nhìn lại về lựa chọn xưa của cá nhân, là cả một câu chuyện rất dài với nhiều chương tiểu thuyết (tin mình đi, vì mình đã thực sự viết tiểu thuyết).

- Mình nghĩ rằng dù đã làm nghề gần 10 năm, vẫn còn quá nhiều thứ mình vẫn chưa hiểu hết về nghề Product. Ngoài hiểu biết của cá nhân mình, thì còn cả của cộng đồng, của xã hội, nhất là khi áp dụng những cách làm của thế giới vào thị trường Việt Nam. Viết là cách để có thể giúp đưa những quan sát và câu hỏi ra ánh sáng, và giúp cho tất cả chúng ta có thể lại gần và thấu hiểu nhau hơn.

- Như mình đã từng viết, một trong những nỗi đau lớn nhất của nghề đấy là luôn phải thấu hiểu người khác, trong khi không ai chịu thấu hiểu cho mình. Và nhiều khi, bạn cần thời gian để thấu hiểu cho tình thế của chính mình. Mình tin rằng cộng đồng làm sản phẩm cần xích lại gần nhau hơn nữa, để có thể làm bạn, giúp đỡ nhau để phát triển tốt hơn.

Một trong những điều mình nhận thấy đấy là: chúng ta không thể tự thành công một mình, dù cho chúng ta có thông minh và cố gắng thế nào đi nữa.

Ngay cả HLV có số má đến mấy, mà doanh nghiệp nào cũng set-up cho bạn ghế đỏ như ở Manchester United, thì kết cục của bạn cũng xoay vòng theo chu kỳ ra vào hang mà thôi. Đến C.Ronaldo còn lên TV phỏng vấn, thì tại sao chúng ta không thử cùng nhau mổ xẻ những câu chuyện của chính mình?

- Và mình cũng nhận thấy nghề còn rất nóng, và nhiều bạn già lẫn trẻ đều quan tâm muốn nhảy vào. Kiến thức sách vở của nghề này thì vô tận, trong khi thực tế thì vừa ảo diệu vừa khốc liệt đến tàn nhẫn. Và mình muốn give back lại những gì mình biết, để các bạn có thể đỡ khổ hơn như mình đã từng.

Anyway, thôi khỏi dông dài nữa, mình sẽ khai bút bằng một bài mở đầu về một trong những nghề thú vị nhất của ngành Công nghệ, mà theo mình chẳng khác gì nghề huấn luyện viên bóng đá cả. Mời các bạn ngồi lên những chiếc ghế không đỏ, đeo dây an toàn và đọc bài nhé. Một số suy nghĩ có thể hơi lạ với những gì bạn biết, vậy nên trước khi quăng gạch nhớ thông cảm cho mình một tí nhé, vì dù sao mình cũng vẫn chỉ là một con ếch ngồi trong cái giếng của mình thôi.

Nghề Product có gì hay?

Trước khi xả van kể khổ về những gì bạn có thể chưa biết, thì mình cũng phải công tâm nói với bạn vì sao mình chọn làm nghề này suốt 10 năm qua, mà đến giờ vẫn cảm thấy mình may mắn vì sớm tìm ra nó.

Nghề Product có rất nhiều điểm hay, và đây là những điểm most-valuable với mình:

1. Nghề Product đòi hỏi sự sáng tạo và học hỏi với những điều mới mỗi ngày

Không có nhiều nghề trên đời này bạn được quyền sáng tạo, và tạo thay đổi nhiều và nhanh như nghề Product.

Bạn cơ bản là sống ở thì tương lai, nơi mà bạn tin giải pháp bạn phụ trách sẽ giải quyết vấn đề của hiện tại. Bạn sống mỗi ngày để đưa giấc mơ thành sự thật, kiểm định giả thiết để tạo ra thay đổi có tác động đủ lớn với vấn đề mà bạn nắm rõ nhất.

Việc thường làm của bạn mỗi ngày đấy là biến những gì không thể của hiện tại thành có thể của tương lai. Bạn được đi sâu vào căn nguyên của từng vấn đề để hiểu và tìm ra giải pháp tối ưu nhất. Và thông thường, giải pháp tối ưu có thể nghĩ ra được, nó sẽ không giống hoàn toàn với một giải pháp nào đó có sẵn.

Nó sẽ phải có một sự may đo, tuỳ chỉnh nào đó mà chỉ những ai thực sự thấu hiểu về mô hình kinh doanh, nền tảng công nghệ và năng lực của đội ngũ hiện tại mới thực hiện được.

Một trong những cảm giác sướng nhất của nghề, ấy là khi bạn giải quyết vấn đề, và thậm chí đưa ra được hẳn một khái niệm mới hoàn toàn (product concept) để các bên liên quan áp dụng (dù không phải lúc nào bạn cũng làm được như vậy).

Product concept có thể được sinh ra dựa trên việc bạn áp dụng được hai hoặc ba phạm trù khác nhau bạn quan sát được của ngành khác để tạo ra một thứ mới cho riêng bạn.

(ví dụ trong một bài từng viết hồi làm Jamja, mình từng đẻ ra khái niệm location-time checking cho Jamja áp dụng từ case của Grab/Uber). Nghĩ lại thì cái này hơi có chút chút giống khái niệm space-time trong vật lý lượng tử (another topic to write about for later 😂). 

Bạn có thể đọc thêm ở đây 👇

My Product Story - Jamja Phuc Long

Làm sản phẩm, bạn có khả năng được sáng tạo dựa trên những gì chưa ai từng làm và hiểu biết về những gì người khác đã từng làm.

Không phải ngành nghề nào cũng cho bạn đặc quyền này. Đối với mình, việc xây, sáng tạo và tạo ra những ảnh hưởng tích cực cho tổ chức và xã hội là niềm vui số một khiến cho mình cảm thấy mỗi ngày mình đi làm đều có ý nghĩa và có sự tôn trọng với nghề.

2. Nghề Product luyện cho bạn nhiều kỹ năng toàn diện về tư duy lẫn thực hành

Làm Product là giải quyết vấn đề và tìm ra vấn đề, và đó thực sự là một kỹ năng quan trọng của cuộc sống.

Bạn sẽ học cách lắng nghe để thực sự thấu hiểu vấn đề, thay vì nhảy vào tranh nhau đưa giải pháp.

Bạn hiểu cách đặt câu hỏi, để điều tra users như phá án, tìm kiếm nguyên nhân sâu xa đằng sau từng hành vi, suy nghĩ sau máy tính.

Bạn học cách lưu vết, giăng tơ (log số liệu) như đặt bẫy, để tìm hiểu xem hành vi người dùng qua từng con số giống và khác nhau ra sao trên từng giả định của bạn và lời nói của họ.

Bạn trở nên khiêm tốn hơn nhiều, khi nhận ra mình có quá nhiều thứ mình tưởng mình hiểu mà lại không hiểu.

Bạn học cách lấy thông tin, và phối hợp cùng các chuyên gia giỏi hơn bạn trong lĩnh vực của họ, để giải quyết được bài toán của bạn.

Bạn học cách trao đổi và truyền đạt thông tin, tạo niềm tin và gây dựng niềm tin với mọi người trong tổ chức.

Bạn trở thành một chuyên gia điền vào chỗ trống, khoả lấp những thứ mà tổ chức của bạn không ai chuyên làm.

Để rồi sau đó, bạn trở thành một lãnh đạo đầy tớ, phục vụ đội nhóm tìm kiếm lời giải cho bài toán bạn đưa ra.

Chỉ giỏi lý thuyết thôi sẽ chưa đủ, vì người ta sẽ nhìn thấy rất rõ cái bạn làm để mà đánh giá. Kết quả thường sẽ phải rõ ràng, vì mọi vấn đề xảy ra người đầu tiên bị chịu trách nhiệm sẽ là bạn.

Và đương nhiên bạn cũng không thể chỉ biết thực hành, vì bạn cần nắm vững lý thuyết để còn thuyết phục các lãnh đạo cấp cao tin tưởng và đặt cược vào phương án của bạn.

Mỗi thứ bạn cần biết đủ dùng, để còn có thể trở thành chuyên gia khi tổ chức không có ai giúp được bạn.

Nhờ nghề này, tôi đã học được cách phân tích số liệu (viết sql, data analysis), thiết kế figma, quản lý dự án Agile, viết yêu cầu sản phẩm, vẽ luồng (BA), phỏng vấn người dùng (user testing), digital marketing cơ bản,... bên cạnh những kỹ năng mềm khác như giao tiếp, dẫn dắt cuộc họp, trình bày vấn đề-giải pháp, host meeting...

Và tất nhiên, cái tôi thích nhất đấy là có một mindset làm sản phẩm, có thể đem vào áp dụng cho cuộc sống. Tôi sẽ có nhiều bài viết để mô tả từng bước về thế nào là mindset làm sản phẩm, các bạn đón chờ nhé.

3. Đây là một liquid career.

Bên cạnh mức lương của nghề mà tôi nghĩ là không quá tệ (dù tất nhiên vẫn còn thua xa một số ngành nghề khác), thì cái mà tôi thích đấy là về cơ hội tự do nghề nghiệp.

Ngoài việc mức đãi ngộ của nghề cũng ở mức tương đối khá, thì một điểm ít người viết nói về nghề đấy là việc đây là một nghề có tính thanh khoản cao (liquid career)

Tính thanh khoản cao nghĩa là việc nghề trang bị cho bạn nhiều cơ hội được thử thách bản thân ở nhiều ngành nghề, vị trí khác nhau, với mức độ linh hoạt lớn.

Đọc thêm 👇

Liquid vs. Illiquid Careers

Giống như khái niệm strategic positioning trong cờ vua đã từng nói ở đây của Dentmaker, thì có những vị trí chiến lược sẽ cho phép bạn có một tầm nhìn tốt và cơ hội để nhảy vào những góc hay ho của bàn cờ cuộc sống.

Đọc thêm 👇:

Chess & Career track

Nghề consulting là một nghề như vậy, với rất nhiều người bước ra làm CEO của các doanh nghiệp, tập đoàn lớn, hay chí ít là một vị trí cấp lãnh đạo dù tuổi đời và kinh nghiệm còn non trẻ.

Product Management dù low key hơn một chút về tên tuổi và sang chảnh (for now) nhưng về độ linh hoạt thực tế thì cũng không hề thua kém (và có nhiều chỗ hơn). Và mình cũng quan sát thấy rất nhiều bạn bè từ Consulting, đi học MBA xong, cũng transition sang làm Product cho Big Tech. Nếu còn trẻ hơn và không vướng gia đình, maybe mình cũng sẽ thử làm như vậy.

Trong thời đại mà công nghệ thay đổi từng ngày, thì đằng sau mỗi ứng dụng được ra mắt, là vô số những giờ phút trăn trở của những product manager đằng sau mỗi sản phẩm. Và một khi bạn có trong tay một portfolio những dự án thực sự, bạn hoàn toàn có khả năng tiếp cận các cơ hội để gia nhập các dự án khác nhau mà bạn hứng thú.

Bạn sẽ không phải quá lo lắng cho việc không thể tìm kiếm việc cần bạn, vì nhu cầu có một PM tốt vẫn luôn còn đó trong xã hội.

Thay vì phải sợ lụy một tổ chức không còn phù hợp với bạn, bạn hoàn toàn có thể tìm thấy cơ hội mới từ khắp nơi. Bạn hoàn toàn có lựa chọn công ty phù hợp với khả năng của bạn.

Với cá nhân mình, nghề Product đã cho mình trải nghiệm đa dạng ở các ngành như làm trình duyệt, bất động sản, bán lẻ, O2O, fintech, sản xuất, chăm sóc sức khoẻ, chỉnh sửa ảnh,... Mình cũng có kinh nghiệm đa dạng môi trường như doanh nghiệp lớn trong nước (VinID, PwC), startup (Jamja, Sapo, Vuiapp), hay doanh nghiệp có yếu tố nước ngoài (Cốc Cốc, Esoft), và thậm chí là làm remote full-time ở công ty nước ngoài - global (công ty hiện tại - sẽ public tên công ty sớm sau khi pass probation).

Mỗi một sản phẩm ở một ngành nghề mới như một câu chuyện và cuộc đời mới, thử thách mới khiến cho bạn luôn phải làm mới bản thân (sẽ có dịp mình sẽ dần kể những gì đã trải qua).

Bạn sẽ được chứng kiến rất nhiều câu chuyện cuộc sống, với những cú tàu lượn cảm xúc từ bế tắc đến thăng hoa, từ đỉnh cao đến rơi tự do. Mỗi trải nghiệm đều sẽ để lại cho bạn những bài học và kinh nghiệm xương máu mà sách vở không thể viết sẵn.

Bạn sẽ được chứng kiến rất nhiều câu chuyện cuộc sống, với những cú tàu lượn cảm xúc từ bế tắc đến thăng hoa, từ đỉnh cao đến rơi tự do. Mỗi trải nghiệm đều sẽ để lại cho bạn những bài học và kinh nghiệm xương máu mà sách vở không thể viết sẵn.

Và tôi nghĩ một sự nghiệp như vậy chắc chắn là sẽ không nhàm chán, dẫu cho bạn có thể vẫn phải nhảy điên loạn để tìm ra góc bàn cờ mà mình muốn thuộc về.

Và một điểm hay nữa là, nghề Product hoàn toàn có thể chấp nhận những người trái ngành nhảy sang, miễn là bạn có đủ năng lực và sự kiên trì với nó.

Bạn cần học gì làm gì nếu quan tâm và muốn nhảy vào nghề này?

Các bạn có thể đọc lại một số bài viết mà mình từng viết ở đây.

Muốn làm nghề Product thì bắt đầu từ đâu? (Phần 1)

Muốn làm nghề Product thì bắt đầu từ đâu? (Phần 2)

Nghề PM mình nghĩ là một nghề đau khổ của việc tự bơi, và số giờ thực hành quan trọng hơn nắm lý thuyết rất nhiều.

Và một trong những đau khổ của học PM đấy là nó có khá nhiều lý thuyết cần học. Mỗi lý thuyết là cả một bầu trời kiến thức cần bạn có trải nghiệm để khám phá.

Mình sẽ list ra đây một vài fundamental concepts để các bạn có thể aware.

1. Hiểu về Product Life Cycle,

2. Hiểu về project management: Agile vs Waterfall

3. Lý thuyết cơ bản Lean Model, MVP

4. Kỹ năng Problem solving, prioritization, user research, roadmapping

5. Tư duy Design thinking, customer centric,..

6. Hiểu về dữ liệu: cách đặt dữ liệu, truy vấn dữ liệu, quan sát dữ liệu và ra quyết định

7. Kỹ năng trình bày và kể chuyện: viết tài liệu, quản lý tài liệu, backlog, xây dựng quan hệ với các stakeholder

8. Kỹ năng về hiểu business: mô hình kinh doanh, phân tích thị trường, chiến lược sản phẩm, chiến lược đưa sản phẩm ra thị trường (GTM strategy)

Điều đáng buồn là thị trường khá khốc liệt và không/chưa có nơi đào tạo chuẩn chỉnh cho nghề này như những nghề truyền thống khác (bác sĩ, kỹ sư,...).

Điều vui đấy là chính vì thế, nếu bạn có khả năng tự học tốt và tư duy nắm bắt vấn đề nhanh, cơ hội sẽ luôn rộng mở cho bạn.

Mình đã thấy có một số nhóm bắt đầu mở những khoá học cho người muốn vào ngành Product, và mình cũng đang cố gắng sẽ đưa ra một khoá học như vậy cho các bạn, dựa trên những điều mình biết.

Mình đang cố gắng cân bằng thời gian bên cạnh công việc chính và gia đình để xây dựng khoá học này. Các độc giả của mình nếu hứng thú, bạn có thể đăng ký ở link này để mình nắm bắt nhu cầu nhé.

Mình sẽ cố gắng viết thêm một số bài viết sâu hơn để chia sẻ một vài góc cạnh của nghề trong quá trình xây dựng nội dung khoá học và giúp các bạn tự học nhanh hơn.

Bài sau, mình sẽ viết về những vấn đề còn tồn đọng của ngành tại Việt Nam dưới cái nhìn "phiến diện" của mình.

Ngành Product của Việt Nam theo mình đánh giá là vẫn còn non trẻ, lý thuyết cao đẹp mà các bạn học được trong sách vở chắc áp dụng được 10%.

——————-
SPOILER ALERT - Nghĩ đi nghĩ lại xong mình quyết định là thôi để luôn nửa bài phần sau lên coi như trailer cho phần tiếp 😂 👇. Ai mà đọc tiếp ráng chịu nhá.

Nếu bạn muốn lạc quan về nghề thì dừng lại ở đây thôi nhé 🤣.

————-

Nghĩ kỹ trước khi đọc phần dưới…

————-

Vài điều không ai nói với bạn về nghề product tại Việt Nam

Đúng hơn đây mới chính là phần động lực chính để viết bài này, tuy nhiên, mình thấy cần thiết phải có những phần trên để các bạn có một cái nhìn lạc quan, đầy cảm hứng, trước khi nói về những chông gai mà các bạn chắc chắn sẽ dễ gặp phải trên đường đi.

Thực ra mình có thể tách thành hai series khác nhau, nhưng như thế sẽ giống như mình có 1 phần đầu nhẹ nhàng, lùa gà nhẹ và thiếu điểm nhấn quá, trong khi câu chuyện chính mình muốn kể nó ở phần này cơ. Thành ra thôi mình sẽ ngâm thật lâu để viết một bài thật dài vậy, chứ kinh nghiệm series cho thấy là mình đẻ xong cũng phải mất vài tuần đến cả tháng (như series mở khoá), lúc ấy đầu óc lại đang muốn viết về vấn đề khác mất rồi.

Câu chuyện này là một câu chuyện có 3 phần liên quan đến nhau, mình note ra từ một cuộc gặp trao đổi với một đồng write là

ThinhVoXuan

- chuyên gia solution architect của Geek-up từ hồi Giáng Sinh.

1. Không nhiều người ở Việt Nam hiểu đúng về Agile và làm Product

Mình đã từng khủng hoảng suýt bỏ nghề khi mới vào và kẹt giữa sự xung đột về mindset giữa waterfall và agile ở tổ chức đầu tiên cho mình cơ hội. Trong vài năm sau đó, mình chứng kiến nhiều cuộc nói chuyện đấu tranh cho việc liệu làm Agile có thực sự phù hợp không.

Đến nay thì Agile dường như có mặt ở khắp mọi nơi, người ta không hỏi là vì sao cần làm Agile nữa, mà là làm Agile đúng như thế nào.

Điều đó không có nghĩa là tất cả mọi người đều hiểu giống nhau về cách làm Agile đúng, và vai trò của nó khi làm sản phẩm.

Tệ hơn, bối cảnh chuyên nghiệp không cho phép các bên tĩnh lại để cùng hiểu bản chất, mà thay vào đó là cắm đầu vào một guồng quay sản phẩm do các chuyên gia Agile vạch sẵn.

Theo mình nhận thấy, mọi người (nhiều nơi) chưa tách bạch giữa việc làm sản phẩm với chạy theo mô hình Agile.

Bản thân Agile là một hệ tư tưởng, với Scrum là một quy trình giao tiếp và làm việc giữa PO và dev team. Agile Scrum là một lát cắt trong công việc làm sản phẩm, chứ không phải toàn bộ công việc làm sản phẩm nằm trong Agile.

Để hiểu kỹ hơn được đoạn trên, các bạn sẽ cần phải hiểu 2 topic lớn: Agile là thế nào, và làm sản phẩm là thế nào.

Sẽ là quá dài để tôi viết kỹ về hai topics đó (xin hẹn các bạn lần sau, nếu các bạn có yêu cầu ở dưới comment). Trong khuôn khổ bài viết này, tôi sẽ viết ngắn gọn như sau.

Trong Agile Scrum, có một role trong 03 vai chính là Product Owner, bên cạnh 2 vai còn lại là Scrum Master và Dev Team. Product Owner là người quản lý backlog của sản phẩm, đưa yêu cầu chi tiết, và giải đáp đồng hành cùng development team trong mỗi Sprint. Dev team là người tiếp nhận yêu cầu, ước tính công việc theo năng lực, và thực hiện việc xây sản phẩm. Scrum Master là trọng tài, giúp hai bên làm việc hợp tác đúng quy trình, kịp tiến độ thực hiện.

Như vậy, vai trò của Product Owner đúng ra chỉ là việc đưa thông tin và trao đổi thông tin cần thiết cho nhóm sản phẩm (dev team). Product không có nhiệm vụ quản lý dev team, kiểm tra công việc hàng ngày, đốc thúc hay kiểm soát thanh tra năng lực của dev team. Tuy nhiên, vì nhiều lý do (tôi sẽ đề cập phần dưới), product owner ở Việt Nam nhiều nơi phải chịu trách nhiệm lớn nhất về performance của cả team, với yêu cầu đáp ứng của servant leader, và bị kéo theo một số những vai trò trên.

Toàn bộ những gì Product Owner làm trong Agile, có thể gói gọn trong một từ là Product Delivery.

Trong Product, đặc biệt là in house, thì delivery là giai đoạn mà mọi yêu cầu đã trở nên tương đối rõ ràng, có thể tài liệu hoá, và có đáp án chi tiết để team dev có thể đi tiếp.

Tuy nhiên, delivery chỉ là phần nổi của tảng băng chìm. Phần chìm của nó, đấy là Product Discovery.

Và việc tốn quá nhiều time vào delivery, khiến cho thời gian ưu tiên để discovery của các product manager/owner bị hạn chế rất nhiều. Hậu quả là một vòng lặp của chuỗi những bong bóng kỳ vọng được dựng xây, rồi tăng dần và nổ vỡ khi các product manager không thể đáp ứng kịp những kỳ vọng đó.

Việc phải duy trì công việc cho mỗi Sprint liên tục cho Dev team tạo một áp lực phải "nghĩ việc" cho Product Manager, và từ đó rất dễ biến công ty thành một xưởng sản xuất Feature (a.k.a Feature Factory).

Vòng lặp của quy trình sẽ diễn ra như sau:

Onboarding => Catchup để join Agile Scrum cùng team dev => Giải quyết 1-2 first quick-win => Build trust => Nghĩ big product roadmap => Chia vào các Sprint => Deliver Roadmap => Pivot & Adjust => New Roadmap => Repeat Delivery.

Mỗi lần Roadmap thay đổi, là một đống những công việc cần thiết của Product Discovery cần được thực hiện, nhưng thường chúng ta không dành đủ thời gian cho việc đó.

Chúng ta thường quickly đưa một Roadmap hợp lý, kịp deadline, để team còn có việc mà chạy đuổi theo nó.

Để rồi khi xây mãi mới xong một vài cái, thị trường thay đổi, âm nhạc dừng chơi, ta lại đập đi xây lại.

Giống như là ta đang chơi trò Musical Chair vậy đó, hết nhạc là lúc các ông lớn Hippo, stakeholders tỉnh ra, dừng trò chơi Agile lại, đổi bài khác chơi tiếp, tái cơ cấu.

Đọc thêm về Hippo ở đây 👇

Và rất có thể, người bị thừa ra do mất ghế là các product owner, dù họ cũng chỉ là người bị dí để đưa deadline product roadmap cho kịp thời gian mà thôi.

Một vòng lặp luẩn quẩn, Agile theo từng trận đánh nhưng mà vẫn waterfall cả cuộc chiến theo đúng quy trình bung toang kiểu Manchester United.

Điều đó cũng là vì một sự thật thứ hai....

2. Cách thiết kế làm product của nhiều công ty rất phản khoa học

Trong vai trò PM, có nhiều vai vế và trình độ, từ junior product owner, senior product owner, feature product owner, senior product manager đến principle product manager,...

Để xây sản phẩm, thì việc ra được một sản phẩm tốt thôi chưa đủ, vì rất có thể người này gặp may mắn. Cái khó là làm ra nhiều những sản phẩm chất lượng và liên tục.

Để làm được việc đó, thì cần có một hệ thống các người làm sản phẩm với nhiều vai trò chuyên môn khác nhau.

Hay đúng hơn, đấy là việc xây dựng hệ thống làm sản phẩm hiệu quả. Nói như Elon Musk, đấy là việc tạo một cỗ máy để xây một cỗ máy (build a machine that builds a machine).

Để sản xuất ô tô hàng loạt, Vinfast phải xây một nhà máy với băng chuyền để từng bộ phận có thể có đồng đều chất lượng, một điều cơ bản của việc scaling.

Để đá được bóng đá sexy như Pep Guardiola, các cầu thủ đều phải có tổ hợp kỹ năng riêng dù ông dùng cũng đa dạng. Một số trung vệ biết đá hậu vệ cánh, hậu vệ cánh biết đá tiền vệ quét, tiền vệ cánh đá như tiền vệ công,...nhưng phải là những con người hợp lý, có năng lực và có người biết dùng họ.

Pep như một Principle PM, ông biết phải làm gì với những cầu thủ ông có trong tay, và dùng họ thế nào. Nhìn thì đa dạng đấy, nhưng là đa dạng có quy tắc.

Điều này không áp dụng với nhiều hlv khác, vì họ bắt chước Pep mà không làm được như Pep.

Nhiều Head of Product ở Việt Nam là những người đi lên thuần từ Tech hoặc thuần business, và không hiểu gì về làm sản phẩm. Điều này chẳng khác gì Ed Woodward làm bóng đá ở Man United vậy.

Cứ product owner nào (cầu thủ) thì vị trí nào cũng phải đá. Tiền đạo cho đi bắt gôn, thủ môn cho lên đá tiền vệ, hậu vệ thì lên tiền đạo.

Chính thế mà nhiều nơi, nghề Product Owner cái gì cũng làm: viết tài liệu kỹ như outsource, vẽ design thay cho designer, quản lý dự án như Scrum Master, có nơi còn cho quản lý luôn cả dev,...

Trong cuốn Inspired, phần giá trị nhất viết rất rõ là Product Management không phải làm gì? Trên thế giới, đã có giai đoạn nghề Product điền hết cả vào chỗ trống, bắt design, viết docs, test sản phẩm, quản lý dự án, phỏng vấn người dùng.... cái gì cũng đòi một cá nhân phải làm và chịu trách nhiệm. Và đó là đều sai lầm.

Sẽ luôn là tiện nhất là vẽ ra một vị trí còn thiếu (Product), và yêu cầu một cá nhân trám vào toàn bộ công việc làm sản phẩm dù cho công ty không có nguồn lực và bộ máy để hỗ trợ.

Nguồn lực có hạn, thôi ta dùng sức ít người cho ngon bổ rẻ.

Không có trâu thì ngựa kéo cày.

Không có chó, bắt mèo ăn 💩

Để khi người này hết sức thì ta tuyển người khác.

Product Owner ở Việt Nam không nên làm thay tất cả, vì nó sẽ dẫn đến burn out, và lỗi nằm ở khâu thiết kế bộ máy mà ông Principle PM đã không biết phải sắp xếp cầu thủ của mình đá ở vị trí nào (nhiều nơi còn chả có Principle PM, các product owner làm phụ tá cho CTO).

Đa phần khi làm ở các tổ chức, tôi từng phải solo với tất cả và dần dần thuyết phục các bên tuyển thêm để giúp tôi cùng xây tất cả.

Product Owner/Manager quản lý về product và phối hợp với các bên chuyên môn (Growth Marketing, User Research, Data Analyst, Designer,... ) để cho ra yêu cầu phù hợp nhất.

Vì quá mải mê theo quy trình Agile, ta làm ngược luôn ưu tiên khi xây sản phẩm.

Build the right product > build the product right (chúng ta gần như nhắm vào phần sau hơn phần đầu).

Chưa kể, cách chúng ta làm cũng đâu có đúng.

Nên có dual track Agile, tức là có room để có đội nhóm cùng làm việc discovery, thay vì bắt 1 product owner phải cày cả discovery khi rảnh sau khi đã bục mặt làm delivery.

Agile nên được dùng như là một cách để giải quyết vấn đề thay vì là một phương pháp để đẩy nhanh tiến độ release.

Và cách các team phối hợp với nhau cho chuẩn Agile cũng còn cần nhiều điều chỉnh.

Bản thân các developer nên coi các tài liệu chỉ là gợi ý, chứ đừng vặn vẹo theo hướng hãy mô tả thật chi tiết tôi cần phải bước chân nào trước, chân nào sau.

Mindset của nhiều dev vẫn khá waterfall, coi người PO phải giỏi hơn mình trên tầm về cái mà mình biết, và coi thường họ nếu họ không giỏi cái mình giỏi.

Điều này không khác gì Pogba bật Mourinho vì Mou không biết đá bóng vậy.

Hay thậm chí nực cười hơn là Anthony khinh Messi vì anh ta (Messi) không biết xoay compa.

Nhiều PO chạy Agile và chật vật với việc viết tài liệu chi tiết, vì để chạy thật nhanh họ không có thời gian làm điều đó.

Nhưng chạy mà không có tài liệu, thì cũng khá rủi ro vì không có gì neo đậu các yêu cầu và kiến thức cần làm. Sau này tìm lại task trên Jira chẳng khác nào mò kim đáy bể.

Việc master được một luồng vừa có tài liệu vừa đủ, vừa giao tiếp và thuần phục các dev sao cho hợp mindset product, là một trong những kỹ năng sống còn của PO. Bạn chắc chắn sẽ bị trảm nếu không làm được điều này.

Tựu trung lại, các vấn đề của các doanh nghiệp gói gọn trong một số gạch đầu dòng sau:

- Về cơ cấu tổ chức, không có người đủ tầm để xây dựng một kết cấu team sản phẩm cho phù hợp, bền vững, dẫn đến việc vai trò PO bị chắp vá

- Về quy trình Agile, không xây dựng được văn hoá cân bằng giữa quyền lực của PO và Dev, giữa việc làm tài liệu và trao đổi yêu cầu.

- Về chiến lược, không có chiến lược rõ ràng từ trên xuống theo hướng ưu tiên vấn đề và chỉ số, dẫn đến roadmap bị quẩn quanh do dí deadline, và xây nhà máy features.

- Về con người và văn hoá, không có nguồn lực phù hợp để nuôi dưỡng hỗ trợ người làm sản phẩm, mà bắt họ làm hết các vai trò còn thiếu. Đội ngũ dev thiếu tự giác khi xây sản phẩm, ỷ lại vào năng lực quản lý của PO.

Mình xin phép dừng tạm kỳ 1 ở đây, nếu mọi người hứng thú mình sẽ viết tiếp, vì nói thật là cái này viết mãi cũng chẳng hết chuyện 😂.

Tuy nhiên, đây again vẫn là góc nhìn phiến diện của mình, rất mong nhận được chia sẻ của các cao thủ khác, có những góc nhìn khác hơn. Mình cũng rất mong mình hiểu sai vấn đề, và có ai đó thông não hộ mình để cuộc sống PM cũng vẫn tươi đẹp hoành tráng như hồi mình mới vào nghề.