Agile Và Continuous Innovation 101

Làm sao để ứng dụng Continuous Mindset?

Mar 23, 2024

Helu anh em. Lại là Long đây. Mọi người thắc mắc tại sao Substack của mình lại có nhiều tác giả rồi nhiều thể loại chủ đề về Product quá vậy. Thật ra ban đầu Segmentation của mình chọn là các bạn Senior và hypothesis của mình là các bạn newbie / junior sẽ dần thích bài của mình nhưng sau khi test thêm các bài Series 101 thì kết quả lại cho khác. Cả hai nhóm đều thích chuỗi các bài 101 và khá ít người lại thích các bài phân tích chuyên sâu của mình. Sau bài viết ngày hôm nay các bạn sẽ hiểu hơn tại bọn mình lại phải mất công chia ra nhiều Segmentations và nhiều topics để test như vậy.

Số liệu được thu thập từ 28/2/2024 – 24/3/2024 – Bài Product Delivery mới chỉ đăng được vài ngày mà đã đạt view hơn bài Business Model Canvas.

Agile Là Gì?

Định nghĩa ngắn gọn nhất cho mọi người dễ hiểu

Agile represents an overarching philosophy for software development, emphasizing the value of iterating quickly and often to satisfy customers. Therefore, an agile framework can be defined as a specific software-development approach based on the agile philosophy articulated in the Agile Manifesto.

Agile hiểu ngắn gọn là linh hoạt và adapt với sự thay đổi liên tục của customer. Tuy nhiên, chúng ta cũng có thể hiểu Agile với một số từ khác như sau:

Agile ~ Continuous ~ Ongoing

Mọi người biết tới Agile Delivery nhưng chắc mọi người chưa nghe tới Continuous Discovery / Continuous Exploration (trong SAFe) nhiều. Thật ra bản chất Agile Discovery chính là Continuous Discovery. Và chúng ta làm Continuous Discovery và Delivery như vậy mục đích để tạo Continuous Innovation.

Hãy kiên nhẫn để đọc và hiểu lý do tại sao mình lại chọn Continuous Innovation để đi theo chuyên sâu trong việc xây dựng sản phẩm công nghệ.

Lý do tại sao mình lại dành nhiều gian nghiên cứu Continuous?

Lý do đầu tiên, mình tốt nghiệp chương trình Master “Applied Economic – Data Science”của Hà Lan. Mình may mắn có 1 bài viết được publish bài Research Paper trên tạp chí JABES (có thể check ranking trên SJR) và được thuyết trình tại Hội Nghị Kinh Tế Châu Á Thái Bình Dương năm 2022 (mình viết bài này từ 2020). Mình tìm ra được bằng chứng “Hội tụ câu lạc bộ giữa các khu vực tại Việt Nam bằng mô hình hồi quy không gian”.

Bài viết của mình có cho thấy rằng các yếu tố chi phí công nghệ và khả năng học hỏi công nghệ từ con người (nhân công có trình độ) giúp thúc đẩy quả trình hấp thục công nghệ từ đẫn tới sự tăng trưởng hơn ở khu vực Đông Nam Bộ khác với các khu vực khác.

Kết quả từ Spatial Regression - Đây là một dạng hồi quy nâng cao hơn so với OLS, FEM, REM mà các bạn DA DS hay chạy. Mình không sử dụng GMM để chạy. Dữ liệu được Viện Nghiên Cứu Kinh Tế cấp nên bao uy tín nhé anh em.

Trong đấy, có một khái niệm là “Learning by doing” được đề cập bởi các nhà khoa học rằng, việc nhân công trình độ hấp thụ kiến thức nhanh nhất là vừa học hỏi vừa làm sẽ giúp hiểu sâu về công nghệ máy móc, giúp tăng hiệu suất trong quá trình sử dụng công nghệ. Nhưng có 1 điều mà mình băn khoăn trong quá trình đấy rằng vậy Learning by doing là tốt đấy. Vậy thực thi nó cụ thể ở ngoài đời như thế nào là đúng? Cũng nhiều người cũng “Learning by doing” nhưng tại sao không hiệu quả?

