Mất đi sự tự tin (Lost confidence)

• Các framework ưu tiên dựa trên mức độ tự tin như RICE phần lớn chỉ là nhiễu; cần một cách ra quyết định mà không giả vờ biết trước tương lai không thể biết
• Điểm tự tin thường được chấm cao cho các dự án nhỏ và thấp cho các dự án lớn, nên nó bóp méo ưu tiên bằng cách đẩy lùi một cách có hệ thống những dự án có giá trị lớn
• Điểm tự tin có định nghĩa mơ hồ, thiếu dữ liệu kiểm chứng; dự án thì hầu như luôn trễ và tác động nhỏ hơn kỳ vọng, nên không đáng tin
• Giải pháp là ở vùng bất định (uncertainty) chứ không phải xác suất (probability): hỏi “hành động nào là khôn ngoan trong mọi phân phối xác suất?”
• Thay vì sự tự tin, điều quan trọng là ưu tiên bằng các kỹ thuật như những điều luôn đúng, tác động tới khách hàng, giữ quyền chọn, các cược bất đối xứng

---

Trò chơi niềm tin (Confidence games)

• Nhiều framework ưu tiên đưa mức độ tự tin rằng có thể tạo ra tác động dự đoán với nỗ lực dự đoán vào điểm số
  • Giữa hai dự án có cùng giá trị và cùng nỗ lực, việc chọn bên có mức tự tin thực thi cao hơn tự thân là hợp lý
  • Nhưng cách dùng thực tế không phải là “1) chấm điểm → 2) thực hiện ứng viên thắng rõ ràng → 3) nếu hòa thì chọn bên tự tin hơn”
• RICE nhân trực tiếp mức độ tự tin vào công thức tính điểm ở bước 1
  • Công thức RICE: Score = (Reach × Impact × Confidence) / Effort
  • Công thức RPS: Score = Reach × Potential × Solution Confidence
• Cách này tạo ra sự tương đương giả khi coi hai kịch bản khác nhau là ngang hàng
  • Một tính năng tăng tiến nhỏ nhưng gần như chắc chắn thực hiện được
  • Một tính năng lớn có tác động cao nhưng đi kèm rủi ro
• Vì các dự án nhỏ thường có mức tự tin cao, còn dự án lớn có mức tự tin thấp, việc nhân thêm tự tin sẽ khiến bạn lệch khỏi hướng tối đa hóa giá trị được chuyển giao một cách có hệ thống
  • Động lực cốt lõi của phong trào Agile chính là trực giác rằng “thành công của dự án lớn luôn phải có mức tự tin thấp”
• Lý do không tin vào điểm tự tin
  • Định nghĩa mơ hồ: không rõ “30%” nghĩa là gì. Về nguyên tắc, phải ghi lại điểm tự tin của mọi dự án rồi đối chiếu với kết quả thực tế để tính độ chính xác bằng số, nhưng thực tế không làm vậy
  • Nếu mỗi năm chỉ ra mắt một vài tính năng lớn, thì ngay cả sau đó cũng không đủ dữ liệu để kiểm chứng
  • Dự án hầu như luôn trễ, có tác động nhỏ hơn và chậm hơn kỳ vọng. Một dự án 9 tháng, 6 đội cũng được bắt đầu vì từng có “một mức tự tin nào đó”
• Trích Định luật Hofstadter: “Mọi việc luôn mất nhiều thời gian hơn bạn dự kiến, ngay cả khi đã tính đến Định luật Hofstadter”
• Nếu hỏi các PM giàu kinh nghiệm về “tính năng mà bạn chắc chắn sẽ được đón nhận nhưng rốt cuộc không phải vậy”, ai cũng có nhiều ví dụ
  • Dù có căn cứ như trò chuyện với khách hàng, yêu cầu rõ ràng, cam kết mua hàng, khi thực sự xây xong thì ngay cả người đã hứa cũng hầu như không dùng
  • Kỹ thuật cải thiện dự đoán: yêu cầu khách hàng giải thích họ sẽ dùng nó từng bước trong workflow thực tế như thế nào. Khi đi qua từng bước, họ sẽ tự nhận ra kiểu như “việc này đòi hỏi viết lại code nên tôi sẽ không làm”
• Người làm nội dung cũng tương tự: bài viết vội vã đăng mà không kỳ vọng gì lại có lượt xem và phản hồi cao nhất năm, còn tác phẩm bỏ hàng chục giờ chăm chút lại bị phớt lờ
  • Cả bốn ô trong bảng 2×2 “có/không tự tin × kết quả (được yêu thích/bị thờ ơ)” đều đầy ví dụ

