Hồi tưởng về việc lựa chọn nền tảng thử nghiệm: Bài học từ cuộc đua giữa Eppo và Statsig

Có một thời điểm trong vòng đời của mọi công ty công nghệ mong muốn xây dựng sản phẩm mà người dùng yêu thích, khi mà ý niệm "chúng ta nên thử nghiệm nhiều hơn" chuyển sang trạng thái "chúng ta không thể tiếp tục thử nghiệm theo cách này nữa". Đó là khi việc phân bổ lưu lượng truy cập thủ công trở nên cồng kềnh, các yêu cầu kỹ thuật bị ném qua lại giữa quản lý sản phẩm (PM) và kỹ sư, và lịch làm việc của các nhà phân tích bị kín mít. Mong muốn trở nên dựa trên dữ liệu (data-driven) đã vượt quá khả năng của cơ chế vận hành hiện tại.

Đó chính là tình thế ManyChat gặp phải vào năm ngoái. Chúng tôi đã chọn Eppo, nhưng quyết định đó chỉ là một phần rất nhỏ của câu chuyện, và là phần ít có thể áp dụng trực tiếp cho công ty của bạn. Thay vào đó, tôi muốn chia sẻ quy trình tôi đã trải qua để đi đến quyết định đó, những gì tôi đã làm sai trên đường đi, và những điều bất ngờ tôi gặp phải sau khi ký hợp đồng.

Bối cảnh thị trường và vấn đề nội tại

Chúng tôi đã chọn Eppo vào một thời điểm khá thú vị của ngành, khi bản đồ các nhà cung cấp đang thay đổi ngay trong quá trình đánh giá. Eppo đã được Datadog mua lại vài tháng trước đó. Statsig vừa được OpenAI mua lại và sau đó bán lại cho Amplitude. Mặc dù những biến động này không làm thay đổi bản chất của bài toán, nhưng nó đã ảnh hưởng phần nào đến tâm lý của chúng tôi khi ra quyết định.

Trước khi mọi chuyện bắt đầu, không khí tại ManyChat khá căng thẳng. Một kỹ sư đã chia sẻ rằng nếu có hai cơ hội chạy thử nghiệm cùng lúc, đội ngũ của anh ấy sẽ đơn giản là hoãn ý tưởng thứ hai sang sprint sau vì đau đầu về mặt kỹ thuật khi phải cấu hình phân bổ lưu lượng. Rủi ro cấu hình sai cuối cùng đã lấn át sự hào hứng muốn thử nghiệm. Về phía phân tích, một đồng nghiệp mô tả mình là một "microservice con người": cô ấy phải tự định nghĩa nhóm kiểm soát (holdout groups), làm mới thủ công, chuyển cho kỹ sư... Đó là lúc nhu cầu về một nền tảng chuyên nghiệp không còn là lý thuyết suông.

Giai đoạn trước quyết định: Phân tầng rủi ro

Chúng tôi đối mặt với hai vấn đề lớn. Thứ nhất, nỗi đau hiện tại chỉ mang tính giai thoại. Lãnh đạo biết có gì đó sai sót, nhưng chưa có danh sách yêu cầu cụ thể để đối chiếu với tính năng của nhà cung cấp. Thứ hai, quyết định này mang tính ràng buộc cao (lock-in) và nguồn lực hữu hạn. Chúng tôi không thể POC (Proof of Concept - thử nghiệm thực tế) mọi nền tảng trên thị trường.

Để giải quyết, tôi bắt đầu bằng các cuộc phỏng vấn sâu với PM, kỹ sư và nhà phân tích để chuyển hóa các giai thoại thành yêu cầu công việc. Từ đó, chúng tôi chia quá trình khám phá thành ba lớp:

1. Nghiên cứu tài liệu: Đọc tài liệu của nhà cung cấp, phác thảo danh sách dài. Nhiều nền tảng tự loại bỏ ở bước này.
2. Bản demo: Cuộc trò chuyện tập trung với các nhà cung cấp đã được lọc danh sách.
3. POC: Trực tiếp thao tác trên nền tảng với dữ liệu thực, chỉ dành cho hai ứng viên cuối cùng.

Mỗi lớp giúp thu hẹp phạm vi và mang lại thông tin với mức "chi phí" có thể chấp nhận được. Đến lúc POC, chúng tôi chỉ còn lại hai cái tên: Statsig hay Eppo?

Giai đoạn ra quyết định: Khi điểm số không nói lên tất cả

Sau POC, các nhà phân tích trong hội đồng đánh giá lần lượt phát biểu. Hai người hiểu rõ nhất về kỹ thuật của chúng tôi kết luận bằng một câu: "Là một nhà phân tích sản phẩm, tôi sẽ rất vui vẻ nếu tiếp tục với bất kỳ cái nào".

