Không gian làm việc AI cho product manager: viết spec, nghiên cứu và kể chuyện trong một công cụ

AI thực sự phù hợp ở đâu trong tuần làm việc của PM

Quản lý sản phẩm là bốn công việc khác nhau dùng chung một lịch làm việc. Bạn đọc rất nhiều (phản hồi, ticket, bản ghi, dữ liệu xuất từ analytics), viết rất nhiều (spec, cập nhật, bản tóm tắt), phân tích một chút (funnel, cohort, kết quả khảo sát) và thuyết phục liên tục. Mỗi việc đó hợp với một model khác nhau, đó là lý do một gói AI duy nhất chỉ bao phủ khoảng hai phần ba khối lượng công việc, phần còn lại giống như một cuộc chiến.

Công việc của PM	Model tốt nhất	Vì sao
Mạch truyện PRD, phát biểu vấn đề, cập nhật sản phẩm	Claude	Giữ được mạch lập luận dài, viết văn xuôi mà kỹ sư thực sự đọc
Gom nhóm phản hồi, phân cụm ticket, trích xuất có cấu trúc	GPT	Đáng tin cậy với định dạng đầu ra chặt chẽ và nhãn phân loại nhất quán
Nghiên cứu discovery, quét đối thủ, bối cảnh thị trường	Gemini	Tốt nhất với tài liệu web mới, trả về nguồn bạn có thể mở ra xem
Bản ghi dài, tài liệu nghiên cứu, báo cáo 100 trang	Gemini	Cửa sổ ngữ cảnh 1 triệu token, nên cả kho dữ liệu vừa trong một lượt
Phản biện spec và săn tìm trường hợp biên	Bất kỳ model nào không viết bản spec đó	Một người đọc độc lập bắt được điều tác giả không thấy

Không điều nào trong số này thay thế được sự phán đoán về việc nên xây gì. Nó rút ngắn khoảng cách từ khi có dữ liệu đầu vào đến khi có thứ được viết ra thành văn bản, đây chính là nơi phần lớn thời gian một tuần làm PM thực sự bị rò rỉ. Việc chuyển đổi model cũng rẻ: trên Whizi Pro, một tin nhắn Claude Sonnet 5 tốn 10 credit trong hạn mức 2,000 credit mỗi tháng, một lượt trích xuất bằng GPT-5.6 Luna tốn 1 credit, còn Gemini 3.7 Flash đọc bản ghi với giá 2 credit mỗi tin nhắn.

Viết một bản PRD mà kỹ sư sẽ không trả lại

Phần lớn spec do AI viết thất bại ở cùng một điểm: chúng mô tả một tính năng thay vì một quyết định. Đội kỹ thuật không cần một đoạn văn về lý do khách hàng quan trọng. Họ cần các trạng thái, các trường hợp biên và điều gì xảy ra khi lệnh gọi thất bại. Hãy yêu cầu rõ ràng điều đó trong prompt, và kết quả sẽ thay đổi hẳn về chất.

Prompt: phát biểu vấn đề trước

Viết phần phát biểu vấn đề của một PRD. Bằng chứng tôi có: [dán ticket hỗ trợ, dữ liệu analytics, trích dẫn phỏng vấn]. Đừng đề xuất giải pháp. Trả về: ai gặp vấn đề này, tần suất ra sao, hiện tại họ làm gì thay thế, điều đó tốn kém với họ như thế nào, và chúng ta kỳ vọng điều gì sẽ thay đổi nếu vấn đề được giải quyết. Đánh dấu mọi khẳng định không được bằng chứng tôi dán hỗ trợ là GIẢ ĐỊNH.

Prompt: phần thân của spec

Chuyển nội dung này thành một bản đặc tả cho đội kỹ thuật. Tính năng: [mô tả]. Các trạng thái người dùng cần bao phủ: [danh sách]. Trả về: user story kèm tiêu chí chấp nhận, mọi trạng thái gồm cả rỗng, đang tải, lỗi và bị từ chối quyền, hành vi khi một phụ thuộc không khả dụng, các sự kiện analytics cùng thuộc tính của chúng, và các câu hỏi còn bỏ ngỏ. Đừng bịa ra yêu cầu tôi chưa nêu. Liệt kê mọi điều bạn phải giả định vào một mục riêng ở cuối.

Prompt: lượt phản biện

Đóng vai một staff engineer đang xem xét bản spec này trước khi ước lượng. Chỉ liệt kê các vấn đề: hành vi chưa được định nghĩa, trạng thái còn thiếu, các yêu cầu mâu thuẫn nhau, công việc migrate ẩn, và bất cứ điều gì sẽ tạo ra câu hỏi tiếp theo trong buổi refinement. Đừng viết lại bản spec.

