Cái bẫy phình to phạm vi: Cách nói không với những tính năng nghe thì hay nhưng thật ra không nên làm

Bạn đã cho ra mắt một app. Người dùng kéo đến. Và giờ hộp thư của bạn đầy ắp những yêu cầu tính năng mà cái nào nghe cũng như một ý tưởng hay.

“Thêm xuất ra Excel được không?” Hợp lý. “Hóa đơn có thể gửi tự động được không?” Cũng có lý. “Tích hợp với Stripe được không?” Đó mới là nơi đồng tiền thật chảy về. “Thêm một ứng dụng di động được không?” Ai cũng hỏi cái đó. “Có thể gắn nhãn trắng (white-label) cái này cho khách hàng của riêng chúng tôi không?” Ồ, giờ thì đã có cả một mô hình kinh doanh.

Từng yêu cầu một nghe đều thông minh. Gộp lại, chúng nghe như thể bạn đang xây năm sản phẩm khác nhau.

Đây chính là sự phình to phạm vi (scope creep), và nó giết chết nhiều app nhỏ do AI dựng nên hơn cả các vấn đề kỹ thuật. Không phải vì bạn xây những tính năng đó — mà vì bạn cạn kiệt thời gian, tiền bạc, hoặc sự tỉnh táo khi cố làm chúng.

Phình to phạm vi giết chết một app đang chạy tốt như thế nào

Đây là điều xảy ra. Bạn đồng ý với ba yêu cầu đầu tiên vì chúng có vẻ hợp lý. Bạn nhờ công cụ AI của mình thêm chúng vào. Mất hai tuần thay vì một, vì mỗi tính năng mới lại đụng phải đoạn code sẵn có. Giờ bạn có một app làm được năm việc, làm tốt ba việc và làm tạm ổn hai việc.

Rồi yêu cầu thứ tư đến: “Có thể có các cấp quyền hạn khác nhau không?” Đột nhiên bạn phải suy nghĩ lại xem ai được thấy cái gì trong mọi màn hình. Đó không phải một tính năng; đó là một thay đổi về kiến trúc. Bạn nhờ công cụ AI làm điều đó. Nó đụng chạm tới mọi thứ. Hai tuần thành ba. App chậm đi vì bạn đã thêm logic vào mọi giao diện.

Đến yêu cầu thứ tám, bạn đã ngừng cho ra mắt thứ mới cho những người dùng ban đầu vì bạn quá bận giữ cho cỗ máy đáp ứng-yêu-cầu-tính-năng quay đều. Những người yêu app của bạn ba tháng trước nay bực bội vì chẳng có cái gì họ yêu cầu được hoàn thành. Những người đang đưa ra yêu cầu mới thì bực bội vì các tính năng mất quá lâu.

Bạn đã xây được thứ chạy được. Bạn làm hỏng nó bằng cách cố trở thành tất cả mọi thứ.

Khung quyết định

Bạn cần một cánh cổng. Mỗi yêu cầu tính năng phải đi qua ba câu hỏi:

Câu hỏi 1: Thứ này có thuộc về app này không, hay nó là một app khác?

App đầu tiên của bạn làm thật tốt một việc. Một app đặt lịch thì đặt lịch. Một app xuất hóa đơn thì xuất hóa đơn. Chúng là những app khác nhau. Nếu ai đó yêu cầu app đặt lịch của bạn xuất hóa đơn, bạn không phải đang thêm một tính năng — bạn đang yêu cầu một app đặt lịch làm kế toán. Đó là một sản phẩm khác.

Một phép thử hay: “Nếu tôi tách tính năng này ra và cho nó ra mắt độc lập, liệu người ta có muốn mua nó không?” Nếu có, nó có lẽ thuộc về một app khác. Nếu câu trả lời là “không, nó chỉ có ý nghĩa khi là một phần của thứ lớn hơn”, thì bạn đang xây đúng phạm vi.

Bạn sẽ nhận những yêu cầu kiểu “tích hợp với CRM của chúng tôi”. Cái đó thật ra có nghĩa là “hãy trở thành CRM của riêng bạn”. Đó là một app khác. Sau này bạn có thể tích hợp với một CRM. Bạn không thể thêm cả một đống tính năng của một CRM mà không trở thành một CRM.

Câu hỏi 2: Thứ này giải quyết một vấn đề cho hầu hết người dùng của bạn, hay chỉ cho riêng người này?

Một khách hàng yêu app của bạn và có một ý tưởng tính năng. Đó là một vấn đề có thật mà họ gặp phải. Nó cũng là một vấn đề có thật mà chỉ riêng họ gặp phải.

Nếu bạn có hai mươi người dùng và một người đang yêu cầu điều gì đó, hãy kiểm tra: liệu mười chín người còn lại có cũng đang chờ thứ này không, hay người này chỉ vừa nghĩ ra nó? Bạn có thể hỏi thẳng họ: “Trước bạn, bạn đã nghĩ tới việc hỏi ai khác xem họ có cần cái này không chưa?” Thường thì câu trả lời là chưa.

Đây là câu hỏi nguy hiểm, vì một khách hàng đang yêu cầu có thể là khách hàng quan trọng nhất của bạn. Bạn có thể cần giữ họ hài lòng. Đó là một quyết định kinh doanh, không phải một quyết định sản phẩm. Nhưng hãy bước vào với đôi mắt mở to: nếu bạn xây thứ gì đó cho một khách hàng, bạn không phải đang phát triển app của mình, bạn đang xây dựng một dịch vụ tư vấn.

