#53 - Khi MVP không chỉ để test giải pháp, mà để khám phá vấn đề

Disclaimer: thực tế làm sản phẩm khá là ngoằn nghèo và có nhiều plot twists, hơn nữa có những quyết định cũng chỉ do intuition chứ không phải logic, nên mọi người thông cảm nếu câu chuyện mình kể có những điểm chưa rõ ràng nhé!

Ranh giới giữa vấn đề và giải pháp

Ai làm sản phẩm cũng từng nghe lời khuyên: phải hiểu rõ vấn đề trước khi nghĩ đến giải pháp. Đó là một nguyên tắc đúng - cho đến khi bạn bắt đầu làm một thứ thật sự mới. Sau vài năm thử nghiệm và xây dựng sản phẩm, mình nhận ra rằng có những lúc, chính việc thử giải pháp lại là cách duy nhất để hiểu sâu hơn về vấn đề.

Frameworks như Double Diamond hay JTBD có thể giúp ta phân biệt rạch ròi giữa “không gian vấn đề” và “không gian giải pháp”. Nhưng trong thực tế, ranh giới đó hiếm khi rõ ràng. Và chính ở khoảng mờ ấy, nhiều phát hiện thú vị nhất thường xuất hiện. Marty Cagan - một nhân vật khá nổi tiếng trong giới Product, cũng có viết về sự nhập nhằng giữa không gian vấn đề và không gian giải pháp.

Trong bài viết này, mình muốn nói về sự nhập nhằng này thông qua một câu chuyện làm sản phẩm mới cho BPM.

Khởi đầu bằng câu chuyện quen thuộc

Để minh hoạ cho điều này, mình muốn kể lại một câu chuyện thật.

Trong những tháng gần đây, tụi mình tại BPM bắt đầu xây dựng một sản phẩm mới dành cho dân làm sản phẩm - với mục tiêu giúp họ vừa thực hành, vừa có thể nói mạch lạc về cách mình làm trong phỏng vấn.

Một lợi thế của tụi mình là đã có sẵn một cộng đồng hơn trăm học viên và cựu học viên - những người luôn muốn phát triển khả năng làm sản phẩm, dù có theo nghề này hay không. Nhờ vậy, tụi mình có thể đi phỏng vấn nhanh hơn mười người để hiểu đâu là nỗi đau thật sự mà họ đang gặp phải.

Và khi tổng hợp lại các buổi phỏng vấn đó, tụi mình nhận ra hai mẫu vấn đề nổi bật - hai hình thái khác nhau của cùng một nỗi đau:

• (Job story 1) Nhóm đầu tiên là các bạn junior hoặc fresher đang vật lộn để bước chân vào ngành Product. Khi họ tốt nghiệp, chuyển ngành, hoặc trở về Việt Nam, họ cảm thấy kỹ năng của mình chưa đủ mạnh để nổi bật giữa một biển ứng viên. Họ đi phỏng vấn, bị từ chối, bị ghost, và ngày càng mất tự tin. Với họ, điều mong muốn rất rõ ràng: làm sao để định vị bản thân đủ khác biệt để có được công việc đầu tiên.
• (Job story 2) Nhóm thứ hai là những bạn đã có một vài năm kinh nghiệm làm sản phẩm, nhưng bắt đầu lo sợ về tương lai. Một bạn nói: “Những thứ em đang làm ở công ty khá replaceable. Một bạn mới lanh hơn vào là làm được.” Cảm giác bị thay thế bởi AI hoặc những người chuyển ngành khiến họ bất an, nhưng cũng thôi thúc họ muốn phát triển năng lực sâu hơn - để không dễ dàng bị thay thế.

Hai nhóm này thể hiện hai hình thái của cùng một nỗi đau: nỗi đau tìm cơ hội và nỗi đau giữ vững vị thế. Khi bàn luận, tụi mình quyết định tập trung vào nhóm đầu tiên trước, vì mức độ cấp thiết của họ rõ ràng hơn - họ cần kết quả ngay bây giờ, không phải “chuẩn bị cho tương lai”. Và đó cũng là lúc tụi mình bắt đầu nghĩ đến MVP đầu tiên.

