Sản phẩm càng ít tính năng thì càng hữu dụng – Feature Audit giúp Product Manager rethink sản phẩm của mình

Mình từng mua 1 món đồ này và mình thừa nhận mình hiếm khi sử dụng:

Đây là dao đa năng Thụy Sĩ thường được sử dụng trong quân đội. Mình từng nghĩ nó sẽ tiện lắm cho tới khi mình mua và phát hiện hầu rất hiếm sử dụng, thậm chí lúc dùng cũng cảm thấy khó khăn. Một phần chắc do thiết kế hơi phúc tạp của nó, một phần chắc mình cũng không nằm trong nhóm Target Users của nhà sản xuất.

Tới đây mình nghĩ, làm một sản phẩm với ít tính năng nhưng thật là xuất sắc thì vẫn tốt hơn là một sản phẩm nhiều tính năng nhưng ít tính năng nào hiệu quả (mình không có ý chê dao Thụy Sĩ nhé, chỉ là mình không thấy dễ dùng với chính mình thôi).

Mình tổng kết lại trong nhiều năm làm việc dưới vai trò PM của sản phẩm công nghệ chắc mình build cũng cả vài chục tính năng lên ứng dụng. Một số thì đến bây giờ vẫn work hiệu quả, người dùng vẫn thích nó, một số thì đã kill, một số ít thì bị coi là của nợ (legacy) chờ PM khác giải quyết (hốt shit giùm).

Tuy vậy nhưng mình sẽ coi đó như là những bài học kinh nghiệm và cố gắng tăng xác suất làm đúng nhất có thể trong tương lai. Có một framework bạn sẽ được biết trong bài này gọi là Feature Audit.

Bạn nên sử dụng framework này khoảng 2-3 lần trong năm, hoặc khi bạn cần áp dụng mỗi khi cần review lại cho sản phẩm nhằm đánh giá hiện trạng sử dụng của từng tính năng.

Hiểu đơn giản, bạn có 2 trục, một trục thể hiện mức độ phổ biến về số lượng người sử dụng, một trục thể hiện mức độ tần suất sử dụng. Mình tạm gọi trục ngang là Adoption và trục dọc là Frequency.

Giờ là lúc bạn list ra những Feature đang có trong sản phẩm của bạn. Ví dụ, mình ngày xưa quản lý và phát triển cho Zalo Call, giả sử mình lấy tính năng này để làm audit cho bạn dễ hình dung cách áp dụng framework nhé (lưu ý con số chỉ mang tính tham khảo vì đã được làm khác đi so với thực tế vì lí do cần bảo mật dữ liệu).

Zalo Call được chia làm 3 tính năng chính:

Audio Call: 2 người gọi thoại cho nhau

Video Call: 2 người gọi video call cho nhau

Group Call: >=3 người gọi cho nhau trong cùng một phiên (thường là video hoặc có khi tất cả đều tắt camera)

Dựa trên framework, mình tính toán số lượng người dùng sử dụng Audio Call, Video Call và Group Call trên toàn app trong vòng 1 tháng (tức A30). Mình thấy tỉ lệ Adoption của Audio đã là 90%, tức cứ 100 người dùng app Zalo trong tháng thì có đến 90 người đã thực hiện gọi Audio. Tiếp tục tần suất sử dụng mình thường chọn một trong 2 cách tính:

Tần suất sử dụng đo bằng số ngày active sử dùng trong một khoảng thời gian nhất định

Tần suất sử dụng đo bằng số lần active sử dụng trong một khoảng thời gian nhất định

Trường hợp mình chọn cách 1, mình sẽ check xem trong 30 ngày thì trung bình User gọi Audio sẽ active bao nhiêu ngày, có người 2 ngày, có người 15 ngày, có người cả 30 ngày (tức ngày nào cũng make call) thì Average giả sử = 15. Tức người dùng Audio Call họ sẽ gọi active trung bình 15 ngày trong 1 tháng (chà, nghĩa là cứ cách ngày là gọi ấy).

Cách 2 thì mình tính bằng số lần gọi trung bình, vd anh A gọi 5 cuộc trong tháng, anh B gọi 10 cuộc, anh C gọi 21 cuộc thì Average của cả 3 anh sẽ là 12 cuộc. Tức người dùng Audio Call họ sẽ gọi trung bình 12 cuộc trong 1 tháng.

