#19 - Từ ý tưởng đến thực sự kiếm được tiền từ khóa học
Đây là cách tụi mình đã làm một khóa học có doanh thu tốt và được nhiều người đăng ký/theo dõi. Đây không phải cách làm duy nhất, nhưng đó là cách tụi mình đã làm.

Tụi mình đang tuyển sinh batch 4 của khóa "Breaking into Product Management". Nếu các bạn muốn:
- Ngành Product có phù hợp với mình không.
- Muốn nắm được kiến thức nền tảng của việc làm Product.
- Muốn vận hành kiến thức làm Product bài bản vào công việc hiện tại.
Thì hãy 👉 bấm vào đây để xem thêm thông tin nhé!
Series "Làm sản phẩm bằng khóa học dạy làm sản phẩm"
- #13 - Làm sản phẩm bằng khóa học dạy làm sản phẩm (phần 1). Bài viết này kể sơ lược về đối tượng người dùng ban đầu tụi mình khai phá, cách tụi mình đánh giá vấn đề cũng như khía cạnh kinh doanh.
- #19 - Làm sản phẩm bằng khóa học dạy làm sản phẩm (phần 2): 0-1 👈 bạn đang đọc bài này. Bài viết này kể về hành trình từ lúc trước khi mình làm BPM cho đến khi chạy xong những khóa đầu tiên với thành công nhất định. Mình cũng viết về những giả thuyết, rủi ro cũng như cách tụi mình de-risk chúng.
- #31 - Làm sản phẩm bằng khóa học dạy làm sản phẩm (phần 3): Tìm kiếm điểm sáng. Bài viết này nói về cách tụi mình tìm ra những điểm đòn bẫy để tăng chất lượng làm bài của học viên trong dự án cuối khóa của BPM bằng việc quan sát các điểm sáng và tìm cách nhân rộng chúng lên.
- #33 - Làm sản phẩm bằng khóa học dạy làm sản phẩm (phần 4): đôi khi quyết định hay nhất là quyết định không làm. Bài viết này nói về cách mà tụi mình đã "xém" scale BPM từ mô hình cohort-based lên mô hình self-paced, nhưng cuối cùng đã quyết định không làm như vậy.
- #36 - Làm sản phẩm bằng khóa học dạy làm sản phẩm (phần 5): một kèo B2B training deal khó nhằn. Bài viết này nói về một cơ hội làm B2B training mà tụi mình bắt gặp, nhưng cuối cùng đã không chốt được deal. Câu chuyện này
- #45 - Làm sản phẩm bằng khóa học dạy làm sản phẩm (phần 6): community bet. Bài viết này nói về cách tụi mình vận hành community, và một canh bạc mà tụi mình đang trộm vía là thấy có kết quả tích cực.
Note: Bài này khá dài (~6500 từ), nên nếu các bạn đang bận thì hãy bookmark hoặc take note lại link này để đọc khi có thời gian nhé. Đây là một bài nhạc các bạn có thể mở nghe lấy dũng khí tinh thần để đọc cái bài dài ngoằn này.
Giới thiệu
Bài này sẽ không hẳn nối tiếp bài viết Làm sản phẩm bằng khóa học dạy làm sản phẩm (phần 1), mà nó miêu tả cùng một bức tranh ở độ phân giải cao hơn (nhiều chi tiết hơn và tổng thể hơn).
Đây là cách tụi mình đã làm một khóa học có doanh thu hơn trăm triệu và được nhiều người đăng ký/theo dõi. Tuy nhiên, mình muốn nhấn mạnh rằng kết quả đó cũng không hoàn toàn dựa vào năng lực thuần túy, vì có những yếu tố may mắn hoặc được tích lũy qua nhiều năm đột nhiên trở nên hữu ích đúng lúc, nhưng nhìn chung thì tụi mình cảm thấy rất thỏa mãn với giá trị mà khóa học mang lại cho học viên.
Quan trọng hơn nữa, mình xem khóa học này như một sản phẩm, và cách mình triển khai khóa học cũng giống như cách mình làm sản phẩm. Trong bài viết này, mình sẽ chia sẻ về hành trình của mình một cách chi tiết nhất, để các bạn có thêm một câu chuyện thực tế trong hành trang của mình.
Những điều kiện để mình nghĩ đến việc mở khóa học