Khi MVP trở thành công cụ học về vấn đề

Khi đã chọn ra được một vấn đề từ discovery ban đầu, chúng ta đi đến bước triển khai MVP - vốn không phải một khái niệm quá mới. Nhưng việc làm MVP về bản chất không phải để release sản phẩm ra thị trường, mà mục đích để "học" thêm về thực tại của người dùng.

Quay trở lại câu chuyện làm sản phẩm mới để giải quyết vấn đề định vị để nổi bật trong thị trường lao động (Job Story 1), có hai khía cạnh: xây dựng kỹ năng và đóng gói kỹ năng đó cho hiring mangers. Bạn không thể đóng gói thứ không có ở đó, nhưng cũng không thể kể lại tất cả những gì đã xảy ra trong lúc làm. Để thỏa mãn hai khía cạnh này, sản phẩm cần giúp cho người dùng tư duy ở mức độ đủ chi tiết để thực hành làm sản phẩm ngày qua ngày, nhưng cũng đủ mức độ trừu tượng để kể lại những điểm trọng yếu trong trải nghiệm của họ trong thời lượng phỏng vấn.

Sau khi bàn luận, tụi mình đã xác định được một quả solution concept về assumptions & learnings có thể cải thiện chất lượng suy nghĩ cũng như khả năng trình bày của một người làm sản phẩm (mình cũng có nói về nó ở một bài viết khác). Nhờ sự phát triển của các công nghệ LLM, bản MVP đầu tiên chỉ tốn tầm hai tuần, khoảng thời gian xứng đáng bỏ ra để lấy được feedback quý giá. Tuy nhiên không thể nói đến MVP mà không bàn đến giả thuyết cần kiểm chứng. Giả thuyết mà tụi mình đặt ra cho MVP này là nó sẽ giúp ít nhất một nửa học viên của lớp BPM cải thiện kết quả của bài làm final project.

Các bạn học viên lớp BPM là early adopters lý tưởng, bởi vì khóa học đã cung cấp nền tảng kiến thức khá tốt để các bạn tiến xa hơn một bước nữa là cải thiện chất lượng tư duy làm sản phẩm của mình. Nếu MVP giúp tăng chất lượng tư duy, thì chúng sẽ biểu hiện ra ngoài một số khía cạnh để tụi mình đánh giá: các bạn tìm ra được vấn đề thật cỡ nào, cách frame vấn đề sắc bén ra sao, và giữa giải pháp đề ra với vấn đề được chọn có độ chặt chẽ đến mức nào.

Đến lúc này tụi mình vẫn đúng trình tự như trong Double Diamond - di chuyển từ không gian vấn đề qua không gian giải pháp, nhưng dường như ông trời luôn thích trêu ngươi khi con người ta cố gắng đi theo một kế hoạch nào có sẵn.

Sau khi quan sát 2 batch liền thì ..... drum roll please 🥁..... chỉ được 2 bạn học viên khá "mạnh" sử dụng MVP thành công trong final project. Bài làm của nhóm 2 bạn ấy đều có chất lượng tốt hơn mặt bằng chung. Dù kết quả không phải vượt ngoài mong đợi, mình đã thấy được một số điểm sáng để tiếp tục đào sâu.

Để giải thích tại sao 2 bạn đó lại sử dụng MVP được, thì chúng mình nhận thấy một vài tính chất:

