Note: Mình đang migrate block từ Substack sang Ghost, nên nếu bạn nhận được email này nhiều hơn một lần thì hãy bỏ qua nha, chắc là do vấn đề kĩ thuật ấy.

Trong bài viết này, mình muốn diễn tả cách mà problem-solving thường xảy ra trong việc làm sản phẩm, nhằm mục đích:

• Giúp các bạn hình dung rõ ràng hơn về cách một vấn đề làm sản phẩm được giải quyết.
• Giúp các bạn đối chiếu mô hình giải quyết vấn đề này với kinh nghiệm cá nhân. Nếu có điểm khác biệt gì thú vị thì hãy để lại suy nghĩ trong comments nhé. 👇

Mình sẽ sử dụng tư liệu từ một bài báo khoa học xuất bản năm 1973 với tựa đề “A Holistic View of Problem Solving”, và đưa ra các ví dụ liên quan đến việc làm sản phẩm nhất có thể.

Nếu các bạn không có thời gian đọc thì diagram này là tl;dr

🔄 Quy trình giải quyết vấn đề

Chúng ta có thể chia quy trình giải quyết vấn đề (problem-solving process) làm 4 giai đoạn.

1/ Genesis: Bắt đầu nhận thức được vấn đề tồn tại.

Chúng ta sẽ dùng một ví dụ tương đối thực tế:

Bạn là Product Manager cho một startup làm sản phẩm về productivity.

Startup của bạn thời điểm ban đầu đánh mạnh vào phân khúc startup. Tuy nhiên gần đây có một vài tìn hiệu cho thấy rằng thị trường productivity tools cho startup đang dần bão hòa. Có một số tin đồn trong công ty rằng chúng ta sẽ bắt đầu đánh vào segment Enterprise mạnh hơn.

Bạn có thói quen theo dõi data thường xuyên, và bạn nhận thấy rằng trong 3 tháng trở lại đây có một sự giảm sút đáng kể trong tần suất sử dụng sản phẩm.

Trong giai đoạn Genesis (khởi nguyên), chúng ta bắt đầu nhìn nhận rằng có vấn đề tồn tại - có một khoảnh cách giữa trạng thái hiện tại và trạng thái lý tưởng.

2/ Diagnosis: Định nghĩa bài toán cần giải quyết.

Khi đào sâu vào dữ liệu, bạn nhận ra rằng hơn 60% người dùng ngưng sử dụng sản phẩm trong tuần đầu tiên. 💰🤑

Con số này tăng hơn 20% so với khoảng thời gian hơn 3 tháng trước (~40%). Vì người mới vào sử dụng sản phẩm khá ít và sau đó họ rời đi, mức độ sử dụng trung bình cũng giảm.

Bạn biết rằng team Growth đã thay đổi giao diện của onboarding flow vào 3 tháng trước, và bạn nghi ngờ rằng nó có liên quan.

Để hiểu rõ nguồn cơn, bạn đi nói chuyện với một vài công ty đã đăng ký và sau đó bỏ sử dụng sản phẩm để có được sự thấu cảm. Có vẻ 60% này đa phần là các công ty vừa và nhỏ.

Bạn có giả thuyết rằng rằng nguyên nhân chính là do giao diện mới quá khó học và sử dụng, từ những feedback gần đây.

Trong giai đoạn Diagnosis (chuẩn đoán), chúng ta bắt định nghĩa vấn đề và thể hiện những thành phần chính kèm với yếu tố cốt lõi.

3/ Analysis: Phân tích vấn đề.

Khi phân tích sâu hơn về giao diện sản phẩm, bạn nhận ra rằng có rất nhiều khái niệm mới mà sản phẩm giới thiệu cho người dùng và họ không thể hoàn thành một công việc cơ bản nếu không nắm được ít nhất 4 khái niệm tương đối phức tạp.

Designers cũng đã thể hiện chúng trên giao diện một cách không hiển nhiên để che dấu đi sự phức tạp đó. 🙈

Dựa vào kiến thức về tâm lý học hành vi của bản thân, bạn nghĩ rằng trải nghiệm như vậy đang tạo ra khá nhiều cognitive load - ảnh hưởng đến khả năng hiểu và sử dụng sản phẩm. 🤯

Bạn tóm tắt vấn đề lại thành một problem statement như sau:

“New customers have to navigate an unintuitive onboarding flow to learn about too many complex concepts in order to finish their first task and realize the value of our product.”

Trong giai đoạn Analysis (phân tích), chúng ta chia vấn đề thành những phần tử nhỏ và MECE để có thể hiểu được cặn kẽ bài toán phải giải quyết.

4/ Synthesis: Hệ thống hóa và tổng hợp thành giải pháp hoàn chỉnh.

Bạn nghĩ rằng người dùng chỉ cần biết 2 khái niệm cơ bản để trải nghiệm được giá trị của sản phẩm.

Giải pháp của bạn là re-design lại những khái niệm trong sản phẩm và cách mà chúng thể hiện ở onboarding flow để người dùng thực hiện được công việc đầu tiên của họ một cách dễ dàng hơn.

Bạn viết toàn bộ những thông tin trên - vấn đề, ảnh hưởng, problem statement, high-level solution, user flows, diagrams, wireframes - vào PRD.

Trong giai đoạn Synthesis (tổng hợp), chúng ta hệ thống những thông tin lại thành một giải pháp hoàn chỉn. Trong quá trình đó, chúng ta sẽ chỉnh sửa hoặc thêm thắt những yếu tố giúp cho cấu trúc giải pháp được toàn vẹn.

Bạn có thấy câu chuyện này còn thiếu chi tiết gì so với việc làm Product thực tế không? 😛

📂 Phân loại vấn đề và 🏎️ phương tiện giải quyết

Ví dụ mà mình đưa ra phía trên thực chất có hai khía cạnh quan trọng, ngoài quy trình giải quyết vấn đề.

1/ PM là người duy nhất giải quyết vấn đề.

Trong câu chuyện trên, chúng ta đang đặt PM là người duy nhất sử dụng kiến thức và kinh nghiệm cá nhân làm phương tiện để giải quyết vấn đề (individual problem-solving mode). Có những phương tiện khác có thể được vận dụng mà mình sẽ bàn ở phía dưới.