Ý tưởng mở khóa học không đùng một phát đến với mình trong một chiều ngồi uống trà nhìn ra cửa sổ, cũng như không phải do ông bà tổ tiên báo mộng mách bảo 🤣 , mà nó là kết quả của quá trình tham gia hoạt động trong lãnh vực Product nhiều năm liền.
- (1) - Kinh nghiệm làm sản phẩm Global/B2B/SaaS/Startup. Sự nghiệp của mình may mắn khi bắt đầu ở các công ty B2B SaaS, và được tiếp xúc với môi trường và khách hàng quốc tế. Tuy rằng mình không có ai mentor khi bắt đầu, nhưng may mắn thay cũng có một số thành quả và câu chuyện để chia sẻ. Kể cả khi thất bại thì mình cũng học được rất nhiều từ những trải nghiệm đó. Từ công ty startup 30 người cho đến khi nó scale lên 300 người, từ VC-backed cho đến bootstrapped, từ early-stage startup cho đến scale-up, mình đã có cơ hội trải nghiệm và làm trong nhiều môi trường khác nhau.
- (2) - Kinh nghiệm mentor thành công cho những bạn muốn và đang làm sản phẩm. Lúc làm ở Katalon thì mình có may mắn mentor được một vài bạn từ những ngành lân cận chuyển sang Product Management. Một phần là việc mentorship cũng tương đối "bắt buộc" vì mình tuyển người vào thì cũng muốn họ làm được việc để đỡ workload cho mình. Một phần nữa là việc mentorship cũng là cách mình "cho đi" khi đã "nhận được" những may mắn trong sự nghiệp. Có những bạn mình mentor bây giờ đã trở thành các Product Manager thực thụ trong những công ty global, nên mình cũng cảm thấy vui vì được là một phần trong hành trình của các bạn.
- (3) - Khả năng giải thích và thấu cảm. Trong quá trình mentor thì mình nhận ra mình có thể nắm được một bạn đang hiểu về một vấn đề cụ thể đến đâu, và xây dựng được cầu nối về mặt khái niệm để các bạn có thể hiểu được trọn vẹn hơn trong ngữ cảnh đó (mình tạm gọi đây là intellectual empathy).
- (4) - Chuyển dịch thị trường khiến nhiều người cân nhắc làm Product. Chợt một vài năm đổ lại đây, nhu cầu chuyển ngành sang Product càng trở nên rõ ràng. Nhiều bạn reach out đến mình và hỏi về ngành Product, cũng như các câu lạc bộ đại học và các chương trình sinh viên ngày càng nhắc đến chữ Product. Có lẽ đại dịch Covid đã tạo ra áp lực kinh tế, khiến cho nhiều người cân nhắc chuyển việc. Product đang trên đà trở thành trend hot tiếp theo, sau khi thị trường làm Data đã dần có vẻ trở nên bão hòa. Những yếu tố đó làm cho nhiều người cân nhắc chuyển qua làm Product nhiều hơn.
Nếu mình mở khóa học sớm hơn thì chưa chắc có nhiều thị trường cho sản phẩm này. Nếu sớm hơn thì mình chưa tích lũy đủ kinh nghiệm mentor, khả năng truyền đạt cũng như quan trọng nhất là kinh nghiệm làm sản phẩm trong thực chiến.
Thời điểm là yếu tố rất quan trọng khi tung một sản phẩm ra thị trường, và có rất nhiều chỉ dấu hội tụ lại mà khiến cho mình quyết định "bây giờ" (why now) chính là thời điểm phù hợp để mở khóa học.
Conviction, không chỉ là co-founders