Bảng điểm tổng hợp đồng tình: hai nền tảng đạt 4.36 và 4.47 trên thang điểm 5, qua hơn 20 tiêu chí. Về mọi khía cạnh hợp lý, đó là một trận hòa. Tôi đã dành tuần để xây dựng một quy trình chỉ ra rõ ràng một nền tảng tốt hơn, nhưng quy trình đó vừa nói với tôi rằng không có sự khác biệt ý nghĩa nào.

Bài học ở đây là sự nghiêm ngặt cấp độ phân tích hiện nay đã trở thành tiêu chuẩn cơ bản. Giá trị cận biên khi chọn một nền tảng hiện đại không nằm ở bảng điểm, mà nằm ở chỗ khác. Chúng tôi không chọn giữa hai bức ảnh tĩnh, mà là giữa hai quỹ đạo phát triển. Eppo đặt cược vào các quy trình làm việc có hướng dẫn, có quan điểm (opinionated), phù hợp với PM. Statsig tập trung vào sự linh hoạt cho người dùng chuyên sâu (power-user).

Chúng tôi nhận ra rằng, trong khi các nhà phân tích có khả năng thích nghi cao với mọi giao diện, thì việc onboarding cho PM lại không linh hoạt như vậy. Nếu nền tảng mà các nhà phân tích đánh giá ngang nhau cũng là nền tảng giảm rào cản cho PM của chúng tôi, đó là một quyết định đúng đắn. Ngược lại, chọn nền tảng thiên về kỹ thuật mà PM gặp khó khăn sẽ là tự phá hoại.

Vì vậy, chúng tôi chọn Eppo. Về dài hạn, Eppo phù hợp hơn với nơi chúng tôi muốn thử nghiệm sống: gần hơn với các đội ngũ thực nghiệm, không chỉ là nhà phân tích. Statsig có những ưu điểm như CUPED (kỹ thuật giảm phương sai) trong máy tính tính năng năng lượng, nhưng chúng tôi chấp nhận những khoảng trống đó để đổi lấy trải nghiệm người dùng tốt hơn cho đội ngũ không kỹ thuật.

Giai đoạn sau hợp đồng: Ống nước không phải là nước sạch

Tôi từng kỳ vọng (mặc dù không thừa nhận) rằng ký hợp đồng là vạch đích. Nhưng tôi đã lầm. Tôi đã dành tuần để xây dựng hệ thống quyết định đáng tin cậy, nhưng công việc thực sự mới chỉ bắt đầu.

Tôi thường dùng ẩn dụ về nước sạch. Chúng tôi đã lắp đặt đường ống: tích hợp SDK, kết nối dữ liệu, kết nối kho dữ liệu. Đường ống mang lại dòng chảy, nhưng không đảm bảo nước sạch. Trong trường hợp xấu nhất, đường ống còn làm ô nhiễm nó (nhiều rác thải đầu ra hơn, nhưng nhanh hơn). Nước sạch là thứ chảy ra từ đường ống khi phần còn lại của hệ thống (nguồn, xử lý, con người bảo trì) làm tốt việc của mình.

Công cụ đã sẵn sàng, nhưng tổ chức thì chưa sẵn sàng cho công cụ.

Ký hợp đồng không mua lại được thời gian, cũng không mang lại ngay lập tức nhiều thử nghiệm hơn. Công việc bắt đầu vào ngày sau khi ký: thành lập nhóm tích hợp đa chức năng, soạn thảo vòng đời thử nghiệm, cấu hình giao thức Eppo, chứng nhận các chỉ số thành công đầu tiên, di chuyển cơ sở kiến thức, thiết kế chương trình đào tạo... Tất cả những thứ này phải xảy ra trước khi nền tảng có thể khai thác tiềm năng tốc độ.

Để các thử nghiệm thực sự đáng tin cậy tại ManyChat, ba yếu tố phải hiện diện cùng lúc: công cụ/kỹ thuật, quy trình/quản trị, và con người/kỹ năng. Thiếu một trong ba, cả hệ thống sẽ mất cân bằng.

Kết luận

Nếu phải nén tất cả những điều này lại, tôi sẽ đúc kết thành vài dòng:

Một quyết định đáng tin cậy là sản phẩm giao hàng, không phải là nền tảng. Nền tảng chỉ là hiện vật. Quyết định là thứ mà tổ chức của bạn sẽ sống trong đó nhiều năm.

Cùng tinh thần đó, ống nước không phải là nước. Một công cụ là hạ tầng cần thiết cho thử nghiệm đáng tin cậy, nhưng chưa đủ. Công việc bắt đầu, không kết thúc, vào ngày ký hợp đồng.

Thị trường công cụ thử nghiệm đang biến động, nhưng những mảnh quy trình tồn tại được với tôi có lẽ là những thứ đáng để mượn: các cuộc phỏng vấn, khám phá phân tầng, định hướng tầm nhìn, và việc dự toán trung thực cho những gì sẽ diễn ra sau đó.