Lựa chọn chiến lược: khi cả hai đều là phương án tốt

• Lựa chọn chiến lược là việc chọn một trong hai phương án đều hấp dẫn, đồng thời chấp nhận cả những hệ quả bất lợi đi kèm
• Chiến lược thực sự không phải là những “lời hay ý đẹp”, mà là những lựa chọn cụ thể đi kèm đánh đổi, và phải xác định rõ ‘một trong hai’ chứ không phải ‘cả hai’
• Lựa chọn chiến lược thực sự là khi phương án đối lập cũng đủ hợp lý, và hiệu ứng bậc hai của lựa chọn đó lan rộng ra toàn công ty
• Khi nhiều lựa chọn chiến lược củng cố lẫn nhau mà không xung đột, toàn bộ tổ chức có thể di chuyển nhanh theo một hướng nhất quán
• Nếu việc chọn lựa không khó, thì đó không phải là lựa chọn thật sự; cần đưa ra quyết định khó từ sớm để các thành viên có thể tự đưa ra phán đoán đúng đắn một cách độc lập

---

Vì sao cần có lựa chọn chiến lược

• Mọi thành viên trong công ty đều tự đưa ra quyết định mỗi ngày, và đó là cơ chế cốt lõi giúp tổ chức mở rộng quy mô
• Nhưng các quyết định hợp lý ở cấp cá nhân có thể mâu thuẫn với nhau; nếu ai cũng đi theo một hướng khác nhau thì dù năng suất cao, kết quả vẫn dậm chân tại chỗ
• Ngay cả đội ngũ tự chủ cũng cần sự đồng bộ, và sự đồng bộ đó không thể dựa trên chiến thuật (thay đổi mỗi tuần) hay khẩu hiệu sáo rỗng (không thay đổi được điều gì), mà phải dựa trên các quyết định ở cấp độ vĩ mô, tức là các lựa chọn chiến lược
• Khi các quyết định thường ngày phù hợp với lựa chọn chiến lược, sự lệch pha giữa lời hứa của marketing và sản phẩm do engineering tạo ra sẽ biến mất, và các quyết định sẽ cộng hưởng với nhau như lãi kép

3 thuộc tính của một lựa chọn chiến lược thực sự

• 1. Cả hai phía đều là phương án hợp lý

  • “Thiết kế tốt” không phải là một lựa chọn chiến lược — vì chưa bao giờ “thiết kế tệ” là một phương án thay thế hợp lý
  • “All-in-one” và “core nhỏ + khả năng mở rộng cực cao” mới là lựa chọn thực sự — có rất nhiều công ty thành công đã chọn mỗi bên
  • “Cả hai” không phải là một lựa chọn hợp lệ — sản phẩm либо tự hoàn chỉnh, либо không
    • Hoặc thiết kế UX như một trải nghiệm hoàn chỉnh, hoặc thiết kế để chấp nhận UX của bên thứ ba
    • Hoặc bán như một “sản phẩm có mọi thứ cần thiết”, hoặc bán như một “nền tảng hệ sinh thái cho mọi thứ”
    • Hoặc đội support trả lời cho toàn bộ sản phẩm, hoặc chuyển hướng sang vendor plugin
  • Khi đã đưa ra lựa chọn chiến lược thật sự, danh sách các hiệu ứng bậc hai lan ra toàn công ty sẽ dài ra
  • Đây cũng chính là khái niệm Opposite Test — nếu phía đối diện là thứ tầm thường hay vô nghĩa thì đó không phải lựa chọn thực chất

• 2. Mỗi lựa chọn đều đi kèm cả kết quả mong muốn lẫn kết quả bất lợi

  • Những tuyên bố sáo rỗng khiến người ta thấy dễ chịu vì không có mặt tiêu cực, nhưng đó không phải quyết định thực sự
  • Ví dụ về chi phí thực tế của việc theo đuổi “thiết kế tuyệt vời”:
    • Cần designer giỏi → cần đội ngũ lớn hơn
    • Engineer phải quan tâm đến độ hoàn thiện UX ngang với việc scale database
    • Cần đầu tư vào design system
    • Tốc độ phát triển tính năng chậm lại — không chỉ cần chạy được mà còn phải được thiết kế tốt
    • Phải từ chối cả những yêu cầu từ khách hàng nếu chúng làm chất lượng thiết kế xấu đi
    • Không phải mọi khách hàng đều đồng ý về thế nào là “thiết kế tốt”, nên sẽ có người hài lòng và cũng có người không
  • Lựa chọn chiến lược là một package deal — không thể chỉ lấy ưu điểm mà tránh được điểm yếu
  • Nếu mô tả rõ các hệ quả này trong chiến lược, có thể giảm bớt cách hiểu cá nhân và giúp đồng bộ các quyết định hằng ngày

