Những bài học đắt giá từ việc xây dựng trình duyệt "đa người chơi"

Vào năm 2022, tôi đang tìm kiếm một cơ hội rất cụ thể: một nhóm nhỏ dưới 10 người, chưa tìm được khớp nhu cầu thị trường (product-market fit), và đang làm việc trên một sản phẩm mà tôi thực sự quan tâm. Hai người bạn cũ đại học, Ron và Jimmy, đã liên hệ. Họ đang ấp ủ ý tưởng về một trình duyệt mới, dựa trên nền tảng Chromium đã được phân nhánh (fork), và đã huy động được 5,5 triệu USD vòng hạt giống (seed round) từ General Catalyst, Naval, YC và các nhà đầu tư khác.

Khi tôi gia nhập với tư cách là kỹ sư sáng lập (founding engineer), phần khó khăn nhất về kỹ thuật đã được giải quyết xong. Chúng tôi có thể xây dựng trên Chromium, truy cập các tab, API lịch sử và toàn bộ giao diện người dùng (UI) đều có thể được tạo bằng công nghệ web. Nhưng thử thách khó khăn khác vẫn đang chờ đợi phía trước: chúng ta sẽ xây dựng cái gì, nó hoạt động như thế nào, và liệu có ai thực sự cần nó không?

Chúng tôi hướng tới việc xây dựng một "cửa sổ" xứng đáng với công việc bạn làm và công việc bạn làm cùng người khác. Điều đó phát triển thành phần mềm cộng tác: đa người chơi theo thời gian thực (realtime multiplayer), khung vỏ vô hạn (infinite canvas), trình soạn thảo văn bản phong phú, chat, tất cả được đóng gói vào trình duyệt cùng với nội dung web.

Thương hiệu của Sail

Sail, và sau đó là Muddy, là những sản phẩm ra đời từ tầm nhìn đó. Chúng tôi đã nỗ lực tạo ra một mô hình máy tính cá nhân mới, nhưng cuối cùng, dự án không thành công như một công ty. Tuy nhiên, tôi đã trở thành một người tư duy sản phẩm, kỹ sư và nhà xây dựng tốt hơn rất nhiều nhờ trải nghiệm này. Dưới đây là những bài học tôi đúc kết được.

Chúng tôi đã xây dựng gì?

Khi tôi gia nhập, Sail là một ứng dụng khung vỏ vô hạn đang trong quá trình phát triển, được xây dựng trên nền tảng Chromium fork của riêng chúng tôi. Bạn có thể đặt các trang web vào, thêm thẻ văn bản, xem con trỏ của người khác, nhưng nó vẫn đang trong quá trình hoàn thiện. Sail giống như "FigJam hoặc Miro nhưng có trình duyệt tích hợp, bạn có thể đặt các trang web trực tiếp lên khung vỏ vô hạn và mọi thứ đều là đa người chơi".

Sail chưa bao giờ có đợt ra mắt công khai rộng rãi. Chúng tôi đã thử nghiệm với nhiều loại người dùng khác nhau, nhưng có lẽ chúng tôi đã thất bại trong việc tiếp cận đúng nhóm người dùng sẽ yêu thích Sail. Một sai lầm lớn là chúng tôi đã không ra mắt sớm hơn. Paul Graham từng nói: "Nguy hiểm của việc làm việc bí mật là tỷ lệ nghịch với sự đơn giản và chính xác của bài kiểm tra." Nếu bạn ra mắt mà không ai để ý, bạn hoàn toàn có thể ra mắt lại.

Sau Sail, chúng tôi trải qua dự án nội bộ mang tên "multiverse", một phiên bản hỗ trợ nhiều loại bảng: khung vỏ vô hạn, khung vỏ có cấu trúc (kiểu Nototo), và chat. Chat là thứ sống sót và trở thành nền tảng của Muddy.

Muddy được định vị là "Slack và một trình duyệt trong một môi trường làm việc tích hợp". Chat là một giao diện lâu đời (Lindy effect), mọi người hiểu ngay lập tức và dễ sử dụng hơn khung vỏ vô hạn. Tuy nhiên, chúng tôi đã quá tập trung vào các tính năng bắt buộc (table stakes) như ứng dụng di động thay vì giải quyết các vấn đề khó hơn về định vị sản phẩm.