Dùng gì thay cho sự tự tin và rủi ro (What to use in place of confidence and risk)

• Câu trả lời nằm ở vùng bất định (uncertainty), không phải xác suất
  • Xác suất giả định ta biết phân phối. Với 100 lần tung đồng xu công bằng, có thể dự đoán rất có khả năng mặt ngửa sẽ rơi vào khoảng 40–60 lần
  • Gần như mọi thứ trong startup đều khác vậy. Thành công, chiến lược, tính năng hoặc chưa có tiền lệ, hoặc quá phức tạp, hoặc thiếu độ chính xác của biến đầu vào, nên không thể gán xác suất có ý nghĩa
  • Khái niệm “Knightian Uncertainty (bất định kiểu Knight)” bắt nguồn từ tác phẩm năm 1921 của nhà kinh tế học Frank Knight
  • Phương pháp Bayesian cũng cần xác suất tiên nghiệm và xác suất có điều kiện bằng số; cả hai đều không biết và không thể định nghĩa
• Câu hỏi trong vùng bất định: “Hành động nào là khôn ngoan bất kể phân phối xác suất?”

• Những điều luôn đúng (True always)

  • Tập trung vào những điều luôn đúng trong mọi tình huống — nguyên tắc hằng số dài hạn (long-term constants) của Bezos
    • Người dùng nhìn chung thích phần mềm nhanh và phản hồi tốt. Họ coi trọng đồng bộ nền, tương tác tức thì, và khả năng hoạt động trên mọi thiết bị
    • Trường hợp xấu nhất (người dùng thờ ơ với tốc độ) thì họ cũng không xem tốc độ là tiêu cực. Trường hợp tốt nhất, giống Notion, Figma, Miro, Gmail, Google Docs, hiệu năng trở thành yếu tố khác biệt hóa cốt lõi
  • Không phải tính năng nào cũng có sức hấp dẫn phổ quát. Thay vì phân rã số liệu thật chính xác, hãy xác định những tính năng mà gần như mọi khách hàng đều thấy có giá trị, hoặc ít nhất là thích
    • Đôi khi điều đó chắc chắn vì nó là nghĩa vụ. Các yêu cầu doanh nghiệp như tuân thủ SOC 2 có thể không thú vị, nhưng chắc chắn có giá trị khi bán cho enterprise
    • Sự chắc chắn như vậy bù đắp cho việc thiếu khác biệt hóa
  • Tuy nhiên, những ý tưởng sáng tạo và khác biệt nhất hiếm khi thuộc nhóm “tuyệt đối chắc chắn”
    • Điều chắc chắn thì có giá trị, nhưng khó trở thành yếu tố khác biệt chiến lược
    • Một sản phẩm xuất sắc cần cả cải tiến đáng tin cậy lẫn bước nhảy đổi mới

• Khám phá nhanh, phục hồi nhanh (Quick discovery, quick recovery)

  • Từ lâu đã ủng hộ việc phỏng vấn có hệ thống khách hàng tiềm năng trước khi xây dựng để kiểm chứng ý tưởng, nhưng việc này cũng rơi vào “bẫy tự tin”
    • Trước khi xây xong, bạn không bao giờ biết chắc
    • Tuy vậy, trước khi xây vẫn có thể bác bỏ/không xác thực được (invalidate), giúp tránh lãng phí nhiều tháng đến nhiều năm, nên đó vẫn là điểm khởi đầu đúng
  • Cách giải điển hình là tạo SLC (một khái niệm nâng cấp từ MVP) — một sản phẩm đơn giản nhưng hoàn chỉnh để nhận phản hồi thật (trải nghiệm, không phải dự đoán)
    • Sản phẩm hiện hữu duy trì một danh mục cân bằng giữa chiến thắng chắc chắn và cược đổi mới, áp dụng các cách kiểm chứng khác nhau cho từng loại
  • Ví dụ về “tính năng giả (dummy features)”: một nút mà khi bấm vào sẽ hiện “Tính năng này chưa có. Hãy cho chúng tôi biết bạn sẽ dùng nó như thế nào”
    • Cung cấp tín hiệu thực bằng hành động về số người dùng quan tâm và các đối tượng có thể phỏng vấn
    • Là tín hiệu tốt hơn khảo sát 100 lần. Trong khảo sát, người ta dễ nói “có”, nhưng hành động như bấm nút đòi hỏi sự quan tâm thật. Hành vi quan sát được thắng ý định được tuyên bố

