Feature Adoption & Impact Evaluation

Ra mắt chưa phải là xong — bốn lăng kính để nhìn một tính năng

Ở phần lớn đội sản phẩm, vòng đời của một tính năng kết thúc vào ngày release: demo cho sếp, đóng ticket, chuyển sang việc tiếp theo. Ba tháng sau có người hỏi "tính năng đó có ai dùng không?" và không ai trả lời được bằng số. Một tính năng chưa được đánh giá là một khoản đầu tư chưa biết lãi hay lỗ — và nó vẫn tiếp tục tốn tiền bảo trì, tốn chỗ trên giao diện, tốn sự chú ý của người dùng.

Đánh giá một tính năng đã ra mắt cần bốn lăng kính, đi theo đúng thứ tự. Thứ tự quan trọng vì mỗi lăng kính là mẫu số của lăng kính sau: không biết tính năng dành cho ai thì không tính được tỉ lệ dùng thử; không có người dùng thử thì không có gì để đo giữ chân.

Vì sao không chỉ nhìn số lượt dùng? Vì "50.000 lượt dùng tháng này" không nói được gì: có thể là 50.000 người dùng một lần rồi bỏ, hoặc 2.000 người dùng mỗi ngày. Hai tình huống đó dẫn đến hai quyết định ngược nhau. Bốn lăng kính tách chúng ra.

Đo từng lăng kính cho đúng

Đối tượng — định nghĩa trước khi đo. Viết ra một câu: "Tính năng xuất hoá đơn hàng loạt dành cho chủ shop có trên 30 đơn mỗi ngày." Sau đó đếm: bao nhiêu shop thoả điều kiện đó trong tháng vừa rồi. Nếu bạn để mẫu số là "toàn bộ người dùng", tỉ lệ dùng thử sẽ thấp một cách giả tạo và đội sẽ hoảng không cần thiết; nếu bạn định nghĩa nhóm mục tiêu sau khi thấy số, bạn đang tự lừa mình.

Dùng thử — định nghĩa "đã dùng" là hành động có giá trị, không phải lượt mở. Mở màn hình xuất hoá đơn chưa phải dùng; xuất thành công ít nhất một lô mới là dùng. Lượt mở đo sự tò mò, hành động cốt lõi đo việc tính năng làm được việc của nó.

Giữ chân — đo theo cohort, vẽ thành đường. Lấy tất cả người dùng thử lần đầu trong cùng một tuần, rồi theo dõi tuần 1, 2, 3... bao nhiêu phần trăm còn thực hiện hành động cốt lõi. Hình dạng của đường nói nhiều hơn bất kỳ con số đơn lẻ nào:

Hài lòng — hỏi đúng người, đúng lúc. Khảo sát người đã dùng tính năng ít nhất ba lần, ngay sau khi họ hoàn thành hành động cốt lõi, với một câu duy nhất. Hỏi người mới dùng một lần sẽ cho bạn ấn tượng đầu tiên, không phải giá trị lâu dài. Đọc thêm ticket hỗ trợ có nhắc tới tính năng: một tính năng được dùng nhiều nhưng sinh nhiều ticket là tính năng đang tốn tiền vận hành theo cách không ai thấy trên dashboard.

Feature scorecard — ví dụ đã điền

Bối cảnh (giả định): Sạp Nhà là một sàn thương mại điện tử tầm trung ở Việt Nam. Ba tháng trước đội ra mắt "Mua chung" — người mua rủ thêm bạn qua Zalo để cùng hưởng giá thấp hơn. Sếp hỏi có nên đầu tư tiếp quý sau không. PM điền scorecard sau, mỗi dòng đều có định nghĩa để người đọc kiểm lại được:

Đọc scorecard này: người dùng thử thì ở lại và hài lòng — giá trị cốt lõi có thật. Điểm nghẽn nằm ở lăng kính thứ hai: chỉ 9% người trong nhóm mục tiêu biết đến hoặc hiểu tính năng. Kết luận hợp lý là cải tiến khả năng được phát hiện (đặt nút ở trang sản phẩm thay vì chỉ ở trang khuyến mãi, giải thích bằng một câu), không phải thêm tính năng mới cho mua chung. Đồng thời tìm hiểu vì sao ticket cao gấp gần ba lần mức trung bình — nhiều khả năng là nhầm lẫn khi nhóm không đủ người.

Lưu ý cột "Mục tiêu đặt trước". Mục tiêu phải được viết trước khi ra mắt; viết sau khi có số thì mọi kết quả đều có thể được gọi là "khá tốt".

Quyết định: giữ, cải tiến, định vị lại, hay khai tử

Scorecard chỉ có giá trị nếu nó dẫn tới một quyết định. Bảng sau là điểm xuất phát, không phải công thức — nhưng nó buộc cuộc thảo luận đi từ số liệu thay vì từ cảm giác của người to tiếng nhất trong phòng.

Cải tiến tính năng cũ hay làm tính năng mới? Phản xạ của phần lớn tổ chức là làm cái mới, vì cái mới dễ được khen trong buổi demo và dễ ghi vào báo cáo quý. Nhưng một tính năng đã có người dùng giữ chân tốt mà dùng thử thấp là cơ hội rẻ nhất trong backlog: hạ tầng đã có, giá trị đã được chứng minh, chỉ thiếu người biết đến. Một quy tắc thực dụng: trước khi đề xuất tính năng mới cho một nhóm người dùng, kiểm tra xem nhóm đó đã có tính năng nào với dùng thử dưới 20% chưa. Nếu có, tăng con số đó gần như luôn rẻ hơn và chắc chắn hơn.