Hãy chạy prompt thứ ba đó trên một model không viết bản spec. Nó thường xuyên phát hiện đúng ba câu hỏi mà đội của bạn lẽ ra sẽ nêu ra trong buổi refinement, và trả lời trước những câu hỏi đó chính là khác biệt giữa một buổi grooming 20 phút và một buổi kéo dài 50 phút.

Biến phản hồi thô thành thứ bạn có thể ưu tiên

Công việc AI mang lại đòn bẩy lớn nhất trong quản lý sản phẩm không phải là viết. Đó là đọc 400 phản hồi dưới một dạng bạn có thể hành động được. Làm thủ công việc này mất nửa ngày. Làm tốt với một model chỉ mất 20 phút, và chất lượng phụ thuộc gần như hoàn toàn vào việc bạn có ép buộc các danh mục ổn định hay không.

Prompt: gom chủ đề lượt đầu

Đây là phản hồi thô từ khách hàng. Hãy phân cụm thành các chủ đề. Với mỗi chủ đề, trả về: một nhãn, số lượng mục, mức độ nghiêm trọng ngụ ý qua ngôn từ, một trích dẫn nguyên văn tiêu biểu chép chính xác, và cho biết chủ đề này là lỗi, tính năng còn thiếu, vấn đề trải nghiệm, hay lệch kỳ vọng. Đừng gộp các chủ đề có nguyên nhân gốc khác nhau dù cách diễn đạt giống nhau. Đừng diễn giải lại trích dẫn. Phản hồi: [dán vào].

Prompt: lượt hai đối chiếu với hệ phân loại cố định

Hãy phân loại lại cùng phản hồi này chỉ dùng các danh mục sau: [dán hệ phân loại hiện có của bạn]. Bất cứ điều gì không khớp thì xếp vào KHÔNG PHÂN LOẠI kèm giải thích. Trả về một bảng gồm danh mục, số lượng và tỷ lệ phần trăm.

Cấu trúc hai lượt này quan trọng. Lượt đầu cho bạn biết thực sự có gì trong dữ liệu. Lượt hai làm cho kết quả có thể so sánh với quý trước, đó là điều khiến nó dùng được trong một cuộc họp ưu tiên hóa chứ không chỉ để tham khảo cho vui.

Nên yêu cầu gì	Bạn nhận được gì	Dùng tốt cho việc gì
Chủ đề kèm số lượng	Một danh sách xếp hạng các mảng vấn đề	Đầu vào cho roadmap, lập kế hoạch quý
Chỉ trích dẫn nguyên văn	Ngôn ngữ khách hàng chưa qua chỉnh sửa	Copy, định vị sản phẩm, thuyết phục ban lãnh đạo
Tách theo mức độ nghiêm trọng và tần suất	Một ma trận 2x2 giữa mức độ đau và khối lượng	Quyết định sửa cái gì trước
Mâu thuẫn	Nơi các phân khúc muốn những điều trái ngược nhau	Bắt sớm một sự đồng thuận giả

Hàng cuối cùng đó đáng để có một prompt cố định: Trong phản hồi này, ở đâu các nhóm người dùng khác nhau muốn những điều không tương thích với nhau? Nêu tên các phân khúc và sự đánh đổi. Một danh sách chủ đề làm phẳng sự bất đồng, mà sự bất đồng thường là điều hữu ích nhất trong dữ liệu.

Discovery, đối thủ và những nghiên cứu bạn không bao giờ có thời gian làm

Discovery là công việc bị cắt bỏ đầu tiên khi một bản phát hành trễ hạn, đúng lúc một quyết định sai lầm tốn kém nhất. Quét dữ liệu với sự trợ giúp của model không thay thế việc nói chuyện với khách hàng, nhưng nó loại bỏ cái cớ để bước vào một quyết định mà không biết gì cả.

Prompt: mổ xẻ đối thủ

Xây dựng một bản mổ xẻ về cách [đối thủ] xử lý [công việc cần hoàn thành]. Bao gồm: cách họ tự định vị bằng chính lời của họ, luồng thao tác được ghi trong trung tâm trợ giúp của họ, giá cả nếu công khai, những gì đã thay đổi trong 12 tháng qua kèm ngày tháng, và các chủ đề than phiền thấy được trong đánh giá công khai. Trích dẫn mọi khẳng định kèm URL. Tách bạch điều công ty tự nói với điều bên thứ ba quan sát được.

Prompt: tổng hợp phỏng vấn