Thách thức về Định vị (Positioning)

Một phần của luận điểm (thesis) công ty được định hình bởi bài viết "The Arc of Collaboration" của Kevin Kwok, cho rằng sự cộng tác nên là bản chất của các ứng dụng năng suất, không phải một lớp riêng biệt. Chúng tôi cố gắng xây dựng trình duyệt như một lớp meta (metalayer) bao phủ tất cả các ứng dụng khác.

Sơ đồ về luồng công việc chức năng và lớp giao tiếp

Tuy nhiên, danh mục trình duyệt đầy rủi ro. Có hai cách để nghĩ về trình duyệt: như một lớp giao tiếp hoặc như một trình kết xuất HTML được nâng cấp. Cả hai đều đúng, và điều đó khiến việc định vị trở nên khó khăn. Khi mô tả sản phẩm, tôi thường bắt đầu bằng "trình duyệt đa người chơi", nhưng những mô tả đó không nhất thiết dẫn người dùng đến hành vi mong muốn.

Thị trường luôn giảm sứ mệnh lớn lao của bạn xuống một mô tả đơn giản. Mighty trở thành "Chrome trên đám mây nhanh hơn". Arc trở thành "trình duyệt đẹp với thanh bên tổ chức tốt hơn". Sail của chúng tôi trở thành "Miro nhưng có trang web".

Việc "ngầu" (cool) không phải là một mô hình kinh doanh. Muse từng có hàng chục nghìn người dùng nhưng vẫn không thể duy trì. Các sản phẩm như Rabbit R1 hay Humane AI Pin cũng gặp vấn đề tương tự: tầm nhìn vĩ đại nhưng mô tả thực tế lại quá đơn giản hoặc không đủ thuyết phục. Notion là một ví dụ hiếm hoi thành công trong việc cân bằng giữa tầm nhìn "công cụ tư duy" và các trường hợp sử dụng thực tế mà người dùng đã hiểu rõ như wiki, công cụ docs.

Nghĩa trang của những trình duyệt tốt hơn

Ngoài vấn đề định vị, người dùng liên tục từ chối tính năng đa người chơi. Điều này không phải là duy nhất đối với chúng tôi. Tandem (ứng dụng văn phòng ảo) kết luận rằng "hầu hết mọi người không cảm thấy nhu cầu nói chuyện với đồng nghiệp của mình thường xuyên đến vậy". Công việc thực tế bị chia tách (siloed) nhiều hơn chúng ta tưởng.

Có một chiến lược mà tôi gọi là "phiên bản được đánh bóng nhất" (the best polished version). Bạn xây dựng phiên bản cuối cùng của một thứ gì đó. Linear đã làm điều này với Jira. Vercel đã làm với trải nghiệm phát triển frontend. Nó chỉ hoạt động khi công cụ hiện tại đủ tệ. Jira thật tệ, nên sự khác biệt giữa Jira và Linear đủ lớn để người dùng chuyển đổi.

Tuy nhiên, Chrome đã đủ tốt. Slack đã đủ tốt, cộng với hàng năm tích hợp và chi phí chuyển đổi (switching cost). Việc tạo ra một phiên bản tốt hơn của một thứ gì đó đã đủ tốt là rất khó. Nghĩa trang của những "Slack tốt hơn" rất dài: Campsite, Quill, Threads... Chúng tôi đã cố gắng thay thế cả Chrome và Slack cùng lúc, nhưng tổng ma sát của chúng đơn giản là chưa đủ tệ để người dùng chịu đau khi chuyển đổi.

Kỹ thuật và Cạm bẫy của việc Tự dùng sản phẩm (Dogfooding)