Trước Dương và Nam - hai người co-founders hiện tại của khóa học, thì mình có tìm kiếm đến một người anh. Người anh này có một cộng đồng Tech ở Việt Nam rất lớn, và cũng đã giảng dạy chuyên môn của mình hơn 10 năm. Mình có đi pitch ý tưởng mở khóa học, thì ảnh cũng rất ủng hộ và ngỏ lời mời hợp tác. Nhưng sau đó mình trăn trở và nhận ra rằng mình cần co-founders cũng là những người có conviction về việc làm sản phẩm như mình.
Mình có viết về conviction ở đây. Nếu bạn đọc bài viết đó chắc sẽ hiểu hơn tại sao conviction đối với mình dường như là điều kiện tiên quyết để bắt đầu làm sản phẩm/startups. Có rất nhiều công ty ăn nên làm ra mà không cần conviction. Mình không đánh giá công ty không có conviction là không tốt, nhưng mình tin rằng nếu muốn làm một thứ gì đó có ý nghĩa và có impact, thì cần có conviction.
Co-founder Dương
Sau đó thì mình vào Holistics (công ty hiện tại), và vô tình gặp được Dương - Product Manager tại Holistics. Dương có một kênh Youtube tên BoringPPl và muốn chuyển hướng từ một kênh dạy lập trình Python trở thành một kênh giúp mọi người Break Into Tech dễ hơn bằng cách cung cấp góc nhìn của nhà tuyển dụng (hiring managers) ở các mảng Product, Data, etc.
Dương mời mình quay tập podcast đầu tiên về chủ đề trên vì mình đã có kinh nghiệm phỏng vấn khá nhiều bạn Associate Product Managers và Product Managers cho Katalon và Holistics. Trong quá trình trao đổi để chuẩn bị làm podcast thì tình cờ mình nhắc đến việc đang tính mở khóa học. Dường như ý tưởng đó nó "clicked" với Dương một cách khá tự nhiên. Sau đó tụi mình có một buổi thảo luận riêng về khóa học và mọi thứ được chốt rất nhanh.

Một yếu tố quan trọng nữa khiến cho mình chọn found khóa học với Dương đó là Dương đã có kinh nghiệm mở khóa học dạy Python và dạy Data từ nhiều năm trước. Đồng thời Dương cũng có khả năng go-to-market (GTM) sản phẩm rất căng, nhờ vào thứ mà mình gọi là Archetypal Empathy.
Bộ kỹ năng của Dương rất bổ trợ cho mình, vì mình mình chủ yếu giỏi GTM những thứ khá niche chứ đánh mass không quá tốt.
Co-founder Nam
Mình đã biết Nam được một vài năm từ hồi làm ở Katalon. Nam là một người rất nỗ lực, kỹ tính và đầy hoài bão. Cho ai chưa biết thì mình với Nam cũng cùng nhau found ra một sản phẩm cải thiện sức khỏe tâm lý. Mình đã viết nhiều về thứ mình và Nam làm cùng nhau, nên sẽ không viết ở đây nữa.
Nam có background engineering, làm BA cũng như làm Product nên conviction của Nam đó là người làm Product phải nắm được nền tảng về Product Delivery vững chắc để có thể cân nhắc trade-offs và tối ưu hoa phần giải pháp.
Đây cũng là bộ skillset của Nam mà bổ trợ cho mình rất giỏi, vì mình không có background làm BA nên chưa từng có môi trường mà ép phải tập trung vào chi tiết solution như Nam.
Market Validation

