hình ảnh

Jason’s Newsletter

Posted on by admin

Xin chào mọi người,

Tuần này của mọi người thế nào? Mình mới bay vào Sài Gòn từ thứ 5 để chuẩn bị cho công việc mới. Trộm vía, cuối cùng hôm nay cũng đã chọn được nhà và lên cho mọi người chiếc post này <3.

Trong một lần đi ăn với bạn gái mình trước khi vào Sài Gòn, câu chuyện về bạn nhân viên Learning Design mà bạn gái mình mới tuyển đã khiến mình chột dạ. Cô ấy kể về cách đồng nghiệp mới của cô ấy gần như tôn sùng một framework học thuật nào đó, và kiên quyết áp dụng nó vào mọi tài liệu giảng dạy – bất chấp thực tế là giáo viên và học viên đang phải loay hoay thích nghi.

Cứ mỗi lần có một tài liệu giảng dạy mới cần được thiết kế, bạn ấy lại lôi ra cái framework được học từ một khóa online nào đó rồi áp dụng một cách… cứng đờ như robot. Bạn gái mình nhăn mặt khi kể: “Những thứ trong framework đó không sai, nhưng để áp dụng được cho cả người giảng dạy và học viên thì cần phải linh hoạt chứ! Đằng này bạn ấy tôn sùng cả framework lẫn người dạy nó như thể đó là thánh kinh vậy.”

Nghe đến đây, mình bỗng thấy một phiên bản quá khứ của chính mình hiện ra trước mắt – cái thời mình mới học và tìm hiểu về Growth Hack. Mình còn nhớ như in cảm giác phấn khích khi mới khám phá ra Growth Hacking. Tràn ngập template, framework, và một chút kiêu ngạo khi nghĩ rằng mình nắm trong tay những bí kíp mà không phải ai cũng biết. Giờ nghĩ lại, mình chính là hiện thân của câu thành ngữ:

Khi bạn chỉ có trong tay một cái búa, mọi vấn đề đều trông giống như một chiếc đinh – Bernard M. Baruch

Hồi đó, mình đọc sách nhiều đến mức thuộc nằm lòng những framework đình đám (AARRR, HEART, SIGNAL, Job to be done, etc…). Case study nào cũng nhai đi nhai lại. Mình tự hào với “kho vũ khí framework” của mình đến mức nào ư? Đến mức nghĩ mình có thể giải quyết mọi bài toán tăng trưởng chỉ bằng cách mở sách ra và làm theo từng bước một. Và niềm tự hào đó tồn tại… cho đến ngày mình tham gia buổi phỏng vấn vị trí Growth Manager với anh Founder của một startup Fintech.

Chuẩn bị một bài thuyết trình hoành tráng với đầy đủ mọi chiến lược dựa trên framework AARRR (Acquisition, Activation, Retention, Referral, Revenue) kèm theo hàng tá chiến thuật growth hack “học từ sách”. Trong đầu mình lúc đó chỉ có một suy nghĩ: “Anh Founder này sẽ phải trầm trồ với kiến thức của mình mất!”

Nhưng rồi, sau khi mình thao thao bất tuyệt suốt 20 phút, anh ấy chỉ nhìn mình với ánh mắt nửa thương hại, nửa bối rối, rồi đặt ra một câu hỏi:

Anh ấy nói tiếp: “Tất cả những framework mà em vừa trình bày, anh đều biết. Anh cũng đọc rất nhiều sách về Growth Hacking rồi. Những tactics mà em đưa ra, hiện tại team cũng đã và đang làm, nhưng kết quả thì chẳng có gì nổi bật cả”

Câu hỏi đó khiến não tôi đơ cứng như máy tính bị treo. Giây phút “đơ” đó đã kéo dài đến mức… mình gần như có thể nghe thấy tiếng kim đồng hồ tích tắc trong phòng phỏng vấn. Mình không biết phải trả lời thế nào vì khi đó, mình chưa có đủ trải nghiệm để hiểu rằng: không phải cứ áp dụng input A sẽ tự động tạo ra output B như một công thức toán học đơn giản. Thực tế phức tạp hơn công thức trong sách rất, rất nhiều.

Bẫy của người “mới vào nghề”

Lúc mình bước ra khỏi buổi phỏng vấn đó, cảm giác hụt hẫng không thể nào tả xiết. Tự ái nghề nghiệp bị tổn thương, nhưng mình biết rằng anh Founder đã đúng. Mình đã dành quá nhiều thời gian để học những gì người khác đã làm mà quên mất bản chất của công việc là phải giải quyết vấn đề thực tế.

