Đọc bài này trước khi nhận job PM AI tiếp theo
TL;DR
- Anthropic Claude Code cắt chu kỳ ra mắt từ 6 tháng xuống còn 1 ngày bằng cách bỏ PRD và xóa ranh giới vai trò.
- PM thời AI không thắng bằng viết code, mà bằng “product taste” – chọn đúng cái cần làm giữa hàng vạn yêu cầu.
- Nhãn “Research Preview” cho phép ra mắt cực nhanh, xóa áp lực hoàn hảo và chấp nhận “làm nhanh, xóa nhanh”.
- Quyết định không cần họp nhiều vì mọi người dùng chung một “mặc định”: ưu tiên tuyệt đối cho sứ mệnh Anthropic.
- Lợi thế cuối cùng của con người tạm thời nằm ở EQ, quan hệ, bối cảnh – nhưng ngay cả thứ đó cũng không vĩnh viễn.
- Đọc bài này trước khi nhận job PM AI tiếp theo
- TL;DR
- Mục lục
- Anthropic Claude Code đã tăng tốc ra mắt tính năng như thế nào?
- Vì sao Claude Code dám vứt bỏ PRD và tối thiểu hóa quy trình?
- Research Preview là gì và tại sao giúp ra mắt trong 1 ngày?
- Tại sao “sứ mệnh” lại thay thế được quy trình và phê duyệt?
- Product Taste là gì và vì sao là vũ khí sống còn của PM AI?
- Làm sao thiết kế sản phẩm khớp với năng lực mô hình AI hiện tại?
- Phần nào trong công việc PM AI vẫn là “vùng đặc quyền” của con người?
- Làm PM tại Claude Code thực sự có nghĩa là làm gì mỗi ngày?
- Nên bắt đầu từ đâu? Lộ trình hành động trong 30 ngày
- Hệ thống lại & bước tiếp theo: Bạn nên làm gì ngay hôm nay?
- Câu hỏi thường gặp
- Q: Vì sao Anthropic có thể bỏ hẳn PRD mà vẫn không hỗn loạn?
- Q: Research Preview khác gì beta thông thường?
- Q: Product Taste có thể học được không hay là bẩm sinh?
- Q: PM AI có nhất thiết phải biết code như Claude Code PM?
- Q: Lợi thế “EQ, hiểu bối cảnh tổ chức” của PM sẽ tồn tại bao lâu trước khi AI bắt kịp?
Mục lục
- Anthropic Claude Code đã tăng tốc ra mắt tính năng như thế nào?
- Vì sao Claude Code dám vứt bỏ PRD và tối thiểu hóa quy trình?
- Research Preview là gì và tại sao giúp ra mắt trong 1 ngày?
- Tại sao “sứ mệnh” lại thay thế được quy trình và phê duyệt?
- Product Taste là gì và vì sao là vũ khí sống còn của PM AI?
- Làm sao thiết kế sản phẩm khớp với năng lực mô hình AI hiện tại?
- Phần nào trong công việc PM AI vẫn là “vùng đặc quyền” của con người?
- Làm PM tại Claude Code thực sự có nghĩa là làm gì mỗi ngày?
- Nên bắt đầu từ đâu? Lộ trình hành động trong 30 ngày
- Hệ thống lại & bước tiếp theo: Bạn nên làm gì ngay hôm nay?
- Câu hỏi thường gặp
Anthropic Claude Code là một trong những ví dụ cực đoan nhất về việc AI đang tái định nghĩa cách xây sản phẩm: họ tung ra 35 tính năng chỉ trong 90 ngày, trung bình 2,6 ngày một lần ra mắt lớn.
Related: Claude Code 2026: Nền tảng AI Operating System | Hướng Dẫn
Related: AI thời hậu code: 12 bài học từ workflow Anthropic
Related: Claude Code Auto Mode: Chạy Tác Vụ Dài Không Bị Hỏi
Related: Claude Managed Agents và sự thật về AI hạ tầng đã chết
Tôi đã xem lại toàn bộ chia sẻ của Cat Wu – Head of Product Claude Code – và phải điều chỉnh lại gần như mọi giả định về nghề PM trong kỷ nguyên AI.
Ở đây không còn chuyện “viết PRD thật đẹp rồi chuyển cho team khác” nữa. PM viết code, designer code frontend, engineer làm luôn vai PM. Gần như mọi tính năng đều được đóng mác “Research Preview” để đẩy ra thị trường cực nhanh.
“Chức năng từng mất 6 tháng, giờ có thể ra đời trong 1 ngày” – với Anthropic, đây không phải khẩu hiệu marketing, mà là số liệu thật được chứng minh bằng lịch sử phát hành sản phẩm.
Anthropic Claude Code đã tăng tốc ra mắt tính năng như thế nào?
Tại sao phần này quan trọng với bạn?
Anthropic Claude Code là case study sống cho thấy sản phẩm AI có thể được ship theo đơn vị ngày, không phải tháng. Nếu bạn đang làm PM, dev hay founder, hiểu cơ chế này sẽ cho bạn một benchmark hoàn toàn mới về tốc độ và cách tổ chức đội.
Trong 90 ngày từ tháng 1 đến tháng 3, Claude Code cùng các mảng khác của Anthropic đã tung tổng cộng 35 tính năng – trung bình cứ khoảng 2,6 ngày lại có một tính năng đủ lớn để được tính là một lần ra mắt, không phải bug fix lặt vặt.
Ngay cả Lenny Rachitsky – host của Lenny’s Podcast, người đã phỏng vấn hàng trăm PM và founder hàng đầu – cũng phải thừa nhận ông “chưa từng thấy nhịp ship nào như vậy”. Khi một người sống bằng nghề nghiên cứu sản phẩm nói câu đó, thường có điều gì đó thực sự khác biệt trong cấu trúc tổ chức phía sau.
Tốc độ này không thể giải thích đơn thuần bằng “thuê thêm người” hay “đổ thêm tiền”. Cat Wu nói rất rõ: chính AI và sự cải thiện liên tục của mô hình đã kéo ngắn chu kỳ phát triển từ 12 tháng xuống 1 tháng, thậm chí 1 ngày với một số tính năng. Cách viết code, thiết kế, kiểm thử lẫn cách ra quyết định – tất cả đều bị AI làm cho nhanh hơn bình thường.
“AI đang kéo timeline sản phẩm từ đơn vị tháng xuống đơn vị ngày. Nếu quy trình của bạn vẫn đứng yên, bạn đang tự biến mình thành nút thắt cổ chai.”
Bạn cần ghi nhớ điều gì?
- Claude Code đạt trung bình 2,6 ngày/tính năng lớn trong 90 ngày.
- Tăng headcount không đủ giải thích – cấu trúc tổ chức và cách dùng AI mới là chìa khóa.
- Timeline build sản phẩm đã chuyển từ “năm, tháng” sang “tháng, ngày”.
- Tốc độ này đặt lại chuẩn kỳ vọng đối với PM, dev, founder trong kỷ nguyên AI.
Vì sao Claude Code dám vứt bỏ PRD và tối thiểu hóa quy trình?
Tại sao phần này quan trọng với bạn?
Bỏ PRD nghe giống “phản bội giáo trình PM”, nhưng Claude Code chứng minh điều ngược lại: bỏ PRD đúng cách giúp họ ship nhanh mà vẫn không loạn. Hiểu cấu trúc thay thế PRD của họ sẽ giúp bạn biết mình có thể lược bớt gì trong quy trình mà không phá nát đội.
PRD (Product Requirements Document) là tài liệu gần như bất khả xâm phạm ở hầu hết công ty phần mềm – nơi PM mô tả chi tiết yêu cầu, luồng, edge case, rồi lần lượt chuyển tay qua design, dev. Claude Code gần như loại bỏ hoàn toàn thứ này khỏi đời sống hàng ngày.
Thay vì dựa vào PRD, họ dựng hai trụ cột khác:
- Metric review hàng tuần – cả đội cùng nhìn vào số liệu.
- Team Principles Document – một tài liệu duy nhất nói rõ ai là người dùng cốt lõi và vì sao.
Nhờ đó, bất kỳ ai cũng có thể tự đọc số, tự đối chiếu với nguyên tắc người dùng, rồi ra quyết định mà không phải đợi một chuỗi phê duyệt. Trên thực tế, chỉ riêng việc bỏ bớt “chờ duyệt PRD” đã cắt được hàng tuần trì hoãn tích lũy ở các team sản phẩm tôi từng làm việc cùng.
“Khi số và nguyên tắc đã rõ, PRD chỉ còn là một lớp giấy tờ giúp mọi người cảm thấy an toàn – chứ không còn là thứ tạo ra giá trị.”
Làm việc không PRD cụ thể như thế nào?
Metric review nghĩa là cả team cùng xem DAU, retention, conversion, complaint rate… nên không ai bị “mù số”. Team Principles thì viết rõ “chúng ta phục vụ ai trước, ưu tiên tình huống nào, bỏ qua điều gì” – để tránh những cuộc tranh luận không hồi kết.
Kết quả khá rõ: PM không còn là cổ chai phê duyệt. Ý tưởng có thể xuất phát từ bất kỳ ai, và người nghĩ ra có thể trực tiếp build bản đầu tiên. Thời gian chờ giữa các bước viết – duyệt – chuyển tay – chỉnh sửa gần như bị xóa sổ.
Đây là phiên bản “lean” đúng nghĩa: tối thiểu quy trình nhưng tối đa hóa sự chia sẻ cùng một bức tranh chung qua metrics và principles. Đội không bị hỗn loạn vì ai cũng nhìn về cùng một hướng.
Bạn cần ghi nhớ điều gì?
- PRD được thay bằng 2 thứ: metric review hàng tuần và tài liệu nguyên tắc đội.
- Thông tin đối xứng giúp ai cũng có thể ra quyết định mà không đợi PM.
- Thời gian chết vì “handoff” giảm mạnh, ý tưởng đi thẳng từ người nghĩ đến người build.
- Quy trình tối thiểu không đồng nghĩa với hỗn loạn nếu “người dùng cốt lõi + số liệu” được chia sẻ rõ ràng.
Research Preview là gì và tại sao giúp ra mắt trong 1 ngày?
Khi nào bạn nên quan tâm tới Research Preview?
Research Preview là nhãn sản phẩm giúp hợp thức hóa việc “ra mắt khi còn dang dở”. Nếu bạn đang bị kẹt vì nỗi sợ “chưa hoàn hảo nên chưa dám release”, cơ chế này có thể mở khóa cả đội.
Research Preview là dạng ra mắt nơi tính năng được công bố rõ là: còn thử nghiệm, đang thu thập phản hồi, và có thể bị gỡ bất cứ lúc nào. Claude Code gắn nhãn này cho hầu hết tính năng mới.
Với đội sản phẩm, điều này gỡ bỏ áp lực “ra mắt lần nào là phải hoàn hảo lần đó”. Tung ra nhanh bỗng trở thành một thí nghiệm chính thức, không phải trò liều lĩnh. Với người dùng, nhãn này đặt kỳ vọng ở mức hợp lý: họ biết mình đang dùng thứ thử nghiệm. Nếu tính năng biến mất, họ ít cảm thấy bị phản bội, và phần lớn phản hồi trên tinh thần “đã hiểu luật chơi”.
“Nhãn Research Preview không chỉ là nhãn marketing – nó là hợp đồng tâm lý cho phép đội ngũ và người dùng cùng chấp nhận sự chưa hoàn hảo.”
Chu kỳ “làm nhanh – xóa nhanh” vận hành ra sao?
Claude Code có một văn hóa độc đáo: mỗi khi mô hình mới ra mắt, họ sẵn sàng xóa những tính năng đã từng là cứu cánh cho phiên bản cũ.
Ví dụ cụ thể: lúc đầu, để bù việc model hay mất ngữ cảnh trong các tác vụ dài, họ làm thêm tính năng to-do list bên cạnh. Khi model đủ tốt để tự quản lý tác vụ, to-do list không còn được đẩy mạnh nữa – thậm chí mờ dần khỏi trọng tâm sản phẩm.
Theo cách nói của họ, “model ăn chính công cụ mà nó từng cần để bù đắp”. Đây là thái độ cực hiếm: chấp nhận vứt bỏ công việc của chính mình khi nền tảng đã vượt qua điểm giới hạn cũ. Làm nhanh, ra nhanh, đo phản hồi thật, rồi xóa cũng nhanh khi model đã giải quyết vấn đề ở tầng sâu hơn. Chu kỳ này chỉ bền vững khi cả đội và người dùng đã quen với khung Research Preview.
Bạn cần ghi nhớ điều gì?
- Research Preview là nhãn cho phép “ra mắt sớm, chưa hoàn thiện, có thể biến mất”.
- Nó gỡ nút thắt tâm lý cho đội sản phẩm và chỉnh lại kỳ vọng của người dùng.
- Claude Code chấp nhận xóa tính năng cũ khi model mới đã tự giải quyết vấn đề.
- Chu kỳ “làm nhanh – xóa nhanh” là đặc trưng của sản phẩm gắn chặt với tiến bộ mô hình AI.
Tại sao “sứ mệnh” lại thay thế được quy trình và phê duyệt?
Khi nào bạn nên áp dụng cách làm này?
Mission-driven decision making là cách dùng sứ mệnh làm “mặc định” cho mọi quyết định nhỏ hàng ngày. Nếu tổ chức muốn giảm bớt phê duyệt mà không rơi vào hỗn loạn, đây là nền tảng bắt buộc.
Anthropic có một câu ngắn gọn: “Đưa AGI an toàn đến với nhân loại.” Nghe trừu tượng, nhưng với Claude Code, nó trở thành kim chỉ nam mỗi khi ưu tiên va chạm nhau. Khi hai lựa chọn cùng tốt cho team, họ hỏi: lựa chọn nào gần sứ mệnh Anthropic hơn? Và nếu câu trả lời là “X tốt cho Anthropic, Y tốt cho Claude Code”, họ sẵn sàng chọn X.
“Nếu Claude Code thất bại mà Anthropic thành công, tôi vẫn rất hạnh phúc.” – câu nói “thử nghiệm tư duy” của Cat Wu, nhưng phản chiếu hệ giá trị thật của đội.
Điểm thú vị ở đây là: đa số tổ chức nói về “sứ mệnh” nhưng lại thưởng – phạt theo KPI riêng lẻ của từng team. Ở Claude Code, câu chuyện ngược lại hoàn toàn – văn hóa chấp nhận hy sinh thành công của sản phẩm con cho sứ mệnh chung đã được nội hóa thật sự, không chỉ nằm trên poster.
Điều này rút ngắn quyết định như thế nào?
Khi đã rõ “ưu tiên Anthropic trước, sản phẩm con sau”, nhiều tranh cãi tự rơi rụng mà không cần họp. Không cần thêm check-point phê duyệt, vì tiêu chí “gần mission hơn” luôn sẵn sàng để so sánh. Cả đội cũng hiểu sẽ có sự trùng lặp, thiếu nhất quán tạm thời – nhưng đổi lại là tốc độ.
Cái giá họ trả là tính nhất quán sản phẩm: có lúc cùng một việc nhưng có đến 2–3 cách làm trong sản phẩm. Thay vì cố dọn sạch từ bên trong, họ “giao phó sự nhất quán cho thị trường”: người dùng sẽ dùng, phản hồi, và họ dọn lại dựa trên tín hiệu thực tế.
“Khi bạn để thị trường quyết định chuẩn mực, nghĩa là bạn chấp nhận sản phẩm trông hơi lộn xộn trong một thời gian – đổi lại bạn không chậm lại vì tranh cãi nội bộ.”
Bạn cần ghi nhớ điều gì?
- Mission-driven nghĩa là ưu tiên sứ mệnh chung hơn KPI cá nhân hay team.
- Điều này giúp quyết định nhanh vì luôn có “mặc định” để so sánh khi có xung đột.
- Cái giá là sản phẩm có thể kém nhất quán trong ngắn hạn.
- Claude Code chấp nhận “ủy quyền sự nhất quán cho thị trường” thay vì cố tối ưu nội bộ.
Product Taste là gì và vì sao là vũ khí sống còn của PM AI?
Product Taste trả lời câu hỏi gì?
Product Taste là khả năng chọn đúng cái nên làm và làm theo cách khiến người dùng thấy “đúng đến kỳ lạ”. Trong thời đại AI khiến việc viết code rẻ đi, năng lực này trở thành lõi nghề của PM.
Cat Wu mô tả rất rõ: khi chi phí viết code giảm mạnh nhờ AI, cái trở nên quý hơn không phải là “biết code thế nào” mà là “quyết định viết cái gì”. Claude Code nhận hàng vạn yêu cầu tính năng qua GitHub mỗi ngày, nhưng thực tế họ chỉ có thể làm được một phần rất nhỏ.
Khi thực sự đọc backlog ở các team AI, phần lớn issue là biến thể hoặc tối ưu cục bộ cho một nhóm nhỏ. Product Taste giúp PM nhận ra ý nào chỉ là “tiện lợi cho một nhóm” so với ý nào tạo ra bước nhảy cho đa số. Và cách thiết kế UX nào sẽ khiến người dùng cảm thấy “sản phẩm hiểu mình” mà không cần giải thích dài dòng.
“Viết code rẻ hơn không làm backlog nhỏ đi – nó chỉ làm sai lầm trở nên rẻ hơn. Product Taste là cái duy nhất giữ bạn khỏi chết chìm trong những sai lầm rẻ tiền.”
Làm sao rèn Product Taste trong bối cảnh AI?
Product Taste không phải kỹ năng học được qua slide hay chứng chỉ. Theo Cat Wu, nó đến từ ba nguồn chính:
Đọc cực nhiều feedback người dùng – hiểu họ đau ở đâu, đọc nguyên văn chứ không chỉ qua báo cáo tóm tắt. Tự dùng sản phẩm mỗi ngày – PM ở Claude Code đều là heavy user của chính Claude Code. Đụng trực diện vào giới hạn model – chỉ khi tận tay va vào lỗi, bạn mới hiểu mình nên bọc product như thế nào quanh năng lực hiện tại.
Kết quả thử nghiệm cho thấy: khi dành 1–2 giờ mỗi ngày chỉ để dùng, phá, thử các luồng lạ trong sản phẩm, cảm giác về “cái gì đáng build” rõ hơn rất nhiều so với thời điểm chỉ ngồi đọc dashboard.
Bạn cần ghi nhớ điều gì?
- Product Taste = chọn đúng thứ cần làm + chọn đúng cách người dùng sẽ thích.
- Khi code rẻ, backlog phình to; Product Taste là bộ lọc sống còn.
- Rèn Product Taste bằng feedback thật, dùng sản phẩm hàng ngày, hiểu giới hạn model.
- Ở Claude Code, PM vừa là người quản lý sản phẩm vừa là power user của chính nó.
Làm sao thiết kế sản phẩm khớp với năng lực mô hình AI hiện tại?
Nên tránh những sai lầm nào?
Thiết kế sản phẩm AI không chỉ là “bọc UI quanh model”. Điều khó nhất, theo Cat Wu, là tìm “điểm công bằng” giữa tin quá nhiều vào AGI tương lai và không tin đủ vào model hiện tại.
Có hai cực nguy hiểm. Cực thứ nhất: thần thánh hóa AGI – tưởng tượng tương lai nơi model làm hết mọi thứ, sản phẩm chỉ còn một ô chat trống. Trong hiện tại, kết quả là sản phẩm không đủ cấu trúc để giúp người dùng, dẫn tới trải nghiệm “model chẳng làm được gì ra hồn”. Cực thứ hai: quá bi quan với model – chỉ nhìn vào limit hiện tại, thiết kế sản phẩm cực bảo thủ. Sáu tháng sau, khi model nhảy vọt, cả sản phẩm trở nên lạc hậu, nặng nề, thừa lớp bọc.
“Thiết kế cho siêu AGI tương lai rất dễ. Cái khó là thiết kế sản phẩm tận dụng tối đa năng lực của model ngay bây giờ.”
Cân chỉnh “độ khó” của sản phẩm ra sao?
Model đang tiến bộ theo tháng, không phải theo năm – sản phẩm mất 6 tháng mới ra có nguy cơ lệch pha ngay khi vừa launch. Vì vậy, không thể coi V1 là bất biến, mà chỉ là một snapshot tạm thời. Nếu model mạnh hơn mong đợi, bỏ bớt UI thừa. Nếu yếu hơn, bổ sung cấu trúc trợ giúp.
Đây là điểm đa số team AI bỏ qua: họ đối xử với model như “backend ổn định”, trong khi thực tế model giống một thành viên đội dev đang lên level cực nhanh. Sản phẩm phải được thiết kế như một “bộ khung đàn hồi”, liên tục co giãn theo sức mạnh model.
Bạn cần ghi nhớ điều gì?
- Nguy hiểm 1: tin quá nhiều vào AGI tương lai, sản phẩm hiện tại không dùng được.
- Nguy hiểm 2: quá sợ hạn chế model, làm sản phẩm cứng nhắc, nhanh lỗi thời.
- PM giỏi phải liên tục re-calibrate sản phẩm theo từng phiên bản model.
- “Thiết kế cho hiện tại” khó hơn nhiều so với “mơ về tương lai”.
Phần nào trong công việc PM AI vẫn là “vùng đặc quyền” của con người?
EQ còn giá trị ở đâu?
Human Domain trong công việc PM là vùng mà model AI hiện tại khó chạm tới: hiểu người, hiểu mối quan hệ, hiểu “luật ngầm”. Nếu bạn là PM đang lo bị AI thay thế, đây là mảnh đất còn lại – ít nhất là trong ngắn hạn.
Để ship một sản phẩm, có vô số “phần chuyển động” ngoài code: Ai là người bị ảnh hưởng? Sales, CS, marketing, đối tác ngoài công ty? Ai đang có xung đột quyền lợi ngầm mà một thay đổi nhỏ cũng có thể khơi lại? Ai thích nghe tin qua email, ai ghét email mà chỉ phản hồi trên Zalo hay Slack?
Cat Wu chia “vùng người” này thành bốn nhóm kỹ năng:
- Nhận diện stakeholder – biết ai cần được lôi vào cuộc.
- Hiểu cấu trúc quan hệ – ai thân với ai, ai đang có lịch sử xung đột.
- Nắm sở thích cá nhân – người này ghét họp đông, người kia chỉ phản hồi khi có số liệu.
- Chọn kênh và thời điểm giao tiếp – email, call, họp trực tiếp, hay update trên Notion/Slack/Zalo.
Đây là “common sense có bối cảnh” và “kiến thức dựa trên EQ” – thứ không có trong tài liệu chính thức nào nhưng lại quyết định 50% khả năng launch trơn tru.
Lợi thế này kéo dài bao lâu?
Điểm thú vị là: chính Cat Wu cũng không tin lợi thế này là vĩnh viễn. Cô nói thẳng: model rồi cũng sẽ giỏi dần lên ở phần này, dù hiện tại còn khoảng cách khá xa.
Điều đó có hai ngụ ý quan trọng. Đừng bám chặt vào một bộ kỹ năng duy nhất và tin nó sẽ cứu bạn mãi mãi. Sự sống còn của PM nằm ở khả năng di chuyển cùng “vùng chênh lệch” giữa người và AI, không phải trấn thủ một vị trí cố định.
Những PM linh hoạt nhất thường xuyên tự hỏi: “Hôm nay AI làm được gì rồi, và lỗ hổng mới ở đâu?” Rồi họ điền vào lỗ hổng đó, thay vì cố bảo vệ lỗ hổng cũ vốn đã bị AI san phẳng.
Bạn cần ghi nhớ điều gì?
- Human Domain hiện tại nằm ở EQ, quan hệ, bối cảnh tổ chức – không phải ở việc viết tài liệu.
- Bốn kỹ năng lõi: tìm stakeholder, hiểu mạng lưới quan hệ, nắm sở thích cá nhân, chọn kênh giao tiếp.
- Lợi thế này không vĩnh viễn; model sẽ dần giỏi hơn ở các mảng này.
- PM sống sót là người di chuyển cùng “khoảng cách người – AI”, không cố đứng yên.
Làm PM tại Claude Code thực sự có nghĩa là làm gì mỗi ngày?
Vai trò PM ở đây khác gì PM truyền thống?
Claude Code PM là một sinh vật “lai”: vừa là PM, vừa là dev, vừa là power user của chính sản phẩm. Nếu bạn quen với hình mẫu PM “ông vua của slide và PRD”, mô hình này gần như là đối nghịch hoàn toàn.
PM viết code, ít nhất là đủ để hiện thực hóa ý tưởng bản đầu. Designer xuất thân từ frontend, có thể tự triển khai thiết kế. Engineer cũng làm luôn vai PM khi cần, từ nói chuyện với user đến quyết định ưu tiên.
“Thay vì tuyển thêm PM truyền thống, họ ưu tiên tuyển engineer có product taste cao” – đó là chiến lược nhân sự được Cat Wu chia sẻ.
Ba hàm ý thực tế cho người làm sản phẩm
Phải là người dùng nặng của sản phẩm mình làm. Team Claude Code dùng Claude nhiều hơn bất kỳ khách hàng nào. Không thể quyết định roadmap nếu mỗi ngày chỉ login cho có.
Ranh giới vai trò phải đàn hồi. PM học code, designer học dev, engineer học product thinking không còn là “nice to have” – đó là lợi thế cạnh tranh thật sự. Một số đội startup AI nhỏ ở Việt Nam đang làm theo mô hình này và ship nhanh hơn hẳn so với các đội giữ nguyên cấu trúc cũ.
Mission và metrics phải nằm trong đầu từng người. Khi bỏ PRD, thứ còn lại để dẫn đường là sứ mệnh và số liệu, không phải tiếng nói của một cá nhân nào. Điều này đòi hỏi mọi người hiểu rất rõ mình đang tối ưu cho cái gì.
Bạn cần ghi nhớ điều gì?
- Claude Code PM = PM + dev + power user, không phải “người trung gian cầm tài liệu”.
- Họ ưu tiên tuyển engineer có product taste, hơn là PM truyền thống.
- Cả đội buộc phải giãn nở vai trò: PM code, designer dev, engineer làm product.
- Mission và metrics thay thế PRD trong việc định hướng hành động.
Nên bắt đầu từ đâu? Lộ trình hành động trong 30 ngày
Khi nào bạn nên áp dụng lộ trình này?
Nếu bạn là PM, dev hay founder muốn dịch chuyển sang cách làm sản phẩm kiểu Claude Code, 30 ngày là đủ để thử phiên bản “mini” trong đội. Lộ trình dưới đây không đòi hỏi quyền lực tổ chức quá lớn – chỉ cần một nhóm sẵn sàng thử nghiệm.
Tuần 1 – Nhìn lại và “dọn backlog”
Rà soát backlog hiện tại, đánh dấu những mục chỉ phục vụ nhu cầu cục bộ hoặc không còn khớp với năng lực model hiện tại. Viết một bản Team Principles một trang: khách hàng cốt lõi là ai, ưu tiên tối thượng là gì.
Tuần 2 – Làm quen với ship nhanh
Chọn 1–2 ý tưởng nhỏ và cam kết ship trong 5–7 ngày, không viết PRD dài, chỉ note nhẹ trên Notion. Tập review metrics đơn giản mỗi tuần: usage, feedback định tính, lỗi thường gặp.
Tuần 3 – Thử “Research Preview nội bộ”
Đặt nhãn “thử nghiệm/preview” cho một tính năng, thông báo rõ cho người dùng nội bộ hoặc nhóm khách hàng nhỏ. Ghi nhận phản hồi, sẵn sàng xóa hoặc sửa mạnh không tiếc nuối.
Tuần 4 – Đẩy mạnh product taste và EQ
Dành mỗi ngày 30–60 phút dùng sản phẩm như user thật, ghi lại insight. Chủ động mapping stakeholder, kênh giao tiếp, cách thông báo mỗi khi bạn muốn thay đổi gì đó trong sản phẩm.
Hệ thống lại & bước tiếp theo: Bạn nên làm gì ngay hôm nay?
| Vấn đề / Câu hỏi | Việc bạn nên làm ngay |
|---|---|
| Quy trình quá chậm, PRD dày nhưng ship chậm | Thử bỏ PRD cho 1–2 tính năng nhỏ, thay bằng metric review + nguyên tắc đội một trang |
| Backlog quá nhiều idea, không biết chọn gì | Dành thời gian dùng sản phẩm mỗi ngày, đọc feedback, bắt đầu rèn Product Taste |
| Sợ ra mắt sớm vì “chưa hoàn hảo” | Áp dụng nhãn “preview/thử nghiệm” cho một tính năng, thông báo rõ cho người dùng |
| Lo AI sẽ lấy mất việc PM | Rèn kỹ năng EQ, mapping stakeholder, bối cảnh tổ chức – thứ model hiện chưa làm tốt |
| Khó thuyết phục team bỏ bớt process | Mang case 35 tính năng trong 90 ngày của Anthropic ra làm ví dụ để đối thoại |
Anthropic Claude Code cho thấy: khi AI kéo chi phí viết code xuống gần bằng 0, nút thắt dịch chuyển sang quyết định sản phẩm và cấu trúc tổ chức. Ship nhanh không còn là chuyện “làm thêm giờ” – mà là dám bỏ những lớp quy trình từng được xem là chuẩn mực.
Điểm khó nhất khi thử áp dụng mini-version cách làm này không phải là kỹ thuật, mà là tâm lý: dám đưa thứ chưa hoàn thiện ra cho người khác xem, dám bỏ công sức cũ khi model đã đủ tốt. Nếu coi AI là đồng đội thay vì kẻ cướp việc, PM và dev sẽ có nhiều cơ hội hơn để bước lên những lớp giá trị mới – nơi câu hỏi không còn là “làm được hay không”, mà là “nên làm cái gì, theo cách nào, vào lúc nào”.
Câu hỏi thường gặp
Q: Vì sao Anthropic có thể bỏ hẳn PRD mà vẫn không hỗn loạn?
A: Anthropic không bỏ trống chỗ của PRD – họ thay bằng hai trụ cột: metric review hàng tuần và tài liệu nguyên tắc đội. Nhờ đó, mọi người cùng chia sẻ một bức tranh số liệu và hiểu chung ai là khách hàng cốt lõi, nên mỗi người có thể tự quyết mà không phải chờ phê duyệt.
Q: Research Preview khác gì beta thông thường?
A: Research Preview nhấn mạnh tính thử nghiệm và có thể bị gỡ bỏ bất cứ lúc nào, không chỉ là “phiên bản beta trước khi stable”. Nó được dùng như một khung tâm lý cho cả đội và người dùng, cho phép ra mắt khi sản phẩm còn thô, miễn là thông tin về tính thử nghiệm được truyền đạt minh bạch.
Q: Product Taste có thể học được không hay là bẩm sinh?
A: Theo Cat Wu, Product Taste không đến từ chứng chỉ hay giáo trình, mà từ việc “ngâm” mình trong sản phẩm và người dùng. Đọc nhiều feedback, dùng sản phẩm hàng ngày và va trực tiếp vào giới hạn model là ba cách chính để dần mài sắc Product Taste theo thời gian.
Q: PM AI có nhất thiết phải biết code như Claude Code PM?
A: Ở Claude Code, phần lớn PM xuất thân engineer hoặc vẫn đang viết code, vì mô hình tổ chức của họ được tối ưu cho tốc độ ship. Không phải mọi PM AI trên thế giới đều buộc phải code, nhưng hiểu code và có thể tự làm prototype nhỏ là lợi thế lớn trong môi trường AI tốc độ cao.
Q: Lợi thế “EQ, hiểu bối cảnh tổ chức” của PM sẽ tồn tại bao lâu trước khi AI bắt kịp?
A: Cat Wu thừa nhận đây chỉ là lợi thế tạm thời: model hiện tại chưa hiểu tốt mạng lưới quan hệ, sở thích cá nhân, ngữ cảnh tổ chức. Nhưng về lâu dài, AI sẽ dần giỏi hơn ở mảng này. PM cần chuẩn bị tâm thế liên tục di chuyển sang những vùng giá trị mới, thay vì trông chờ vào một “vùng an toàn vĩnh viễn”.
Tham khảo thêm:
- Anthropic – Tài liệu về Claude và nền tảng: https://docs.anthropic.com
- Google – Hướng dẫn thiết kế sản phẩm AI có trách nhiệm: https://ai.google/responsibilities/responsible-ai-practices/
- OpenAI – Gợi ý về xây dựng ứng dụng dựa trên model: https://platform.openai.com/docs/guides
- GitHub – Tài liệu về cách quản lý issue và backlog hiệu quả: https://docs.github.com/en/issues
Bài viết này có hữu ích không?
Nhận thêm những bài viết công nghệ miễn phí.
Gửi phản hồi