Sau khi mình gặp Dương, và kết nối Dương với Nam, thì ba đứa mình quyết định triển khai ý tưởng làm khóa học này.
Những rủi ro về thị trường trong làm sản phẩm
Trong bài viết (mà đối với mình thì khá kinh điển) có tựa đề Excuse me, is there a problem?, tác giả có đề cập đến những yếu tố nên cân nhắc trước khi làm sản phẩm/startup. Ý niệm này đã ảnh hưởng đến cách mình làm sản phẩm rất nhiều Bước đầu tiên chính là liệt kê ra những giả định trong đầu và xem giả định nào rủi ro nhất:
- (1) Người dùng có vấn đề này không? Cần ít nhất một vài dữ liệu định tính để cho bạn tự tin là có người có vấn đề này trước khi đầu tư quá nhiều công sức vào việc xây dựng sản phẩm.
- Đối với BPM, mình đã thấy tận mắt các trường hợp cố gắng chuyển ngành, nghiêm túc tìm kiếm công việc làm sản phẩm nhưng gặp nhiều rào cản, nên mình có niềm tin rằng đây là một vấn đề thật sự tồn tại.
- (2) Có đủ người dùng có cùng vấn đề này không? Điều này ảnh hưởng đến việc mô hình kinh doanh có khả thi không, vì thường bạn chỉ capture được một phần nhỏ của thị trường, nên nếu thị trường không đủ lớn thì sẽ rất khó để doanh nghiệp có thể có khách hàng.
- Đối với BPM, đây là một rủi ro vào thuở đó mà mình đã nhìn nhận được. Dù đã thấy tận mắt vài trường hợp, yếu tố "đủ" hay không đối với mình vẫn còn khá bất định. Đây cũng là một rủi ro mà tụi mình đã có plan giải để giải quyết.
- (3) Họ có biết họ có vấn đề này không? Ví dụ tiêu biểu như vấn đề về security. Khi doanh nghiệp không tập trung vào security thì họ sẽ dễ dàng bị hacked, thông tin khách hàng bị lộ, danh tiếng bị hủy hoại. Tuy nhiên vẫn có rất nhiều doanh nghiệp không nghĩ nó là vấn đề. Bạn không thể ép khách hàng thừa nhận rằng mình có vấn đề được. Nếu họ không biết họ có vấn đề thì họ sẽ không đi tìm giải pháp, cũng như không quan tâm khi bạn trình bày giải pháp.
- Đối với BPM, yếu tố này không phải là rủi ro, vì họ không thể nào không biết mình đang có vấn đề khi họ không có được công việc họ mong muốn.
- (4) Họ có budget để giải quyết vấn đề này không? Sức khỏe tâm lý quan trọng với nhiều người, và nhiều người cũng nhận thức rằng đó là vấn đề, nhưng lại rất ít người chịu bỏ tiền ra để giải quyết (ít nhất là ở Việt Nam). Việc người ta có hành vi bỏ tiền ra mua một thứ gì đó để giải quyết vấn đề của họ cũng ảnh hưởng rất nhiều đến tiềm năng của mô hình kinh doanh.
- Đối với BPM, khi tham chiếu từ các hành vi mua sắm trên thị trường, thì thấy rằng nhiều bạn sẵn sàng bỏ tiền để đi học khóa học, và đây cũng là một hình thái dịch vụ không còn quá xa lạ nữa.
- (5) Họ có muốn mua từ bọn mình không? Có ai đang độc chiếm thị trường chưa, hay thị trường này đã bão hòa chưa? Có lý do gì để họ chọn mua sản phẩm của bạn mà không phải của bên khác không? Đây là những vấn đề liên quan đến lợi thế cạnh tranh của công ty.
- Đối với BPM, tụi mình không phải là KOL ở trong ngành, nhưng với kinh nghiệm profile tích lũy của tụi mình thì đây không phải là một rủi ro quá lớn.
Validate những giả định về thị trường rủi ro nhất
Khi map những giả định trong đầu ra theo hai chiều không gian Uncertainty và Importance thì nó nhìn như này.

Một trong những câu hỏi mình thường nhận được đó là làm sao đánh giá được độ quan trọng của một giả định. Câu hỏi mình thường dùng là: "Nếu giả định này sai thì nó ảnh hưởng đến sự thành công của sản phẩm như thế nào?" để đối chiếu giữa các giả định với nhau.
Để đánh giá độ bất định, chúng ta sẽ hỏi câu hỏi "Độ tự tin của mình đối với việc giả định này đúng là bao nhiêu?". Kinh nghiệm, dữ liệu định tính hay định lượng đều sẽ được thể hiện qua mức độ tự tin của bạn (nhớ thành thật với bản thân nhé).
Nếu bạn cảm thấy không có cơ sở để đánh giá chúng thì nên nói chuyện với người dùng nhiều hơn, và dành nhiều thời gian làm practitioner trong ngành để dần xây dựng được sense về về những thứ đang diễn ra trong ngành nghề hay thị trường này. Cái sense đó sẽ giúp cho các bạn cân chỉnh độ quan trọng và độ bất định của các giả định trong đầu.
Quay trở lại câu chuyện làm khóa học, mình đã nói chuyện với một số bạn rất muốn làm PM, nên mình đánh giá rủi ro họ không thật sự có vấn đề hay họ không nhận thức được họ có vấn đề đó là tương đối thấp.
Việc đội ngũ mentors đã có kinh nghiệm làm việc ở các công ty startup, B2B SaaS global và có nhiều năm kinh nghiệm trong nghề giảm thiểu đáng kể rủi ro thị trường sẽ không tin tưởng và mua từ tụi mình. Còn một yếu tố nữa là hiện tại chưa có nhiều khóa học dạy làm Product, nên rủi ro về cạnh tranh cũng thấp.
Có rất nhiều khóa UI/UX hay Data trên thị trường và có rất nhiều người sẵn sàng bỏ tiền ra học, điều đó đã giảm cho tụi mình rủi ro về việc người ta không có budget trong việc phát triển bản thân và thay đổi nghề nghiệp.
Rủi ro lớn nhất mà mình quan ngại đó là cần nhiều bằng chứng hơn để biết có nhu cầu đủ lớn ngoài thị trường hay không. Ngành Product cũng là một ngành còn chưa hẳn là trendy, nên việc có nhiều người muốn break into ngành này hay không là một rủi ro tụi mình chưa có sự tự tin nhất định.
Đây là lúc mà tụi mình xài một chút kỹ thuật định tính. Tụi mình đã dùng tập podcast mà Dương nhờ mình quay để soft-launch nhẹ nhàng, tụi mình không trực tiếp sell khóa học mà chỉ bảo là nếu bạn nào có nhu cầu Breaking into PM thì hãy đăng ký để nhận được một cái roadmap miễn phí do tụi mình tạo ra.