Mình gọi đây là “căn bệnh Framework” – triệu chứng phổ biến của những người mới vào nghề Product Management (và nhiều ngành khác).

Hình dung thế này nhé: Bạn vừa tốt nghiệp một khóa Product Management đắt tiền. Bạn nắm trong tay vài chục framework nổi tiếng, từ Double Diamond, Jobs-to-be-Done, đến OKRs, HEART, JTBD, và cả RICE prioritization. Bạn có thể thao thao bất tuyệt về UI/UX, về customer development, về agile scrum… Bạn cảm thấy mình đã sẵn sàng chinh phục thế giới product.

Rồi bạn bước vào công ty đầu tiên, và bất ngờ thay, không ai làm theo đúng những gì sách vở dạy cả! Scrum master kiêm luôn developer, PM kiêm cả customer support, designer vẽ UI mà không có thời gian nghiên cứu user journey, và CEO thì liên tục “pivot” chiến lược sản phẩm mỗi hai tuần.

Phản ứng tự nhiên của bạn là gì? “Mọi người đang làm sai hết rồi! Để tôi chỉ cho các bạn cách làm đúng framework nào!”

Nghe quen không? Mình đã từng như vậy đấy.

Từ tín đồ Framework đến người giải quyết vấn đề

Sau buổi phỏng vấn đó (tất nhiên là mình không nhận được offer), mình đã dành cả tuần để suy nghĩ về câu hỏi của anh ấy. Và đó cũng là lúc mình bắt đầu nhận ra rằng, trong ngành Product Management, có một khoảng cách khổng lồ giữa lý thuyết và thực tế mà không cuốn sách nào nhắc đến. Và câu trả lời bắt đầu hiện ra:

Nó giống như bản đồ vậy. Bản đồ giúp bạn định hướng, nhưng không phải lúc nào cũng phản ánh đúng địa hình thực tế. Đôi khi bạn cần bỏ bản đồ xuống và nhìn xung quanh để tìm đường đi riêng.

Mình bắt đầu một vai trò mới tại một Start up nhỏ, không phải với vai trò Growth Manager như tham vọng ban đầu, mà chỉ là Product Owner cho một tính năng nhỏ. Tại đây, mình học được bài học đầu tiên và quan trọng nhất: Lắng nghe.

Thay vì vội vàng áp dụng AARRR framework, mình lắng nghe team engineer nói về những khó khăn kỹ thuật. Thay vì áp đặt journey map “chuẩn sách” theo kiểu bánh vẽ, mình dành thời gian nói chuyện với khách hàng thực sự. Và điều kỳ diệu xảy ra – tôi bắt đầu hiểu vấn đề thực sự của sản phẩm, không phải qua lăng kính của framework, mà qua con mắt của những người dùng nó hàng ngày.

Khi nào thì Framework có ích và khi nào nó là rào cản?

Framework như AARRR (Acquisition, Activation, Retention, Referral, Revenue) rất hữu ích khi bạn cần một cái nhìn tổng quan. Nó giúp bạn không bỏ sót yếu tố nào trong chiến lược. Nhưng vấn đề nảy sinh khi bạn cố gắng ép mọi thứ vào framework đó, ngay cả khi thực tế đang kêu gào một cách tiếp cận khác.

Mình nhớ một dự án mà team mình phụ trách tính năng giới thiệu bạn bè (referral). Theo framework, đây là bước quan trọng để tăng trưởng new user. (Chắc hẳn mọi người đều biết đến Case study tăng trưởng nổi tiếng của Dropbox nhờ Referral mà phải không?) Team mình thiết kế một hệ thống phức tạp với mã giới thiệu, reward points, notification… đúng như “best practice” trong sách.

Ba tháng sau khi ra mắt, tính năng này chỉ đóng góp 0.5% user mới. Một thất bại.

Thay vì cố gắng “fix” framework, mình quyết định quay lại với câu hỏi cơ bản: “Tại sao người dùng của chúng ta không giới thiệu bạn bè?” Qua phỏng vấn, mình phát hiện ra rằng vấn đề không phải ở cơ chế giới thiệu, mà là ở giá trị sản phẩm. Người dùng không thấy đủ tự tin để giới thiệu vì chính họ cũng chưa thấy giá trị rõ ràng.

Thay vì tập trung vào “R” (Referral) trong AARRR, mình và team quay lại với “A” (Activation) và “R” thứ hai (Retention). Và khi giá trị sản phẩm được cải thiện, tỷ lệ giới thiệu tự nhiên tăng lên mà không cần quá nhiều cơ chế phức tạp.

Những sai lầm mình mắc phải khi làm PM mà bạn nên tránh

