Năm 2004, một kỹ sư trẻ tên Josh Elman đi phỏng vấn vào LinkedIn. Reid Hoffman hỏi đúng một câu: “Sản phẩm mà một PM tạo ra là gì?” Elman trả lời không chần chừ: bản spec. Hai mươi năm sau, ông nói đó là câu trả lời sai. Sản phẩm thật của PM không bao giờ là bản spec. Là câu chuyện.
Nhưng ai cũng nói “kể chuyện” bây giờ. Vấn đề nằm ở chỗ ít người nói rõ: viết câu chuyện khó hơn viết spec rất nhiều. Spec có ô để tick. Câu chuyện phải sống sót khi được kể lại bởi người không có mặt trong phòng lúc bạn nghĩ ra nó.
Cái vòng lặp bị lộn ngược
Ngày xưa, quy trình làm sản phẩm chạy theo một cái vòng mà ai làm PM đều thuộc lòng: ý tưởng, viết spec, phân scope, rồi mới build. Mỗi bước tốn thời gian, tốn tiền, tốn cuộc họp. Viết spec 120 trang là cách bảo vệ đội kỹ thuật khỏi phải xây sai thứ, vì xây sai thì đắt lắm.
AI làm sập một vế của cái vòng đó. Giá xây thứ gì đó giảm không phải vài phần trăm, mà giảm theo bậc. Elman gọi thẳng: “absurdly cheap.” Khi xây rẻ như vậy, cái vòng lộn ngược: ý tưởng, xây luôn, chơi thử, rồi mới thiết kế cho đàng hoàng, rồi ship.
Nghe thì giải phóng. Nhưng cái giá của phán đoán (judgment) vẫn nguyên. Xây rẻ hơn, quyết định xây cái gì vẫn đắt như thường.
Đây là chỗ cần tách rõ hai thứ mà người ta hay trộn lẫn. Có hai vòng lặp khác nhau chạy song song trong đầu bất kỳ PM nào: vòng khám phá (sản phẩm này có ý nghĩa gì trong đời người dùng?) và vòng kiểm chứng (cái mình xây có hoạt động đúng không?). AI lộn ngược được vòng kiểm chứng, không lộn ngược được vòng khám phá.
LinkedIn phát hiện ra mục đích cốt lõi “tìm và được tìm thấy” không phải bằng cách xây prototype nhanh, mà bằng cách ngồi với người dùng, quan sát họ làm gì, rồi nhận ra rằng người ta chỉ cần LinkedIn một, hai lần mỗi năm, và tần suất đó là đúng.
Twitter cũng vậy. Khủng hoảng giữ chân người dùng không giải quyết bằng hack tăng trưởng, mà bằng cách phân tích vì sao hàng triệu người đăng ký xong rồi biến mất. Những đột phá sản phẩm quan trọng nhất đến từ quan sát, phân tích, ngồi im nghe, không phải từ xây nhanh hơn.
Trộn hai vòng lặp này lại với nhau là cách nhanh nhất để rơi vào cái mà Elman gọi là “AI slop for product”: nhồi nhét mọi thứ vào vì xây thì rẻ, kết quả là một sản phẩm trông như ráp chứ không phải thiết kế.
Ai là người nói “không”?
Khi xây đắt, PM kiểm soát một tài nguyên khan hiếm: thời gian của dev. Muốn xây gì phải qua PM, vì PM giữ chìa khóa quyền ‘truy cập’ dev. Cái quyền nói “không” của PM nằm ở đó, ở cổ chai tài nguyên.
Khi xây rẻ, bất kỳ kỹ sư nào cũng có thể dựng một prototype hoạt động trong một buổi chiều. Cổ chai biến mất. Và quyền nói “không” của PM bốc hơi theo.
Elman nói rằng “taste and curation matter a lot here.” Đúng. Nhưng đó là mô tả, không phải cơ chế. Taste quan trọng khi bạn có taste. Tầm nhìn quan trọng khi bạn có tầm nhìn. Câu nói này giống một lời khuyên cho người đã giỏi, không phải một công thức cho người đang học.
Bản spec 120 trang mà Elman viết hồi mới vào LinkedIn không phải lãng phí. Đó là dữ liệu huấn luyện cho cái phán đoán mà hôm nay ông gọi là “taste.” Mỗi trang spec buộc PM phải suy nghĩ kỹ: tính năng này phục vụ ai? Edge case nào sẽ nổ? Cái gì phải hy sinh? Viết spec là bài tập kỷ luật tư duy, không chỉ là tài liệu giao cho kỹ thuật.
Giết spec, có thể bạn đang giết luôn cái pipeline đào tạo thế hệ PM tiếp theo.
Mình từng ngồi trong những cuộc họp mà bên kinh doanh đẩy sang một file Excel nói “nếu chạy quảng cáo mỗi lần mở app thì doanh thu tăng X%.” Không ai phản bác được file Excel. Phản bác bằng cái gì? Bằng “câu chuyện sản phẩm”? Câu chuyện không có ô để tick, không có con số để so. Đó là lý do spec từng tồn tại: nó là thứ duy nhất PM có thể đặt lên bàn mà cả phòng phải nhìn vào.
Câu hỏi thật không phải “spec hay story.” Câu hỏi thật là: ai trong tổ chức có quyền giết một tính năng chỉ vì nó không khớp với câu chuyện? Hầu hết tổ chức chưa xây được cơ chế đó.
Bài kiểm tra kịch bản
Elman đề xuất một cái test đơn giản, gọi là Mục đích, Hành động cốt lõi, Chu kỳ (Purpose / Core Actions / Cycle). Nếu bạn không viết được một câu mô tả mục đích sản phẩm, liệt kê được những hành động chính mà người dùng thực sự làm, và biết tần suất mong đợi cho mỗi hành động, thì sản phẩm của bạn chưa có câu chuyện.
LinkedIn: mục đích là “tìm và được tìm thấy” trong sự nghiệp. Hành động cốt lõi là cập nhật hồ sơ, tìm người, nhận lời mời. Chu kỳ: một, hai lần mỗi năm. Nghe ít, nhưng đó là đúng. Elman kể rằng hiểu được cái chu kỳ “thấp” đó là chìa khóa để không cố ép LinkedIn thành thứ người ta mở mỗi ngày, một sai lầm mà nếu mắc thì chết.
Twitter: mục đích là “tìm ra chuyện gì đang xảy ra, ngay bây giờ, từ những người bạn quan tâm.” Hành động cốt lõi: follow, đọc tweet, tweet. Nhưng hàng triệu người đăng ký Twitter rồi không hiểu mình đang nhìn cái gì, vì sản phẩm giả định bạn đã biết “follow” nghĩa là gì, “timeline” hoạt động thế nào.
Elman xây một thứ gọi là Learn Flow: từng bước, dạy từng khái niệm. Bước 1: follow vài người. Bước 2: xem timeline. Bước 3: thử tweet. Nhiều bước đơn giản hơn, mỗi bước ngắn hơn, luôn thắng ít bước phức tạp. A/B test ở nhiều công ty, kết quả giống nhau. Learn Flow cải thiện tỉ lệ giữ chân người dùng hơn bất kỳ tính năng nào khác ra mắt năm đó.
Cái nhóm người dùng quan trọng nhất không phải nhóm hăng hái (bạn sẽ có họ bằng mọi giá) cũng không phải nhóm lướt qua (họ chưa bao giờ là của bạn). Đó là nhóm ở giữa: tò mò, chưa chắc chắn, đang chờ bạn kể cho họ nghe sản phẩm này có gì hay. Nhóm đó chuyển đổi bằng câu chuyện, không bằng tính năng.
Câu chuyện khó QA hơn spec
Đây là chỗ mà luận điểm của Elman mở ra một vấn đề ông không trả lời.
Spec có thể kiểm chứng: build xong, tick từng ô, xong. Câu chuyện thì không. Bạn không thể “kiểm tra” xem một câu chuyện đã được hiểu đúng chưa. Hai kỹ sư nghe cùng câu “LinkedIn giúp bạn tìm và được tìm thấy” có thể xây hai tính năng hoàn toàn khác nhau. Spec giải quyết vấn đề phối hợp bằng các ô tick kiểm chứng được. Câu chuyện giải quyết vấn đề truyền cảm hứng nhưng để ngỏ vấn đề phối hợp.
PM bây giờ cầm một thứ sản phẩm (deliverable) vừa quan trọng hơn bao giờ hết, vừa khó kiểm chứng hơn bao giờ hết. Đó là loại sản phẩm mà tổ chức lịch sử luôn không biết cách định giá, cho đến khi quá muộn.
Cũng giống như “taste,” PM bây giờ cần xây dựng taste từ đâu nếu không còn spec để tập? Nếu câu trả lời là “bạn chỉ cần có taste sẵn,” thì cái framework này là mô tả thực tế của PM giỏi, không phải phương pháp luận cho cả nghề. Pipeline đào tạo talent sẽ gãy.
Chiyoko vẫn chạy
Trong bộ phim hoạt hình Millennium Actress của đạo diễn Satoshi Kon, nữ diễn viên huyền thoại Chiyoko Fujiwara kể lại đời mình cho hai nhà làm phim tài liệu. Câu chuyện nhảy qua nhiều thời đại lịch sử Nhật Bản, nhiều thể loại phim, nhiều phiên bản của chính cô. Xuyên suốt tất cả là một người đàn ông mà cô đuổi theo, không bao giờ bắt kịp.
Cuối phim, khi được hỏi “Cô có tìm thấy ông ấy không?”, Chiyoko cười: “Thật ra, tôi yêu việc đuổi theo ông ấy.”
PM giỏi không cần tìm thấy câu chuyện hoàn hảo. Câu chuyện hoàn hảo không tồn tại, giống như người đàn ông trong phim Kon. Thứ tồn tại là hành động liên tục khám phá sản phẩm này có ý nghĩa gì trong đời người dùng, mỗi tuần, mỗi quý, mỗi lần thị trường xoay. Spec cho bạn ảo giác rằng bạn đã “xong.” Câu chuyện thì không bao giờ xong.
Nhưng tổ chức nào chịu trả lương cho người suốt đời đuổi theo thứ không bắt được?