• Có kinh nghiệm chuyên môn. Hai bạn có sử dụng MVP đều là những người đã đi làm có chuyên môn ở các ngành nghề khác. Kinh nghiệm chinh chiến trong môi trường công sở giúp cho các bạn không chỉ "đại đại" final project mà còn có băng thông để suy nghĩ cách gia tăng chất lượng bài làm của cả nhóm. Còn những bạn "tấm chiếu mới" hoàn toàn sẽ vật vờ với khối lượng công việc lớn của final project, dẫn đến chuyện không còn tâm trí làm cho nó tốt hơn.
• Nền tảng tư duy tốt. Họ có khả năng logical thinking tốt, và tư duy của họ khá thực tế và "gần mặt đất" (chắc do đi làm bị quật cũng nhiều 🤣). Thế mạnh này giúp các bạn hiểu được concept của sản phẩm tụi mình một cách nhanh chóng hơn để bắt đầu sử dụng (đương nhiên vẫn cần ví dụ + hướng dẫn ban đầu). Còn những bạn chưa tự phản biện được chính suy nghĩ của mình thì cũng không có nhu cầu phải cải thiện tư duy.
• Nền tảng kiến thức sản phẩm tốt. Các bạn đều làm bài tập về nhà đầy đủ và tốt trong suốt quá trình học, trước khi vào final project. Điều này có nghĩa là các bạn đã nắm được kiến thức căn bản trong việc làm sản phẩm, trước khi cố gắng cải thiện tư duy hơn nữa trong lúc thực hành. Còn những bạn chưa nắm được nền tảng thì vấn đề không phải cần cải thiện tư duy mà mà cần luyện tập căn bản nhiều hơn.

Chính MVP đã giúp tụi mình nhìn thấy cấu trúc thật của vấn đề - điều mà discovery ban đầu chưa chạm tới: kinh nghiệm chuyên môn, nền tảng tư duy và kiến thức làm sản phẩm là ba yếu tố cho phép người dùng sẵn sàng để cải thiện chất lượng tư duy làm sản phẩm.

Khi cùng một giải pháp mở ra vấn đề khác

Nếu các bạn để ý sẽ thấy, đa phần các product management frameworks chỉ dừng lại ở việc giúp bạn xác định vấn đề và launch MVP. Sau đó thì gần như không còn hướng dẫn rõ ràng nào về việc phải làm gì tiếp theo. Đây cũng là lúc chúng ta phải vận dụng sự sáng tạo của mình. Khi đó, có thể hướng đi không còn là “làm thêm tính năng mới” hay "cải thiện MVP", mà là dùng chính giải pháp hiện tại để khám phá một không gian vấn đề khác. Đôi khi, cách tốt nhất để mở rộng không gian vấn đề không phải là bỏ giải pháp đi, mà là đặt nó vào một ngữ cảnh mới.

Quay trở lại câu chuyện làm sản phẩm ở trên.

Mình có cân nhắc một vài thứ có thể làm để tiếp tục giải quyết JS1 - "Định vị bản thân để tìm được vị trí entry level làm sản phẩm."

• Liệu chúng ta có thể làm cho solution concept dễ sử dụng hơn, để các bạn học viên dù không phải là người có các tính chất trên vẫn sử dụng thành công?
• Làm cách nào tạo điều kiện để các bạn học viên đã sử dụng sản phẩm trong final project tiếp tục sử dụng sản phẩm ngay cả sau khi khóa học kết thúc?
• Làm thế nào để thiết kế output của sản phẩm để hiring managers thấy ồ wow, từ đó tạo động lực cho những bạn đang có nhu cầu kiếm được job PM đầu tay?

Việc cải thiện trải nghiệm để dẫn dắt những người mới hơn tiếp cận sử dụng MVP vẫn là con đường khả dĩ, nhưng như vậy sẽ cần làm solution concept hiện tại dễ hơn. Mình vẫn có conviction là solution concepts cho vấn đề này phải có một độ khó "vừa đủ" mới cải thiện được tư duy, nên mình không muốn làm nó dễ dàng hơn quá sớm. Tối ưu hóa quá sớm là nguồn gốc của rất nhiều tội lỗi.

Thay vì cố đơn giản hóa solution để giúp nhóm người dùng của JS1 dùng được, mình chọn chuyển sang giải quyết cho tập người dùng của JS2 - "Định vị bản thân để tăng lợi thế cạnh tranh trong tương lai bất định." Lý do quan trọng nhất đó là mình muốn quan sát được cách mà solution concept này sẽ cải thiện được chất lượng suy nghĩ qua thời gian dài, và thời lượng hai tuần của bài cuối khóa là không đủ cho mục đích đó.