Cách 1 thì dễ dùng hơn vì min = 0 và max = 30 (giả sử bạn chọn tham chiếu khung thời gian là 30 ngày). Cứ gần tới con số 30 là Frequency cao, dễ hiểu. Cách 2 thì vẫn áp dụng được nhưng bạn cần clear một cái benchmark rõ ràng để xác đinh tần suất như vậy là nhiều hay ít. Giả sử trung bình 1 người Việt Nam trong tháng họ chỉ gọi cho bạn bè / khách hàng / đồng nghiệp / gia đình (tất cả các mối quan hệ) đâu đó được 15 cuộc thôi mà đã có đến 12/15 cuộc đấy là dùng tính năng Audio Call thì mình nghĩ feature này đang làm rất tốt rồi.

Giả sử mình mapping 3 features này thì ra được kết quả như bên dưới:

Tới đây bạn dễ dàng nhận thấy Audio Call đang nằm ở khu vực có rất nhiều người đang dùng với tần suất sử dụng cao, Video Call thì thì cũng nhiều người dùng đấy nhưng tần suất chưa phải thường xuyên lắm. Còn Group Call thì đang ít người dùng và tần suất sử dụng khá thấp. Điều này cũng make sense khi bạn hiểu về User Behavior đối với 3 feature này.

Tuy nhiên cuộc đời chắc không màu hường như thế, giả sử mình không phải PM của Zalo mà là PM của Microsoft Teams (bạn biết Teams chứ? Họ mới vượt mặt Slack đấy). Mình giả định mình đang quản lý Call trên Teams và khi thực hiện Audit thì thấy kết quả như thế này.

Nghĩa là tính năng Group Call được hầu hết User dùng Teams sử dụng nhưng tần suất còn khiêm tốn. Tính năng Video Call cũng cũng kha khá nhiều người sử dụng nhưng tần suất ít hơn so với Group Call. Tính năng Audio Call thì rất ít người mà tần suất cũng ít luôn. Sau khi audit xong và ra kết quả như vậy, lúc này bạn cần xác định xem nên làm gì tiếp theo với nó đúng không? Chúng ta tới Phần 2 ☟

Những Feature nằm ở khu vực Tần suất sử dụng thấp và cũng ít Người dùng thì bị coi là Shit 💩 . Feature nào nằm ở góc phải trên cùng thì đây được xem là Ngôi sao, đại diện cho giá trị lõi của sản phẩm. 2 khu còn lại được coi là Cây thông và Trực thăng, bạn hãy cùng xem hình bên dưới:

Ok, quay trở lại với ví dụ trên thì:

Với Zalo:

