Khi nào nên bổ sung tính năng mới cho sản phẩm?

Vì vậy, thời điểm thích hợp để phát triển tính năng mới là khi nhiều điều kiện cùng hội tụ: vấn đề đã được xác thực, nhu cầu đủ đáng kể, tính năng phù hợp định hướng sản phẩm, tác động kỳ vọng có thể đo lường, giải pháp đã được kiểm chứng và doanh nghiệp đủ khả năng vận hành nó lâu dài.

Quyết định đúng không phải là thêm càng nhiều tính năng càng tốt. Mỗi tính năng mới đồng thời tạo thêm giao diện, logic nghiệp vụ, dữ liệu, tài liệu, hỗ trợ khách hàng, kiểm thử và chi phí bảo trì. Giá trị mà tính năng tạo ra vì thế phải lớn hơn cả chi phí xây dựng lẫn độ phức tạp mà nó bổ sung cho sản phẩm.

Chỉ bổ sung tính năng khi vấn đề người dùng đủ rõ và đáng giải quyết

Điều kiện đầu tiên không phải là có ý tưởng tốt, mà là có một vấn đề người dùng đủ rõ. Đây là điểm phân biệt giữa phát triển sản phẩm dựa trên nhu cầu và phát triển sản phẩm dựa trên danh sách yêu cầu.

Ví dụ, khách hàng có thể liên tục yêu cầu “thêm nút xuất Excel”. Nếu đội sản phẩm lập tức xây chức năng này, họ đang xác thực giải pháp thay vì xác thực vấn đề. Nhu cầu thật có thể là người dùng cần tổng hợp dữ liệu cho báo cáo, chuyển dữ liệu sang hệ thống khác hoặc chia sẻ thông tin với quản lý. Mỗi vấn đề đó có thể dẫn tới một giải pháp khác nhau.

Một vấn đề đáng đầu tư thường có ba đặc điểm: xuất hiện lặp lại, gây ra hậu quả đủ lớn và hiện chưa được giải quyết thỏa đáng. Tần suất cao nhưng tác động thấp chưa chắc đáng ưu tiên; ngược lại, một vấn đề hiếm gặp nhưng khiến khách hàng không thể hoàn thành tác vụ cốt lõi vẫn có thể rất quan trọng.

Đội sản phẩm nên tìm bằng chứng từ hành vi thực tế như nơi người dùng bỏ cuộc trong luồng thao tác, tác vụ phải làm thủ công, yêu cầu hỗ trợ lặp lại, nguyên nhân hủy dịch vụ hoặc những bước mà khách hàng phải sử dụng công cụ bên ngoài để hoàn thành công việc.

Điểm cần tránh là dùng một vài phản hồi nổi bật để đại diện cho toàn bộ tập người dùng. Khách hàng nói nhiều nhất, khách hàng lớn nhất hoặc người dùng nội bộ chưa chắc đại diện cho phân khúc mà sản phẩm đang phục vụ.

Vì vậy, chỉ nên chuyển từ “ý tưởng tính năng” sang “cơ hội phát triển” khi đội sản phẩm có thể diễn đạt rõ: ai đang gặp vấn đề, vấn đề xảy ra trong hoàn cảnh nào, mức độ ảnh hưởng ra sao và điều gì chứng minh đây không phải trường hợp cá biệt.

Khi dữ liệu cho thấy nhu cầu có thật chứ không chỉ có nhiều yêu cầu

Số lượng yêu cầu tính năng là một tín hiệu, nhưng không phải bằng chứng đầy đủ về nhu cầu.

Một tính năng có thể nhận được rất nhiều phiếu đề xuất đơn giản vì nó dễ mô tả. Trong khi đó, một vấn đề nghiêm trọng hơn có thể ít được yêu cầu trực tiếp bởi người dùng không biết sản phẩm có thể giải quyết vấn đề đó như thế nào.

Do đó, nên kết hợp ít nhất hai lớp bằng chứng. Dữ liệu định tính giúp hiểu tại sao người dùng gặp khó khăn; dữ liệu định lượng giúp xác định vấn đề lớn đến mức nào.

