- Một sản phẩm đã trở nên phức tạp có thể được cải thiện không phải bằng nhiều giải thích hơn, mà bằng cách loại bỏ những yếu tố không cần thiết; trường hợp máy tính giá của Pinecone cho thấy điều này
- Máy tính giá vốn là công cụ giúp ước tính trước chi phí dựa trên mức sử dụng, nhưng chỉ một lỗi nhập nhỏ cũng có thể khiến chi phí dự kiến bị thổi phồng lên tới 1.000 lần, ngăn người dùng đăng ký
- Nội bộ đã cố khắc phục vấn đề bằng cách thêm giải thích và giá trị mặc định, nhưng các chỉnh sửa lại tạo ra những nhầm lẫn khác, khiến kênh Slack chuyên trách tích lũy hơn 550 tin nhắn
- Trong A/B test loại bỏ máy tính, những khách truy cập không thấy máy tính có khả năng đăng ký cao hơn 16%, khả năng liên hệ cao hơn 90%, và không có sự gia tăng ticket hỗ trợ liên quan đến giá
- Một khi đã được thêm vào, một yếu tố thường dễ bị giữ lại ngay cả khi giá trị giảm đi, vì vậy cần chủ động xem xét các quyết định cắt bỏ những mảng lớn trong sản phẩm, dự án và quy trình
Trường hợp Pinecone loại bỏ máy tính giá
- Vì với mô hình định giá dựa trên mức sử dụng, người dùng khó biết chính xác chi phí thực tế từ trước, Pinecone đã đặt một máy tính chi phí trên trang giá
- Khi gặp gỡ người dùng tiềm năng để xác nhận, họ phát hiện một số người đã từ bỏ đăng ký sau khi thấy chi phí ước tính rất cao trong máy tính
- Trường hợp sử dụng đó tương đối nhỏ theo tiêu chuẩn của Pinecone
- Máy tính gây nhầm lẫn và nhạy cảm hơn nhiều so với dự kiến
- Chỉ một hiểu lầm nhỏ hoặc nhập sai cũng có thể khiến chi phí dự kiến bị phóng đại lên tới 1.000 lần
- Máy tính tạo cho người dùng một sự chắc chắn sai lệch, và họ chấp nhận con số từ máy tính như chi phí thực tế mà không kiểm tra tài liệu, hỏi đội ngũ, hay tự dùng thử để xác minh
- Để phản ứng nhanh, nhóm đã thêm giải thích, tuyên bố miễn trừ trách nhiệm, chi tiết và giá trị mặc định, nhưng nỗ lực giảm một nhầm lẫn lại sinh ra nhầm lẫn khác
- Thảo luận nội bộ cũng phình to, kênh Slack chuyên trách tích lũy hơn 550 tin nhắn, đồng thời tiêu tốn nhiều thời gian cho họp hành và viết tài liệu
- Một người đã hỏi “máy tính này có thật sự cần thiết không?”, nhưng ban đầu câu hỏi đó bị chìm trong ý kiến số đông
- Sau đó, họ tiến hành A/B test để kiểm chứng liệu giá trị có biến mất nếu loại bỏ máy tính và các vấn đề do nó gây ra hay không
- Khách truy cập không thấy máy tính có khả năng đăng ký cao hơn 16% so với khách truy cập thấy máy tính
- Khả năng liên hệ cao hơn 90%
- Không có sự gia tăng ticket hỗ trợ liên quan đến giá
- Trong khảo sát nội bộ, 7 trên 10 thành viên công ty dự đoán phiên bản có máy tính sẽ tốt hơn, nhưng kết quả thử nghiệm lại ngược lại
Vì sao việc loại bỏ lại khó
- Nhiều tổ chức khi giải quyết vấn đề thường nghĩ đến việc thêm vào trước khi nghĩ đến cắt bớt
- Ngay cả khi việc loại bỏ có thể mang lại lợi ích lớn, nó vẫn khó trở thành lựa chọn trực giác
- Bài viết trích dẫn nghiên cứu liên quan People systematically overlook subtractive changes
- Hệ thống khen thưởng cũng thường được thiết kế theo hướng thêm một thứ gì đó, còn việc loại bỏ thì hiếm khi có động lực khuyến khích
- Bài viết cũng đưa ra Negative 2000 Lines Of Code như một ví dụ cho việc loại bỏ cũng nên được tưởng thưởng
- Người từng mạnh mẽ ủng hộ việc thêm một yếu tố nào đó thường khó thừa nhận rằng nó không tạo thêm giá trị
- Nếu cố loại bỏ một yếu tố mà người khác từng đề xuất thêm vào, việc đó có thể trông như đang công kích phán đoán hoặc công sức của họ, nên người ta dễ để nguyên
- Nhiều trường hợp mặc định cho rằng thứ đã tồn tại thì phải tồn tại vì một lý do tốt, nên không xem xét lại
- Khi đã quen với hiện trạng, người ta có xu hướng ngại thay đổi trước cả khi suy nghĩ đầy đủ về việc loại bỏ
- Việc đơn giản hóa bằng cách mạnh dạn cắt bỏ các yếu tố không cốt lõi có thể dẫn đến tỷ lệ phản hồi từ khách hàng tốt hơn, hệ thống đáng tin cậy hơn, tăng trưởng và doanh thu nhanh hơn
- Thay vì chỉ cắt tỉa nhỏ, cần lựa chọn loại bỏ những mảng lớn của dự án, sản phẩm và quy trình; những đề xuất loại bỏ càng gặp phản đối mạnh trong đội ngũ thì càng có thể ẩn chứa lợi ích lớn
1 bình luận
Ý kiến trên Hacker News
Tôi không biết cái máy tính đó tốt hay tệ, nhưng lập luận thoạt nhìn khá vô lý
Nếu bạn che giấu việc chi phí sản phẩm có thể cao, thì đương nhiên số lượt đăng ký sẽ tăng. Việc họ có thật sự tốt hơn hay không còn phụ thuộc vào chuyện sau đó họ có nhận một hóa đơn gây khó chịu hay không, và điều đó thì không thể biết được bằng một A/B test ngắn trên trang đăng ký
Tôi cũng thường thấy các ví dụ kiểu như khi bỏ bớt thông tin khỏi snippet kết quả tìm kiếm thì tỷ lệ nhấp tăng lên. Vì giờ muốn xem thông tin vốn có trong snippet thì phải nhấp vào, nên việc số lượt nhấp tăng là điều hiển nhiên, nhưng rốt cuộc bên nào thật sự tốt hơn thì lại bị quên mất
Thế lưỡng nan là “làm sao sửa những trường hợp như vậy”, và giải pháp là “bỏ cái máy tính tệ hại đó đi”. Không phải là che giấu chi phí gấp 1000 lần, mà là tránh mất người dùng vì một ước tính sai gấp 1000 lần
Ví dụ là các đại lý ô tô làm cho việc xem giá trực tuyến trở nên khó khăn và thúc người dùng gửi email hoặc đến tận nơi. Máy tính giúp việc mua sắm so sánh dễ hơn, mà nhiều công ty thì không thích điều đó. Dù có ý thức hay không, đây vẫn là một động cơ cần được cân nhắc
Nếu minh bạch với người dùng thì tất yếu sẽ khiến họ bối rối hơn. Vì bản thân tiêu chí so sánh đang đối xử với người dùng như một con gia súc ngu ngốc có thể bị lùa vào lò mổ. Theo tiêu chí này, bất kỳ tính năng nào đối xử với người dùng như một con người biết suy nghĩ đều sẽ tạo ra sự rối rắm và làm hại tỷ lệ chuyển đổi
Đương nhiên trang giá trông xấu đi, nhưng vì “số lượt đăng ký đang tăng” nên chuyện đó không còn quan trọng nữa. Trong trường hợp này, cái máy tính có thể gây quá tải cho những người không quen thuật ngữ, nhưng quyết định trực giác đáng lẽ phải là “làm sao đơn giản hóa nó?”. Văn hóa A/B test cho rằng mọi thứ đều phải được phân tích và chứng minh bằng thống kê thì không hay lắm
Nếu ngay từ đầu người dùng đã không ở lại, thì làm sao kiểm tra được về sau họ hài lòng hay không hài lòng? Nếu khép kín vòng lặp và tăng mức độ tham gia, thì khả năng giáo dục khách hàng đúng cách và làm họ hài lòng thông qua các tương tác sau đó cũng tăng lên
Tôi đã upvote vì muốn lan tỏa sự khôn ngoan lớn của bài viết, nhưng ranh giới có thể nhanh chóng trở nên mờ nhạt
Lối nghĩ “nếu bỏ phần này đi thì có thứ gì có giá trị sẽ biến mất không?” đôi khi phản tác dụng trong các dự án giai đoạn đầu. Đặc biệt là vì với code và dữ liệu, rất khó ước tính giá trị tương lai
Có lần trong một dự án mới, tôi tạo một SQL schema ban đầu có các cột metadata bổ sung cho tag bài viết, nhưng tuần sau một kỹ sư senior viện dẫn nguyên tắc YAGNI và xóa hết chúng. Lúc đó chúng không có trong roadmap nên về mặt kỹ thuật là đúng, nhưng công việc ban đầu chỉ mất khoảng một giờ, còn chi phí giữ dữ liệu gần như bằng 0
Một năm sau, người xây dựng tính năng cần các cột đó rốt cuộc lại là tôi, và giờ tôi phải làm lại cùng việc đó, kèm cả migration DB production đã có người dùng. Vì vậy cũng cần nghĩ theo chiều ngược lại: “nếu bỏ phần này đi thì có tạo ra thứ gì có giá trị không?”. Trong bài viết này câu trả lời rất rõ, nhưng trường hợp của tôi thì không
Tôi nhớ SpaceX có một chỉ số nắm bắt một khái niệm tương tự: tỷ lệ các tính năng đã bị xóa rồi được thêm lại lần thứ hai. Nếu mọi tính năng bị xóa đều được thêm lại, đó là tỷ lệ tái phạm tính năng 100%, tức là cắt quá thường xuyên; 70% cũng cao và 30% cũng cao
Nhưng 0% cũng không tốt. Nếu không cố gắng loại bỏ đủ các tính năng không cần thiết thì cuối cùng sản phẩm sẽ phình to. Ở giai đoạn đầu của sản phẩm, tỷ lệ này cao hơn có vẻ hợp lý, và khi trưởng thành thì nên giảm xuống một mức thấp nhưng không phải 0
Vì ở thời điểm hiện tại không thể biết chính xác tập hợp tính năng nào cần cho sản phẩm tốt nhất, nên cũng ổn khi dùng cách tiếp cận xác suất để cắt bỏ những thứ không cần thiết. Nếu cần thì thêm lại, và miễn là chuyện đó không xảy ra quá thường xuyên, không có lý do gì để nghi ngờ quyết định xóa ban đầu
Hoặc thay vì thử cả hai trong thực tế rồi xem kết quả, ta cũng có thể họp suốt 6 tháng về các chỉ số thay thế cho giả thuyết và những niềm tin tiên nghiệm không được nói ra
Nó trở thành “có được dùng không? có được xóa không?”, và ai đó sẽ nhớ đến Knight Capital, nơi đã tái sử dụng một field cũ rồi gây ra sự cố lớn. Vì thế giữ lại field sẵn có luôn trở thành lựa chọn an toàn hơn, và cuối cùng xuất hiện
metadatavàmetadata_1. Năm sau nữa thì không ai biết vì sao lại có hai field metadata, khiến mọi thứ càng rối hơnCodebase tệ nhất tôi từng gặp là thứ được thiết kế với các trường hợp sử dụng phức tạp trong tương lai trong đầu. Ngay cả trong ví dụ này, codebase cũng chỉ cần cột đó sau 1 năm. Vì vậy tôi cho rằng tiền lệ đúng là xóa mọi đoạn code được viết để dự đoán nhu cầu tương lai. Kể cả cuối cùng nó lại cần đến
Với người này đó là tối ưu hóa quá sớm, với người khác lại là “tôi từng thấy mô hình tương tự trước đây và sẽ thêm thứ mà khi đó tôi ước là đã có”. Dường như không có cách nào đáng tin cậy để phân biệt bên nào đúng
Tình huống bạn mô tả có ba kết quả lớn. Thứ nhất, field trở nên hữu ích đúng theo cách đã triển khai ban đầu. Thứ hai, tính năng được triển khai nhưng bằng field khác hoặc cách triển khai khác. Thứ ba, tính năng không được triển khai
Ngay cả khi gán xác suất bằng nhau cho ba lựa chọn, việc làm sẵn từ đầu chỉ là chiến thắng trong 1/3 trường hợp. Nếu không xóa nó, cũng cần nghĩ xem trong thời gian đó đã tốn bao nhiêu chi phí nhận thức để kiểm tra các tính năng khác được triển khai có hoạt động đúng với cột metadata hay không
Lần này phán đoán của bạn là đúng và bạn hiểu dự án rất sâu, nhưng một quyết định có đúng hay không phải được đánh giá dựa trên thông tin có sẵn vào thời điểm đó, chứ không phải khi đã biết hết thông tin sau sự kiện
Đoạn “trong cuộc bỏ phiếu nội bộ công ty, 7 trên 10 người cho rằng phiên bản có máy tính sẽ tốt hơn” vừa thú vị vừa là một động lực rất điển hình.
Nhìn chung bài viết hay, nhưng điểm này đáng được nhấn mạnh hơn. Nếu 30% những người liên quan xem máy tính là điều không tốt, thì dù đa số thấy ổn, đó vẫn là tín hiệu về một vấn đề tiềm ẩn lớn.
Ở đây cần cẩn thận với chính trị nội bộ. Khi không có lợi ích chính trị, người ta thường không muốn phê bình đội khác. Vì vậy nếu hỏi cả công ty rằng “thứ đội chúng ta làm ra có tạo tác động ròng tích cực không?”, câu trả lời mặc định dễ là “có”, vì chẳng ai muốn vô cớ gây chia rẽ.
Trong tình huống đó, việc 30% gửi tín hiệu rằng nó có thể phá hủy giá trị quan trọng hơn nhiều so với tưởng tượng. Cần đào khá sâu xem vì sao họ nghĩ vậy. Trong trường hợp này, thực tế họ đã ý thức được điểm đó và kết thúc tốt đẹp, nhưng kết quả bỏ phiếu này ngay từ đầu đã là bằng chứng của một vấn đề nghiêm trọng.
Khi lợi ích liên quan xen vào thì càng phức tạp hơn. Bộ phận bán hàng muốn bật đủ loại dark pattern, còn hỗ trợ khách hàng có thể đã chán ngấy việc xử lý hoàn tiền vì bảo hành mở rộng bị tự động thêm vào giỏ hàng.
Đoạn trong bài nói rằng bỏ máy tính đi thì nhiều giao dịch bán hàng hoàn tất hơn, nên có thể tốt hơn cho người dùng, nghe khá buồn cười. Biết đâu việc người dùng bị sốc giá đúng lúc rồi rời đi mới là lựa chọn phù hợp, nhưng điều đó đã bị bỏ qua.
Hãy tưởng tượng mã của máy tính là một đống hỗn độn so với phần còn lại của dự án, dùng thư viện cũ, cập nhật là hỏng, có thể có lỗ hổng bảo mật, ngốn tài nguyên bất thường, và phá hệ thống build. Chẳng ai muốn đụng vào nó cả.
Trong tình huống đó, nếu hỏi đây có phải ý tưởng hay không, đa số sẽ trả lời “không” và mong loại bỏ cái đống hỗn độn ấy. Khi đó 70% là một con số rất tốt. Ngược lại, nếu đó là tính năng mà mọi người thích làm việc với nó, thì 70% lại là con số thật sự tệ.
Tất nhiên họ cũng có thể đã nghĩ vậy, nhưng đó là một bước nhảy suy luận khá lớn. Có thể họ nghĩ sẽ chẳng khác biệt mấy, hoặc đoán rằng hiệu quả thấp là do có những trường hợp máy tính đưa ra câu trả lời sai.
Thông điệp chung thì thú vị, nhưng phần này khiến tôi hơi khựng lại.
Câu “chỉ cần hiểu nhầm hoặc nhập sai một chút là ước tính có thể bị thổi phồng tới 1000 lần” có nghĩa là trong sử dụng thực tế, chỉ cần hơi hiểu nhầm hoặc đánh giá sai chỉ số là sẽ phải trả chi phí gấp 1000 lần so với kế hoạch sao?
Với hệ thống tính phí trực tuyến thì chuyện đó hoàn toàn thực tế. Tôi từng cấu hình sai một nguyên mẫu GCP, tưởng chỉ tốn khoảng 2–3 đô, nhưng lơ là vài ngày thì nhận hóa đơn hơn 100 đô.
Nhìn thấy giá dự kiến tăng điên cuồng chỉ vì chỉnh nhẹ thanh trượt thì cũng dễ hiểu vì sao khách hàng rời bỏ. Loại bỏ công cụ có thể giúp tăng đăng ký, nhưng không giúp được khách hàng khi sau này họ gặp đúng vấn đề như vậy.
Một người dùng nghĩ số truy vấn mỗi giây được tính bằng số lượt tìm kiếm × top-k của mỗi tìm kiếm. top-k là số kết quả muốn nhận về. Nếu top-k là 10, họ sẽ nhập vào số truy vấn mỗi giây cao hơn thực tế 10 lần và thấy báo giá cao hơn hóa đơn thực khoảng 10 lần.
Một người dùng khác nghĩ số vector được tính bằng số embedding × số chiều embedding. 1.536 là số chiều phổ biến, nên giá trị nhập vào đã cao hơn đúng nghĩa là 1.536 lần. Lượng dùng thực tế được Pinecone tính đúng, nên họ sẽ không bị tính phí cao như vậy.
Số chiều vector là khái niệm cơ bản với kỹ sư AI, và QPS là chỉ số cơ bản với quản trị viên DB, nhưng Pinecone có nhiều người dùng mới với AI, hoặc mới với quản trị DB, hoặc mới với cả hai.
Tác giả nên tự làm theo lời khuyên của mình. Nên bỏ đoạn “Psst... Get the next post in your inbox” chen giữa bài, và cũng nên gỡ cái nút ngớ ngẩn cứ bám theo khi cuộn trang.
Tôi đếm được tận năm cách đăng ký chỉ trên trang đó. Có thật sự cần năm cách không? Có cần phải dí vào mặt người đọc ngay giữa nội dung không? Họ nghĩ làm phiền và gây bực bội cho người ta sẽ giúp có thêm người đăng ký à? Họ có muốn những người đăng ký kiểu đó không?
Việc loại bỏ thứ gì đó thường khá rõ ràng. Chỉ cần thoát khỏi lối nghĩ hố sâu kiểu “nhiều hơn nữa, kiếm tiền, kéo khách”, và nghĩ “điều gì là đúng để tôn trọng người dùng, và làm sao giúp họ như con người chứ không phải đối tượng để vắt ví”.
Cần nhớ rằng phần lớn doanh nghiệp tồn tại để kiếm tiền, chứ không phải để mang lại sự dễ chịu cho độc giả HN.
Tôn trọng người dùng là gì là một câu hỏi riêng, dù không hoàn toàn không liên quan.
Việc có một kênh Slack riêng, tích lũy hơn 550 tin nhắn với ý kiến từ khắp công ty, rồi tiêu tốn hàng chục giờ họp và hàng nghìn từ để bàn xem cần thêm gì nhằm sửa máy tính, là triệu chứng của tuyển dụng quá mức.
Khi có quá nhiều người, quyền chủ động biến mất. Nếu quên mất điều gì thật sự quan trọng và cảm thấy phải đạt đồng thuận kiểu ủy ban, thì tức là có quá nhiều người.
Thiết kế kiểu ủy ban thì cũng nên bị giới hạn trong phạm vi ủy ban.
Chẳng phải tốt hơn là loại bỏ chính cơ chế giá phức tạp đến mức khách hàng không thể mô hình hóa hữu ích sao?
Tức là khi tùy chọn A giá x đô và tùy chọn B giá 10x đô, nếu hầu hết người dùng nhầm rằng họ cần B, thì máy tính trở thành một công cụ gây hiểu lầm.
Tôi khá thích cách “liên hệ để biết giá”. Nó gây khó chịu cho người dùng chỉ muốn biết nhanh khoảng giá đại khái, nhưng giúp xác định những trường hợp có thể thương lượng giá chuẩn hoặc mức giá khó giải thích dễ dàng trên mạng. Nó cũng có thể giữ lại những tình huống mà người dùng lẽ ra đã bỏ qua. Tất nhiên cách này không phù hợp với phần lớn trường hợp như thương mại điện tử.
Công ty chúng tôi có khoảng 250 sản phẩm, trong đó 5 sản phẩm chịu trách nhiệm cho 80% doanh thu
Đội phát triển của 5 sản phẩm đó còn chật vật mới theo kịp việc sửa lỗi, và gặp khó khăn trong việc thêm các tính năng mới quan trọng. Dù ai yêu cầu đi nữa, chỉ riêng việc đưa thứ gì đó vào roadmap đã là một cuộc chiến bất khả thi
Công ty có hàng nghìn lập trình viên, nhưng phần lớn lại đang gắn với những sản phẩm gần như không đóng góp gì cho doanh thu
Để tiến lên, có vẻ rõ ràng là nên cắt bỏ phần lớn sản phẩm và tái tổ chức đội ngũ để đẩy mạnh các sản phẩm doanh thu chủ lực còn lại. Nhưng chuyện đó đã không xảy ra, cũng không có dấu hiệu hay tin đồn nào cho thấy sẽ xảy ra. Chính trị trong công ty thật sự rất khốc liệt
Tôi từng có trải nghiệm tương tự. Trên một website có nhiều sản phẩm trông khá giống nhau, tôi lo rằng mọi người khó quyết định nên mua gì nên cuối cùng sẽ không mua
Vì vậy chúng tôi tạo một applet gợi ý sản phẩm: người dùng trả lời vài câu hỏi thì nó sẽ đề xuất một hoặc hai sản phẩm phù hợp nhất. Để làm cho đúng cũng tốn không ít công, nhưng sau khi hoàn thành thì nó hoạt động tốt
Đưa lên site thì tỷ lệ chuyển đổi tụt mạnh. A/B test cho thấy rõ ràng nó làm hại tỷ lệ chuyển đổi. Đến giờ tôi vẫn không biết vì sao, nhưng thực tế là vậy. Vì thế chúng tôi chuyển nó từ trang chủ sang mục FAQ, và gần như không còn ai dùng nữa
Có thể mọi người vốn đang do dự, và nó đã giúp họ khỏi phải tự thử cái này cái kia để tìm hiểu
Nếu là dịch vụ, có thể chiến lược kiểu Amazon Prime sẽ hiệu quả: vì không chắc nên cứ đăng ký trước, rồi sau đó tận dụng sai lầm chi phí chìm. Hoặc nếu không có applet, họ có thể đã đăng ký với kỳ vọng rằng bản rẻ nhất là đủ, nhưng applet đã dập tắt hy vọng đó ngay lập tức
Nếu là sản phẩm vật lý, có thể xem như nó đã giúp họ tránh một giao dịch mua tệ
Tôi không kỳ vọng người ta sẽ tìm nó trong FAQ. Nếu ở footer thì còn có thể, chứ FAQ thì không
Đây là một case study thú vị, nhưng tôi hoài nghi về các hàm ý rộng hơn. Pinecone nổi tiếng là đắt so với các dịch vụ cơ sở dữ liệu vector khác. Nếu so sánh giá ngang hàng, trên thị trường có khá nhiều lựa chọn tốt hơn
Việc bỏ công cụ tính toán không giải quyết vấn đề cốt lõi. Nó chỉ làm chi phí trở nên mờ mịt hơn và khiến người dùng khó so sánh các lựa chọn ngay từ đầu. Theo tôi, việc này có khả năng rút ngắn bước so sánh, khiến nhiều người dùng thiếu thông tin tải dữ liệu lên mà chưa hiểu đầy đủ tác động về giá
Đơn giản hóa đôi khi có giá trị, nhưng trong trường hợp này có vẻ có lợi cho công ty hơn là cho người dùng. Có lẽ tốt hơn là cải thiện độ chính xác và khả năng sử dụng của công cụ tính, thay vì loại bỏ hoàn toàn. Đặc biệt với các dịch vụ B2B nơi chi phí có thể tăng nhanh, minh bạch về giá là điều quan trọng