Không Có Framework Nào Hoàn Hảo – Và Con Người Cũng Thế

Không có Framework nào sinh ra để có thể hoàn hảo áp dụng vào mọi ngữ cảnh công ty. Và những người làm xây dựng sản phẩm sinh ra cũng không ai hoàn hảo để xây dựng một sản phẩm hoàn hảo cả.

Tác giả - Thăng Long

Hế sờ Lô cả nhà!! Bữa giờ mình bận đi chuẩn bị pitching để raise fund cho Quỹ Đầu Tư nên mình khá là bận nên chưa viết được bài. Để đền bù thì mình sẽ viết 1 bài viết mà mình cho rằng mình yêu thích nhất đấy chính là định nghĩa về “sự hoàn hảo” trong việc apply Framework và nhìn nhận bản thân của chúng ta. Cùng bất đầu đọc nào.

Sự Hoàn Hảo Là Gì?

Sự tồn tại song song của hai khái niệm hoàn hảo, một nghiêm ngặt ("hoàn hảo") và lỏng lẻo khác ("xuất sắc"), đã nảy sinh, có lẽ từ thời cổ đại nhưng chắc chắn từ thời Phục hưng, đến một nghịch lý duy nhất: đó là điều tuyệt vời nhất sự hoàn hảo là sự không hoàn hảo. Điều này được xây dựng bởi Lucilio Vanini (1585-1619), người có tiền thân trong nhà văn thế kỷ 16 Joseph Juste Scaliger, và đến lượt họ nhắc đến nhà triết học cổ đại Empedocles. Lập luận của họ, như được đưa ra bởi hai người đầu tiên, là nếu thế giới hoàn hảo, nó không thể cải thiện và do đó sẽ thiếu "sự hoàn hảo thực sự", điều này phụ thuộc vào sự tiến bộ. Đối với Aristotle, "hoàn hảo" có nghĩa là "hoàn thành" ("không có gì để thêm hoặc bớt"). Đối với Empedocles, theo Vanini, sự hoàn hảo phụ thuộc vào sự không hoàn hảo ("perfectio propter imperfectionem"), vì không hoàn hảo có tiềm năng phát triển và bổ sung cho các đặc điểm mới ("perfectio complementii"). Quan điểm này liên quan đến thẩm mỹ baroque của Vanini và Marin Mersenne: sự hoàn hảo của một tác phẩm nghệ thuật bao gồm việc buộc người nhận phải hoạt động tích cực để bổ sung cho tác phẩm nghệ thuật bằng nỗ lực của trí tuệ và trí tưởng tượng.

Trong bộ phim The Godfather mình có nhớ 1 câu rất nổi tiếng đấy là:

Nhưng câu nói trên hơi hạn hẹp cho nam giới. Nên mình dựa vào câu nói trên có 1 câu nói mình tự nghĩ ra mà mình hay dùng để khuyến khích bạn bè mình.

Không có ai hoàn hảo nên cũng sẽ không có hình tượng 1 ai đấy hoàn hảo. Nên việc cải thiện sự không hoàn hảo của chúng ta chính là đang tạo nên một con người của chúng ta trong tương lai hoàn hảo hơn.

Không Có Framework Nào Hoàn Hảo Cả

Khi mình mới bước chân vào các công ty công nghệ và bắt đầu xây dựng Product thì mình bị bắt đi học các Models và Frameworks như Product-Market Fit, Value Proposition Canvas, Lean Canvas, Design Thinking, Agile, Opportunity Solution Tree, Continuous Experiment… Nhưng mình dường như nhận ra rằng mỗi một mô hình đều có những ưu điểm và khiếm khuyết giống như con người chúng ta vậy. Nó sẽ chỉ tốt và phù hợp ở ngữ cảnh này nhưng sẽ không tốt cho ngữ cảnh khác. Ví dụ: khi mình apply các Value Proposition Canvas thì việc interview sẽ rất chung chung, rất không có hướng dẫn cụ thể nên đặt câu hỏi gì để khai thác Customer Job, từ Customer Job ra Pain Point và làm sao đào sâu vào Pain Point. Nhưng bù lại Value Proposition Canvas làm rất tốt ở việc trực quan hóa và có process hệ thống rõ ràng nên làm các bước như thế nào (Value Proposition Design Book).