Dữ liệu định tính có thể đến từ phỏng vấn, quan sát người dùng, nội dung ticket hỗ trợ, cuộc gọi bán hàng và phản hồi hủy dịch vụ. Dữ liệu định lượng có thể bao gồm tỷ lệ hoàn thành tác vụ, tỷ lệ bỏ dở, tần suất sử dụng chức năng liên quan, tỷ lệ giữ chân hoặc chuyển đổi của nhóm người dùng chịu ảnh hưởng.

Không có một ngưỡng phổ quát như “10% khách hàng yêu cầu thì phải xây”. Ngưỡng hợp lý phụ thuộc vào loại sản phẩm, phân khúc khách hàng và mức độ nghiêm trọng của vấn đề. Với một chức năng phục vụ tác vụ cốt lõi, tỷ lệ người gặp vấn đề tương đối nhỏ vẫn có thể đáng xử lý. Với tính năng tiện ích, phạm vi ảnh hưởng thường cần lớn hơn để bù lại chi phí phát triển và bảo trì.

Cách đánh giá tốt hơn là so sánh với baseline của chính sản phẩm. Nếu một bước trong hành trình người dùng tạo ra mức bỏ dở cao bất thường so với các bước khác, hoặc nhóm người gặp vấn đề có tỷ lệ giữ chân thấp hơn đáng kể so với nhóm không gặp vấn đề, đội sản phẩm đã có bằng chứng mạnh hơn nhiều so với số lượng lời yêu cầu đơn thuần.

Một yêu cầu được nhắc lại nhiều lần nên kích hoạt quá trình tìm hiểu. Nó không nên tự động kích hoạt quá trình phát triển.

Bổ sung khi tính năng phù hợp chiến lược và tạo giá trị đo lường được

Ngay cả một nhu cầu người dùng có thật cũng chưa đủ để chứng minh rằng doanh nghiệp nên xây tính năng.

Nguồn lực sản phẩm luôn hữu hạn. Khi đội ngũ chọn phát triển một chức năng, họ đồng thời từ bỏ cơ hội dành thời gian đó cho vấn đề khác. Vì vậy, câu hỏi tiếp theo phải là: nếu giải quyết vấn đề này, sản phẩm tiến gần hơn tới mục tiêu nào?

Một tính năng phù hợp có thể giúp người dùng hoàn thành giá trị cốt lõi nhanh hơn, tăng khả năng sử dụng thường xuyên, giảm rào cản kích hoạt, cải thiện giữ chân hoặc hỗ trợ một phân khúc chiến lược. Ngược lại, một chức năng dù được yêu cầu nhiều nhưng nằm ngoài định hướng sản phẩm có thể biến thành khoản đầu tư có giá trị cục bộ nhưng làm sản phẩm mất tập trung.

Trước khi phát triển, nên xác định một kết quả kỳ vọng có thể quan sát được. Chẳng hạn, thay vì đặt mục tiêu “ra mắt tính năng cộng tác”, có thể đặt giả thuyết rằng chức năng này sẽ làm tăng tỷ lệ nhóm mời thêm thành viên và tăng tỷ lệ nhóm tiếp tục sử dụng sản phẩm sau một khoảng thời gian xác định.

Điểm quan trọng là đo outcome, không chỉ đo output. “Đã phát hành ba tính năng trong quý” phản ánh khối lượng giao hàng. Nó không chứng minh người dùng nhận được thêm giá trị.

Các chỉ số đánh giá cũng phải gắn với cơ chế mà tính năng dự kiến tạo ra giá trị. Một tính năng nhằm rút ngắn tác vụ nên quan sát thời gian hoàn thành hoặc tỷ lệ hoàn thành. Một chức năng nhằm tăng cộng tác nên quan sát hành vi cộng tác. Một cải tiến nhằm giải quyết nguyên nhân rời bỏ cần theo dõi hành vi và retention của nhóm chịu ảnh hưởng.

Nếu đội sản phẩm không thể giải thích tính năng sẽ thay đổi hành vi nào và thay đổi đó tạo ra giá trị gì, quyết định phát triển vẫn còn thiếu một mắt xích quan trọng.