• 3. Không chỉ nhất quán mà còn củng cố lẫn nhau

  • Cần dùng danh sách lựa chọn-hệ quả để kiểm tra mâu thuẫn, vì xung đột thường ẩn trong các hiệu ứng bậc hai
  • Ví dụ: “đội ngũ nhỏ” và “giàu tính năng” nhìn qua có vẻ không liên quan, nhưng thường lại xung đột vì đội nhỏ thì sản phẩm cũng phải nhỏ và đơn giản
    • Tuy nhiên, có thể giải quyết bằng lựa chọn bổ sung là “đội nhỏ + core nhỏ + hệ sinh thái mở rộng được” — hệ sinh thái sẽ đảm nhiệm phần giàu tính năng
    • Mỗi lựa chọn đều kéo theo những hàm ý riêng, và quá trình khám phá đó chính là cách đi đến một bộ quyết định nhất quán
  • Lý tưởng không chỉ là không xung đột, mà là củng cố lẫn nhau — “khả năng mở rộng” hỗ trợ “giàu tính năng”, còn đội nhỏ giữ cho core nhỏ gọn để tạo không gian cho hệ sinh thái phát triển
  • Khi những lựa chọn mạnh mẽ củng cố lẫn nhau, công ty sẽ hình thành một cá tính kiểu “thế giới nên vận hành như thế này”, và những khách hàng đồng điệu sẽ yêu nó sâu sắc hơn
  • Toàn bộ tổ chức sẽ di chuyển nhanh hơn, việc tranh luận lại các đánh đổi sẽ ít đi, và tạo ra một vòng lặp tích cực nơi sự nhất quán được cảm nhận như năng lực thực thụ

Cách biến lựa chọn yếu thành lựa chọn mạnh

• Khi xây dựng lựa chọn chiến lược, mọi người thường lặp đi lặp lại những lựa chọn giả yếu không vượt qua được Opposite Test
  • Vì đã có sẵn bên mình thích, họ có xu hướng biến phía đối diện thành thứ hiển nhiên là xấu để lựa chọn của mình “thắng”
• Điều quan trọng là rút ra được góc nhìn hợp lệ đang ẩn dưới cách diễn đạt yếu đó
• Những câu hỏi hữu ích:
  • Có công ty thành công và được yêu mến nào chọn phía “xấu” đó không?
  • Vì sao mọi người vẫn yêu thích họ dù có những nhược điểm ấy?
  • Chính điều “được yêu thích” đó mới là phía đối lập thực sự của lựa chọn chiến lược
• Ví dụ cụ thể: ứng dụng ghi chú
  • Các app all-in-one như Apple Notes, Bear — kiểm soát toàn bộ trải nghiệm mà không cần plugin hay API, để đạt được sự nhất quán đẹp mắt
  • Obsidian — cung cấp một dải chức năng tải về đáng kinh ngạc; dù có người phàn nàn UX lộn xộn, nó vẫn được yêu thích nhờ nhiều lựa chọn tính năng và khả năng tự xây dựng hệ thống quản lý thông tin của riêng mình
  • Khi hỏi “vì sao Obsidian vẫn được yêu thích dù UX lộn xộn”, ta chạm tới lựa chọn thật sự là “all-in-one vs khả năng mở rộng vô hạn”

Cám dỗ của việc muốn chọn “cả hai”