Tính chất của bài cuối khóa là ngắn và áp lực. Trong bối cảnh học tập, những ràng buộc đó rất tốt để học viên bước ra ngoài cùng an toàn và tập trung cao độ, tuy nhiên ngữ cảnh sử dụng đó cũng sẽ biến mất khi khóa học kết thúc. Hơn nữa, hai tuần đó các bạn ngoài discovery/delivery còn phải làm những công tác logistics và thuyết trình khác. Điều này khiến cho việc đánh giá độ hiệu quả của solution concept trong thời gian dài khá khó khăn.

Tại sao JS2 lại phù hợp hơn cho mục đích nói trên? Tập người dùng có JS2 là dân đã có một vài năm kinh nghiệm làm sản phẩm, nên họ có sẵn một công việc mà yêu cầu họ phải cải thiện tư duy làm sản phẩm một cách thường xuyên và bền vững, chứ không phải cố gắng làm xong trong 2 tuần để present. Ngoài ra, tập này cũng có sẵn kinh nghiệm chuyên môn, có nền tảng tư duy tốt và có nền tảng kiến thức sản phẩm - ba tính chất nổi bật với những người đã sử dụng MVP thành công. Mình cho rằng việc chuyển qua phục vụ tập có JS2 sẽ cho mình ngữ cảnh sử dụng nghiêm túc và dài hạn, đủ để quan sát được liệu solution concept có giúp họ hay không.

Liệu solution concept làm ra cho JS1 có giải quyết được cho JS2 không? Mình tin rằng câu trả lời là có. Nhóm gặp vấn đề JS2 cần phải đạt được lợi thế cạnh tranh về lâu dài để không bị thay thế. Nói cách khác, họ cần phải trở thành những người làm sản phẩm giỏi hơn. Để làm được điều đó, họ phải nâng cao khả năng tiếp cận giải quyết những bài toán bất định. Ngoài kinh nghiệm ra, thì cốt lõi của khả năng đó chính là chất lượng tư duy - ảnh hưởng không chỉ cách PM frame bài toán mà còn đến thứ mà công ty deliver. Solution concept hiện được thiết kế để giúp cải thiện chất lượng tư duy khi làm sản phẩm, vì vậy mình vẫn tin nó sẽ phục vụ được cho nhóm JS2 này.

Vậy còn lý do cấp thiết mà ban đầu dùng để lựa chọn JS1 thay vì JS2 thì sao? Đây là một đánh đổi mà mình khá cân nhắc, vì nếu giải quyết JS2 thì hiện tại có vẻ người dùng đang không có một deadline rõ ràng để thúc đẩy họ cố gắng giải quyết vấn đề này. Nó giống như một nỗi sợ len lỏi ngày qua ngày về việc bị thay thế, nhưng chưa rõ cảm xúc đó có được khơi gợi đủ thường xuyên để tạo ra động lực thay đổi hành vi hay không. Đây là một đánh đổi đáng có, nếu nó cho phép mình quan sát được solution concept có hiệu quả trong thời gian dài.

Tóm tắt lại: từ discovery ban đầu, tụi mình khám phá ra nhiều vấn đề và cũng chọn ra một trong số đó để tập trung, nhưng có nhiều biến số rất khó để nhìn ra được nếu chỉ thông qua phỏng vấn người dùng. Chúng chỉ lộ diện rõ ràng hơn khi tụi mình launch MVP và quan sát cách mà người dùng tương tác với solution concept. Sau khi quan sát được những biến số đó, tụi mình thấy một bài toán khác mà solution concept có vẻ sẽ giải quyết được tốt. Từ đó, chúng mình quyết định nhảy qua không gian vấn đề mới, nhưng vẫn kế thừa các quan sát được đúc kết khi cố gắng giải quyết vấn đề ban đầu.

Điều mình nhận ra là, khi MVP launch rồi, hiếm khi ta còn đi đúng theo framework - mà phải dựa vào trực giác và niềm tin để điều hướng. Mình kể câu chuyện này không phải để khuyến khích nhảy từ vấn đề này sang vấn đề khác, mà để nói rằng khi thực tế không còn khớp với bản đồ, đôi khi điều đúng đắn nhất là dừng lại và quan sát lại địa hình. Đừng chỉ làm theo frameworks, mà hãy tạo ra con đường riêng của mình.