Hoặc khi qua làm Agile – Scrum Kanban thì mình cũng tập tành chạy Sprint nhưng mình cũng không hiểu nếu trong môi trường messy toàn requirements từ BOD vs Stakeholders thì làm ra sao. Trong Scrum Guide cũng không giải thích kĩ. Rất may thì thời điểm đó mình được sếp cũ mình là từng làm Agile hơn chục năm hướng dẫn cách customize lại để run phù hợp cho tổ chức công ty nhưng vẫn đảm bảo tăng performance theo đúng tinh thần Agile.

Sau đấy, mình mới chợt nhận ra rằng không có 1 framework nào hoàn hảo để apply tốt cho mọi công ty, mọi người ngữ cảnh, mọi người lực. Bản thân Framework cũng chỉ là 1 tập hợp các bước, các sự kiến của 1 người hoặc 1 nhóm người nào đấy ứng dụng hiệu quả ở một số bối cảnh công ty nào đấy viết ra và tạo nên. Bản thân những người tạo ra các Frameworks cũng chỉ mong muốn giúp cho thế giới tốt hơn nên họ muốn phổ cập Framework ra toàn thế giới và hy vọng những người ứng dụng nó có thể tự điều chỉnh lại cho phù hợp cho doanh nghiệp của mình.

Như vậy, bản thân Framework không hoàn hảo. Sự hoàn hảo chỉ xảy ra khi chúng ta liên tục cải tiến những sự không hoàn hảo (Continuous Learning).

Cải Thiện Sự Không Hoàn Hảo Của Framework

Để cải thiện Framework thì chúng ta cần liên tục cải thiện nó từ việc áp dụng vào công việc thực tế của chúng ta. Chúng ta cần nhìn nhận sự không hiệu quả một cách khách quan không mắc phải thiên kiến cá nhân của chúng ta thì chúng ta mới thật sự tìm ra sự không hoàn hảo của Framework trong môi trường của chúng ta.

Tuy nhiên, có một trở ngại ở Việt Nam đấy là việc áp dụng sẽ không được trọn vọn như ở nước ngoài. Vì có thể các sếp hoặc công ty thấy rằng quá rủi ro khi chuyển đổi qua một Framework làm việc. Mình hoàn toàn đồng ý với sự lo lắng từ rủi ro này. Nhưng để vượt qua được và chứng minh rằng nỗi sợ này là không đúng thì chúng ta cần âm thầm bóc tách từng phần trong Framework (Component) để ứng dụng vào công việc. Chúng ta lúc này hãy xem Component như là 1 Hypothesis để chứng minh rằng nó có hiệu quả trong công việc ở góc độ cá nhân chúng ta hay không.

Đã là Hypothesis thì kết quả đầu ra là có thể hiệu quả hoặc không hiệu quả. Kết quả chính là 1 dữ liệu đầu vào cho chúng ta quyết định tiếp rằng vậy nó không hiệu quả ở đâu, chúng ta có thể cải thiện nó tiếp hay không. Nếu sau khi cải thiện nhiều lần thì Hypothesis này thực sự không phù hợp với doanh nghiệp hoặc công việc của chúng ta hiện tại. Chúng ta lại tiếp tục test với các component khác trong Framework. Để hiểu thêm về những gì mình giải thích thì chúng ta cùng tới với ví dụ ngay phía dưới

Job To Be Done Cũng Không Phải Là Framework Hoàn Hảo

Mình sẽ lấy ví dụ mà mình ứng dụng Framework Outcome-Driven Innovation (Internal Job To Be Done). Mình bóc tách component của Framework này ra gồm các phần như sau:

• Phỏng vấn sâu khách hàng định tính

• Khảo sát khách hàng để lượng hóa các nỗi đau của khách hàng

• Tính toán Opportunity Score và đưa ra quyết định từ đấy xem có nên xây dựng solution hay không

• Thiết kế giải pháp dựa trên Job To Be Done