• Tập trung vào tác động tới khách hàng thay vì sự tự tin (Focus instead on customer impact)

  • Thay thế sự tự tin bằng tác động. Tác động được định nghĩa theo hai cách
    • Nguyên tắc đa số (Majority rule): tính năng được đa số người dùng dùng thường xuyên rõ ràng là quan trọng, và có khả năng là lý do cốt lõi của việc nhận dùng và duy trì
    • Người ủng hộ nhiệt thành (Passionate advocates): tính năng tạo ra fan cuồng trong một nhóm thiểu số. Những người nói “tôi mua chỉ vì cái này”. Không phổ quát, nhưng tạo lòng trung thành sâu sắc trong một phân khúc cụ thể (“magnificent delighters”)
  • Khi người dùng thật sự yêu một phần nào đó, họ sẽ chịu đựng các khiếm khuyết khác
    • Nhờ sức hấp dẫn của iPod, hàng tỷ người đã chịu đựng iTunes, một phần mềm tệ hại nhất
    • Phần mềm được thiết kế đẹp có thể được chấp nhận chỉ nhờ trải nghiệm thiết kế, dù thiếu tính năng hoặc bị giới hạn nền tảng
  • Định nghĩa định lượng của tính năng có tác động cao
    • (1) ít nhất 51% khách hàng dùng thường xuyên, hoặc
    • (2) ít nhất 15% khách hàng nhắc đến nó trong top 3 lý do chọn mua/ở lại
    • Đây là tiêu chuẩn cao, nhưng các tính năng đổi mới và rủi ro xứng đáng với tiêu chuẩn cao; quy mô phần thưởng phải biện minh được rủi ro

• Đầu tư vào đòn bẩy (Invest in leverage)

  • Có những lĩnh vực mà thay đổi tăng tiến nhỏ tạo ra kết quả lớn
  • Có những vùng đòn bẩy gần như luôn đúng về mặt toán học và cấu trúc
    • (phần quảng bá sách liên quan được loại trừ như quảng cáo)

• Tối đa hóa quyền chọn (Maximize optionality)

  • Nếu không thể biết tương lai, hãy chọn phương án tối đa hóa số lựa chọn bạn có khi tương lai đến
    • Vượt ra ngoài sự linh hoạt đơn thuần hay tránh bị lock-in; thiết kế để xử lý bất cứ điều gì xuất hiện
  • Ví dụ
    • Duy trì chi phí thấp → bảo vệ lợi nhuận, đồng thời có thể thử nghiệm nhiều mức giá/gói khác nhau và tăng sức chống chịu trong tương lai
    • Chọn thư viện/framework UI đa nền tảng đã được kiểm chứng tốt và phát triển tích cực → ứng phó với sự tiến hóa của nền tảng và thiết bị
    • Kiến trúc plugin → cho phép bản thân và cộng đồng xây dựng những thứ hiện chưa thể tưởng tượng
    • Kiến trúc API-first → tách biệt đội ngũ, kết nối frontend/backend/tích hợp khách hàng
    • Lớp bọc dịch vụ vendor → có thể thay thế vendor bất ổn, đắt đỏ hoặc tụt hậu
  • Giữ các quyền chọn tương lai đòi hỏi thêm việc hôm nay
    • API bọc vendor hiện tại không tạo thêm giá trị ngay hôm nay
    • Đây là lựa chọn khôn ngoan với công ty trưởng thành, nơi ổn định và dự đoán được là quan trọng; nhưng có thể là lựa chọn sai ở giai đoạn đầu, khi cần dùng tốc độ để thắng các đối thủ lớn sẵn có
  • Cách tối đa hóa quyền chọn cho toàn công ty là xây dựng một công ty xuất sắc
    • Tăng trưởng lành mạnh và bền vững, biên lợi nhuận gộp lớn và mở rộng, tình yêu của khách hàng được chứng minh qua giữ chân/nâng cấp/truyền miệng, tình yêu của nhân viên được chứng minh qua gắn bó dài hạn và phát triển sự nghiệp
    • Một công ty xuất sắc có nhiều quyền chọn như được mua lại, tiếp tục tồn tại độc lập, gọi vốn, IPO, kế nhiệm

