Xin chào mọi người, lại là mình (Thomas) đây 👋! Hiện tại tụi mình đang tuyển sinh cho Batch 3 của khóa Breaking into Product Management, khai giảng vào tháng 8. Nếu các bạn có hứng thú, hoặc biết ai đó có hứng thú, thì hãy nhanh tay dành chỗ nhé (14/20 "chỗ ngồi" đã có chủ).

Trong một bài viết trước, mình có viết về Do Things That Don't Scale. Tuy nhiên nội dung của bài viết đó khá là high-level. Trong bài viết này, mình sẽ đi sâu hơn vào một câu chuyện thực tế để các bạn có những abstractions cụ thể hơn về chủ đề này.

Bài này mình viết cùng với Nam Nguyễn - Co-Founder cùng với mình tại A Little Better. Hãy đọc thêm về hành trình làm sản phẩm của chúng mình với A Little Better ở nhé.

Startups & Unscalable Quiz

Tụi mình đã chuẩn bị một bài quiz nho nhỏ, để các bạn sau khi đọc xong thì có thể quay lại làm thử để có thể nhớ được những chi tiết khái niệm trong bài viết tốt hơn. Các bạn đọc lần đầu có thể skip phần này rồi quay lại sau nhé!

Chúng ta học tốt hơn khi chủ động cố gắng nhớ lại (thông qua việc làm quiz), hơn chỉ là đọc một cách thụ động!

Unscalable Work là gì?

Mình cũng không biết dịch "Things That Don't Scale" như nào ngoài cụm từ "Những Việc Chẳng Thể Nào Scale Được". Tuy nhiên, nghĩ đến chuyện phải viết cụm từ này ra hơn chục lần trong bài viết này thì cũng bủn rủn tay chân. Vì vậy, mình xin phép sử dụng cụm từ tiếng anh có cùng ngữ nghĩa - Unscalable Work, để tiết kiệm cả sức lực của mình lẫn trí lực của độc giả.

Nghe hơi trừu tượng phải không? Để mình cho các bạn một ví dụ cụ thể nhé.

Cách tụi mình làm Unscalable Work

Cho những bạn nào chưa biết thì tụi mình (mình và Nam) có cùng xây dựng 1 sản phẩm thực hành biết ơn bền vững để cải thiện sức khỏe tâm lý, gọi là A Little Optimism.

Sau khi đã chọn ra được một vấn đề để giải quyết: thực hành biết ơn bền vững cho A Little Optimism (sản phẩm đầu tiên của A Little Better), mentor của tụi mình nói rằng việc thực hành biết ơn một mình có vẻ không hiệu quả, bởi vì những đối tượng mà tụi mình nhắm tới hầu như đều đã tự thực hành, nhưng họ không tạo được thành thói quen biết ơn thường xuyên.

Anh mentor đề xuất rằng tụi mình tiếp cận giải pháp theo hướng multi-player, vì yếu tố cộng đồng đã được khoa học chứng minh có ảnh hưởng tích cực với việc giải quyết các vấn đề tâm lý. Và thế là tụi mình đã bắt đầu triển khai giải pháp để kiểm chứng giả định: "Việc cho và nhận được sự giúp đỡ từ người khác sẽ giúp người dùng thực hành biết ơn bền vững hơn".

Giải pháp đầu tiên mà mình nghĩ tới, cũng là giải pháp mà chắc hẳn nhiều bạn Junior PMs sẽ chọn lựa, là làm tính năng kết nối giữa hai người và cho phép họ thực hành biết ơn cùng nhau. Tuy nhiên, giải pháp này có một vài vấn đề:

• (1) Độ phức tạp của solution cao. Sau khi hình dung ra sơ đồ mô hình dữ liệu (Conceptual Data Models) và Workflow cơ bản (mấy công cụ trong Product Delivery tụi mình thường nhắc tới trong BPM), giải pháp này có thể phải code để điều chỉnh matching những người dùng hiệu quả cho những vấn đề được nhắc dưới đây.
• (2) Giải pháp cần user base lớn để kiểm chứng được giả định. Tụi mình định nghĩa Activation của sản phẩm là khi người dùng thực hành biết ơn lần đầu tiên. Giả sử có 6 người đang sử dụng sản phẩm và đã match với nhau rồi, thì người dùng thứ 7 sẽ phải chờ đến khi có người thứ 8 đăng ký để có thể bắt đầu sử dụng. Chắc chúng ta có thể đồng ý rằng không ai muốn người dùng phải chờ quá lâu để trải nghiệm Aha Moment ((khoảnh khắc người dùng nhận ra giá trị sản phẩm).
• (3) Nếu một trong hai người được match với nhau không sử dụng, thì người còn lại sẽ không nhận được quà. Nếu người dùng còn lại cũng không tiếp tục sử dụng, tụi mình sẽ không biết là họ không xài do assumption của tụi mình không đúng, hay là do lý do khác.

Khi nhìn vào mục tiêu hiện tại đó là kiểm chứng giả định trên, thì tụi mình cần phải biết được liệu người dùng có thể thực hành bền vững nếu họ cho đi và nhận được sự giúp đỡ từ người khác hay không. Để làm được điều đó, tụi mình phải đảm bảo rằng mỗi người dùng đều có một người dùng khác hỗ trợ họ xuyên suốt quá trình sử dụng sản phẩm.