Bản prototype và sản phẩm: Cách nhận biết app bạn tạo bằng AI đã thật sự hoàn thiện

Vài tuần trước, một nhà sáng lập tôi biết đã xây một app đặt lịch cho các nhà trị liệu tâm lý. Cả thứ mất của cô bốn ngày với một công cụ tạo app bằng AI. Nó làm đúng cái cô cần: nhà trị liệu xem được lịch của mình, khách hàng đặt được hẹn, xác nhận được gửi qua email. Nó chạy được.

Cô đã nhìn nó chằm chằm suốt hai tuần và vẫn chưa ra mắt.

Khi tôi hỏi vì sao, cô nói: “Nó chạy được, nhưng… nó không có cảm giác đã xong.”

Tôi hỏi cô sẽ thay đổi gì. Cô nói: “Tôi không biết. Đó mới là vấn đề.”

Đây là khoảnh khắc khó nhất khi xây dựng với một công cụ tạo app bằng AI. Cái thứ ấy vận hành được, nhưng có một khoảng cách giữa “vận hành được” và “tôi thấy thoải mái khi mời người thật dùng cái này”. Hiểu được khoảng cách đó — và biết mình thực sự đang ở phía nào của nó — là khác biệt giữa việc ra mắt và việc mắc kẹt mãi trong giai đoạn cái-giọng-nói-trong-đầu.

”Xong” thực sự có nghĩa là gì

Đây là sự phân biệt quan trọng: một bản prototype là thứ bạn dùng để kiểm chứng một ý tưởng. Một sản phẩm là thứ bạn dùng để giải quyết một vấn đề.

App đặt lịch cho nhà trị liệu là một bản prototype. Nó chứng minh rằng ý tưởng chạy được. Một nhà trị liệu có thể dùng nó. Nhưng có mười bảy thứ nhỏ khiến nó có cảm giác thô ráp:

Email xác nhận trống trơn. Không logo, không thương hiệu riêng, câu chữ chung chung.
Việc hủy hẹn không gửi thông báo. Khách hàng cứ thế không đến.
Không có danh sách chờ nếu một nhà trị liệu đã kín lịch.
Luồng đăng ký không thu thập chuyên môn của nhà trị liệu, nên không có cách nào lọc theo loại hình hành nghề.
Không có email nhắc hẹn gửi 24 giờ trước buổi hẹn.

Không điều nào trong số này làm app hỏng. Nhưng tất cả chúng khiến một nhà trị liệu thật nghĩ: “Cái này có cảm giác như thứ ai đó ráp lại trong một cuối tuần, chứ không phải thứ người ta đang thu tiền của tôi.”

Cảm giác đó là có thật, và nó quan trọng. Một bản prototype giải quyết vấn đề trên lý thuyết. Một sản phẩm giải quyết nó trong thực tế, cho đúng con người đang dùng nó.

Ba câu hỏi phân biệt prototype với sản phẩm

Đây là phần khó: bạn không thể biết hết những gì còn thiếu. Công cụ AI của bạn cũng không thể biết. Vậy nên bạn cần ba câu hỏi nhanh để tìm ra mình đang ở phía nào của ranh giới.

1. Bạn có dùng cái này để giải quyết vấn đề của chính mình không?

Câu này thành thật, vì bạn phải thật sự sống chung với sản phẩm của chính mình.

Nếu bạn là nhà sáng lập của app đặt lịch cho nhà trị liệu đó, bạn có dùng nó để đặt lịch hẹn trị liệu của chính mình không? Không phải “bạn có thể không” — mà bạn có thật sự dùng nó thay vì một chuỗi email hay một Google Doc dùng chung không?

Nếu câu trả lời là không, bạn chưa xong. Bạn biết chính xác cái gì sai — bạn cảm thấy nó mỗi lần mở app lên. Nếu câu trả lời là có, bạn đã gần hơn.

Nhà sáng lập tôi nhắc đến đã tự mình trải qua quá trình đăng ký như một nhà trị liệu. Cô bị mắc kẹt ở biểu mẫu (nó hỏi quá nhiều thông tin trước khi cho cô đặt hẹn). Cô thấy email xác nhận và nghĩ nó trông nghiệp dư. Cô bắt đầu nghĩ xem nhà trị liệu của cô sẽ nhận email kiểu gì và liệu nó có rơi vào spam không.