Còn rất nhiều componens nữa nhưng chắc mình sẽ lấy tạm 3 components trong Framework thôi nhé! Sau đấy mình đặt 3 components đấy là 3 Hypothesis khác nhau cần được test ở các môi trường khác nhau khi mình đi làm ở công ty hoặc đi tư vấn.

1. Hypothesis 1 – Phỏng vấn sâu khách hàng định tính

Khi mình apply vào công ty lập tức gây ra sự phản đối mạnh mẽ từ BOD hoặc đội ngũ nhân viên. Vì concept JTBD còn quá mới ở Việt Nam, trong khi đấy mọi người vẫn quen thuộc với concept Design Thinking như Empathy Map, Value Proposition Canvas,…

1.1 Ở Context 1 – Công ty cho phép đi phỏng vấn users nhưng đừng lý thuyết JTBD gì cả

Mình nói rằng mình vẫn sẽ sử dụng các concept cũ mà mọi người quen thuộc, nhưng trong quá trình phỏng vấn mình lái theo framework job to be done thì các đồng nghiệp mình khá bất ngờ vì độ đào sâu vào nỗi đau của khách hàng khác hẳn cách đồng nghiệp mình hỏi bằng Value Proposition Canvas. Vậy là sau khi đem results từ interview users giữa bản đồng nghiệp mình và bản của mình thì các sếp đều thích bản của mình hơn. Như vậy, mình thuyết phục các sếp ở đây là kết quả của việc ứng dụng thay vì giải thích.

1.2 Ở Context 2 – Công ty không cho đi interview users

Mình vẫn tận dụng nguồn lực là bạn bè và người quen của mình để tiến hành interview bằng JTBD. Thậm chí mình bỏ tiền túi của mình ra để đi interview. Tuy nhiên, mình cần phải thu gọn bảng câu hỏi lại hoặc xây dựng Job Map theo 1 cách tinh gọn hơn vì time không cho phép nhiều, nguồn lực không cho phép nhiều.

Từ 2 context và ứng dụng thì cho mình data để test hypothesis 1 như sau. Ở ngữ cảnh được phép và cho nguồn lực thì Framework được ứng dụng khá tốt, chỉ mỗi tội là cần chứng minh results. Còn ở context không có nguồn lực thì phải điều chỉnh về độ dài và phức tạp của Job Map để đáp ứng về mặt thời gian. Từ những dữ kiện đấy có thể accept hypothesis (theo thống kê thì phải có P-Value < 0.05 thì mới được chấp nhận) rằng Component này có thể apply.

2. Hypothesis 4 – Thiết kế giải pháp dựa trên Job To Be Done

2.1 Ở context 1 – Công ty là công ty dạng truyền thống hoặc startup không có concept Experiment

Ở ngữ cảnh này thì khi có data khảo sát và tính toán thì ra make decision khá là nhanh. Vì dựa vào kết quả tính toán được từ Opportunity Score thì team Product có thể biết nên solve pain point nào với nguồn lực công nghệ hiện tại nhưng vẫn đem lại Business Value.

2.2 Ở context 2- Công ty là dạng cần phải chạy Experiment

Ở ngữ cảnh này thì khi thiết kế giải pháp có 1 sự khác biệt đấy là phải brainstorm nhiều solutions khác nhau (Phân kỳ idea) và từ 1 Solution lại phải Brainstorm nhiều Prototypes khác nhau. Như vậy thì ở ta cần phải thiết kế nhiều Treatments cho context này

Từ hai context này thì chúng ta có thể rút ra kết luận Hypothesis này apply khá dễ dàng ở phần quyết định xây dựng giải pháp. Nhưng sẽ phải làm khác ở context thiết kế experiment

Con Người Cũng Không Ai Hoàn Hảo

Nếu một ngày nào đấy bạn phải nghe những lời sỉ nhục như:

• Mày không biết gì về Technical cả, bạn không sinh ra để trở thành người xây dựng Product,đừng làm Product nữa

• Mày không biết Framework này à, sao lạc hậu vs out of date thế

• Mày không tốt nghiệp ở trường điểm, trường top của Việt Nam hoặc thế giới thì nên sao bằng được người A, người B học ở trường nước ngoài danh giá

• Đi làm nhiều năm như thế mà không có thăng tiến gì bằng thằng A / con B học chung trường Đại Học ngày xưa à

