Kích thước backlog tỷ lệ nghịch với tần suất trò chuyện với khách hàng

• Càng trò chuyện thường xuyên với khách hàng, kích thước backlog càng giảm
• Điều quan trọng là thay thời gian lập kế hoạch bằng các cuộc trò chuyện với khách hàng
• Càng có nhiều người trung gian giữa nhà phát triển và khách hàng, sản phẩm càng khó đáp ứng nhu cầu của khách hàng
• Backlog lớn đồng nghĩa với việc có nhiều giả định chưa được kiểm chứng và khả năng tạo ra giá trị cho khách hàng thấp

Hãy tập trung vào thiết kế các thành phần kỹ thuật hơn là thiết kế UI

• Đừng dành quá nhiều thời gian cho thiết kế UI; điều quan trọng là nhanh chóng phát hành một UI cơ bản rồi cải thiện nó thông qua phản hồi của khách hàng
• Cần giữ nợ kỹ thuật ở mức thấp để có thể nhanh chóng thực hiện những thay đổi mà khách hàng cần

Cách mọi người nghĩ rằng họ dùng ứng dụng khác với cách họ thực sự dùng

• Việc quan sát cách khách hàng sử dụng ứng dụng là rất quan trọng
• Khi quan sát trực tiếp hành vi của người dùng, bạn có thể thu được những insight mà chỉ số định lượng đơn thuần không thể cho thấy

Triển khai account spoofing

• Đầu tư vào tính năng account spoofing là rất quan trọng để hiểu một khách hàng cụ thể thực sự đang nhìn thấy màn hình nào
  • Account Spoofing: tính năng cho phép quản trị viên sử dụng ứng dụng như một người dùng production cụ thể
• Nhờ đó có thể chẩn đoán vấn đề hiệu quả hơn và giảm sự phụ thuộc vào dữ liệu thử nghiệm

Tầm quan trọng của trang đầu tiên

• Cần cung cấp ngắn gọn những thông tin phù hợp nhất cho khách hàng khi họ lần đầu truy cập ứng dụng
• Nếu cố nhồi nhét quá nhiều thông tin vào trang đầu tiên, gánh nặng nhận thức của người dùng sẽ tăng lên

Khách hàng là marketer quan trọng nhất

• NPS(Net Promoter Score) là một chỉ số tốt cho thấy khách hàng có thiện cảm đủ mạnh để giới thiệu sản phẩm hay không
• Có thể chi tiền cho quảng cáo, nhưng bắt đầu từ những khách hàng hài lòng là một chiến lược marketing hiệu quả

MVP không có ý nghĩa nếu không được cải tiến lặp lại

• MVP không nên chỉ là cái cớ để cung cấp trải nghiệm khách hàng chất lượng thấp với lý do áp lực thời hạn
• MVP giúp xác định có cần lặp lại thêm hay không, và nếu cần thì nên cải thiện điểm nào

Ý kiến của GN⁺

• Điều quan trọng nhất trong bài viết này là tầm quan trọng của việc phát triển sản phẩm phản ánh nhu cầu của người dùng thực tế thông qua đối thoại liên tục với khách hàng
• Bài viết nhấn mạnh tầm quan trọng của thiết kế UI linh hoạt và các thành phần kỹ thuật có thể nhanh chóng phản ánh phản hồi của khách hàng
• Bài viết cho thấy việc liên tục cải thiện sản phẩm vượt ra ngoài MVP và nâng cao mức độ hài lòng của khách hàng có thể dẫn tới thành công dài hạn
• Bài viết chia sẻ những bài học rút ra từ cuộc sống startup và mang đến các insight thực tiễn cho nhà sáng lập hoặc nhà phát triển

[GN⁺]

Ý kiến trên Hacker News