Đọc các bản ghi phỏng vấn này. Trả về: những công việc người dùng đang cố hoàn thành, các giải pháp tạm họ đã tự nghĩ ra, những khoảnh khắc họ bày tỏ sự bực bội kèm trích dẫn chính xác, và bất kỳ chỗ nào điều một người dùng nói mâu thuẫn với điều họ mô tả mình đã làm. Đừng khái quát hóa vượt ra ngoài các bản ghi. Nếu một khuôn mẫu chỉ xuất hiện ở ít hơn ba cuộc phỏng vấn, hãy gán nhãn đó là một quan sát đơn lẻ chứ không phải một khuôn mẫu.

Ràng buộc cuối cùng đó là điều PM hay quên nhất. Các model rất hào hứng tạo ra những khuôn mẫu gọn gàng, và một khuôn mẫu gọn gàng rút ra từ hai cuộc phỏng vấn là cách một roadmap kết thúc bằng việc phục vụ một khách hàng không tồn tại. Hãy luôn yêu cầu số lượng đi kèm mọi khẳng định.

Kể chuyện cho ban lãnh đạo và truyền thông ra mắt

Cùng một nội dung phải tồn tại ở bốn độ cao khác nhau: một bản spec cho đội kỹ thuật, một bản cập nhật cho cả đội, một đoạn văn cho buổi review với lãnh đạo, và một ghi chú ra mắt cho khách hàng. Viết lại giữa các độ cao là công việc máy móc nhất trong nghề, và cũng dễ giao lại nhất.

Prompt: đổi độ cao

Viết lại nội dung này cho [đối tượng]. Họ quan tâm đến [những mối bận tâm cụ thể]. Họ có mức độ hiểu biết [mức độ] về mảng sản phẩm này. Giữ nguyên mọi khẳng định về sự kiện. Độ dài: [ràng buộc]. Mở đầu bằng quyết định hoặc kết quả, không phải bối cảnh. Bản nháp: [dán vào].

Prompt: đoạn văn cho lãnh đạo

Nén bản cập nhật này thành 120 từ cho một lãnh đạo chỉ đọc một lần. Cấu trúc: điều gì đã thay đổi, điều đó có ý nghĩa gì với chỉ số chúng ta đã cam kết, chúng ta cần gì từ họ, và rủi ro duy nhất đáng để họ chú ý. Không dùng tính từ nào không được đo lường.

Prompt: kịch bản khai tử trước

Giả sử bản ra mắt này thất bại sáu tháng sau. Viết ba lời giải thích khả dĩ nhất, xếp theo mức độ khả năng, chỉ dùng thông tin trong kế hoạch bên dưới. Với mỗi lời giải thích, nêu tín hiệu sớm mà chúng ta có thể theo dõi. Kế hoạch: [dán vào].

Hãy giữ cả bốn độ cao trong cùng một luồng chat trên Whizi. Ghi chú ra mắt sẽ thừa hưởng bối cảnh từ bản spec và bản phân tích phản hồi, nhờ vậy bạn không phải giải thích lại tính năng mỗi lần đổi đối tượng.

Nơi AI dễ đánh lừa product manager nhất

Ba kiểu sai lầm này quan trọng với công việc này hơn với hầu hết công việc khác.

Trích dẫn nguyên văn bịa đặt. Nếu bạn yêu cầu trích dẫn tiêu biểu mà không neo model vào văn bản gốc, đôi khi bạn sẽ nhận một câu nghe hợp lý mà không khách hàng nào từng nói. Luôn ra lệnh chép trích dẫn chính xác, đừng diễn giải lại, và kiểm tra ngẫu nhiên ba trích dẫn đối chiếu với dữ liệu thô trước khi bất kỳ trích dẫn nào lên slide.

Sự tự tin sai lệch từ mẫu nhỏ. Một model sẽ gom chủ đề cho tám ticket hỗ trợ với đúng mức tự tin y hệt như khi gom tám trăm ticket. Hãy yêu cầu số lượng cho mọi chủ đề, và coi bất cứ điều gì dưới một vài trường hợp là một quan sát chứ không phải một tín hiệu.

Kịch diễn roadmap. Yêu cầu một model ưu tiên hóa backlog của bạn sẽ tạo ra một bảng xếp hạng đầy tự tin, chỉ dựa trên câu chữ trong ticket của bạn. Nó không có quyền truy cập vào chiến lược, năng lực, nợ kỹ thuật, hay hợp đồng sẽ chốt vào quý sau của bạn. Hãy dùng nó để cấu trúc hóa sự đánh đổi, không bao giờ để nó đưa ra quyết định cuối cùng.