Khi bạn không thích nghi, bạn sẽ bị đào thải

Mình muốn chia sẻ một ví dụ cụ thể từ dự án gần đây nhất. Team mình đang xây dựng một feature nhỏ về kiểm soát chi tiêu nhắm vào nhóm người dùng trẻ. Theo framework truyền thống về phát triển sản phẩm, sẽ cần:

  1. Nghiên cứu thị trường

  2. Phỏng vấn người dùng

  3. Xây dựng persona

  4. Tạo wireframe

  5. Prototype

  6. Usability testing

  7. Phát hành MVP

Sounds perfect, right? Team đã làm đúng từng bước một, dành 2 tháng để nghiên cứu, 1 tháng để thiết kế, và 3 tháng để phát triển. MVP ra mắt với đầy đủ 5 tính năng chính mà nghiên cứu chỉ ra rằng người dùng “cần”.

Kết quả? Chỉ 10% người dùng truy cập ứng dụng sau 1 tuần. Tỷ lệ chuyển đổi? Thảm hại.

Vấn đề là gì? Mình và team đã quá tập trung vào việc làm đúng framework mà quên mất yếu tố thời gian và cạnh tranh. Trong 6 tháng khi team mình “làm đúng quy trình”, thị trường đã thay đổi, 2 đối thủ đã ra mắt sản phẩm tương tự, và hành vi người dùng đã dịch chuyển.

Giờ đây, chúng mình làm khác đi. Thay vì theo đúng trình tự, team mình:

  • Validate nhu cầu từ target segment (tập khách hàng mục tiêu)

  • Phát hành sớm với chỉ 1 tính năng cốt lõi nhất

  • Thu thập phản hồi thực tế (không phải từ nghiên cứu giả định)

  • Cải tiến nhanh trong vòng 1-2 tuần

  • Lặp lại quy trình

Kết quả? Tỷ lệ giữ chân người dùng tăng 30% vì họ cảm giác được lắng nghe và đóng góp cho sản phẩm. Chúng mình không thông minh hơn, đơn giản là team đã thích nghi mà thôi.

Cái bẫy của những con số

RICE (Reach, Impact, Confidence, Effort) – một framework tuyệt vời để ưu tiên các tính năng sản phẩm, đúng không? Tính điểm cho từng yếu tố, cộng lại, và ta có thứ tự ưu tiên rõ ràng.

Mình đã áp dụng RICE một cách nghiêm túc trong dự án đầu tiên của mình. Mọi tính năng đều được tính toán cẩn thận. Kết quả? Mình đề xuất ưu tiên phát triển tính năng “chia sẻ lên mạng xã hội” vì nó có điểm RICE cao nhất.

Nhưng khi đem ý tưởng này trình bày với team, một developer senior đã hỏi một câu đơn giản: “Impact này dựa trên đánh giá gì?”

Mình trả lời: “Impact này dựa trên việc các đối thủ đều có nó và lượng user sử dụng rất lớn !”

Anh ấy phản bác: “Nhưng chúng ta có data nào cho thấy user thực sự muốn chia sẻ sản phẩm của chúng ta lên mạng xã hội không? Hay đây chỉ là giả định của chúng ta?”

Và thế là toàn bộ bảng tính RICE mình được đem ra ngoài bãi rác. Mình đã quên mất một điều căn bản: Data chỉ tốt khi input của nó đáng tin cậy – “Garbage in, garbage out”

Đây là một số sai lầm phổ biến mà mình (và có lẽ nhiều junior PM khác) thường mắc phải:

  1. Tin rằng mọi vấn đề đều có một giải pháp đúng duy nhất: Thực tế, trong Product Management, hầu hết các quyết định đều là sự đánh đổi (trade-off). Không có giải pháp hoàn hảo, chỉ có giải pháp phù hợp nhất với bối cảnh hiện tại.

  2. Áp dụng framework một cách cứng nhắc: Framework chỉ là công cụ, không phải là mục tiêu. Đừng ngại điều chỉnh, thay đổi, thậm chí là kết hợp nhiều framework để tạo ra phương pháp phù hợp nhất với dự án của bạn.

  3. Quá phụ thuộc vào data: Data rất quan trọng, nhưng không phải là tất cả. Đôi khi, trực giác và kinh nghiệm của bạn cũng có giá trị. Như Reid Hoffman (nhà sáng lập LinkedIn) đã từng nói: “Nếu bạn không thấy xấu hổ với phiên bản đầu tiên của sản phẩm, thì bạn đã ra mắt quá muộn.”

  4. Quên mất yếu tố con người: Product Management không chỉ là về sản phẩm, mà còn là về con người – người dùng, đồng nghiệp, stakeholders. Không framework nào dạy bạn cách xử lý một designer đang có ngày tồi tệ, hay cách thuyết phục một CEO bướng bỉnh.