Và sau khi launch chỉ trong vòng một tuần thì tụi mình đã nhận được hơn 40 người đăng ký nhận roadmap. "Ồ, có vẻ là có nhiều người có vấn đề này đấy!"
Và tụi mình đã khai phá và giảm đi độ bất định của những rủi ro lớn nhất.

Product Validation

Rủi ro trong việc triển khai solution làm khóa học
Sau khi giảm độ bất định của những gia đỉnh rủi ro nhất về mặt thị trường, chúng mình chuyển sang phần phát triển giải pháp.
- (1) Tụi mình có thể package expertise thành một hệ thống có trật tự để giảng dạy. Rủi ro này là về việc tụi mình có thể articulate ra thế giới quan về việc làm sản phẩm rõ ràng tới đâu, và sắp xếp lại thế giới quan đó thành một hệ thống lý luận đến mức nào.
- (2) Tụi mình có thể deliver khóa học (bài giảng, exercises, assignments) một cách hiệu quả. Việc tụi mình có thể articulate được thế giới quan và sắp xếp lại thành hệ thống lý luận vẫn để lại rủi ro về cách thức truyền đạt, mức năng lượng và kỹ năng giảng dạy để khiến cho học viên quan tâm chú ý nghe giảng.
- (3) Tụi mình có thể tận hưởng việc dạy học. Việc tụi mình có tận hưởng giảng dạy trong thời gian dài, từ tháng này qua tháng nọ hay không cũng là một rủi ro ảnh hưởng đến vận hành khóa học. Khi bạn giảng dạy, mức năng lượng của bạn sẽ được thể hiện rất rõ ràng và ảnh hưởng đến cách học viên tiếp nhận. Vì vậy một người không tận hưởng việc giảng dạy nữa sẽ rất khó để có thể làm việc đó một cách hiệu quả. Tuy nhiên giả định này tụi mình chỉ có thể kiểm chứng qua một thời gian dài dạy học thôi.