• Vì cả hai phía đều hấp dẫn, nên cám dỗ kéo các yếu tố từ phía đối diện vào là điều tất yếu
  • Bạn đã làm một sản phẩm all-in-one, nhưng thấy plugin của đối thủ rất được ưa chuộng nên bắt đầu cân nhắc plugin
  • “Hãy tăng giá đi, chúng ta đang để tiền rơi mất” hoặc “hãy chậm lại và trau chuốt hơn, như thế này thật đáng xấu hổ”
• Cám dỗ này nghe thuyết phục chính vì lựa chọn đối diện cũng thực sự xuất sắc
• Lý do chiến lược tồn tại là để bất kỳ ai trong tổ chức cũng có thể tự tin nói rằng “đây là ý tưởng tốt ở mức trừu tượng, nhưng không phù hợp với gói đánh đổi mà chúng ta đã chọn”
• Nguyên tắc cốt lõi: khi có xung đột thì giữ vững lựa chọn chiến lược; khi không xung đột thì chọn điều tốt nhất
  • Ví dụ: theo chiến lược “giá thấp nhất”, nhưng nếu có thể cải thiện chất lượng mà không làm tăng chi phí thì vẫn nên chấp nhận
  • Nhưng trong phần lớn trường hợp sẽ có xung đột, và nếu ra quyết định thiếu nhất quán thì bạn sẽ rơi vào vị thế chỉ có thua — không đủ chất lượng để tạo trung thành, cũng không đủ sức mạnh để thắng ở những use case phức tạp
• Agile Manifesto thể hiện rất rõ thái độ này — “phần mềm chạy được hơn là tài liệu toàn diện” không có nghĩa tài liệu là xấu, mà nghĩa là khi thời gian có hạn (mà luôn là có hạn), ta đầu tư nhiều hơn về một phía
  • Tuyên ngôn này nói rõ: “dù các mục bên phải cũng có giá trị, chúng tôi coi trọng các mục bên trái hơn”
• Có thể áp dụng cùng một mô thức cho chiến lược: nếu theo chiến lược giá rẻ thì đừng đưa vào sản phẩm cao cấp chỉ để “bắt luôn nhóm khách đó”, nhưng vẫn chấp nhận nâng chất lượng miễn là không làm phương án giá rẻ bị đe dọa
• Đây là một lựa chọn nghiêm ngặt, không phải sự cân bằng

Bảng ví dụ về các lựa chọn chiến lược

• Giá thấp nhất vs giá premium
  • Giá thấp nhất: thị trường lớn nhất, định vị về khả năng tiếp cận và tính hợp lý, chặn được nhiều đối thủ chỉ thắng bằng giá / không thể đầu tư mạnh vào quảng cáo·sales, phụ thuộc vào truyền miệng, có trần về chất lượng·tính năng
  • Giá premium: biên lợi nhuận cao để đầu tư vào thương hiệu·phân phối, tín hiệu địa vị tự nó trở thành một tính năng / thị trường nhỏ hơn, cần liên tục đầu tư vào thương hiệu (marketing, prestige), nếu ngừng đầu tư thì premium sẽ sụp đổ
• UX all-in-one nhất quán vs hệ sinh thái có thể mở rộng
  • All-in-one: trải nghiệm được thiết kế kỹ để tạo niềm tin và thói quen, support·onboarding đơn giản / toàn bộ độ rộng tính năng là trách nhiệm của chính công ty, người dùng power user cần plugin·scripting sẽ rời đi
  • Hệ sinh thái: có được các tính năng long-tail mà bản thân công ty không thể cung cấp, đối tác đóng vai trò như kênh phân phối / tính nhất quán UX giảm, bảo mật·tương thích·support trở thành vấn đề chuỗi cung ứng nằm ngoài tầm kiểm soát
• UX đơn giản vs tính năng mạnh mẽ
  • UX đơn giản: thời gian đạt giá trị ngắn, tăng trưởng self-serve, tải nhận thức thấp / mất các deal cần workflow phức tạp·governance, bất lợi trong checklist·RFP
  • Tính năng mạnh mẽ: thắng trong các workflow rủi ro cao, doanh thu trên mỗi khách hàng cao, tỷ lệ giữ chân cao nhờ chi phí chuyển đổi / onboarding cần đào tạo·setup·chuyên gia, support trở thành chi phí bắt buộc
