Tôi tự xây sản phẩm này hoàn toàn một mình, chủ yếu vào buổi tối, cuối tuần và bằng nhiều ngày nghỉ hơn mức tôi muốn thừa nhận. Trong một thời gian dài, dù đã nằm trên web, nó vẫn giống một dự án cá nhân hơn là một sản phẩm thực sự.
Cảm giác đó thay đổi ngay khi tôi bật thanh toán. Code không bỗng nhiên trở nên phức tạp hơn, nhưng trách nhiệm của tôi đối với sản phẩm thì có. Khi một người có thể trả tiền, một flow bị hỏng không còn đơn giản là một edge case chưa làm xong. Onboarding, moderation, retention, niềm tin và độ tin cậy không còn là những việc dành cho tương lai. Chúng trở thành một phần của lời hứa mà sản phẩm đang đưa ra ngay lúc đó.
Đó là bài học lớn nhất tôi rút ra từ lần launch này: tự mình xây một dự án nhiều tính năng và vận hành một sản phẩm thật là hai công việc khác nhau.
Trong solo development, sự chú ý trở thành nút thắt
Trong lúc xây sản phẩm, tôi gần như biến mất khỏi mạng xã hội. Đó không phải chiến lược launch. Quyết định sản phẩm, implementation, edge case, test flow và chuẩn bị release đều cạnh tranh cho cùng một lượng thời gian có hạn.
Bây giờ tôi hiểu phần này của solo development rõ hơn nhiều. Nút thắt không phải lúc nào cũng là tốc độ tôi viết code. Nó là lượng sự chú ý tôi có thể dành cho số lượng state, transition và failure mode ngày càng tăng trong sản phẩm.
Một build thành công không trả lời những câu hỏi đó. Một giao dịch thanh toán thành công cũng không.
Thanh toán thay đổi ý nghĩa của một bug
Trước khi có thanh toán, tôi vẫn có thể coi một số điểm chưa hoàn thiện là thứ sẽ sửa sau. Khi thanh toán được bật, cách nghĩ đó không còn phù hợp với tôi. Một sản phẩm trả phí không cần phải hoàn toàn không có bug; điều đó không thực tế. Nhưng chi phí của việc để một vấn đề đã biết chưa được giải quyết thay đổi khi một người khác đã tin tưởng sản phẩm bằng tiền của họ.
Onboarding và moderation cũng vậy. Trong lúc phát triển, chúng có thể trông như các hệ thống hỗ trợ quanh tính năng “chính”. Trong production, chúng là một phần của chính trải nghiệm vì người dùng chạm trực tiếp vào chúng. Retention cũng tương tự: một phiên đầu tiên tốt không chứng minh rằng sản phẩm cho người dùng lý do để quay lại.
Thanh toán không chứng minh rằng sản phẩm đã hoàn thành. Nó cho tôi thấy từ “hoàn thành” đã che giấu bao nhiêu công việc.
Launch cho tôi một loại thông tin khác
Sau release là phần công việc ít đẹp để chụp màn hình hơn: bug chỉ lộ ra sau khi phát hành, flow bị hỏng, vấn đề moderation trở thành chuyện thật khi người dùng xuất hiện, và những câu hỏi về retention khó hơn rất nhiều so với việc tạo ấn tượng đầu tiên tốt.
Tôi cố không diễn giải quá mức các tín hiệu đó. Một bug sau release không tự động có nghĩa là architecture tệ. Một vấn đề retention tự nó chưa phải là chẩn đoán về product-market fit. Một vấn đề moderation không chứng minh rằng toàn bộ hệ thống không an toàn. Triệu chứng cho tôi biết nên điều tra ở đâu; nó không tự động nói cho tôi nguyên nhân.
Thứ thay đổi là chất lượng của bằng chứng. Trước launch, tôi có thể test điều tôi kỳ vọng người dùng sẽ làm. Sau launch, tôi phải đối mặt với điều họ thực sự làm. Release không phải lúc sự bất định biến mất. Nó là lúc một phần bất định quan trọng nhất cuối cùng trở nên quan sát được.
Vòng lặp post-launch tôi dùng bây giờ
Bây giờ tôi quan tâm đến công việc sau launch hơn là làm cho câu chuyện launch thật đẹp: bài học từ thanh toán, flow hỏng, thách thức moderation, hành vi người dùng, bất ngờ về retention và những sửa đổi nhỏ giúp sản phẩm dần đáng tin cậy hơn.
- Quan sát flow thật. Không mặc định con đường tôi thiết kế cũng chính là con đường người dùng thực sự đi.
- Tách triệu chứng khỏi nguyên nhân. Một bước thất bại cho biết nơi có vấn đề, không tự động cho biết vì sao.
- Ưu tiên lỗi ảnh hưởng đến niềm tin. Thanh toán, quyền truy cập, onboarding và moderation khẩn cấp hơn lỗi thẩm mỹ vì chi phí thất bại cao hơn.
- Sửa vấn đề nhỏ nhất đã được xác nhận trước. Tôi thà loại bỏ một nguồn friction đã biết còn hơn thiết kế lại cả hệ thống dựa trên suy đoán.
- Kiểm tra lại trải nghiệm người dùng sau khi sửa. Một thay đổi code có thể đúng về kỹ thuật nhưng vẫn không giải quyết vấn đề ở phía người dùng.
Đây không phải framework áp dụng cho mọi nơi. Nó chỉ là kỷ luật làm việc hợp lý nhất với tôi sau khi chuyển từ xây sang vận hành nó.
Launch thay đổi nguồn sự thật của tôi
Điểm khác biệt tôi quan tâm nhất bây giờ là giữa đã xây xong sản phẩm và sẵn sàng vận hành sản phẩm. Xây dựng hỏi liệu hệ thống có làm được thứ tôi thiết kế hay không. Vận hành hỏi điều gì xảy ra khi người thật sử dụng nó, hiểu sai nó, rời đi, quay lại, trả tiền hoặc đi vào một luồng tôi không dự đoán.
Đó là lý do tôi không còn xem launch là vạch đích. Trước launch, phần lớn bằng chứng đến từ giả định và test của chính tôi. Sau launch, sản phẩm bắt đầu phản hồi bằng hành vi thật, lỗi thật và việc sử dụng lặp lại.