• Danh mục các cược (Portfolio of bets)

  • Danh mục làm giảm biến động, nhưng cũng giảm mức tăng tối đa
    • Khả năng không có chiến thắng nào thấp nên downside không quá tệ, nhưng vì chiến thắng phải bù lỗ, ngay cả cú trúng lớn thỉnh thoảng cũng không lớn bằng cược đơn lẻ
    • Ẩn dụ: tốt nhất là mua Amazon lúc IPO rồi giữ mãi, nhưng nếu áp dụng cùng cách đó cho các IPO khác cùng năm thì có thể về $0. Danh mục sẽ không về 0, nhưng mức tăng tối đa nhỏ hơn rất nhiều so với cổ phiếu tốt nhất
  • Phụ chú toán học: lý do danh mục hoạt động bất kể phân phối là Định lý giới hạn trung tâm (Central Limit Theorem)
    • Nếu lặp lại việc lấy N mẫu từ một tổng thể có phân phối ổn định nhưng không biết, rồi vẽ histogram của trung bình mẫu, phân phối đó sẽ hội tụ về Gaussian (phân phối chuẩn) (trung bình là trung bình tổng thể, phương sai là phương sai tổng thể chia cho 1/n)
    • Lindeberg–Lévy CLT cho thấy điều này vẫn đúng ngay cả khi mỗi mẫu đến từ một phân phối khác nhau (trong điều kiện độc lập, phương sai hữu hạn, và không có biến đơn lẻ nào chi phối)
    • Tuy nhiên, trong các phân phối thường gặp ở môi trường startup, điều kiện này có thể bị phá vỡ (một số Power Law có phương sai vô hạn)
  • Danh mục hoạt động khi bạn muốn kết quả dự đoán được nhưng bình thường, và không hoạt động khi bạn muốn outlier
    • Ví dụ danh mục venture/angel: 65% bị lỗ, chỉ khoảng 10% tạo ra lợi nhuận đủ để biện minh cho rủi ro và tính kém thanh khoản
    • Khi nhắm tới outlier, cần đầu tư tất tay, không phải danh mục (vì phân phối lợi nhuận startup là Power Law vi phạm tiêu chí Lindeberg)
  • Kết luận: nếu ưu tiên là tìm khác biệt hóa thị trường và động lực tăng trưởng, danh mục là công cụ sai. Nó phù hợp với các kết quả tăng tiến nhỏ và đáng tin cậy; khi đó không cần tranh cãi về mức độ tự tin

• Cược bất đối xứng (Asymmetric bets)

  • Là đối cực tự nhiên của danh mục. Nếu danh mục dành cho độ tin cậy, thì cược bất đối xứng dành cho outlier
    • Không dự đoán thành bại của cược, mà chọn các cược có downside bị giới hạn/định lượng được và upside lớn
  • Nếu kịch bản xấu nhất là “mất 2 tháng”, còn tốt nhất là “khác biệt hóa hoàn toàn”, thì xác suất gần như vô nghĩa
    • Chỉ cần downside có thể sống sót và upside đủ lớn để một lần thắng bù được mười lần thua
    • Không thể biết xác suất chính xác, nhưng có thể biết hình dạng (shape) của mỗi cược
  • Cược bất đối xứng ở cấp chiến lược thường có hình dạng được xác định sẵn (thị trường mới nơi các giới thiệu kép tích lũy, hào lũy sâu hơn khi bán nhiều hơn)
    • Ở cấp tính năng, phải tự cấu trúc sự bất đối xứng. Vì hình dạng mặc định của dự án phần mềm thường trôi từ “2 tuần → 2 tháng → đã tốn quá lâu nên buộc phải hoàn thành”
    • Cơ chế là ngân sách được viết ra trước khi bắt đầu: “2 kỹ sư, 3 tuần, sau đó dừng lại và xem xét”. Timebox chính là downside bị giới hạn
  • Cũng có thể thay sự tự tin bằng câu hỏi “nó bất đối xứng đến mức nào”
    • RICE yêu cầu ước lượng một xác suất mà ta đã thừa nhận là không biết
    • Bất đối xứng hỏi hai điều có thể ước lượng thực sự: kịch bản xấu nhất theo thời gian/chi phí và kịch bản tốt nhất theo giá trị khách hàng. Cả hai đều cụ thể; nếu giới hạn mọi con số ở các lũy thừa của 10, trong cuộc họp chúng có thể hội tụ về các con số có thể thống nhất

Kết luận

• Hãy ngừng giả vờ rằng có thể định lượng hoặc định nghĩa sự tự tin
• Thay vào đó, dùng những kỹ thuật hoạt động mỗi khi tương lai không thể dự đoán — vì tương lai luôn không thể dự đoán

[hmmhmmhm]

"Thay vào đó, hãy sử dụng kỹ thuật hoạt động mỗi khi tương lai không thể dự đoán, bởi vì tương lai thì lúc nào cũng không thể dự đoán" Hay thật.

[spilist2]

Đây là một bài viết rất tuyệt.