Chỉ xây đầy đủ sau khi giả thuyết đã được kiểm chứng với chi phí thấp

Một sai lầm phổ biến là xem việc lập trình hoàn chỉnh như phương pháp đầu tiên để biết người dùng có cần tính năng hay không. Đây thường là cách kiểm chứng đắt nhất.

Trước khi đầu tư lớn, đội sản phẩm nên tìm cách giảm bất định bằng thử nghiệm có chi phí thấp hơn. Tùy loại tính năng, có thể sử dụng prototype, bản mẫu tương tác, usability test, fake-door test, quy trình xử lý thủ công phía sau giao diện hoặc phiên bản giới hạn cho một nhóm người dùng.

Mục tiêu của giai đoạn này không phải chứng minh rằng giao diện “đẹp” hay người dùng nói rằng họ “thích” ý tưởng. Điều cần kiểm chứng là các giả định quan trọng nhất: người dùng có thực sự gặp vấn đề, có hiểu giải pháp, có sử dụng nó trong bối cảnh thực tế và hành vi đó có khả năng tạo ra kết quả mong muốn hay không.

Có một khác biệt lớn giữa ý định và hành vi. Câu trả lời “tôi chắc chắn sẽ dùng tính năng này” trong phỏng vấn có giá trị hạn chế nếu người dùng chưa phải đánh đổi thời gian, dữ liệu, tiền bạc hoặc thay đổi quy trình làm việc. Vì vậy, bằng chứng từ hành vi thực tế thường mạnh hơn mức độ hào hứng được mô tả trong khảo sát.

Việc thử nghiệm cũng giúp phát hiện trường hợp giải pháp được đề xuất quá lớn. Có thể người dùng chỉ cần một thay đổi nhỏ trong workflow hiện tại thay vì một module hoàn toàn mới. Khi đó, đội sản phẩm tạo được phần lớn giá trị với ít độ phức tạp hơn.

Nên bắt đầu xây dựng đầy đủ khi những giả định có khả năng khiến sáng kiến thất bại đã được kiểm tra đủ để rủi ro còn lại phù hợp với quy mô đầu tư.

Bổ sung tính năng khi sản phẩm đủ khả năng duy trì nó sau khi ra mắt

Chi phí của một tính năng không kết thúc vào ngày release.

Sau khi phát hành, tính năng có thể tạo thêm mã nguồn cần bảo trì, trường hợp kiểm thử, dữ liệu cần quản lý, tài liệu hướng dẫn, câu hỏi hỗ trợ, phụ thuộc kỹ thuật và những quyết định tương thích cho các phiên bản sau. Nếu tính năng ảnh hưởng tới nhiều phần của hệ thống, chi phí dài hạn thậm chí có thể lớn hơn chi phí xây dựng ban đầu.

Bởi vậy, tính khả thi không chỉ là “đội kỹ thuật có làm được không?”. Câu hỏi đầy đủ hơn là: sản phẩm có thể sở hữu tính năng này trong nhiều năm mà không làm giảm đáng kể khả năng phát triển phần còn lại hay không?

Trước khi triển khai, cần đánh giá ít nhất phạm vi kỹ thuật, phụ thuộc hệ thống, dữ liệu cần xử lý, rủi ro bảo mật, ảnh hưởng hiệu năng, khả năng hỗ trợ và chi phí vận hành. Với tính năng liên quan tới quyền truy cập, thanh toán, dữ liệu cá nhân hoặc quy trình quan trọng của khách hàng, yêu cầu về độ tin cậy và kiểm soát thường cao hơn các tiện ích thông thường.

Trade-off này đặc biệt quan trọng với sản phẩm đã trưởng thành. Càng nhiều tính năng, càng có nguy cơ tăng cognitive load: người dùng phải hiểu nhiều lựa chọn hơn, giao diện khó học hơn và đội sản phẩm phải bảo vệ nhiều hành vi cũ hơn khi thay đổi hệ thống.

Do đó, một tính năng mới phải tạo ra đủ giá trị để biện minh không chỉ cho effort ban đầu mà còn cho total cost of ownership của nó.

