#110: Mình học được gì từ lá thư nội bộ của Apple?

Red pill or blue pill?

Photo by Dall-E.

Chào buổi tối!

Bạn vẫn khoẻ chứ? Tuần vừa rồi có gì đáng nhớ không? Kể cho mình nghe nhé!

Hôm vừa rồi mình đọc được một đoạn thư trao đổi giữa Steve Jobs (CEO Apple thời bấy giờ), Scott Forstall và Philip Schiller (2 phó chủ tịch cấp cao), và nhận ra nhiều bài học hay dành cho một người làm sản phẩm.

Thực ra những bài học này không mới, nhưng khi được nhìn ở góc độ của những người lãnh đạo của một công ty tỉ đô, chúng trở nên thú vị hơn nhiều.

Tóm lược nội dung đoạn email trao đổi: Jobs, Scott và Philip bàn luận xem có nên cho phép ứng dụng Facebook trên iPad tích hợp các tiểu ứng dụng (mini apps) hay không. 

👉 Bạn có thể đọc đầy đủ nội dung đoạn email trao đổi tại đây

Dưới đây là 3 bài học mình rút ra được:

• Xem xét ảnh hưởng lên người dùng/ đối tác hiện tại

• Cẩn thận với việc tạo ra tiền lệ

• Quay trở về với định nghĩa

Chúng ta cùng đi qua từng bài học nhé!

1. Xem xét ảnh hưởng lên người dùng/ đối tác hiện tại

Nhiều công ty đổ rất nhiều tiền để quảng cáo, cũng như cố gắng xây dựng nhiều loại tính năng để thu hút nhiều người dùng ban đầu, để rồi sau đó, vì muốn thu hút thêm các nhóm khách hàng mới, họ đưa ra các quyết định làm ảnh hưởng tới tập người dùng hiện tại (nếu bạn còn nhớ vụ Evernote quyết định tăng giá sản phẩm khiến cho những người dùng cũ tức giận) 

Một người dùng giận dữ trên Reddit

Khi Steve Jobs không đồng ý với việc cho phép Facebook tích hợp mini apps dưới dạng webview (do sợ Facebook sẽ đưa người dùng tới các ứng dụng web không được Apple kiểm duyệt), Scott cho rằng điều này sẽ làm ảnh tưởng tới Flipboard - một ứng dụng đọc tin tức - vì họ đã và đang làm như vậy rồi.

Mình nghĩ lo lắng của Scott là có cơ sở, vì nếu Apple chỉ vì muốn cạnh tranh với Facebook mà làm ảnh hưởng tới người dùng của Flipboard (và cơ số các app khác) thì không khác gì họ đang tự bắn vào chân mình. 

Ý này làm mình nhớ tới bài viết: There are no small changes của Intercom.

2. Cẩn thận với việc tạo ra tiền lệ

Đây là điểm mình ấn tượng nhất ở cuộc trao đổi này. Các nhà lãnh đạo Apple lo rằng nếu cho phép Facebook tích hợp Mini apps, rất nhiều các công ty (có thể là đối thủ) khác sẽ dựa vào đó mà làm theo. Nỗi lo này cho thấy tầm nhìn dài hạn của họ, về việc dập một đám cháy nhưng có thể gây ra nhiều đám cháy khác. 

Khi làm sản phẩm, mình cũng hay phải đối mặt với các quyết định tương tự: nếu mình “đặc cách" cho một khách hàng, đồng ý là mình có thể “win" khách đó, nhưng những khách hàng khác có thể tị nạnh hay thậm chí khiếu nại về sau nếu họ phát hiện ra. 

Khi thiết kế tính năng mới cũng vậy, sẽ rất dễ để chúng ta dựa quá nhiều vào một số use-case cụ thể (mà khả năng cao là đến từ một vài khách hàng thân thiết), để rồi từ đó làm ra tính năng mà chỉ một nhóm công ty cụ thể mới dùng được.

Những quyết định kiểu này tạo ra “tiền lệ" khiến cho nhóm công ty đó nghĩ rằng họ được ưu ái hơn và từ đó tiếp tục đặt nhiều áp lực lên phía làm sản phẩm để đáp ứng các yêu cầu (éo le) khác. 

3. Quay trở về với định nghĩa

Có lẽ đây là bài học đắt giá nhất với mình từ khi làm sản phẩm: Việc định nghĩa rõ ràng và cụ thể một tính năng sẽ giúp tiết kiệm rất, rất (x3,14) nhiều thời gian về dài hạn. 

Trong cuộc trao đổi, Scott nhắc đến việc Mark Zuckerberg phản đối quyết định từ phía Apple dựa vào sự mập mờ trong định nghĩa về “đường dẫn ứng dụng" (thế nào mới là link dẫn tới ứng dụng, và thế nào mới là link dẫn tới web?)

Đây chính là điểm yếu của Apple, do họ đã không suy tính tới định nghĩa này từ ban đầu và đưa vào hệ thống luật của họ. Bây giờ, Apple rơi vào một tình thế là họ không đồng ý với những gì Facebook chuẩn bị làm, nhưng họ lại lỡ cho phép các công ty khác làm rồi.

Việc định nghĩa sản phẩm nghe thì dễ nhưng thực ra lại cực khó:

