TẠI SAO ITBA LẠI CHUYỂN QUA PO PM DỄ THÀNH CÔNG HƠN UI UX? VÀ CÓ NHẤT THIẾT LÀ PHẢI CHUYỂN QUA?
Phân tích các lý do ITBA dễ chuyển qua PO PM thành công hơn các role khác
Bài viết lần này mình cũng tiếp tục dựa trên quan điểm của mình nên nếu mọi người có ý kiến gì bổ sung thì đừng ngần ngại comment phía dưới nhé. (Mình học Finance nhưng đi lên từ ITBA và Data. Đồng thời mình cũng kiêm quản lý khối ITBA của MindX nên mình nắm khá nhiều insight về vấn đề này)
Cách đây 1 tuần mình có viết 1 bài viết đối tượng UI UX tại sao lại muốn sang chuyển sang PO PM nhiều. Ở bài viết đấy mình cũng nói rằng UI UX không nên nhất thiết phải chuyển sang vị trí PO PM.
Nhưng ở bài viết này mình sẽ phân tích lý do tại sao ITBA là nhóm đối tượng có khả năng pass cao để chuyển sang vị trí PO PM. Mình dùng từ “chuyển sang” chứ không phải là “đi lên” vị trí PO PM vì bản chất PO PM không nhất thiết phải là sếp của ITBA hay nói cách khác không phải lúc nào PO PM cũng là cấp trên của ITBA. Vậy tại sao lại như vậy thì chúng ta cũng tới bài viết thôi nào?
ITBA LÀM GÌ?
Theo định nghĩa của The BABOK® Guide nói rằng: “business analysis as the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders.”
Để tóm gọn thì mình sẽ sử dụng Mindmap để dễ hiểu hơn
Nếu nhìn mindmap thì có thể thấy ITBA sẽ khá nặng về phần phân tích nghiệp vụ của Solution. Giúp phân rã requirements từ PO PM xuống detail để từ đấy Developer và Tester có thể hiểu sâu hơn và thực hiện nó. Đồng thời ITBA còn phải làm khá nhiều về mặt vẽ các flow chi tiết nâng cao như BPMN. Điều này dễ hiểu vì phần lớn các sản phẩm đều có sự tương tác giữa các actors với nhau chứ không chỉ có 1 actor. Ví dụ nếu chúng ta xây dựng 1 sản phẩm platform / marketplace như Grab thì chúng ta phải có sự tương tác qua lại giữa Merchants; Customer; Shipper và Hệ thống của Grab. Nên nếu dùng user flow thì không đủ để cover được hết nên chúng ta cần sẽ phải sử dụng tới BPMN 2.0 để có thể bóc tách từng activities; gateway; data in; data out của từng actor.
Product Owner Làm Gì?
Theo một số định nghĩa thì Product Owner là: “A product owner is a role on a Scrum team that is responsible for the project's outcome. The product owner seeks to maximize a product's value by managing and optimizing the product backlog.”
Mình đi từ Product Strategy để mọi người dễ hiểu rằng là 1 quyết định về tính năng nào đấy trong Product Backlog là giúp doanh nghiệp đấy tăng Business Value. Business Value ở đây không nhất thiết là về mặt kiếm tiền hoặc tối ưu hóa ROI (Return on Investment). Business Value ở đây có thể hiểu là giúp cho hệ thống hoạt động tốt hơn (sản phẩm nội bộ như CRM / HRM;…) từ đấy giúp gián tiếp phòng ban khác kiếm được khách hàng nhanh hơn, giảm chi phí cho doanh nghiệp. Hoặc có thể hiểu rằng tính năng đấy ra đời chưa chắc kiếm được tiền ngay nhưng trong tương lai nó sẽ là tiền đề giúp tính năng khác kiếm được tiền tốt hơn. Cũng có thể hiểu tính năng đấy giúp grow users tốt hơn mặc dù công ty đấy đang đi theo model là user growth chưa cần có Profit vội. Nhưng điều này giúp gián tiếp tăng Retention (user quay trở lại) hoặc Acquisition (new users) để khi đạt tới một ngưỡng users nào đấy thì doanh nghiệp bắt tay vào kiếm tiền.
LÝ DO ITBA DỄ CHUYỂN SANG PO PM
Anh em hãy đọc 2 mindmaps và thấy có những chỗ mình highlight màu xanh dương để nhấn mạnh những skills đấy hai role PO và ITBA đều có sự tương đồng nhau. Ví dụ giống nhau là cả ông PO và ITBA đều dựng Wireframe nhưng điều khác biệt đấy chính là thông thường việc detail hóa dựng các màn hình ở các use case khác nhau thì ITBA sẽ mạnh hơn và cover tốt hơn PO. Mình đã từng được các anh chị Senior ITBA hịn hò support điều này rất nhiều. Vì trong đầu mình lúc đấy hình dung ra solution giúp giải quyết problem của customer để từ đấy kiếm tiền. Nhưng mình chỉ draft rất nhanh các màn hình trong đầu mình đang nghĩ tới từ đấy ITBA sẽ tư vấn cho mình thêm về mặt logic và mở rộng các màn hình khác. UI UX sẽ hỗ trợ tư vấn về mặt UX làm sao cho user có trải nghiệm tốt hoặc dựng component trong Wireframe làm sao để có thể tái sử dụng các component trong Design System (Ant Design / Material Design).
Điểm giống nhau thứ 2 là viết User Story thì cả 2 ông đều phải viết. Nhưng hồi mình làm PM thì sếp cũ mình là CTO có nói rằng anh thuê em nhiều tiền không phải để làm công việc là đặc tả quá kĩ trong User Story, hãy để việc đấy là chuyên môn của ITBA (lương của anh chị ITBA cũng rất cao nhé). Lý do sếp mình nói thế vì nếu PO spend time quá nhiều vào detail hóa AC trong Stories thì sẽ dẫn tới time để nghiên cứu thị trường; phân tích chiến lược; phân tích user behavior sẽ bị giảm xuống;… trong khi công việc của PO PM là phải đem lại Business Value cao cho doanh nghiệp. Việc viết AC chi tiết đúng là có thể đem lại Business Value cho doanh nghiệp như giảm bug hoặc giúp tính năng deliver nhanh hơn. Nhưng nếu tính năng đấy không đem lại Business Value về mặt kinh tế như khách hàng không muốn sử dụng hay stakeholders không sử dụng được hệ thống CRM dẫn tới không kiếm được khách hàng tiềm năng. Thì liệu vai trò của PO còn có giá trị ở công ty hay không.
Mình theo kinh doanh gia đình từ khi học cấp 1 nên có 1 câu mình luôn được dạy khá kĩ “nếu con sử dụng chân tay để làm việc thì con có thể kiếm được 10 đồng. Nếu con biết phân tích và dùng cái đầu cộng thêm làm tay chân thì con có thể kiếm được 100 đồng. Nhưng nếu con có tầm nhìn chiến lược dài hạn và dùng đầu óc thì con có thể giúp hàng trăm người có thể sử dụng tay chân kiếm được 10 đồng và 100 đồng.”
Hiểu đơn giản trong ngữ cảnh của PO là nếu xây dựng 1 sản phẩm kiếm được hàng tỷ đồng hoặc chục tỷ đồng thì bạn đang giúp các đồng nghiệp ITBA; UI UX; Developer và Tester không bị layoff. Điều này minh chứng là trong giai đoạn bong bóng công nghệ bùng nổ dẫn tới thực trạng nhà nhà người người apply PO PM mà không giúp tăng Business Value trong long-term strtaegy. Cứ deliver features càng nhiều càng tốt và xem đấy là thực chiến, xem đấy là thành tích để đi khoe với xã hội là tôi đang làm việc năng suất. Nhưng khi bong bóng bị nổ và các Startup rơi vào “mùa đông gọi vốn” tức các Venture Capital bắt đầu siết lại dòng vốn vào các giai đoạn Seed hoặc Series A hoặc Series B. Dẫn tới các Startup hết nguồn vốn và khi một business model không chứng minh được traction của mình và khả năng scalable trong tương lai thì việc phá sản là chuyện bình thường; chuyện layoff là chuyện bình thường.
Vì theo lý thuyết kinh tế vĩ mô thì khi supply side (bên cung) cung cấp quá nhiều ra nhiều ra thị trường thì giá thành sẽ giảm theo tức là nhu cầu không đổi nên khách hàng có nhiều lựa chọn nên các công ty sẽ phải cạnh tranh nhau về giá và giảm giá thành. Mà chiến lược về giảm giá là một chiến lược khiến các doanh nghiệp đi vào con đường xuống lòng đất vì họ đang tự bóp chết margin profit của mình và khi dần cạn vốn thì họ sẽ cần phải tái cấu trúc bằng cách cut cost và các vị trí về IT sẽ bị cắt hàng đầu do mức lương luôn cao.
Lý do thứ 1 là các tasks có 1 số tasks overlap nhau như trên mindmap. Lý do thứ 2 là các công ty vì trong giai đoạn suy thoái kinh tế và nổ bong bóng công nghệ nên sẽ layoff và dồn các vị trí thành 1. Ví dụ thay vì thuê 1 ông PO lương 40 triệu; 1 ITBA là 38 triệu thì tôi chỉ thuê 1 ông PO hoặc 1 ông ITBA với lương 45 triệu. Nhưng sẽ phải cover các tasks từ ITBA tới PO dẫn tới PO sẽ phải làm tốc độ hơn thì mới làm kịp các tasks; dành nhiều thời gian trong 1 ngày hơn để làm tasks thậm chí là cuối tuần. Ví dụ trước đây PO chỉ làm 40 tiếng ở công ty và 5 tiếng OT trong tuần thì có thể tăng lên là 45 tiếng trên công ty và 10 tiếng OT trong tuần. Bạn bè mình là PO và thậm chí là mình đã từng phải nhập viện để truyền nước hoặc phải đi khám do loét dạ dày, nặng hơn là trầm cảm. Vì stress là thứ khiến dẫn tới bệnh loét dạ dày và trầm cảm.
Lý do thứ 3 là do ITBA overlap khoảng 40% kiến thức của PO trong quá trình làm việc thì ITBA chỉ cần học bổ sung 60% kiến thức còn lại để làm PO như Business Strategy; Product Analytic; Unlock Underserved Needs; Manage Agile Team;…
Lý do thứ 4 là ITBA là role được tiếp xúc trực tiếp nhiều nhất với PO PM và BOD cũng như các Stakeholders nên ITBA trong quá trình làm việc nếu quan sát cẩn thận thì có thể học luôn các tasks của PO PM, thậm chí là tốt hơn. Nên mình có nhiều học viên trong quá trình làm ITBA thì được các sếp đề bạt sang PO luôn.
Lý do thứ 5 là các anh chị Senior ITBA lâu năm sau 1 thời gian làm phân tích nghiệp vụ quá nhiều rồi họ muốn chuyển sang làm quản lý con người và chiến lược nhiều hơn thì việc xin công ty qua PO PM cũng tiện hơn. Do khi đã lên Senior ITBA thì họ nắm rất vững domain và logic nghiệp vụ của công ty đấy. Họ chỉ cần bổ sung kiến thức là có thể thành Managers.
Vậy Có Nhất Thiết Là ITBA Nên Chuyển Qua PO Không?
Câu trả lời là phụ thuộc vào tính cách và định hướng của ITBA. Nếu bạn muốn thử thách làm các thứ khó như chiến lược và phân tích thị trường hay muốn trở thàn quản lý có tính leadership nhiều hơn là ngồi thực thi cả ngày. Hay bạn muốn trở thành 1 Founder cho tương lai đi gọi vốn thì nên chuyển qua PO. Nhưng nếu bạn không chịu được áp lực từ BOD và phải đi họp quá nhiều hay phải chịu trách nhiệm sự sống còn cho 1 sản phẩm của công ty hay bạn khá là sống hướng nội chỉ muốn lấy requirements của stakeholders xong về làm phân tích nghiệp vụ thì câu trả lời nên tiếp tục lên các vị trí Senior ITBA hoặc ITBA Leaders hay thử sức qua ITBA Consultant. Lương PO PM không phải lúc nào cũng cao hơn ITBA nên bạn đừng nghe các trung tâm abcd kêu là làm ITBA xong “chuyển qua” PO PM thì mới up được lương. Bạn làm ITBA đủ lâu và đủ cứng và đủ skills đỉnh thì lương bạn còn có thể cao hơn rất nhiều PO PM.
Kết Lại
Qua bài viết chúng ta có thể những góc nhìn tại các công ty rằng tại sao ITBA lại có khả năng dễ chuyển qua PO PM thành công cao hơn các vị trí khác như UI UX hay Tester. Và qua bài viết này mình cũng muốn truyền tải thông điệp là không nhất thiết là chuyển qua PO PM thì mới có 1 mức thu nhập cao.
Thông tin thêm về mình:
Mình có một thời gian trải nghiệm làm tại các công ty như Onpoint, VnExpress, KAS, Zalo. Mình cũng hiện là Trainer và quản lý chất lượng khối Product Manager của 1 trung tâm đào tạo công nghệ lớn tại Việt Nam. Đồng thời mình cũng đang là một trong những người tiên phong tư vấn ứng dụng bài bản Job To Be Done cho các Bank và công ty công nghệ tại Việt Nam. Một số mình tư vấn đã ứng dụng như Momo, Chợ Tốt, BIDV, Vua Nệm… và một số công ty Startup AI khác. Background của mình thật ra không dính tí gì tới Product cả :v Mình học Quantitative Finance rồi lên Master mình học Applied Economic and Data Science của chương trình Erasmus University Rotterdam với UEH. Mình có một bài viết liên quan về “Hấp thụ công nghệ và bằng chứng về Hội Tụ Câu Lạc Bộ” tại hội nghị Kinh Tế Châu Á, được đăng trên tạp chí khoa học JABES. Mình thấy khá hứng thú về hấp thụ công nghệ nên từ đấy mình chuyển sang làm công nghệ và Product luôn là thế. Mình là dân dữ liệu và định lượng nhưng mình lại có niềm đam với việc tìm hiểu các nhu cầu của khách hàng.
Mình có 2 công ty: 1 công ty về Education, 1 công ty về cửa hàng đồ ăn. Bạn nào ở HCM có thể qua ăn ủng hộ :D
Cộng Đồng Job To Be Done:
Các kênh và group có tên “Job To Be Done Viet Nam” hoặc Job To Be Done VN” hầu như là của mình nên mọi người search là ra.
Linkedin của mình:
Đăng ký để đọc nhiều bài viết hay hơn!!!