• Support tối thiểu vs support high-touch
  • Support tối thiểu: biên lợi nhuận cao, tập trung vào sản phẩm, buộc phải nâng chất lượng usability và tài liệu / không thể đáp ứng người mua đòi hỏi điện thoại·SLA, mất vòng lặp phản hồi khi khách rời bỏ
  • Support high-touch: bắc cầu qua những khoảng trống mà đối thủ không lấp được, tạo lòng trung thành và sự khác biệt, là động cơ khám phá sản phẩm khi mỗi ngày đều nghe được sự thật / chi phí cao và khó scale, tạo kỳ vọng 24/7 và sự phụ thuộc
• Sự đơn giản cho đội nhỏ vs độ phức tạp enterprise
  • Đội nhỏ: chu kỳ bán hàng ngắn, khách hàng có thể thành công mà không cần consultant / mất các deal enterprise đòi hỏi governance·audit·tích hợp doanh nghiệp
  • Enterprise: vượt qua cổng procurement và lấy được ngân sách lớn, tích hợp·phân quyền·governance tạo ra lock-in và giữ chân / chu kỳ bán hàng dài đòi hỏi vốn·kiên nhẫn·cỗ máy sales, sản phẩm·UX bị phình to
• Tốc độ tiên phong vs sự ổn định vững chắc
  • Tốc độ tiên phong: sự mới lạ tạo khác biệt, thu hút builder và early adopter / bug·lỗi trở thành một phần của thương hiệu, các use case bảo thủ sẽ rời đi
  • Ổn định vững chắc: niềm tin trong các workflow quan trọng trở thành hào phòng thủ, “không bao giờ hỏng” thắng “mới lạ”, support thấp·churn thấp / tốc độ chậm, cái mới thu hút sự chú ý và ngân sách, dễ bỏ lỡ cơ hội frontier và có nguy cơ tụt hậu
• Mã nguồn mở vs mã nguồn đóng
  • Mã nguồn mở: rào cản niềm tin thấp, cộng đồng đẩy nhanh tính năng·tích hợp / core bị cảm nhận là “miễn phí” nên khó kiếm tiền, governance·bảo trì mang tính chính trị và hao tổn
  • Mã nguồn đóng: kiểm soát hoàn toàn roadmap·UX·licensing·pricing, governance đơn giản / chậm được chấp nhận ở các phân khúc lo ngại tính minh bạch·lock-in, phải tự tài trợ tốc độ phát triển mà không có đòn bẩy cộng đồng
• Ít tính năng nhưng độ hoàn thiện cao vs nhiều tính năng
  • Ít nhưng hoàn thiện: độ chỉn chu và nhất quán tạo ra sự hài lòng·giữ chân·truyền miệng, độ phức tạp thấp → ít bug·ít tài liệu·ít ticket·lặp nhanh / bất lợi trong checklist·RFP, mất khách ở các edge case của phân khúc cụ thể vì không đáp ứng được
  • Nhiều tính năng: có nhiều ô được tick hơn trong so sánh procurement, mở rộng thị trường và đa dạng đường upsell nhờ độ phủ rộng / chất lượng không đồng đều, UX mất nhất quán, support·tài liệu tăng bùng nổ

Kết luận

• Việc chấp nhận điểm yếu của lựa chọn mình đưa ra là điều đau đớn, và sức hấp dẫn từ ưu điểm của lựa chọn đối diện chính là bản chất của chiến lược
• Nếu lựa chọn không khó, thì đó không phải là lựa chọn thật sự. Một lựa chọn luôn phải bao gồm sự từ bỏ và tác dụng phụ
• Hãy đưa ra lựa chọn khó ngay bây giờ để giảm gánh nặng cho những thành viên còn lại, và để mọi người đều có thể tự đưa ra quyết định khôn ngoan một cách độc lập

[bbulbum]

Tôi nhớ rằng trong nhiều trường hợp, vì ưu điểm của lựa chọn khác mà người ta lại chọn phương án ở giữa, hoặc đưa ra ngoại lệ, kiểu như vậy.

[roxie]

Có vẻ là một nhận định rất hay. Nếu việc đưa ra quyết định đã dễ dàng, thì có lẽ đó vốn không phải là chuyện thật sự cần phải quyết định!