Cô đã không dùng sản phẩm của chính mình theo cách một khách hàng trả tiền sẽ dùng. Khi cô làm vậy, cô tìm ra mười thứ cần sửa.

2. Bạn đã cho ba người không phải bạn xem nó chưa?

Trò chuyện với người dùng tiềm năng khó hơn xây dựng, và phần lớn nhà sáng lập bỏ qua bước này vì họ muốn làm mọi người bất ngờ vào ngày ra mắt. Đó là một sai lầm.

Bạn không cần một nhóm khảo sát. Bạn cần ba người giống với hình dung của bạn về khách hàng. Với app cho nhà trị liệu, đó là ba nhà trị liệu thật.

Đây là điều bạn cần tìm: họ rối ở chỗ nào? Họ ngần ngại ở đâu? Họ hỏi về cái gì? Không phải “họ nghĩ gì về nó?” (người ta tử tế quá mức). Hãy yêu cầu họ thật sự làm việc đó — đặt một cuộc hẹn, gửi một email xác nhận, hủy một cái gì đó.

Khi nhà sáng lập cho ba nhà trị liệu xem app, hai người trong số họ hỏi: “Tôi đặt được quy tắc cho thời gian mình rảnh không? Kiểu như, tôi chỉ nhận khách mới vào thứ Năm, và tôi không nhận hai hẹn cùng lúc trước 2 giờ chiều.” App có một cái lịch, nhưng không có quy tắc. Cô đã xây bản prototype theo cách cô nghĩ việc đặt lịch vận hành, chứ không phải cách nhà trị liệu thật sự làm việc.

Đó là thông tin về sản phẩm. Bạn không thể đoán ra điều đó từ một tài liệu đặc tả.

3. Cái gì sẽ hỏng nếu bạn giao nó cho mười người dùng thật?

Đây là câu khó nhất vì nó đòi bạn phải thật sự suy nghĩ về các trường hợp ngoại lệ của mình.

Với app cho nhà trị liệu:

Chuyện gì xảy ra nếu một khách hàng thử đặt hai cuộc hẹn cùng một thời điểm? (App không kiểm tra.)
Chuyện gì xảy ra nếu một nhà trị liệu hủy một cuộc hẹn? Khách hàng có được tự động báo không? (Không.)
Lỡ địa chỉ email của khách hàng bị sai thì sao? Có cách nào sửa mà không phải làm lại từ đầu không? (Không.)
Lỡ một nhà trị liệu ốm và cần đóng lịch cả tuần thì sao? (Cô ấy sẽ phải tự tay xóa từng cuộc hẹn.)

Đây không phải lỗi. App không sập. Nhưng chúng là những vết cứa nhỏ. Với mười người dùng thật và các trường hợp ngoại lệ thật, bạn sẽ vấp phải tất cả chúng ngay trong tuần đầu.

Một sản phẩm xử lý được các trường hợp ngoại lệ. Không phải tất cả — vài thứ có thể đợi. Nhưng những thứ xảy ra trong hai tuần đầu với người dùng thật thì cần phải chạy được.

Cách quyết định: bài kiểm tra ba lớp

Hãy dùng cái này để tìm ra mình đang ở đâu:

Lớp 1: Luồng cốt lõi — Con đường suôn sẻ có chạy không? Một người dùng có làm được cái việc chính mà app của bạn được thiết kế cho không?

Với app đặt lịch cho nhà trị liệu: có. Ai đó đăng ký được, đặt được hẹn, nhận được xác nhận. Nó chạy được.

Lớp 2: Các trường hợp ngoại lệ từ việc dùng thật — Bạn đã cho ba người dùng thật xem. Họ có vấp phải thứ gì bạn không xây không? Họ có rối ở đâu không?

Với app đặt lịch cho nhà trị liệu: có. Ba nhà trị liệu muốn lịch rảnh theo quy tắc. Một người rối vì email xác nhận trông quá chung chung. Một người thử xóa hàng loạt cuộc hẹn và không làm được.

Lớp 3: Sự trau chuốt và chuyên nghiệp — Nó có cảm giác như bạn có để tâm không? Hay có cảm giác như bạn ráp đại nó lại?

Với app đặt lịch cho nhà trị liệu: cảm giác như ráp đại. Email xác nhận trống trơn. Không có thương hiệu riêng. Không có thông báo lỗi nếu có gì trục trặc, nên nếu có thứ hỏng, người dùng chẳng biết chuyện gì đã xảy ra.