Sau một thời gian đi làm tại các công ty công nghệ, thì mình được tiếp xúc tới khái niệm Agile. Nhưng thực sự lúc đấy mình chưa biết cách sử dụng và hiểu Agile chuẩn đâu. May mắn tiếp theo đối với mình là mình gặp được anh Nhân – Cựu CTO của KAS. Anh có hơn 20 năm kinh nghiệm trong ngành công nghệ. Anh cũng là một trong những người có chứng chỉ SAFe Consultant (Scaled Agile Framework) tại Việt Nam. Anh cũng đã chỉ dạy mình thực thi và học hỏi Agile theo đúng tinh thần của nó (thật ra hồi đó mình bị dí đi học PMI – ACP vs Leading SAFe). Đấy chính là sự học hỏi và cải thiện từ các Sprint. Và mình phát hiện ra rằng wow nó rất giống với “Learning by doing” mình đang tìm câu trả lời. Đây cũng chính là lý do thứ 2 khiến bùng lên ngọn lửa về tìm ra cách learning by doing. À quên anh Nhân xuất thân từ Developer đi lên Tech Lead và từng có time Head và CTO nên cách ứng dụng của anh Nhân giúp tăng Performance của Dev cực khủng khác với nhiều SM khác làm việc mà mình biết trước đó, sorry điều này đụng chạm với các Scrum Master / Agile Couching không xuất thân từ Dev.

Trong quá trình mình tổng hợp lại các tài liệu từ lúc đi làm tới giờ thì mình lại tìm được các kiến thức mà chị Hải – Chủ tịch VnExpress hướng dẫn mình cách làm Product Strategy và khái niệm về Continuous Discovery để tìm ra Customer Needs (chị Hải là người thầy đầu tiên của mình dạy về Digital Product Strategy, cách VnExpress tạo ra các sản phẩm kiếm được nhiều tiền). Nhưng thời điểm đấy mình làm ở tầng Strategy với các sếp nhiều quá nên cũng có làm Discovery nhưng chưa quá bài bản theo Continuous Disovery.

Mình cũng bắt tay vào research rất nhiều framework về Continuous Innovation trên thế giới. Nhưng thật sự mình chưa quá hài lòng vì sau khi apply mình lại thấy rất nhiều lỗ hổng. Ví dụ Framework nổi tiếng nhất mà nhiều PM / PO / PD apply là Opportunity Solution Tree. Nó lại đi từ Goal Metrics đi xuống Problem và Opportunity. Cách remove các Hypothesis của OST thì lại quá đơn giản chỉ là dùng một số kĩ thuật như Assumption Test.

Phương pháp Job To Be Done – Outcome-driven Innovation thì nó lại quá bự để làm 1 lần Innovation. Không phù hợp quá nhiều cho các công ty. Mình cũng lại tìm tới các framework liên quan tới Continuous Experiment của Netflix, Google, Uber, Spotify, Zalo, Momo, Chợ Tốt,… đang dùng thì thấy các công ty lại tập trung quá nhiều về việc nghĩ ra các Hypothesis và setup run Experiment (mình chơi thân vs nhiều PM các Big Corp ở VN nên may mắn được tiếp cận và tư vấn cho họ nhiều case study). Nhưng phần Problems lại không tập trung quá nhiều và đào sâu vào nó.

Book Demo Tư Vấn

Cũng có nhiều bạn bè mình kêu thử apply Design Sprint xem sao. Thú thật là mình đã thử Design Sprint và thậm chí tư vấn cho 1 doanh nghiệp dùng Version mới nhất của nó là Design Sprint 2.0 (chạy trong 4 ngày). Nhưng thú thập nó chỉ giải quyết được cho mình đoạn sáng tạo ra nhiều giải pháp và cách make decision khi có Decider (CEO hoặc những sếp lớn) join vào cuộc chơi. Phần Problems Space trong Design Sprint thì mình chỉ ứng dụng duy nhất phần HMW, Can We, Sprint Goal. Còn đâu phần Interview Expert và xây dựng Map mình không quá hài lòng về tìm problems của users. Nên trong Framework của riêng mình là Continuous Job-Outcome Tree mình đã có thể giảm được xuống 3 ngày.

