Bạn minh bạch đến đâu – Phần III – Minh bạch trong ra quyết định – Spotify, Linkedin, Agoda

Với những công ty công nghệ có sản phẩm riêng, câu hỏi được đặt ra đầu tiên có lẽ là “Vì sao bạn xây dựng sản phẩm này” – hay nói cách khác: Vấn đề bạn đang muốn giải quyết là gì, và vì sao người dùng nên dùng sản phẩm của bạn.

Khi bạn đã có một sản phẩm cơ bản, câu hỏi tiếp theo được đặt ra là “Vì sao tính năng X cần được xây dựng”. Có nhiều cách tiếp cận câu hỏi này.

Một trong những cách phổ biến, đó là hỏi ý kiến chuyên gia. Các cuộc họp sẽ được tổ chức giữa các chuyên gia (ở nhiều công ty, quản lý được mặc định coi là chuyên gia để tham dự các cuộc họp này) – những người sẽ mang đến dữ liệu và thông tin hữu ích, thảo luận với nhau để tìm ra câu trả lời. Cách làm này rất phổ biến, đến mức người ta không nhận ra những sai lầm dễ đi kèm với nó.

Thứ nhất, những dữ liệu được dẫn chứng thường rất chung chung, không liên hệ trực tiếp đến giải pháp hay những tính năng cần xây dựng. Tôi từng chứng kiến một quản lý (từng làm quản lý nhiều năm ở Yahoo Singapore & US) dẫn chứng: Churn rate (tỷ lệ bỏ) của số điện thoại ở Malaysia là 15%/năm, vì thế dùng số điện thoại để đăng nhập là rất nguy hiểm, đặc biệt khi số điện thoại bị bỏ có thể sau này sẽ được một người khác mua lại. Vì thế, vị này quyết định SSO (Single sign-on) platform (tạm dịch: cổng đăng nhập chung) sẽ bắt buộc người dùng phải điền email khi đăng ký, mặc dù SSO được dùng trong 30+ sản phẩm của Astro. (!?)

Thứ hai, khi những dữ liệu không đủ để đưa ra kết luận, các chuyên gia thường dùng kinh nghiệm và cả cảm tính để tranh luận. Chẳng hạn, “tôi thấy layout (bố cục) này đẹp hơn và truyển tải thông tin  dễ dàng hơn”, hoặc “Call to action phải đổi sang màu Xanh lá cây thì sẽ nhiều click hơn”.

Thứ ba, vì kết quả của những cuộc họp trên đến từ các “chuyên gia”, những kết luận sau cuộc họp thường được coi là “chân lý” và được ứng dụng một cách mù quáng. Một dấu hiệu dễ nhận thấy, đó là khi có người hỏi: “Vì sao lại có logic này?”, câu trả lời thường là “Vì 6 tháng trước nhóm chuyên gia đã họp và kết luận như vậy. Ông A đã quyết định rồi”.

Optimizely, một công ty tương đối thành công trong mảng Analytics và A/B testing, từng đưa ra lời khuyên cho ứng dụng Secret Escapes: Không nên cho người dùng Skip bước đăng ký trước khi sử dụng app [1]. Một lời khuyên có khả năng gây tranh cãi – Nếu người dùng có thể Skip bước đăng ký, họ có thể trải nghiệm trước rồi quyết định đăng ký, như vậy biết đâu khả năng đăng ký sẽ cao hơn? Kết quả của lời khuyên này: Secret Escapes tăng 2 lần số đăng ký [1]. Điều thú vị ở chỗ, với một khách hàng khác, Optimizely đưa ra lời khuyên trái ngược – Cho phép người dùng Skip bước đăng ký, kết quả là lượng đăng ký không giảm, nhưng số lượng giao dịch tăng đáng kể. (Tiếc là tôi không tìm lại được ví dụ này – Tuy nhiên lời khuyên “Skip bước đăng ký” là khá phổ biến, chẳng hạn Nielsen Norman Group cũng đưa ra lời khuyên này cho các website thương mại điện tử [2])

Nếu cho 2 “chuyên gia” ngồi lại và tranh luận – nên hay không nên cho phép người dùng Skip bước đăng ký – họ có thể ngồi tranh luận hàng tháng trời. Và dù ai thắng, ai thua, kết quả của cuộc tranh luận này cũng không có nhiều ý nghĩa – chỉ đến khi được kiểm định thực tế, chúng ta mới biết được một kết luận là đúng hay sai.

Our product approach needs to change

Các cuộc thảo luận nên xây dựng sản phẩm thế nào thường diễn ra như này

Hai phần trước nói về tính minh bạch trên khía cạnh văn hoá với Netflix và Gitlab là 2 ví dụ cụ thể. Bài viết này bàn luận về tính minh bạch trong quyết định, đặc biệt là về định hướng xây dựng sản phẩm, thông qua các dẫn chứng về Spotify, Linkedin, Amazon, Grab, Booking.com và Agoda.

Tiện nói về Spotify – công ty này cũng công bố cho thế giới biết cách thức nó hoạt động thế nào, qua 2 video cực ngắn gọn và súc tích [3,4]. Tôi cực thích cách vận hành giống như Spotify đang làm, và từng định viết một bài về Spotify, nhưng cuối cùng không biết viết gì hơn vì 2 video đó đã giải thích rất đầy đủ và dễ hiểu, tối viết gì có chăng cũng chỉ là dịch lại.

