- Phần lớn người dùng chỉ sử dụng khoảng 20% tính năng của ứng dụng mà họ thực sự cần, và 20% đó khác nhau ở mỗi người
- 80% tính năng còn lại đôi khi bị xem là yếu tố gây xao nhãng, thậm chí còn tạo ra sự bất tiện hoặc bất mãn
- Nếu nhắm đúng thị trường ngách, có thể xây dựng được một tệp người dùng rất mạnh
- Những trường hợp như Kagi, Figma, Notion — tạo ra thị trường có mức độ trung thành cao bằng cách giải quyết tốt 20% mà các tập đoàn lớn bỏ qua — cho thấy cơ hội thị trường mới
- VS Code, Slack, Discord hỗ trợ khả năng mở rộng và cá nhân hóa để người dùng tự tối ưu “20% của riêng mình”
- Cốt lõi không phải là tạo ra một sản phẩm cho tất cả mọi người, mà là làm ra một công cụ thỏa mãn sâu sắc phần mà mỗi người thực sự muốn, và đó cũng là cách tránh vấn đề phình to tính năng
Trải nghiệm thời thơ ấu và cách con người sử dụng phần mềm
- Khi còn nhỏ, tác giả thường làm hỏng máy tính vì xóa các tệp không cần thiết để quản lý 2GB dung lượng lưu trữ
- Sau khi xóa các tệp hệ thống quan trọng như
.ini, tác giả phải cài lại Windows và Office 97 từ đầu
- Cha của tác giả luôn nhấn mạnh phải cài Excel, nhưng với tác giả, Excel chỉ là công cụ để dán bảng vào Word
- Trong vô số tính năng của Excel, chỉ việc sao chép/dán bảng là có ý nghĩa với bản thân tác giả
- Một người quen của tác giả cũng chỉ từng dùng Excel như sổ chi tiêu gia đình, còn các tính năng khác thì không đụng tới
20% khác nhau của mỗi người
- Trong cách dùng phần mềm có một quy luật 80/20: đa số người dùng chỉ sử dụng 20% tổng số tính năng
- Nhưng 20% mà mỗi người tập trung vào lại khác nhau, và ai cũng cho rằng phần mình dùng là quan trọng nhất
- Ví dụ: trong Word thì dùng tạo bảng nhưng không dùng mail merge, trong Excel thì dùng pivot table nhưng không dùng script, còn trong PowerPoint thì không dùng animation
- Khi có tính năng mới được thêm vào hoặc giao diện bị thay đổi qua các bản cập nhật, người dùng dễ cảm thấy ứng dụng chậm hơn hoặc có quá nhiều thứ không cần thiết, từ đó nảy sinh bất mãn
- 80% tính năng không dùng đến thậm chí còn có thể bị xem là thứ cản trở workflow của 20% đang dùng
Khao khát về kết quả hoàn hảo
- Hiện tượng này không chỉ xảy ra với Microsoft mà cũng xuất hiện tương tự ở các công ty IT khác
- Chẳng hạn, khi muốn tìm kiếm từ khóa chính xác trên Google Search, các kết quả liên quan nhưng không cần thiết lại có thể dẫn tới sự khó chịu
- Từ góc nhìn doanh nghiệp, đó có thể bị coi là “nhu cầu của 1% người dùng”, nhưng 1% của 1 tỷ người là 10 triệu người — một thị trường rất lớn
- Kagi nhắm vào thị trường nhỏ mà Google bỏ sót, khác biệt hóa bằng tìm kiếm chất lượng cao, không quảng cáo và bảo vệ quyền riêng tư
- Nếu khai thác khoảng trống mà các công ty khổng lồ để lại, có thể hình thành thị trường ngách để làm hài lòng một nhóm người dùng nhỏ
- Không nhất thiết phải làm hài lòng tất cả mọi người; hoàn toàn có thể xây dựng chiến lược thỏa mãn hoàn hảo trải nghiệm 20% của một nhóm cụ thể
Tìm ra 20% bị lãng quên
- Nhiều công ty đổi mới đã tập trung đánh mạnh vào những nhóm người dùng cụ thể mà các tập đoàn lớn bỏ lỡ
- Figma tập trung vào việc vượt Adobe ở mảng thiết kế cộng tác, còn Notion cũng định vị mình như một công cụ hybrid được tối ưu cho nhu cầu của một nhóm người dùng nhất định
- Phần mềm thành công thường dần có thêm nhiều tính năng theo thời gian, nhưng trong quá trình đó sẽ xuất hiện những khoảng trống nơi 20% của một số người dùng bị chìm lấp
- Phần mềm mã nguồn mở có lợi thế trong lĩnh vực này vì có thể tạo ra các bản build tùy biến chuyên cho một workflow cụ thể
- Ví dụ, có thể phát triển một phiên bản Blender nhẹ chỉ dành cho trực quan hóa kiến trúc
Thiết kế cho đúng 20%
- Triết lý này được thể hiện rất rõ trong VS Code
- Tính năng mặc định tập trung vào chỉnh sửa văn bản đơn giản, nhưng thông qua extension, người dùng có thể xây dựng môi trường phát triển theo đúng nhu cầu của mình
- Đây là một cấu trúc cho phép mọi người tùy biến “20% của riêng mình”
- Integration của Slack, bot của Discord cũng hoạt động theo cùng nguyên lý, hỗ trợ người dùng tự điều chỉnh trải nghiệm
- Ngay từ đầu rất khó dự đoán 20% của mọi người là gì, nhưng nếu cung cấp khả năng mở rộng và tùy biến, mỗi người đều có thể đạt được cách dùng tối ưu của riêng mình
Kết luận: thay vì sản phẩm cho tất cả mọi người, hãy tập trung vào “20% cần thiết” của từng người
- Nếu cố làm tốt mọi tính năng, kết quả cuối cùng thường là một kiểu phần mềm nặng nề và làm gia tăng bất mãn
- Điều quan trọng là tập trung để từng tính năng hoạt động hoàn hảo với đúng nhóm người dùng đang tìm đến nó
- Dù sao người dùng cũng chỉ dùng một phần trong toàn bộ tính năng, nên tập trung làm cho một tính năng cụ thể thực sự xuất sắc lại hiệu quả hơn
- Cần thừa nhận rằng phần mềm có thể được dùng theo những cách ngoài dự đoán, và phải lập kế hoạch trong bối cảnh chấp nhận sự đa dạng đó
- Không áp đặt mọi thứ lên người dùng, mà chỉ tập trung phát triển những phần thực sự được yêu thích, sẽ mang lại mức độ hài lòng lớn hơn
2 bình luận
Cứ thế mà gắn ngay định luật Pareto vào nhỉ;; Cũng có thể là 15% mà, đúng không? hihihi
Ý kiến trên Hacker News
Ở một công ty SaaS tôi từng làm, đã có lần chúng tôi thử phân tích chỉ dựa trên một phần các tính năng mà người dùng thực sự sử dụng. Mục tiêu là giảm độ phức tạp của sản phẩm cho phù hợp với một vài kiểu người dùng cốt lõi, đồng thời loại bỏ các tính năng gây phiền toái. Kết quả là, ngoại trừ màn hình đăng nhập, 20% mà mỗi người cho là quan trọng lại hoàn toàn khác nhau. Kết quả phân tích chẳng khác gì lấy mẫu ngẫu nhiên có trọng số
Rất đồng cảm. Nhưng khi bắt đầu bán sản phẩm cho khách hàng doanh nghiệp thì mọi chuyện thay đổi hoàn toàn. Chỉ cần thiếu một “tính năng vệ sinh” là thương vụ có thể đổ bể. Và mỗi doanh nghiệp lại có một tính năng bắt buộc khác nhau. “Tính năng vệ sinh” ở đây là phép ví von với nhà vệ sinh, tức những yếu tố tối thiểu ai cũng cần
Đây là một bài viết gợi nhớ đến các bài trên blog của Spolsky
strategy-letter-iv-bloatware-and-the-8020-myth
simplicity
Tôi đã tự làm một ứng dụng cho sở thích cá nhân của mình, và đôi khi nghĩ rằng muốn trau chuốt rồi công khai nó. Nhưng tôi hoàn toàn không có ý chí quảng bá hay giới thiệu ứng dụng đó, nên cảm thấy bản thân việc công khai cũng vô nghĩa. Thật ra lý do lớn hơn là tôi không có ý định triển khai 80% tính năng còn lại mà chính tôi cũng không dùng
Trong marketing có một khái niệm gọi là Modified Pareto. Không phải 80/20 mà là 60/20. Tức là 20% người dùng nặng tiêu thụ 60% giá trị của sản phẩm, còn 80% người dùng nhẹ tiêu thụ 40%. Đây không phải tỷ trọng đủ nhỏ để có thể bỏ qua, nên nhất định vẫn phải quan tâm tới người dùng nhẹ
value-paretos-bottom-80
Đại khái là như vậy. Trên thực tế, điều quan trọng hơn nhiều là người dùng có “nhận thức” rằng phần mềm có thể giải quyết vấn đề của họ hay không. Nếu muốn khiến họ bỏ tiền, bạn phải tạo cho họ cảm giác rằng phần mềm có khả năng giải quyết nhiều loại vấn đề của họ. Những vấn đề đa dạng đó có thể liên quan đến cả những tính năng mà bản thân họ không trực tiếp dùng. Ví dụ, trong phần mềm 3D, một hệ thống rigging có thể chỉ được 2% người dùng sử dụng trong 1% thời gian, nhưng nếu không có nó thì sẽ có những người thậm chí còn không thèm cân nhắc sản phẩm
Tôi không giỏi dự đoán tác phẩm của mình rồi sẽ được dùng như thế nào trong thực tế, nên tôi chỉ thích cách làm kiểu lát đường theo những lối mòn đã lộ ra, thứ thường được ví là “Desire paths”
the-road-most-traveled-by-paving
Tôi đồng ý với ý rằng “thay vì cố ngăn tính năng ngày càng phình to, ta nên chấp nhận rằng phần mềm có thể được sử dụng theo những cách không ai tưởng tượng nổi”. Vì thế tôi cho rằng interoperability là yếu tố quan trọng nhất của phần mềm. Vấn đề chính trong bài này, với tôi, là sự khép kín của định dạng tệp theo từng phần mềm và từng phiên bản. Tôi không ngại kết hợp nhiều công cụ với nhau, nhưng vấn đề là các công cụ không cộng tác tốt trong một pipeline. Giấc mơ Unix quả thật rất khó
Với một ứng dụng có quy mô nhất định, gần như không bao giờ mọi tính năng đều được sử dụng 100%. Theo kinh nghiệm của tôi, gần như mọi ứng dụng đều có khoảng 10~30% phần hoàn toàn không được tận dụng. Nguyên nhân chủ yếu là hoặc cách dùng quá khó hiểu nên ngoài đội phát triển ra không ai biết, hoặc workflow quá tệ và kém hiệu quả, hoặc đó là tính năng quá cơ bản đến mức những công ty thật sự cần nó lại không có đủ khả năng tài chính để mua phần mềm đó
Đúng vậy, nhưng vì có nhiều người dùng mỗi người lại coi trọng một 20% tính năng khác nhau, nên phải giữ tất cả các tính năng thì mới duy trì được số người dùng hiện tại. Dù vậy, nếu loại bỏ những tính năng gần như không ai dùng nhưng lại ngốn rất nhiều thời gian bảo trì hay phát triển thì ROI sẽ tăng lên
Nhưng người dùng không nhất thiết cùng coi trọng một 20% giống nhau. Một điều nữa cần nghĩ tới là người dùng thực ra không biết ứng dụng có những tính năng gì trước khi họ dùng thử. Quyết định cài đặt được đưa ra dựa trên những tính năng mà họ kỳ vọng trước khi cài, chứ không phải những gì thực sự có trong ứng dụng. Đó là một khác biệt quan trọng. Dù bạn đầu tư công sức vào tính năng, thực tế bạn chỉ gặt hái kết quả sau khi đã thu hút được người dùng.
Điều này đặc biệt quan trọng khi làm MVP (sản phẩm khả dụng tối thiểu): trong đa số trường hợp, thứ ngăn cản việc cài đặt và sử dụng lâu dài không phải là thiếu tính năng. Thường là do thông điệp, marketing, hoặc đơn giản là sản phẩm không có giá trị đủ hấp dẫn với người dùng. Cứ liên tục thêm tính năng cũng không giải quyết được các vấn đề đó. Đây là điều tưởng như đơn giản nhưng rất nhiều công ty bỏ lỡ.
MVP đơn giản nhất là ban đầu thậm chí chưa cần triển khai gì cả, mà chỉ cần khiến mọi người đăng ký trước. Bằng cách đó, bạn có thể kiểm chứng xem thông điệp của mình có đang được truyền đạt đúng hay không. Nếu họ thất vọng sau khi đăng ký, thì ít nhất cũng có nghĩa là thông điệp đã được truyền đạt tốt.
Tuy nhiên, làm vậy cũng đồng nghĩa bạn phát hành MVP khi nó chưa hoàn thiện đúng như lời hứa, và sẽ có nguy cơ gây thất vọng vì những lời hứa chưa được hoàn thành. Ngoài ra, rất nhiều tính năng thực ra có cũng được không có cũng được, đặc biệt trong SaaS, nơi có nhiều tính năng trên thực tế không đủ thiết yếu để người ta bỏ tiền trả. Thay vì lập tức coi yêu cầu của khách hàng là yêu cầu bắt buộc, bạn nhất định phải làm rõ xem họ có thực sự coi đó là “giá trị” hay không, có sẵn sàng trả tiền cho nó không, và nó có thật sự giải quyết một điểm đau quan trọng hay không. Hiểu được vì sao yêu cầu đó xuất hiện quan trọng hơn nhiều so với việc lập tức làm ra chính tính năng ấy