Khi nào thì framework vẫn cần thiết?

Bài viết này không khuyến khích bạn vứt bỏ mọi framework. Ngược lại, framework vẫn cực kỳ cần thiết trong những trường hợp sau:

  1. Khi bạn mới bắt đầu: Framework giúp bạn định hướng khi chưa có nhiều kinh nghiệm.

  2. Khi giao tiếp với team: Framework cung cấp ngôn ngữ chung để mọi người hiểu nhau.

  3. Khi cần nhìn tổng quan: Framework giúp đảm bảo bạn không bỏ sót yếu tố quan trọng nào.

  4. Khi đánh giá và đo lường: Framework cung cấp cấu trúc cho việc đánh giá hiệu suất.

Vấn đề không phải là có sử dụng framework hay không, mà là biết khi nào nên tuân theo nó và khi nào nên linh hoạt điều chỉnh.

Tiếp cận và áp dụng Framework một cách healthy

Đây là những lưu ý của mình trước khi đọc và học các framework cũng như case study bất kì mà mọi người có thể áp dụng

  1. Hiểu trước, áp dụng sau: Trước khi nghĩ đến việc áp dụng bất kỳ framework nào, hãy đảm bảo bạn thực sự hiểu vấn đề bạn đang cố gắng giải quyết. Đôi khi, vấn đề bạn nghĩ mình đang giải quyết không phải là vấn đề thực sự

  2. Học framework, nhưng đừng tôn thờ nó: Framework là điểm khởi đầu tốt, nhưng đừng để nó giới hạn tư duy của bạn.

  3. Tập trung vào vấn đề, không phải giải pháp: Nhiều PM mới vào nghề quá tập trung vào feature mà quên đi vấn đề cốt lõi cần giải quyết.

  4. Điều chỉnh cho phù hợp: Không framework nào là hoàn hảo cho mọi tình huống. Hãy sẵn sàng điều chỉnh, thay đổi, thậm chí là bỏ qua một số phần của framework nếu chúng không phù hợp với bối cảnh của bạn.

  5. Chấp nhận sự không chắc chắn: Product Management không phải là toán học theo kiểu 1+1 = 2. Đôi khi, bạn phải đưa ra quyết định dựa trên thông tin không đầy đủ. Và đó là lúc trực giác và kinh nghiệm của bạn phát huy tác dụng.

Share

Kết luận: Từ “Hammer” đến “Toolbox”

Quay lại câu thành ngữ mình đề cập ở đầu bài: “Khi bạn chỉ có trong tay một cái búa, mọi vấn đề đều trông giống như một cái đinh.”

Giờ đây, mình không còn coi mình là người cầm búa nữa. Mình muốn trở thành người thợ có cả một hộp công cụ đa dạng – búa, cưa, tuốc-nơ-vít, kìm – và biết khi nào nên sử dụng công cụ nào.

Framework chỉ là một công cụ trong hộp đồ nghề của Product Manager. Đôi khi bạn cần nó, đôi khi không. Nghệ thuật nằm ở chỗ biết khi nào dùng và khi nào cần sáng tạo giải pháp riêng.

Với các bạn PM mới vào nghề, hãy học thật nhiều framework, template, best practice. Nhưng đừng quên rằng cuối ngày, công việc của chúng ta là giải quyết vấn đề thực sự của người dùng và doanh nghiệp, không phải áp dụng hoàn hảo một framework nào đó.

Và có lẽ, đó chính là điều khiến công việc này thú vị đến vậy. Không có công thức chắc chắn, chỉ có những nguyên tắc hướng dẫn và rất nhiều không gian để sáng tạo.

Có lẽ câu trả lời tốt nhất cho câu hỏi của anh Founder khi đó là: “Điều khiến sản phẩm của chúng ta khác biệt không phải là framework chúng ta áp dụng, mà là cách chúng ta thích nghi và điều chỉnh framework đó để giải quyết vấn đề cụ thể của người dùng theo cách mà không ai khác làm được.”

Và đó, chính là bài học quý giá nhất mà tôi học được trong hành trình Product Management của mình.

Mời Jason cốc bạc sỉu

P/S: Nếu bạn đang phải đối mặt với tình huống tương tự, hãy nhớ rằng không có gì sai khi thừa nhận framework không phải lúc nào cũng có câu trả lời. Đôi khi, câu trả lời tốt nhất đến từ việc hiểu rõ vấn đề và can đảm thử nghiệm giải pháp mới.