…

Nếu bạn nghe thấy những lời sỉ nhục này thì cứ buồn đi. Chúng ta hãy cho bản thân, tâm hồn của chúng ta được phép buồn và không phải đấu tranh với trạng thái cảm xúc bên trong của chúng ta. Nếu buồn xong thì hay nhớ câu này của mình: “

Nếu chúng ta chấp nhận sự không hoàn hảo của chúng ta thì chúng ta sẽ không bao giờ hoàn hảo, nhưng chúng ta cải thiện sự không hoàn hảo bằng một cách nào đấy thì chúng ta sẽ trở nên hoàn hảo hơn so với chính chúng ta ngày hôm qua”

Nếu chúng ta cải thiện sự không hoản hảo thì chúng ta cứ cho phép bản thân mình vui vì chúng ta đã trở nên tiến bộ hơn mỗi ngày. Đừng để sự so sánh của xã hội, sự soi mói sân si của những kẻ không ưa chúng ta làm phải phiền lòng. Vì sự phiền lòng và nỗi buồn sẽ khiến cho tốc độ cải thiện của bạn chậm lại. Nó giống như chúng ta đang phải tự đeo một cục đá lên người chúng ta. Chắc gì những người soi mói bạn, những người được gọi là “con nhà người ta” thực sự hoàn hảo. Hay họ chỉ hoàn hảo trước mặt mọi người và công chúng. Hãy dẹp những thứ đấy qua một bên, hãy đặt North Star Metric của bạn là: “Số lượng kiến thức trong 1 ngày tôi đã học hỏi được từ xã hội và sách vở là bao nhiêu”. Hãy dùng nó là 1 Leading Indicator đễ dẫn dắt cuộc đời bạn đến với 1 cuộc sống tốt hơn thay vì sống một cuộc đời của 1 người khác mong muốn.

Hãy Dành Thời Gian Cho Người Mình Yêu Thương Cũng Chính Là Sự Tiến Tới Hoàn Hảo

Khi chúng ta đang trên con đường tìm kiếm sự không hoàn hảo để cải thiện thì chúng ta cũng vô tình quên mất hai chữ “gia đình”. Vì chúng ta dành quá nhiều thời gian nên chúng ta quên mất rằng sự không hoàn hảo về mặt tinh thần cũng có thể khiến bạn chậm hơn. Nếu chúng ta có gia đình ở bên cạnh làm chỗ dựa thì mình tin rằng động lực để tìm ra sự không hoàn hảo trong công việc của các bạn cũng sẽ nhanh hơn bao giờ hết. Nhất là mấy ông con trai nhé, đừng vì theo đuổi sự nghiệp quá mà quên mất gia đình và người con gái bên cạnh mình nhé!

Kết Lại

Cả Framework và bản thân con người cũng không hoàn hảo. Sự hoàn hảo chỉ được tiệm cận khi chúng ta nhìn thấy được điểm yếu và sự không hoàn hảo. Hãy không ngừng học hỏi và tiến về phía trước vượt qua các thử thách. Mình tin các bạn sẽ tạo ra được những kỳ tích nếu chúng ta tìm thấy nhiều điều không hoàn hảo của cả Framework và bản thân của chúng ta.

Khi bạn tìm ra những thứ không hoàn hảo của Framework và chính con người bạn thì mình tin chắc chắn rằng sẽ rất nhiều công ty tìm tới bạn và mong muốn bạn đầu quân về công ty họ. Hãy đưa ra cho họ 1 lời mời mà các công ty không thể từ chối được Nếu bạn không tin thì hãy thử đi, tuổi trẻ có bao nhiêu mà không dám thử.

Reference

https://vi.wikipedia.org/wiki/S%E1%BB%B1_ho%C3%A0n_h%E1%BA%A3o

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

Địa Chỉ Quán Mình

Cộng Đồng Job To Be Done:

Group Facebook

Group Zalo

Web Job To Be Done Viet Nam

Kênh Youtube

Fanpage Facebook

Link Tải Giáo Án Product

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:

Linkedin của Long

Đăng ký để đọc nhiều bài viết hay hơn!!!