Bằng việc pivot qua giải quyết JS2: tụi mình đã tìm được power user đầu tiên - một bạn junior PM có một vài năm kinh nghiệm, nền tảng tư duy và kỹ năng làm sản phẩm đều tốt. Bạn đang sử dụng MVP của tụi mình đã gần được hai tháng để cải thiện chất lượng cho một công việc hiện tại. Mình đã có cơ hội quan sát cách bạn tương tác với solution concept trong một ngữ cảnh sử dụng nghiêm túc, và kiểm chứng được một số thứ, kèm theo một quả feedback ấm lòng:

"bữa a hỏi e là viết ra assumption thì có thấy clear khum ó, e nghĩ là lúc chỉ viết xuống assumption thì chưa, nhưng việc map xuống assumption somehow giống như vẽ ra 1 cái mental concept về product. sau khi nghe lại interview của user và viết lại transcript thì e dần validate đc những assumption đó trong đầu, tự dưng có cảm giác nhìn 1 bức tranh bị out nét nó dần dần có đường nét rõ ràng hơn vậy á có cảm giác đang tiến gần với chứ "clear" rùi 🤣"

Mình không hề ảo tưởng rằng đây là thành công - chỉ mới có một power user mà thôi. Là một người làm sản phẩm, bản năng của mình luôn là nghĩ đến các giả thuyết hay rủi ro cần kiểm chứng: có nhiều người giống power users hay không, liệu họ sử dụng thành công có phải do mình tận tình support không, nó có scale lên được hay không. Nhưng cũng do may mắn làm ở một vài startups, mình đã dần học cách trân trọng vào những điểm sáng như vậy trong màn đêm u tối. Làm sản phẩm mới hay startup giống như cố gắng thay đổi thực tại. Dù chúng ta nhận thức rõ khả năng thất bại rất cao, đôi khi chúng ta phải tim vào một vài dấu hiệu tích cực để tiếp tục cố gắng. Có được một power user nghiêm túc sử dụng sản phẩm của bạn là một điều đáng mừng, vì nó cho thấy tiềm năng giúp đỡ được ít nhất là một người thay đổi hành vi và cuộc sống của họ. Khi bạn đi từ 0-1, trước khi đến 1 triệu đô thì bạn phải đến được 1 người dùng đầu tiên cái đã.

Kết: Bản đồ là mô hình, thực tại là địa hình

Khi bắt tay làm MVP, tụi mình nghĩ rằng mình đang “giải” vấn đề. Nhưng hoá ra, điều quý giá hơn là những gì nó giúp mình thấy được nhiều hơn: ai thực sự nhìn thấy giá trị của sản phẩm, điều kiện nào khiến họ dùng được, và khi nào cùng một giải pháp lại soi ra một vấn đề hoàn toàn khác. Những điều này không thể hiện trong phỏng vấn, cũng không nằm trong framework nào - chúng chỉ lộ ra khi giải pháp va chạm với thực tế, khi người dùng phản hồi và buộc ta phải quan sát lại chính cách mình đang nghĩ.

Từ đó, mình nhận ra rằng không phải lúc nào ta cũng có thể hiểu rõ vấn đề trước khi hành động. Đôi khi, chính việc làm mới giúp ta hiểu vấn đề sâu hơn. Giải pháp, trong trường hợp này, không còn là đích đến, mà là công cụ để học, để quan sát, để tinh chỉnh lại cách ta nhìn thế giới. Frameworks và mô hình vẫn quan trọng - chúng cho ta điểm khởi đầu, ngôn ngữ, và hướng đi - nhưng địa hình thật mới dạy ta cách đi. Mình tin rằng làm sản phẩm tốt không chỉ đi theo bản đồ, họ liên tục vẽ lại nó mỗi lần chạm vào thực tế, mỗi lần thấy vấn đề rõ hơn nhờ chính những giải pháp mà họ dám thử.

Cuối cùng, có lẽ discovery thật sự không diễn ra trước khi ta làm, mà trong khi ta đang làm.