• Ý kiến về cách tổ chức tính năng/cải tiến

  • Theo kinh nghiệm, chiến lược biến mọi ý tưởng thành ticket là không hiệu quả. Cách này tạo ra một “ngăn đá” đầy những ý tưởng sẽ chẳng bao giờ được dùng tới.
  • Ngay cả khi cần một ý tưởng trong ngăn đá cho một thương vụ quan trọng, người ta vẫn không nhớ là ý tưởng đó có tồn tại nên lại tạo ticket mới.
  • Ưu tiên các ticket có khả năng triển khai trong ngắn hạn hoặc trung hạn, còn những ý tưởng khác thì lưu riêng.
  • Đội ngũ engineering duy trì danh sách technical debt muốn xử lý, còn PM duy trì danh sách các khả năng cải tiến theo từng dự án.
  • Với tính năng/sản phẩm mới thì viết PRD, nhưng không chuyển ngay thành ticket.
  • Một backlog khổng lồ mà phần lớn sẽ không bao giờ được xử lý là dấu hiệu của một PM yếu, sợ nói “không”.

• Mối quan hệ giữa kích thước backlog và tỷ lệ thay PM

  • Kích thước của backlog tỷ lệ nghịch với tỷ lệ thay PM.
  • Với PM lâu năm, backlog là công cụ gợi nhớ cho các cuộc trao đổi về sản phẩm trong quá khứ.
  • PM mới nhìn vào backlog sẽ thấy rối rắm và cố dọn dẹp những thứ họ không hiểu.

• Ý kiến phản đối việc duy trì backlog dựa trên khách hàng

  • Các đội ngũ duy trì backlog phần lớn lấy backlog từ khách hàng.
  • Việc “tìm ra tính năng giúp cải thiện cuộc sống của khách hàng rồi biến nó thành tính năng tiếp theo” không hề đơn giản.
  • Nếu có nhiều khách hàng, và những tính năng giúp cải thiện cuộc sống của từng người lại không liên quan đến nhau và còn phức tạp, thì phải làm sao?
  • Phải luôn lắng nghe yêu cầu của khách hàng, nhưng gần như không bao giờ nên xây đúng thứ họ yêu cầu.
  • Khách hàng yêu cầu tính năng không chỉ để mô tả cách triển khai UX mà còn ngầm chỉ ra vấn đề và quy trình làm việc hiện tại mà họ đang dùng.
  • Cần xác định bài toán kinh doanh, rồi loại bỏ các ý tưởng triển khai UX và những chi tiết quá đặc thù theo quy trình.
  • Cần xây dựng một tính năng tối thiểu giải quyết bài toán kinh doanh một cách kinh tế, với thiết kế UX tốt và nhất quán.

• Nhu cầu của PM về nơi ghi nhận yêu cầu khách hàng

  • PM cần một nơi để ghi nhận các yêu cầu của khách hàng.
  • Nếu không có công cụ chuyên dụng, các yêu cầu đó phần lớn sẽ kết thúc dưới dạng ticket Jira.
  • Có hai cách tiếp cận: ProductBoard và Jira Product Discovery.
  • ProductBoard đi theo hướng CRM, ghi lại mọi tương tác với khách hàng rồi sau đó tách chúng thành các yêu cầu và mong muốn.
  • Jira Product Discovery bắt đầu từ ý tưởng, nên mọi thứ nghe được từ khách hàng phải được tách ngay thành một danh sách dài các yêu cầu và mong muốn.
  • Điểm mạnh của Jira Product Discovery là tách danh sách ý tưởng khỏi backlog của developer, nhưng đồng thời lại tạo thêm một danh sách dài khác.
  • Nếu muốn phân tích mức độ ưu tiên sản phẩm dựa trên các cuộc trò chuyện với khách hàng, ProductBoard là công cụ product discovery tốt hơn.

• Tầm quan trọng của backlog được tinh lọc bởi phản hồi khách hàng

  • Vì gần như ngày nào cũng trò chuyện với khách hàng, nên trong backlog có các tính năng và cải tiến được phản hồi khách hàng cung cấp thông tin trực tiếp và tinh lọc.
  • Việc cần làm thì lúc nào cũng nhiều, nhưng điểm khác biệt nằm ở chỗ backlog đó có được phản hồi khách hàng cung cấp thông tin và tinh lọc hay không.