Câu hỏi 3: Cái này tốn gì, và cái giá phải trả cho ý tưởng ban đầu là gì?

Mọi thứ đều có giá của nó. Xuất ra Excel tốn của bạn thời gian kỹ thuật. Nó khiến app của bạn phức tạp hơn. Nó tốn sự tập trung. Xây cái đó thay vì một tối ưu hiệu năng mà người dùng phàn nàn hằng ngày, thì bạn đã đưa ra một lựa chọn.

Hãy hỏi cụ thể: “Nếu tôi xây cái này, tôi sẽ không xây cái gì?” Nếu câu trả lời là “không gì cả, chúng ta có thời gian vô hạn”, thì bạn đang không thành thật. Chúng ta không có. Thời gian là hữu hạn.

Cái giá phải trả cho ý tưởng ban đầu thường vô hình. Khi bạn đang ngập trong các yêu cầu tính năng, bạn ngừng chăm sóc cái cốt lõi mà người ta yêu thích ở bạn. Cốt lõi chậm đi. Cốt lõi nhiều lỗi hơn. Cốt lõi có cảm giác bị bỏ bê. Và rốt cuộc người ta bỏ đi vì cái app từng tuyệt vời nay chỉ tàm tạm và lại làm những thứ nó chưa bao giờ được thiết kế để làm.

Một ví dụ thật: biểu mẫu tiếp nhận

Ai đó đã xây một biểu mẫu tiếp nhận khách hàng đơn giản. Khách hàng điền vào, huấn luyện viên xem xét, rồi họ sắp lịch. Đó là cả cái app.

Yêu cầu một: “Tôi đánh dấu các đơn tiếp nhận khẩn được không?” Được, đó là một biến thể của quy trình cốt lõi. Xây đi.

Yêu cầu hai: “Tôi xuất các đơn tiếp nhận ra Excel để lưu hồ sơ được không?” Đây là một tính năng tài liệu. Nó không phải việc của app. Các đơn tiếp nhận sống trong app. Nếu họ cần Excel, họ có thể sao chép-dán. Nhưng thôi được, xuất file có thể có ý nghĩa như một tiện ích. Xây đi.

Yêu cầu ba: “Các đơn tiếp nhận có thể tự động tạo sự kiện lịch được không?” Giờ bạn đang làm đặt lịch. App này là để tiếp nhận, không phải đặt lịch. Nếu ai đó muốn cả hai, họ có lẽ muốn một hệ thống đặt lịch thực thụ, chứ không phải một mánh chắp vá dán một cái vào. Hãy từ chối khéo.

Yêu cầu bốn: “Huấn luyện viên có thể gửi tin nhắn theo dõi đơn tiếp nhận qua SMS không?” Giờ bạn là một hệ thống truyền thông. Không.

Đến yêu cầu thứ ba, bạn đã chạm tới ranh giới. App này là tiếp nhận. Bất cứ thứ gì khác đều là một app khác. Sau này bạn có thể tích hợp với những app đó. Bạn không thể thêm chúng vào mà không trở thành chính những app đó.

Cách nói không

Phần khó nhất là thật sự nói ra điều đó. Bạn không muốn làm người dùng bực mình.

Hãy thành thật: “Đó là một ý tưởng tuyệt vời, nhưng nó là một sản phẩm khác với thứ chúng tôi đang xây ở đây. Thứ chúng tôi đang xây là [một việc duy nhất của bạn]. Nếu chúng tôi cố làm cả đặt lịch hay xuất hóa đơn hay mấy thứ CRM, chúng tôi sẽ tàm tạm ở tất cả và xuất sắc chẳng ở cái nào.”

Thường thì khách hàng sẽ hiểu. Họ hỏi vì ý tưởng chợt đến với họ, chứ không phải vì họ đang thử thách bạn.

Đôi khi họ sẽ phản đối. “Nhưng tôi cần cả hai.” Đó là lúc bạn gợi ý: dùng app đặt lịch thực thụ. Dùng app xuất hóa đơn thực thụ. Dùng CRM thực thụ. Rồi dùng app này cho thứ nó làm tốt. Đó là câu trả lời thành thật.

Sự cám dỗ trở thành tất cả mọi thứ

Phần khó nhất khi xây một sản phẩm nhỏ là nói không. Nói không có cảm giác như đang để tiền trên bàn không nhặt. Nhỡ đâu vị khách đó thật sự sẽ trả tiền cho cả hai thì sao? Nhỡ đâu tính năng đó sẽ khiến bạn lớn gấp mười lần thì sao?

Có thể lắm. Nhưng bạn chẳng phải một sản phẩm lớn gấp mười nếu bạn không cho nó ra mắt. Bạn là một sản phẩm dở dang làm năm việc một cách tệ hại. Những người yêu phần cốt lõi thì bực bội. Những người muốn các tính năng mới thì bực bội. Và bạn đã tự dồn mình vào chân tường, nơi thêm bất cứ thứ gì mới đồng nghĩa với việc phải tái cấu trúc năm thứ cũ trước đã.

Những sản phẩm phát triển là những sản phẩm làm thật tốt một việc, rồi mới thêm vào một cách thận trọng. Chúng không cố trở thành Salesforce ngay từ ngày đầu. Chúng là cái app bạn với tay tới khi cần làm đúng một việc đó, và là cái app bạn tin tưởng sẽ nhanh và đáng tin cậy khi bạn làm việc ấy.

Hãy nói không. Hãy bảo vệ phần cốt lõi. Làm được điều đó, và bạn sẽ xây nên thứ mà người ta thật sự muốn dùng.