Trong một số trường hợp, quyết định tốt hơn là đơn giản hóa chức năng hiện tại, tích hợp với công cụ khác hoặc cải thiện khả năng khám phá một tính năng đã tồn tại thay vì xây thêm.

Khi nào nên trì hoãn hoặc không bổ sung tính năng?

Có những thời điểm “không xây” là quyết định sản phẩm tốt hơn.

Nên trì hoãn khi bằng chứng chủ yếu đến từ ý kiến nhưng chưa thấy vấn đề trong hành vi thực tế; khi nhu cầu chỉ xuất hiện ở một nhóm không thuộc phân khúc mục tiêu; hoặc khi chưa xác định được kết quả kinh doanh và kết quả người dùng mà tính năng sẽ tác động.

Cũng nên thận trọng khi một tính năng được đề xuất để bắt chước đối thủ. Đối thủ có chức năng nào đó chỉ chứng minh rằng chức năng tồn tại, không chứng minh người dùng của bạn cần nó. Hai sản phẩm có thể khác nhau về phân khúc, mô hình kinh doanh, workflow và lợi thế cạnh tranh.

Một tín hiệu khác là khi tính năng chủ yếu bù đắp cho vấn đề của thiết kế hiện tại. Nếu người dùng yêu cầu thêm bộ lọc vì cấu trúc thông tin quá khó tìm, hoặc yêu cầu thêm hướng dẫn vì workflow khó hiểu, việc thêm chức năng có thể chỉ che đi nguyên nhân gốc.

Tính năng cũng nên được hoãn nếu tổ chức chưa có khả năng đo tác động sau phát hành. Không có cơ chế quan sát adoption, hành vi và kết quả, đội sản phẩm rất dễ duy trì một chức năng chỉ vì đã đầu tư vào nó, dù giá trị thực tế thấp.

Cuối cùng, cần cân nhắc loại bỏ hoặc không phát triển khi lợi ích chỉ xuất hiện trong một trường hợp hiếm nhưng chi phí phức tạp ảnh hưởng tới toàn bộ người dùng. Sản phẩm tốt không phải sản phẩm đáp ứng mọi trường hợp; nó là sản phẩm lựa chọn có chủ đích những vấn đề mà mình sẽ giải quyết.

Một phép kiểm tra thực tế trước khi cam kết phát triển là trả lời sáu câu hỏi:

1.    Người dùng cụ thể nào đang gặp vấn đề này?

2.    Bằng chứng nào cho thấy vấn đề đủ quan trọng?

3.    Tại sao giải quyết vấn đề phù hợp với chiến lược sản phẩm?

4.    Hành vi hoặc chỉ số nào được kỳ vọng sẽ thay đổi?

5.    Giả định rủi ro nhất đã được kiểm chứng chưa?

6.    Giá trị kỳ vọng có đủ bù cho chi phí xây dựng, vận hành và độ phức tạp dài hạn không?

Nếu chưa trả lời thuyết phục một hoặc nhiều câu hỏi quan trọng, trạng thái hợp lý thường là tiếp tục nghiên cứu hoặc thử nghiệm thay vì chuyển ngay sang phát triển.

Thời điểm nên bổ sung tính năng sản phẩm không được xác định bởi số lượng ý tưởng trong backlog hay mức độ thúc giục của một vài khách hàng. Tín hiệu mạnh hơn xuất hiện khi một vấn đề người dùng đã được chứng minh, có mức độ quan trọng đủ lớn, phù hợp chiến lược sản phẩm, tạo ra outcome có thể đo lường và giải pháp đã được kiểm chứng trước khi đầu tư đầy đủ.

Đồng thời, quyết định phải tính cả mặt còn lại của phương trình: mỗi tính năng làm sản phẩm phức tạp hơn và tạo thêm nghĩa vụ bảo trì. Vì vậy, chỉ nên bổ sung tính năng khi giá trị kỳ vọng của việc giải quyết vấn đề lớn hơn chi phí cơ hội, chi phí phát triển và độ phức tạp dài hạn mà tính năng tạo ra.