• Quản lý backlog thông qua trò chuyện hằng ngày với khách hàng

  • Với tư cách là một người thiên về kỹ thuật và nói chuyện với khách hàng mỗi ngày, lý thuyết này nghe hấp dẫn nhưng có một vài vấn đề.
  • Thiên lệch gần đây và chi phí cơ hội: vẫn phải tiếp tục thu thập phản hồi về những không gian vấn đề mà ta cố ý chưa làm vì đang có ưu tiên cao hơn.
  • Phát triển mang tính phản ứng: nếu bỏ qua việc ghi log phản hồi, ta sẽ tập trung vào những việc mới nhất và dễ tiếp cận nhất, rồi bỏ sót các vấn đề cũ hơn.
  • Nền tảng tri thức của đội ngũ: nếu có một người chịu trách nhiệm duy nhất trong việc thu thập phản hồi và đưa ra giải pháp, lập luận của OP có thể đúng.
  • Nếu cả đội cùng tham gia, thì cần một cơ sở dữ liệu dùng chung để có thể ghi lại và tìm kiếm các data point theo cách bất đồng bộ.
  • Backlog có thể phình to rất nhanh, nhưng làm việc với các hệ thống và con người phức tạp vốn dĩ luôn khó khăn.
  • Với một đội ngũ được tổ chức tốt, cần quản lý backlog bài bản; điều này bao gồm lưu trữ các việc không liên quan, loại bỏ việc trùng lặp, định kỳ sắp xếp ưu tiên và tận dụng công cụ ở mức tốt nhất.
  • Việc quản lý backlog quan trọng hơn bản thân công cụ, và có thể cần một “mặt tiền” phía trên backlog để làm nổi bật thông tin, giúp đào sâu hơn khi cần.

• Tầm quan trọng của việc quan sát người dùng ứng dụng

  • Việc quan sát khách hàng sử dụng ứng dụng là rất quan trọng.
  • Có thể theo dõi mọi chỉ số, nhưng tận mắt thấy người dùng cuộn để tìm thứ gì đó, bấm nút quay lại, hoặc cố nhấp vào thứ không thể nhấp được là một trải nghiệm rất thực.
  • Mong rằng mọi công ty như Apple, Google và các công ty khác đều quan sát người dùng nhiều lần mỗi ngày.

• Sự vô dụng của backlog lớn

  • Backlog lớn chứa rất nhiều giả định chưa chắc chắn, và khả năng tạo ra giá trị cho khách hàng thấp.
  • Đã nhiều lần mắc sai lầm khi cho rằng thứ gì đó có giá trị, trong khi thực tế chẳng ai quan tâm.
  • Backlog lớn phản ánh việc trò chuyện với khách hàng không đủ thường xuyên, nên cần nhìn nó bằng con mắt rất hoài nghi.

• Cảnh báo về việc triển khai account spoofing

  • Account spoofing là cách dễ để kiểm thử vấn đề trong môi trường production, nhưng đội hỗ trợ và đội phát triển phải được khách hàng tin tưởng về dữ liệu production.
  • Trong một số ngành, điều này có thể trở thành vấn đề lớn với khách hàng.
  • Startup cuối cùng mà người viết làm việc thậm chí không cho developer truy cập dữ liệu production chút nào.
  • Về mặt bảo mật, đây nên được xem là lựa chọn cuối cùng; tốt hơn là làm việc với giả định rằng bạn không thể truy cập dữ liệu khách hàng.

• Cấu trúc cây của kế hoạch sản phẩm

  • Kế hoạch sản phẩm luôn nên được tổ chức theo cấu trúc cây.
  • Nút cao nhất là mục tiêu kinh doanh, bên dưới là sản phẩm, dưới nữa là vấn đề của khách hàng, và dưới cùng là các mục backlog.
  • Việc có quá nhiều mục backlog có thể có nghĩa là chưa thiết lập được cấu trúc phù hợp và cũng không có danh sách các mục tiêu kinh doanh đã được ưu tiên.
  • “Nói chuyện với khách hàng” hữu ích để hiểu vấn đề của khách hàng, nhưng trước hết vẫn phải biết mục tiêu kinh doanh là gì. Nếu không, bạn sẽ lãng phí thời gian thu thập phản hồi ở những lĩnh vực mà rốt cuộc cũng sẽ không làm.