(1) Tụi mình có thể package expertise thành một hệ thống có trật tự để giảng dạy
Đối với giả định này thì cách tụi mình kiểm chứng chính là thông qua việc ngồi tạo ra curriculum cho khóa học. Lúc đầu tụi mình tính dạy 50% Product Discovery và 50% Product Delivery, tuy nhiên sau khi bàn bạc thì đi đến kết luận rằng đa số những kỹ năng mà mọi người cần để bắt đầu một công việc làm sản phẩm sẽ là về phần Product Delivery.
Các công ty cũng có xu hướng tuyển những người có khả năng delivery sản phẩm vào vị trí junior để các bạn senior hơn làm những công việc mang tính bất định hơn như discovery. Tụi mình nhận thấy PM mà không có khả năng delivery thường dễ mâu thuẫn và bất đồng với developers, do họ không nói cùng ngôn ngữ và không thấu cảm được việc deliver sản phẩm nó phức tạp đến như thế nào.
Vì thệ nên tụi mình quyết định tập trung nhiều về Product Delivery. Từ high-level artifacts như ORD và Workflow, đến low-level artifacts như activity diagram hay user stories, đều là những thứ nên biết để một người làm Product có thể thật sự nắm rõ về solution space. Đôi khi đánh giá ngầm một solution bằng những artifacts trên giúp cho chúng ta nhận ra mức efforts và độ phức tạp có thể lớn đến mức nào. Đó là tiền để PM có thể đơn giản hóa solution nhưng vẫn dựa trên những nguyên lý nền tảng và thực tế.
Nhưng nếu chỉ dạy Product Delivery thì không khác gì khóa học BA cả, vả lại tụi mình vẫn muốn đào tạo những con người có tư duy làm Product chứ không chỉ thuần execute hay làm requirements. Làm sản phẩm thì phải biết phân biệt giữa problem space và solution space, phải biết frame vấn đề, phải biết phỏng vấn người dùng và trích xuất insights. Và đó cũng là những kỹ năng mà tụi mình dạy trong khóa học.
Tụi mình quyết định không dạy về strategy/vision, với niềm tin rằng đó là những high-level work mà bạn không thể nào làm nếu như chưa nắm vững được kiến thức ở các tầng cơ bản hơn. Theo một cách hề hước, thì đây cũng là là một quyết định mang tính chiến lược, vì nó hoạch định thứ tụi mình KHÔNG tập trung, và ảnh hưởng đến hình thái nội dung cũng như cách tụi mình tương tác với học viên.
(2) Tụi mình có thể deliver khóa học (bài giảng, exercises, assignments) một cách hiệu quả
Khi có được outline của khóa học (40% product discovery, 60% product delivery), tụi mình tiến hành "Usability Testing" để kiểm tra giả định thứ hai.
Mình để trong ngoặc kép vì nó không giống với cách mà bình thường mọi người hay dùng để usability test một sản phẩm phần mềm thông thường, nhưng về mặt outcome thì nó tương tự - để hiểu và thay đổi dựa trên trải nghiệm và tương tác tác thật của người dùng với sản phẩm.
Tụi mình chuẩn bị nội dung cụ thể buổi đầu tiên của khóa học, sau đó nhờ bạn bè của tụi mình tham dự để nghe giảng và đánh giá. Sau đó tụi mình nhận feedback và lại tổ chức giảng dạy thử buổi thứ hai của khóa học. Ngoài feedback từ những người bạn tham gia buổi dạy thử, tụi mình còn tự feedback cho lẫn nhau.
Mình nhớ cụ thể là lúc đó đã mượn được văn phòng của Holistics vào cuối tuần để mời một số bạn bè (đa số là của Nam) mà có nhu cầu học hiểu hơn về quản lý sản phẩm đến cho buổi dạy thử. Việc quan sát được phản ứng của các bạn trong cùng một không gian đã cho tụi mình nhiều feedback sâu hơn về cách tụi mình truyền tải nội dung cũng như nội hàm của kiến thức.


Những feedbacks tụi mình note lại
Thứ tụi mình học được sau khi làm "Usability Testing" cho khóa học đó là: dù có một số góc cạnh cần phải mài giũa để mượt mà hơn, tụi mình vẫn có thể deliver được thông điệp mà các bạn cảm thấy có giá trị. Rủi ro thứ hai đã được giảm thiểu đi đáng kể.
Tuy nhiên, chỉ khi sau khi launch xong batch 1 của khóa học thì tụi mình mới đúc kết nhiều hơn về khía cạnh delivery này. Batch 1 của khóa học là một bản MVP - là một phương tiện để get validated learnings, và với mình thì mục tiêu của bản MVP đầu tiên đó là để kiểm chứng được giả thuyết về cái cốt lõi của khóa học thật sự tạo ra giá trị, dù cho trải nghiệm học còn nhiều điểm đứt gãy. Tụi mình muốn xem khi mọi người tiếp nhận kiến thức và áp dụng chúng thì các bạn có cảm thấy hiểu thêm về việc làm sản phẩm không. Tụi mình collect feedback sau mỗi buổi học để đánh giá khía cạnh này.
Chính vì vậy mà về mặt trình bày (slides, cấu trúc giữa các buổi học, không gian cho các bạn làm bài tập, etc) tụi mình còn nhiều thiếu sót ở batch 1. Đây là một lựa chọn có chủ đích vì cái cốt lõi phải tồn tại và có giá trị trước thì tối ưu hóa phần trình bày mới hợp lý. Nếu tụi ham làm quá nhiều thứ ở bản MVP thì sẽ không kiểm chứng được gì cả, vì efforts sẽ không đủ tập trung vào một khía cạnh cụ thể nào để có thể có được validated learnings.
Một trong những cách mà tụi mình biết học viên đã hiểu thêm về việc làm sản phẩm đó là thông qua việc họ nhận ra có thể không phù hợp với ngành này. Có một perception mà nhiều người lầm tưởng đó là làm Product chủ yếu là về tìm hiểu người dùng, thị trường, vấn đề. Nhưng thực tế mà nói, PM không thể là người chỉ tay năm ngón, mà phải nắm vững cả problem space và solution space. Bạn cũng không thể lựa chọn công ty mà có những người đủ giỏi deliver để bạn chỉ làm discovery, cũng như lựa chọn bắt đầu công việc Product mà chỉ hoàn toàn làm discovery (còn nếu bạn chọn được thì mình rất hoan hỷ chúc mừng 😄). Vì vậy product delivery chính là thứ mà nhiều người họ không expect là phải làm khi làm product.
Một bạn học viên khác cũng nhận ra rằng mình không phù hợp với ngành này, nhưng là vì bạn không thích và cũng không giỏi nói chuyện để tìm hiểu nhu của người dùng. Bạn tự reflect và thấy có vẻ thiên hướng và điểm mạnh của bản thân sẽ phù hợp với việc làm Project Manager hơn.