• Nhiều khi bạn mô tả sản phẩm một kiểu, nhưng khách hàng lại hiểu theo một kiểu khác. Ví dụ, ngày xưa hồi làm ở Holistics, mình có đặt tên cho một tính năng là Drill-through, giúp khách hàng nhảy từ dashboard này qua dashboard khác một cách nhanh chóng.
  Các dashboard có thể chứa dữ liệu liên quan đến nhau, không nhất thiết là con của nhau. Thế nhưng, khách hàng của mình khi nghe giới thiệu xong hoặc đọc trên website đa phần đều gọi tính năng này là Drill-down, tức là bổ dữ liệu từ tổng quát tới chi tiết (ví dụ: từ Region > Country > Province > City), vì họ quen phân tích dữ liệu từ trên xuống. Khi nghe tới chữ “Drill” cùng khả năng “nhảy từ dashboard này qua dashboard khác”, họ nghĩ như vậy ngay.
  

• Hoặc là khi làm việc với các bạn lập trình viên, ngày xưa mình hay mô tả tính năng kiểu: Tính năng A nó nằm trong tính năng B. Xong toàn bị chửi vì “thế nào là nằm trong???”
  Nằm trong có nghĩa là mở B ra sẽ thấy A, hay là thay đổi B thì sẽ thay đổi cả A? tính năng C cũng giống với B, vậy A có “nằm trong" C hay không??
  Để mô tả được sự “nằm trong" cần không biết bao nhiêu biểu đồ và các bản thiết kế thử, và test thử. Việc định nghĩa không chỉ ảnh hưởng tới phía code, mà cả phía design và sau này là phía chăm sóc khách hàng nữa (để họ viết các bài hướng dẫn cho chính xác). 

Thời gian đầu mình học làm sản phẩm, đúng ra là toàn học cách định nghĩa sản phẩm ấy chứ :) 

Đây là thiết kế hệ thống của Drill-through. Rất phức tạp phải không =)) Nhưng biểu đồ này là cần thiết để mô tả tính năng này. Nguồn: Holistics.io

—

Thế mới thấy làm sản phẩm là một việc khó. 

Đôi khi chỉ là một tính năng bé xíu xiu, nhưng để người dùng cuối nhìn thấy nó lù lù trên sản phẩm cũng là không biết bao nhiêu cuộc họp/ cãi vã/ sửa đổi rồi lại họp/ cãi vã/ sửa đổi.

Dù có bao nhiêu dữ liệu hay nghiên cứu đi chăng nữa, cuối cùng người làm sản phẩm đều phải có một niềm tin sắt đá rằng những gì mình đang phát triển sẽ mang lại giá trị cho người dùng. Trên thực tế, người dùng có đón nhận (và hiểu) giá trị mà chúng ta cung cấp hay không, lại là một chuyện rất khác =))

Weekly question: Red pill, Blue pill 

Hôm vừa rồi mình đi team bonding, được sếp hỏi câu này, thấy thú vị ghê nên mình muốn thử hỏi mọi người để xem kết quả ra sao. 

Giả sử mọi người trên thế giới phải lựa chọn uống 1 trong 2 viên thuốc: Xanh và Đỏ. Bạn cũng phải đưa ra lựa chọn.

• Nếu bạn chọn màu Xanh:

  • Nếu tổng số người chọn màu Xanh > số người chọn màu Đỏ: Tất cả mọi người sẽ sống sót. Bạn sẽ sống sót.

  • Nếu số người chọn màu Xanh < số người chọn màu Đỏ: Tất cả những người chọn màu xanh sẽ chết, chọn màu đỏ sẽ sống. Bạn sẽ chết.

• Nếu bạn chọn màu Đỏ: Chắc chắn bạn sẽ sống. Nhưng hãy nhớ rằng, nếu số người chọn màu Xanh ít hơn số người chọn màu Đỏ, bạn sẽ sống trong khi một số người khác (chọn màu Xanh) sẽ chết. 

Câu hỏi là bạn sẽ chọn việc mình chắc chắn sống và có khả năng một số người sẽ chết (Đỏ), hay là chọn việc tất cả mọi người có khả năng cùng sống sót, nhưng bạn có khả năng sẽ chết (Xanh)? 

Suy nghĩ kĩ và trả lời bằng cách lựa chọn poll dưới đây nhé! 

Mình sẽ rất vui nếu bạn muốn chia sẻ về lý do bạn lựa chọn, cũng như những suy nghĩ liên quan, qua email ;) 

---

Cảm ơn bạn đã dành thời gian đọc thư! Đừng ngại chia sẻ lá thư này tới bạn bè nếu bạn thấy nó hữu ích!

Như thường lệ, nếu có điều gì newsletter này làm bạn suy nghĩ, bạn có thể reply và chia sẻ với mình, mình sẽ rất rất vui đó (＊๑˘◡˘)

Chúc bạn một buổi tối thư giãn và một tuần mới thật năng suất!

Thân,
Tuấn Mon

P/s: Tháng 10 tới mình và Akwaaba Tung sẽ khai giảng khóa học Writing On the Net - nơi bọn mình sẽ chia sẻ những hệ thống và công cụ để bắt đầu hành trình blogging bền vững trên Internet. Nếu bạn quan tâm, bạn có thể:

• Tìm hiểu thêm về nội dung khóa học, giảng viên và rất nhiều thứ thú vị khác của lớp tại đây

• Đăng ký luôn và ngay cho nóng!