Vào một ngày đẹp trời bà chị mình là Founder Staylab (công ty tư vấn về UX Research) quăng cho mình quyển sách mới toanh (xuất bản 2024) của Debbie Levitt và đồng tác giả viết. Bà đưa ra một số mô hình và quan điểm cho thấy rằng OST cũng không hiệu quả và Customer Centric lắm, vì nó sẽ đi từ mục tiêu OKR / Metrics của doanh nghiệp để tìm Problem cho sản phẩm. Cách của bà đưa ra là đi ngược lại và tìm xem Problems nào impact lên các metrics của mình.

Tuy nhiên, các framework trên chỉ là tác động vào internal của product (sức mạnh nội tại bên trong và cung cấp value tới khách hàng). Nếu chúng ta không có sự tác động từ External (distribute tới customer, stickyness họ, xây dựng network effect, grow loop) như Growth Team và Marketing Team thì liệu sản phẩm của chúng ta có sự tăng trưởng một cách Growth Hack hay không?

Mình rất may là mình được học và tiếp xúc bài giảng trực tiếp từ Head of Markplace của Grab, người đi từ những người đầu với Grab. Chị đã giúp mình hiểu thêm ngoài làm Continuous Experiment bên trong sản phẩm mà cũng cần phải có sự kết hợp với team growth để tìm ra đúng các Growth Levers cũng như các Growth Targets. Mình rất ấn tượng bởi cách sử dụng Data-Informed và Machine Learning để kết hợp tạo impact với tới các Growth Levers. Phần này mình sẽ không đề cập trong bài viết hôm nay quá nhiều nhưng mình sẽ đính kèm cho mọi người hiểu sơ về Growth Framewok mà mình được học từ chị. Dĩ nhiên, đây là Framework tổng quan thôi còn execute sao thì phức tạp hơn thế.

Final Continous Process Innovation

Hãy cùng tới Continuous Process Innovation mà mình xây dựng trong quá trình làm việc. Hình đầu tiên mình sẽ đề cập tới cách thực thi Learning by doing hiệu quả. Hình tiếp theo sẽ về các bước mình đi qua. Còn mọi người muốn xem Full Process thực thi từ đầu tới cuối hãy book mình 1 buổi demo tư vấn doanh nghiệp để trải nghiệm.

Book Demo Tư Vấn

Trước tiên, chúng ta cần thay đổi mindset của chúng ta và làm rõ thực thi khái niệm Learning by doing.

Sau khi chúng ta biết về 1 công nghệ hoặc lý thuyết hoặc framework nào mới không phải chúng ta cứ để đó và dùng 100% theo. Mà chúng ta cần phải học bản chất, bối cảnh của thứ chúng ta mới học. Vì ngữ cảnh của thứ đó giúp chúng ta hiểu tại sao nó ra đời và phù hợp cho khi nào.

Tiếp đến chúng ta cần tìm ra xem khi ứng dụng ở doanh nghiệp ta nó chưa ổn chỗ nào, cần tinh chỉnh sao cho phù hợp. Nhưng sự khác biệt ở đây là chúng ta cần phải đưa cho nhiều người bạn xung quanh chúng ta cùng apply để xem khi doanh nghiệp khác sử dụng thì nó không hiệu quả chỗ nào. Sau đấy chúng ta mới gom những điểm chưa tốt của chúng ta khi apply với bạn bè và các công ty khác apply rồi cải thiện. Vì chúng ta càng có nhiều feedback thì sự cải thiện chúng ta càng tốt.

Khi kết hợp các Frameworks ở trên thì chúng ta sẽ có process như sau:

Process này hiện tại là Process Overview mà mình hay sử dụng trong công việc, startup của mình, đi tư vấn, đi giảng dạy,…

Vài case study mình đã apply thành công Process này nhé.

Đầu tiên là MindX, khi mình vào làm quản lý chất lượng khối Product Manager và ITBA tại MindX thì feedback về chất lượng giáo án hoặc điểm hài lòng vô cùng vô cùng thấp. Khoảng 2.5 – 3.0 mà thôi. Nhưng sau đấy mình apply lấy Learner-Centric và tìm ra các pain points thông qua hàng trăm cuộc phỏng vấn khác nhau với các học viên tại các khóa. Mình đã giúp tăng điểm Satisfaction lên khoảng 4.0 – 4.8. Đồng thời số lượng học viên tham gia đầy đủ mỗi buổi cũng tăng lên rất nhiều, tỷ lệ học viên mình giảng dạy pass job rất cao sau khi học. Học viên các lớp có newbie, junior, senior, C-Level cũng rất nhiều nhưng làm sao cân bằng được các nhu cầu các bên mình cũng đã phải thức trắng nhiều đêm để xây dựng lại giáo án, cải thiện chất lượng giảng viên theo Continuous Process. Riêng cải thiện để học viên lên lớp liên tục thì mình dùng Hooked Model. Cái này bài viết sắp tới của bọn mình.
Một công ty Kỳ Lân Công Nghệ đã bắt đầu apply và giúp tính năng grow 15%. Hiện tại bạn take care dự án chuẩn bị được nhận project mới để run process này. Và UX Leader của công ty cũng chuẩn bị apply cho team UX.
Chợ Tốt apply để tìm ra Underserved Needs
Big 4 Bank apply để tìm ra các Underserved Needs cho các sản phẩm B2B trong chiến lược tái cấu trúc lại và chuyển đổi số.

Giờ mọi người đã hiểu tại sao mình và team viết bài lại thử nghiệm liên tục nhiều topic (hypothesis) như vậy rồi đúng không. Ban đầu mình và team phỏng vấn một vài người trong giới Product và xem họ đang gặp vấn đề gì với các bài viết hiện tại. Bọn mình collect được rất nhiều Problems và tạo ra nhiều Hypothesis. Như các bạn thấy bọn mình đăng liên tục gần đây với các bài viết đan xen các chủ đề trên Linkedin, Facebook Group,… Sau đấy thấy rằng các bài viết nào impact mạnh tới Metrics mà bọn mình chọn. Bọn mình lại tiếp tục chạy thử các bài xoay quanh topic đó xem liệu impact tiếp hay không, hay là do tính mùa vụ của Time Series impact vào.

Book Demo Tư Vấn

Kết lại

Qua bài viết này mình muốn tri ân tới những người đã giúp đỡ mình trong thời gian qua. Đồng thời qua bài viết mình hy vọng mọi người có góc nhìn mới hơn về khái niệm Continuous Innvovation. Continuous không phải là chúng ta chỉ ngồi estimate point bằng cách chơi Planning Poker, define AC, define DoD và làm Sprint Retrospective trong team với nhau cũng như deliver sản phẩm càng nhanh càng tốt. Quan trọng nhất là chúng ta đi ra khỏi bàn làm việc chúng ta, khám phá nhu cầu liên tục, đưa ra nhiều hypothesis và chạy Experiment liên tục. Biết học hỏi từ những lần Discover và Experiment không hiệu quả. Anh em deliver feature nhanh nhưng không đáp ứng nhu cầu khách hàng không bán hàng được hiệu quả, dẫn tới doanh thu giảm thì việc deliver feature còn có ý nghĩa gì nữa.

Nếu muốn là những công ty apply process này sớm hãy book mình 1 buổi demo tư vấn doanh nghiệp để trải nghiệm.

Book Demo Tư Vấn

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ểm 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

Địa Chỉ Quán Mình