Kiến trúc đa người chơi của chúng tôi thực sự thông minh. Thay vì truyền phát video, chúng tôi truyền phát các thay đổi DOM (DOM mutations). Khi ai đó tham gia vào một tab chia sẻ, hệ thống sẽ chụp nhanh và tái tạo lại DOM. Động cơ đồng bộ (sync engine) bên dưới sử dụng GraphQL subscriptions qua WebSockets, giúp việc chuyển đổi giữa các dạng sản phẩm (từ canvas sang bảng, sang chat) trở nên dễ dàng.

Màn hình Cursor ở giai đoạn đầu

Tuy nhiên, không có điều nào trong số này là nút thắt cổ chai. Kiến trúc là âm thanh, nhưng đòn bẩy (leverage) không giúp ích gì nếu bạn không tìm ra ai cần nó.

Tại một thời điểm, chúng tôi chuyển hoàn toàn khỏi Discord để sử dụng sản phẩm của chính mình. Chúng tôi theo dõi nhiệm vụ trong Sail và Muddy thay vì Linear. Chúng tôi chạy công ty bằng nó. Điều này cảm giác như sự xác nhận. Hãy cảnh giác với việc "tự dùng sản phẩm" (dogfooding). Nó dạy bạn ít hơn về việc đưa sản phẩm ra thị trường (go-to-market) hơn bạn nghĩ. Nếu bạn sao chép Slack và tự dùng nó, bạn sẽ biết liệu nó có lỗi hay không, nhưng bạn không kiểm tra xem liệu có ai khác muốn nó không. Người dùng bên ngoài gặp cùng một bức tường: "Tôi nên làm cái gì với cái này đây?"

Kinh nghiệm thực chiến (Reps) và Bằng chứng công việc (Proof of Work)

Mọi startup đều có một luận điểm. Luận điểm của chúng tôi là trình duyệt sẽ trở thành nền tảng cho sự cộng tác thời gian thực. Đó là một luận điểm tốt, được lập luận chặt chẽ. Nhưng vấn đề là luận đề không phải là sản phẩm. Một bí mật (secret) chỉ có giá trị nếu bạn có thể lặp lại cách của mình để chứng minh nó.

Elad Gil từng nói: "Nhìn chung, những thứ hoạt động thường hoạt động khá nhanh, thường là trong năm đầu tiên ra mắt." Số lần lặp lại (reps) chỉ được cộng dồn nếu bạn thay đổi đủ nhiều biến số giữa các lần thử và thực sự đưa từng phiên bản trước người dùng. Một số reps của chúng tôi bị lãng phí vì chúng tôi lặp lại mà không có đủ tín hiệu từ người dùng. Luận đề quá thuyết phục đến mức khó có thể đặt câu hỏi.

Trong khi làm việc tại Sail, tôi đã học vẽ người (figure drawing). Giáo viên nghệ thuật của tôi nói điều mà tôi luôn suy nghĩ: làm việc đồng đều trên toàn bộ bức tranh để bạn có thể dừng lại bất cứ lúc nào và coi như xong. Đừng để một bàn tay được vẽ đẹp trong khi phần thân vẫn là hình que. Tại Sail, chúng tôi đã làm điều này. Chúng tôi lặp lại trên ba phiên bản của thanh bên một mình. Đôi khi chúng tôi đánh bóng quá mức một tính năng trong khi phần còn lại của sản phẩm hầu như chưa có.

Cuối cùng, tôi nghĩ luận đề nên là la bàn, không phải đích đến. Bạn phải nắm giữ nó đủ lỏng lẻo để sản phẩm có thể phân kỳ khỏi câu chuyện. Luận đề cho bạn biết nơi để tìm. Các lần lặp lại cho bạn biết thực sự có cái gì ở đó. Bằng chứng công việc không chỉ là vận chuyển nhiều thứ. Đó là việc tìm kiếm sự thật một cách không ngừng nghỉ, vận chuyển theo cách mà mỗi phiên bản dạy cho bạn điều gì đó thay đổi phiên bản tiếp theo.

Hiện tại, tôi rất hào hứng về AI. Những khả năng mới biến những gì mô hình có thể làm thành sản phẩm mà mọi người thực sự sử dụng. Tôi vẫn còn nhiều reps để đi. Nếu bạn đang xây dựng phần mềm tham vọng, hãy liên hệ với tôi.