Khai tử tính năng mà không làm người dùng nổi giận

Khai tử là quyết định đúng nhiều hơn người ta tưởng, và bị né nhiều hơn người ta thừa nhận. Mỗi tính năng còn sống tốn kiểm thử hồi quy, tốn thời gian onboarding cho kỹ sư mới, và làm giao diện rối thêm cho tất cả những người không dùng nó. Cái khó không nằm ở quyết định mà ở cách làm, vì nhóm nhỏ người dùng đều đặn sẽ lên tiếng to hơn nhiều lần số lượng của họ.

• Bước 1 — Biết chính xác ai đang dùng. Lập danh sách người dùng đều đặn 90 ngày qua. Với sản phẩm B2B, xem họ thuộc hợp đồng nào và có điều khoản nào nhắc tới tính năng này không. Một khách hàng doanh nghiệp lớn trong danh sách đổi toàn bộ kế hoạch.
• Bước 2 — Có đường thay thế trước khi thông báo. Tính năng khác làm được việc tương tự, cách xuất dữ liệu, hoặc hướng dẫn làm bằng tay. Thông báo khai tử mà không có đường thay thế là đẩy người dùng sang đối thủ.
• Bước 3 — Báo trước, theo tầng. Người dùng đều đặn nhận tin trực tiếp (email, Zalo OA, cuộc gọi của account manager với B2B) ít nhất 30–60 ngày trước. Người dùng thỉnh thoảng thấy banner trong ứng dụng. Người chưa từng dùng không cần biết.
• Bước 4 — Nói lý do thật, ngắn gọn. "Chúng tôi tập trung đội ngũ vào X, nơi phần lớn khách hàng cần nhất" đáng tin hơn những câu chung chung về "nâng cấp trải nghiệm". Người dùng nhận ra câu né tránh.
• Bước 5 — Tắt dần, không tắt một lần. Ẩn khỏi người dùng mới trước, rồi chuyển sang chỉ đọc, rồi mới tắt hẳn. Mỗi bước là một cơ hội phát hiện người dùng mà danh sách ở bước 1 bỏ sót.
• Bước 6 — Xoá code. Tắt cờ tính năng mà không xoá code là để lại chi phí bảo trì mãi mãi. Đặt ngày xoá vào kế hoạch sprint ngay khi chốt quyết định.

Bản Feature Impact Review — mẫu để copy

Một trang, viết 6–12 tuần sau khi ra mắt, gửi cho những người đã duyệt đầu tư ban đầu. Mục đích không phải báo cáo thành tích mà là đóng vòng lặp: chúng ta đã đặt cược gì, kết quả ra sao, chúng ta học được gì để cược tốt hơn lần sau.

FEATURE IMPACT REVIEW — [tên tính năng]
Ngày ra mắt: ...   Ngày đánh giá: ...   Người viết: ...

1. Chúng ta đã cược gì
   Vấn đề: ...
   Đối tượng mục tiêu (định nghĩa đo được): ...
   Mục tiêu đặt trước khi ra mắt: dùng thử ...%, giữ chân tuần 8 ...%, chỉ số kinh doanh ...
   Chi phí đã bỏ ra: ... người x ... tuần

2. Kết quả theo bốn lăng kính (kèm định nghĩa, nguồn số liệu)
   Đối tượng: ...   Dùng thử: ...   Giữ chân: ...   Hài lòng: ...
   Tác động kinh doanh so với nhóm đối chứng: ...

3. Điều bất ngờ
   Ai dùng mà ta không dự kiến? Ai không dùng mà ta tưởng sẽ dùng?

4. Quyết định đề xuất: GIỮ / CẢI TIẾN / ĐỊNH VỊ LẠI / KHAI TỬ
   Lý do: ...
   Việc cụ thể tiếp theo, người chịu trách nhiệm, thời hạn: ...

5. Bài học cho lần ước tính sau
   Ước tính ban đầu lệch bao nhiêu, và lệch vì giả định nào: ...

Mục 5 là mục bị bỏ trống nhiều nhất và có giá trị nhất. Sau năm bản review, đội có một bộ dữ liệu về việc mình thường lạc quan bao nhiêu — và đó là thứ giúp các lần ước tính giá trị sau trở nên đáng tin.

Lỗi thường gặp

Luyện trong tuần này

• Chọn một tính năng đội bạn ra mắt 2–6 tháng trước. Viết một câu định nghĩa đối tượng của nó, rồi đếm số người thuộc đối tượng đó. Chỉ bước này thôi đã làm nhiều người ngạc nhiên.
• Nhờ data analyst (hoặc tự viết truy vấn) một đường giữ chân theo cohort tuần cho hành động cốt lõi của tính năng đó. Gọi tên hình dạng của đường.
• Điền scorecard sáu dòng như ví dụ Sạp Nhà, kể cả khi có ô phải ghi "chưa đo được" — ô trống là thông tin về những gì đội đang không theo dõi.
• Viết một đề xuất quyết định trong ba câu: giữ, cải tiến, định vị lại hay khai tử, và vì sao. Đem đến buổi họp sản phẩm tiếp theo.
• Với tính năng sắp ra mắt, viết mục tiêu bốn lăng kính vào PRD ngay hôm nay.