Audio Call là Ngôi sao, Video Call là Cây thông, còn Group Call là shit :((

Với Microsoft Teams:

Audio Call là shit, Video Call với Group Call với Cây thông

Lí do chọn 4 hình tượng này thì:

Ngôi sao đại diện cho giá trị của sản phẩm, phản ánh lõi (chắc đó là lí do chúng ta có khái niệm gọi là North Star Metric)

Cây thông đại diện cho những thứ ít xảy ra nhưng được nhiều người hưởng ứng, hình tượng này khiến bạn liên tưởng tới Giáng sinh, một năm có 1 lần thôi nhưng ai cũng hào hứng tham gia

Trực thăng đại diện cho những cái tần suất cao (bay liên tục ấy) nhưng ít ai có đủ khả năng làm điều ấy

Cuối cùng là Shit, thôi cái này mình cũng không muốn bàn sâu thêm, bạn chỉ cần gọi nó là Shit được rồi

Sếp mình thỉnh thoảng sẽ chê mỗi khi mình làm feature nào đấy chưa ngon lắm: “Feature chú làm như c*t vậy!”. Chắc ý của sếp được lấy cảm hứng từ framework này.

Câu hỏi đặt ra là ta sẽ làm gì với feature 4 nhóm đấy sau khi mapping vào xong? Với mỗi loại, chúng ta có 4 lựa chọn khác nhau:

Về cơ bản thì tính năng được xếp vào Ngôi sao đã nhiều người dùng và được thường xuyên sử dụng rồi, nhiệm vụ của bạn thông thường sẽ là duy trì nó và bổ sung thêm một số cải thiện sao cho đã tốt nay càng tốt hơn.

Cách này được gọi là Deliberate Improvement.

Bạn thậm chí không cần improve thì nó vẫn tốt, vẫn sống khỏe (và giúp cho product của bạn sống khỏe). Nhưng có một yếu tố sẽ thay đổi theo thời gian mà theo mình bạn cần để ý, đó là User Expectation. Một tính năng được xây dựng như vậy đối với người dùng trong thời điểm hiện tại có thể là good, khiến họ happy và liên tục sử dụng vì bạn đã đáp ứng được mong đợi của họ (thậm chí hơn) nhưng bạn không thể chắn chắn trong tương lai người dùng vẫn sẽ happy với điều ấy. Có thể họ đã nâng tiêu chuẩn lên, do vậy nếu bạn không theo dõi, bỏ lơ việc thực hiện “Deliberate Improvement”, dẫn tới feature ngôi sao đấy sẽ không còn tỏa sáng trong product của bạn nữa.

Ví dụ với Audio Call, mình và team liên tục tìm cách cải thiện chất lượng cuộc gọi, giảm tiếng ồn, khiến âm thanh nghe tự nhiên hơn, cải thiện design, làm cho nó ngày càng dễ dùng hơn, make call tiện hơn, vân vân.

Tuy nhiên khi cải thiện các Star feature này cũng cần chú ý, high risk high return, bạn làm tốt không sao, lỡ vô tình làm hỏng coi như tự bắn vào chân mình. Do vậy nên áp dụng một số cách tiếp cận như test thử nghiệm trên một tập người dùng nhỏ, nếu thấy phản hồi tốt thì mới mở all, không thì nên bình tĩnh hít thở mà cải tiến.

Cái này nhiều người dùng nhưng tần suất ít, mục tiêu của bạn là tìm cách tăng mức độ sử dụng của feature đó lên.

Khoan! Trước hết bạn cần tự đặt câu hỏi liệu có thực sự khả thi để có thể tăng frequency không? Có những tính năng mà theo mình, về mặt nhu cầu người dùng, bạn khó có thể khiến họ dùng nhiều hơn được. Giả sử bạn đang own tính năng thanh toán hóa đơn điện trên một ứng dụng Payment, bạn khó có thể ép người dùng thanh toán hóa đơn nhiều hơn 1 lần trong tháng. Trong trường hợp này, mình sẽ tìm cách tạo thêm nhiều usecase có liên quan tới tính năng hoặc tăng giá trị bổ sung vào tính năng. Trong bán hàng gọi là cross-sell và up-sell. Nếu đã xác định không thể sell được tính năng đó nhiều lần hơn cho người dùng thì tìm cách cross hoặc up thêm value vào.

Ví dụ với Video Call, do đặc tính của nhu cầu nên người dùng thường chỉ gọi vào cuối tuần hoặc buổi tối vào một số ngày nhất định trong tuần. Xác định khó tăng tần suất cho tính năng này nên mình và team bổ sung một số chức năng trong cuộc gọi như thả Emoji, Sticker, Chụp ảnh hay đơn giản là tăng cường chất lượng hình ảnh trở nên rõ nét hơn, chuyển động các frame mượt mà hơn, lọc noise cho cuộc gọi, vân vân. Mục tiêu nhằm khiến User có trải nghiệm tốt nhất trong cuộc gọi.

Quay lại với trường hợp feature có thể thực hiện Frequency Improvement. Hãy nghĩ tới Hook Model của Nir Eyal.

Mô hình này gồm 4 bước theo thứ tự: Trigger (Kích hoạt) → Action (Hành động) → Reward (Phần thưởng) → Investment (Đầu tư) → và lặp lại. Mục tiêu của Hook nhằm khiến người dùng của bạn của khả năng quay trở lại nhiều hơn và sử dụng tính năng, sản phẩm của bạn nhiều hơn. Dĩ nhiên điều này còn tùy thuộc vào việc bạn “Trigger” và tạo ra “Reward” hấp dẫn người dùng tới mức nào.

Có 3 cuốn sách mình highly recommend bạn nên tìm đọc thêm để hiểu cách con người nghiện một cái gì đấy hay hành động dựa trên thói quen hình thành trước đó là gì, đó là:

Hooked: How to Build Habit-Forming Products của Nir Eyal

Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones của James Clear

Tiny Habits: The Small Changes That Change Everything của BJ Fogg

Còn khá nhiều cuốn sách và nội dung để nói về chủ đề thiết kế gia tăng Frequency cho sản phẩm nên mình sẽ không đi sâu vào ở Topic này. Có thời gian mình sẽ viết riêng về nó.

Điểm hay của feature dạng này là đã tồn tại một tập người dùng sử dụng thường xuyên cho nó (mặc dù không phải ai cũng dùng). Mục tiêu của bạn là mong muốn cải thiện nó nhằm có thêm nhiều người dùng hơn tuy nhiên bạn nên đặt câu hỏi về tính khả thi trước, chẳng hạn feature “Voice Message” (Tin nhắn thoại) thì mình quan sát tập người dùng chính, chiếm phổ biến là những người không tiện tay nhắn tin thủ công lắm trong hầu hết khoảng thời gian. Bạn có thể đoán họ là ai không? Là các anh tài xế Grab nè. Yeah, vì khi chạy thì rất khó để sử dụng tay mà nhập từng kí tự tin nhắn được đúng không. Tuy nhiên khi nhìn sang thị trường Trung Quốc thì Tin nhắn thoại là phổ biến với hầu hết người dùng chứ không còn chỉ useful cho một nhóm nào đấy. Lí do là vì bàn phím nhập tiếng Trung (khác với bảng chữ cái Latinh) khiến User cảm thấy việc input vào trở nên khó khăn hơn so với sử dụng Voice.

Nếu bạn đã xác định việc có thể reach được thêm nhiều người dùng sử dụng feature này hơn thì bạn cần thực hiện Adoption Improvement.

Để có thể thực hiện Adoption Improvement, bạn cần xác định tại sao còn nhiều User khác họ không sử dụng? Lí do thực sự ẩn chứa đằng sau đó là gì? Hãy đặt những câu hỏi để Discover như:

Nhóm User nào chưa adopt được vào tính năng này?

Nguyên nhân khiến cho họ không dùng là gì? Có phải họ không nhìn thấy value nào mà tính năng có thể mang lại?

Họ có đang bị stick vào solution nào đấy khác (vd thay vì dùng Voice Message, User có thể dùng Voice Typing, chức năng thu âm và chuyển đổi Voice thành Text do bàn phím OS hỗ trợ) hoặc feature tương tự ở sản phẩm đối thủ không?

Họ có dễ dàng tìm thấy / truy cập feature khi cần không? (nếu không thể findable hoặc khó accessible thì rất khó nhiều User biết mà sử dụng)

Có những rào cản nào khiến họ không thể dùng hoặc không biết tới feature này?

Tìm ra câu trả lời cho những câu hỏi như vậy nhằm khám phá thực sự điều gì đang khiến một sản phẩm (có tần suất dùng cao ở một nhóm nhỏ) lại bị hạn chế có thể thêm nhiều User sử dụng hơn nữa. Giải quyết những rào cản đấy và thực hiện promote thêm cho feature sẽ giúp bạn biến Trực thăng trở thành Ngôi sao trong tương lai.

Dù sao thì Shit cũng chưa hẳn bị coi là thứ bỏ đi, chỉ là bạn chưa nhận ra giá trị sử dụng của nó thôi, hãy chú ý và tìm hiểu đến nhóm người sử dụng tính năng đó:

Nếu mình xác định được feature này rất có value, có tiềm năng để develop thêm trong tương lai, solve được đúng nhu cầu, vấn đề nào đấy của người dùng rồi nhưng do cách thực thi feature, implement chưa tới thì mình sẽ cần bắt tay vào sửa cho nó tốt lên. Hoặc là Adoption Improvement, hoặc là Frequency Improvement.

Tuy nhiên nếu thực sự xác định đó là feature cần bỏ đi (ít mang lại value cho User và Business của bạn) thì bạn cũng nên kiên quyết remove nó (đôi khi nó chỉ là những legacy do những PM đi trước để lại). Mình gọi đó là đi “dọn shit” giùm người khác.

Mình có tổng hợp hơn 50 Framework có thể áp dụng trong quá trình develop sản phẩm, nếu bạn là Product Manager hoặc người làm trong ngành tech thì 50+ Frameworks for Product Managers sẽ rất hữu ích, bạn có thể tham khảo thêm tại đây:

Ngoài ra nếu bạn là một life-long-learner đang thường xuyên đọc, xem học từ Youtube từ mình có build 1 sản phẩm hữu dụng này ( ), bạn tham khảo nhen:

Cảm ơn bạn đã đọc bài viết của mình. Mình chuyên viết về Product Management, mong có thể giúp bạn hiểu thêm về ngành này.