Chặng đường tiếp theo

Hiện tại tụi mình rất hài lòng với chất lượng giảng dạy và nội dung của batch 2. Batch này tụi mình đã tập trung hoàn toàn vào việc delivery, rút gọn phần bài giảng những chi tiết không chặt chẽ, rãi những điểm kiểm tra bất ngờ trong bài giảng để mọi người chú ý tập trung, tạo không gian để các bạn làm bài tập và được chấm bài ngay trong lớp.
Vậy khóa học này sẽ phát triển như thế nào trong tương lai? Tụi mình sẽ tiếp tục cải thiện chất lượng giảng dạy và tối ưu hóa vận hành để mang lại trải nghiệm tốt nhất cho học viên.
Trong tương lai mình còn có nhiều dự định khác liên quan đến việc giúp cho những bạn đang làm Product có thể tăng tốc kỹ năng, trình độ, sự nghiệp để phục vụ đam mê làm sản phẩm của mình. Khóa học là một giải pháp, nhưng mình nghĩ nó chưa phải giải pháp tốt nhất.
Mình đang ấp ủ một dự án xây dựng cộng đồng và nền tảng deliberate practice cho Product Builders để mọi người có thể tự luyện tập, nhận được feedback chi tiết, chia sẻ hành trình của bản thân và lắng nghe chia sẻ của những người khác có cùng đam mê làm sản phẩm.
Nếu các bạn hứng thú với dự án này, thì phiên bản Light của khóa học Breaking into PM là mô hình cộng đồng có tính phí mình đang thử nghiệm. Dù gọi là phiên bản Light nhưng value proposition của nó nhiều về cộng đồng và tương tác với tụi mình hơn là khóa học. Tụi mình thường xuyên thảo luận chuyên sâu và chia sẻ kinh nghiệm trong những buổi office hours cũng như trên Discord. Nếu các bạn muốn làm early adopters thì hãy đăng ký nhé!
Lời kết
Mình không muốn tạo ấn tượng rằng ở mỗi bước trong quá trình làm sản phẩm mình đều biết chính xác phải làm gì. Có những suy nghĩ và quyết định đến từ intuition, sau đó mình mới map chúng lại về những kiến thức và frameworks để đối chiếu xem có thật sự hợp lý không. Đôi khi những quyết định và suy nghĩ đó dẫn đến kết quả không mong muốn, và mình lại học từ chúng rất nhiều.
Ngay cả khi đã làm sản phẩm gần 7-8 năm, intuition đôi khi vẫn sai. Nhận thấy mình sai và có can đảm thay đổi suy nghĩ cũng là một phần không thể thiếu trong việc làm sản phẩm. Chỉ thông qua việc tương tác với thực tại chúng ta mới có thể rèn giũa thế giới quan để nó tiệm cận hơn với thực tế, rồi từ đó đưa ra những quyết định đúng đắng hơn.
Hy vọng thông qua bài viết này bạn có thêm một câu chuyện làm sản phẩm trong hành trang của mình, để sau này có thể lấy ra tham khảo khi tự làm sản phẩm riêng, hoặc trích xuất những patterns mà bạn thấy hữu dụng từ bài viết này vào công việc hằng ngày. Nếu có ai đó làm được như vậy thì coi như bài viết của mình đã thành công.