Ở video thứ 2, có đoạn nói về “Experiment-friendly culture” của Spotify –  Các quyết định được đưa ra đều là data-driven, tuyệt đối không phải là opinion-driven, ego-driven hay authority-driven. Các squad (đọc [3] để biết squad là gì, Spotify tổ chức công ty ra sao) sẽ tự đưa ra giả thuyết (hypothesis), kiểm chứng và đặt câu hỏi “chúng ta đã học được gì (sau khi kiểm chứng)”,  và “chúng ta sẽ thử giả thuyết nào tiếp theo?” Ví dụ, khi có 2 lựa chọn A và B, giải pháp được đưa ra là, hãy thử cả 2 và quyết định [4]. Hình dưới đây được cắt từ trong video nói lên tất cả điều đó:

Cách ra quyết định ở Spotify

Phương pháp được Spotify thực hiện nêu trên là A/B testing [5] – nếu có 2 lựa chọn A và B, cả sẽ sẽ được thực hiện và kiểm nghiệm trên 2 tập người dùng khác nhau (nhưng tương đương nhau) – Lựa chọn nào đem lại kết quả tốt hơn sẽ được chính thức áp dụng với toàn bộ tập người dùng. Mỗi lần như vậy được tính là một thử nghiệm (experiment) cho một giả thuyết nào đó.

Phương pháp này cũng được ứng dụng ở Linkedin – mỗi năm Linkedin thực hiện hàng ngàn thử nghiệm [6]. Linkedin còn xây dựng hẳn một nền tảng A/B testing cho riêng mình tên là XLNT [7] chứ không sử dụng những dịch vụ có sẵn, như trường hợp Gitlab đang sử dụng dịch vụ Optimizely [8]. (Lại một ví dụ nữa về tính minh bạch ở Gitlab – họ đưa cả quyết định sẽ mua dịch vụ của Optimizely lên mạng 1 năm trước, như hình dưới)

Gitlab: “Phải mua Optimizely để test”

Không khó để biết những công ty nào sử dụng A/B testing trong ra quyết định. Chỉ cần Google “tên công ty + A/B testing”, bạn sẽ ngạc nhiên khi thấy hầu như các công ty công nghệ lớn đều sử dụng. Chẳng hạn:

  • Amazon [9]
  • Grab [10]
  • Booking.com [11]
  • Agoda [12]

Tôi từng phỏng vấn một lập trình viên backend đến từ Agoda, và cũng được chia rẻ trực tiếp rằng A/B testing là “điều bắt buộc” trước khi một chức năng/thay đổi được áp dụng cho toàn bộ người dùng.

Tôi cho rằng phương pháp này còn có thể ứng dụng bên ngoài mảng phát triển sản phẩm. Ví dụ với mảng sale, chúng ta có thể đặt ra các giả thuyết:

  • Khách hàng đến từ trang tìm kiếm, sau đó liên hệ thông qua contact form, sẽ có nhiều khả năng chuyển sang bước tiếp theo trong sale funnel hơn
  • Khách hàng được tiếp cận bằng cold call có conversion khoảng 10%
  • Khách hàng đến từ trang tìm kiếm, dù là từ keywords trả phí hay từ organic keywords, đều có conversion rate như nhau..
  • Đặt Call to action Submit form lên đầu tiên và để màu nổi bật sẽ tăng lượng click, hơn là đặng Submit form button ở dưới cùng.

Những giả thuyết này đều có thể được kiểm định bằng A/B testing hoặc con số thực tế. Việc chủ động đặt ra giả thuyết và kiểm chứng hiệu quả hơn nhiều so với việc tổng kết số liệu, họp và cố gắng tìm ra một insight nào đó từ dữ liệu tổng hợp – một cách làm khá phổ biến ở các công ty, dù không hiệu quả. Khi bạn đặt ra một giả thuyết, dù bạn chưa có số liệu, bạn đã biết insight sẽ nằm ở đâu rồi.

Tóm lại, việc minh bạch trong quyết định có thể được thực hiện trong nhiều chức năng của một công ty – chỉ cần con người thực sự có experimental mindset – Dám nghĩ, dám kiểm tra, dám chấp nhận sai lầm. Khi đó mọi quyết định sẽ tự mang tính hướng dữ liệu, và những quyết định này hoàn toàn dễ dàng được công khai.

Disclaimer: Bài viết này để bày tỏ quan điểm cá nhân và thảo luận, không nhằm mục đích chứng minh cho 1 vấn đề nào là đúng/sai. Tác giả đã cố gắng đưa ra trích dẫn/nguồn cho các luận điểm được đưa ra – tuy nhiên sẽ không dẫn chứng cụ thể đến từng mục, từng dòng, và có thể sẽ có các luận điểm không được trích dẫn, do tác giả từng đọc nhưng không tìm lại được nguồn.

Trích dẫn:

[1] https://www.optimizely.com/resources/experimentation-case-studies/?utm_campaign=emea-kickstart2018

[2] https://www.nngroup.com/articles/optional-registration/

[3] https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/

[4] https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/

[5] https://en.wikipedia.org/wiki/A/B_testing

[6] https://engineering.linkedin.com/blog/2015/11/top-five-lessons-from-running-a-b-tests-on-the-world-s-largest-p

[7] https://engineering.linkedin.com/ab-testing/xlnt-platform-driving-ab-testing-linkedin

[8] https://gitlab.com/gitlab-com/www-gitlab-com/issues/1064

[9] https://aws.amazon.com/blogs/machine-learning/ab-testing-at-scale-amazon-machine-learning-research/

[10] https://engineering.grab.com/feature-toggles-ab-testing

[11] https://medium.com/booking-writes/a-b-tests-and-copy-what-why-how-8cc4ae17eae2

[12] https://medium.com/@lolevsky/are-you-sure-in-your-new-feature-a-b-testing-might-help-3068796dbdc

Comments

comments

 

Tung Dao

Tung is a Msc. in IT Management from University College Dublin. Tung is currently working in Astro Bhd as Scrum Master.