Đây là quy tắc nhanh:

Cả ba lớp đều chạy? Bạn đang có một sản phẩm. Ra mắt đi.
Lớp 1 và 2 ổn, lớp 3 thì chưa? Bạn đã xong 80%. Hãy dành một ngày để trau chuốt.
Lớp 1 chạy, lớp 2 và 3 thì chưa? Bạn đang có một bản prototype. Đừng ra mắt vội.
Lớp 1 chưa vững? Bạn chưa xong. Cứ tiếp tục xây.

App cho nhà trị liệu mắc kẹt ở ranh giới giữa Lớp 1 và Lớp 2. Luồng cốt lõi chạy được, nhưng nhà trị liệu thật thấy nó thiếu mảnh. Vậy nên nhà sáng lập có một lựa chọn: dành thêm một tuần với công cụ AI để thêm những tính năng nhà trị liệu thật sự cần, hoặc ra mắt với những gì cô đang có rồi thêm sau.

(Cô đã thêm. Mất ba ngày. Giờ nó là một sản phẩm.)

Cái khiến chuyện này khó

Lý do khiến rất nhiều nhà sáng lập mắc kẹt ở đây là vì xây dựng thì vui còn ra mắt thì đáng sợ.

Xây dựng là một cuộc trò chuyện với công cụ AI của bạn. Bạn có một ý tưởng, bạn mô tả nó, công cụ thực thi. Có một vòng phản hồi chỉ mất vài phút. Ra mắt thì khác. Bạn bấm xuất bản, và nếu có gì sai, người thật sẽ phát hiện ra. Không có cơ hội làm lại.

Thế là chúng ta tìm lý do để không ra mắt. “Chưa đủ trau chuốt.” “Mình nên thêm một tính năng nữa.” “Lỡ font chữ sai thì sao?” Và sáu tuần sau, bạn vẫn ngồi trên một thứ chạy được nhưng không có cảm giác đã xong, và bạn đã tự thuyết phục mình rằng đó là vì cái font chữ.

Không phải vì font chữ đâu.

Thường là vì bạn chưa dành thời gian với một người dùng thật, hoặc bạn đã xây một thứ hợp lý trong đầu bạn nhưng không khớp lắm với cách người thật làm việc. Điều đó sửa được. Nó chỉ đòi bạn thừa nhận rằng có những thứ bạn không biết là mình không biết, rồi đi nói chuyện với người biết.

Danh sách kiểm tra mức độ sẵn sàng ra mắt

Hãy dùng cái này. Nó ngắn và trung thực.

Tôi đã tự dùng nó để làm cái tác vụ thật, và nó chạy được (không phải theo kiểu chế độ demo, mà thật sự).
Tôi đã cho ba người thật sự sẽ dùng nó xem, và tôi đã sửa những thứ khiến họ rối.
Mọi lỗi có thể xảy ra đều có một thông báo cho người dùng biết phải làm gì (không phải “lỗi”, mà là hướng dẫn thật sự).
Tôi sẽ thấy ổn nếu đây là phiên bản cuối cùng trong sáu tháng (nghĩa là: nó đủ hoàn chỉnh để hữu ích kể cả khi tôi không bao giờ động đến nó nữa).
Tôi háo hức với những gì sẽ học được từ người dùng thật hơn là với việc thêm tính năng trong chân không.

Nếu bạn đánh dấu được cả năm ô, bạn đã xong. Ra mắt đi.

Nếu chưa, thì đừng. Nhưng hãy cụ thể về lý do. “Nó không có cảm giác đã xong” không phải một lý do. “Nhà trị liệu thật cần quy tắc lịch rảnh và tôi chưa xây cái đó” là một lý do. Đó là thứ hành động được. Đó là thứ sửa được. Đó là khác biệt giữa việc mắc kẹt và việc đang trên một con đường.

Nhà sáng lập của app cho nhà trị liệu đã ra mắt nó hôm qua. Cô đã có khách hàng trả tiền đầu tiên. Sản phẩm chưa hoàn hảo, nhưng nó có thật, và khách hàng của cô đã đang nói cho cô biết nên xây gì tiếp theo. Đó là lúc bạn biết mình đã xong: không phải khi app hoàn hảo, mà khi bạn đã sẵn sàng học xem hoàn hảo thực sự có nghĩa là gì với những người đang dùng nó.