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”

Feature Audit là một Framework hữu ích, được áp dụng thường xuyên trong quy trình đánh giá hiện trạng sử dụng của từng tính năng trong một sản phẩm. Từ đây, Product Manager có thể dễ dàng xác định được đâu là tính năng cần được duy trì và cải thiện, đâu là tính năng cần được loại bỏ.

Mình từng mua 1 món đồ này và mình thừa nhận là 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ò Product Manager (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 “sh*t” 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.

1. Feature Audit Framework

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 review 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. Ví dụ, mình ngày xưa từng quản lý và phát triển sản phẩm cho Zalo Call, 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 ý là 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ẽ kiểm tra 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 gọi) thì Average giả sử bằng 15. Tức người dùng Audio Call 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. Ví dụ, 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 có Benchmark rõ ràng để xác định 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 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ĩ tính năng này đang làm rất tốt rồi.

Nếu mình mapping 3 tính năng 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ì 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 tính năng 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 đến phần 2.

2. Shit – Cây Thông – Trực Thăng – Ngôi Sao

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à Sh*t. 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. Hai 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à Sh*t.
• 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ó một 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 người có đủ khả năng làm điều ấy.
• Cuối cùng là Sh*t (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à Sh*t đượ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ới Ngôi sao

Về cơ bản thì tính năng được xếp vào Ngôi sao đã có 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 cải thiện 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ắc 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, thì 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 thiết kế, làm cho nó ngày càng dễ dùng hơn, thực hiện cuộc gọi thuận tiện hơ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ư 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ở đồng bộ, không thì nên bình tĩnh hít thở mà cải tiến.

Với các tính năng được xếp vào Ngôi sao, nhiệm vụ của bạn là duy trì và bổ sung thêm một số cải thiện sao cho đã tốt nay càng tốt hơn.

Với Cây thông

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.

Nhưng 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 phát triển 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 use-case 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 giá trị 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... 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.

Nguồn: mobileappdaily.com

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ó 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ó.

Với tính năng được xếp vào Cây thông, mục tiêu của bạn là tìm cách tăng mức độ sử dụng (nếu thực sự khả thi).

Với Trực thăng

Đ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à cải thiện nó nhằm thu hút nhiều người dùng hơn, tuy nhiên, bạn cũng nên đặt câu hỏi về tính khả thi trước.

Chẳng hạn với Feature Voice Message (Tin nhắn thoại), 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 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ỉ use-ful 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 trở nên khó khăn hơn so với sử dụng Voice.

Với tính năng được xếp vào Trực thăng, mục tiêu của bạn là cải thiện nhằm thu hút nhiều người dùng hơn (nếu thực sự khả thi).

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 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 giá trị nào mà tính năng có thể mang lại?
• Họ có thói quen sử dụng một giải pháp nào khác (ví dụ 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 iOS 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ể tìm thấy hoặc khó truy cập thì ít 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 sẽ giúp bạn khám phá ra đ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ỏ) bị hạn chế, khó 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.

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ả.

Với Sh*t

Dù sao thì Sh*t 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 nhóm người đã và đang sử dụng tính năng đó.

Nguồn: Fanpage Lười Chăm Chỉ

Nếu bạn xác định được Feature này rất có giá trị, có tiềm năng để phát triển thêm trong tương lai, giải quyết đượ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ì bạn 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 giá trị cho User và doanh nghiệp 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 sh*t giùm người khác”.

Chốt lại một lần nữa, 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 có tổng hợp hơn 50 Framework có thể áp dụng trong quá trình phát triển sản phẩm. Nếu bạn là Product Manager hoặc người làm trong ngành Công nghệ 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 thì mình có “build” một sản phẩm hữu dụng này (cokeep.me), bạn tham khảo nha: https://leanhtu.com/trycokeepwithyoutube.

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.