{"product_id":"claude-cho-pm-viết-product-spec-prd","title":"Claude cho PM: Viết Product Spec (PRD)","description":"\n\u003ch2\u003ePRD tốt là tài liệu engineering muốn đọc\u003c\/h2\u003e\n\u003cp\u003eProduct Requirements Document (PRD) hay Product Spec không phải để PM thể hiện mình biết nhiều — mà là công cụ giúp \u003cstrong\u003ecả team aligned về: chúng ta đang build gì, tại sao, và done trông như thế nào\u003c\/strong\u003e. Claude giúp bạn viết PRD đủ chặt chẽ để tránh scope creep nhưng không quá rigid để chặn sáng tạo của engineer.\u003c\/p\u003e\n\n\u003ch2\u003eBước 1: Xác định feature và thu thập context\u003c\/h2\u003e\n\u003cp\u003eClaude có thể bắt đầu từ bất cứ điểm nào — ý tưởng mơ hồ, user complaint, hoặc yêu cầu từ sales.\u003c\/p\u003e\n\n\u003ch3\u003ePrompt khởi đầu:\u003c\/h3\u003e\n\u003cpre\u003e\u003ccode\u003eTôi cần viết Product Spec cho:\n[Mô tả feature — có thể là: tên tính năng \/ user problem \/ user request \/ ý tưởng mơ hồ]\n\nContext tôi có:\n- User problem: [Ai đang gặp vấn đề gì? Tần suất? Evidence?]\n- Target users: [Segment nào?]\n- Success sẽ trông như thế nào: [Metric nào sẽ thay đổi?]\n- Constraints: [Technical \/ timeline \/ regulatory \/ dependencies]\n- Prior art: [Đã thử gì chưa? Tài liệu nào đã có?]\n\nHãy confirm bạn đã hiểu scope, đặt câu hỏi làm rõ nếu cần, rồi guide tôi qua việc viết PRD hoàn chỉnh.\u003c\/code\u003e\u003c\/pre\u003e\n\n\u003ch2\u003eBước 2: Viết Problem Statement mạnh\u003c\/h2\u003e\n\u003cp\u003eProblem statement là nền tảng của mọi PRD. Nếu không clear về problem, mọi thứ sau đó đều shaky.\u003c\/p\u003e\n\n\u003ch3\u003ePrompt viết Problem Statement:\u003c\/h3\u003e\n\u003cpre\u003e\u003ccode\u003eTừ context tôi đã share, hãy viết Problem Statement cho PRD này.\n\nTiêu chí Problem Statement tốt:\n- 2-3 câu, không dài hơn\n- Ai đang gặp vấn đề này và tần suất như thế nào?\n- Cost của việc KHÔNG giải quyết vấn đề là gì? (user pain, business impact, competitive risk)\n- Grounded in evidence — quote data\/research nếu có, không phải assumption\n\nSau khi viết: Xác nhận với tôi — Problem Statement này có capture đúng core problem không? Có điểm gì bị miss không?\u003c\/code\u003e\u003c\/pre\u003e\n\n\u003ch3\u003eVí dụ Problem Statement tốt:\u003c\/h3\u003e\n\u003cp\u003e\u003cem\u003e\"45% người dùng mới bỏ qua trong 3 ngày đầu (data từ analytics tháng 3). Phỏng vấn với 12 churned users cho thấy nguyên nhân chính là bước setup ban đầu quá phức tạp — trung bình mất 23 phút và 40% gặp ít nhất 1 lỗi. Nếu không cải thiện, chúng ta sẽ tiếp tục mất ~$X MRR potential mỗi tháng từ new signups.\"\u003c\/em\u003e\u003c\/p\u003e\n\n\u003ch2\u003eBước 3: Goals và Non-Goals\u003c\/h2\u003e\n\u003cp\u003eNon-goals quan trọng không kém goals — chúng ngăn scope creep trong lúc development.\u003c\/p\u003e\n\n\u003ch3\u003ePrompt viết Goals:\u003c\/h3\u003e\n\u003cpre\u003e\u003ccode\u003eHãy viết Goals cho PRD này.\n\nTiêu chí Goals tốt:\n- 3-5 goals specific, measurable\n- Mix giữa user goals (user được gì) và business goals (business được gì)\n- Outcomes, không phải outputs (\"giảm time-to-first-value xuống \u0026lt;5 phút\" không phải \"build onboarding wizard\")\n- Mỗi goal có thể trả lời: \"Làm sao biết feature này succeed?\"\n\nSau khi viết Goals: Hãy viết Non-Goals.\n\nNon-Goals cần:\n- 3-5 items explicitly out of scope\n- Brief rationale cho từng (tại sao out of scope: không đủ impact, quá phức tạp, separate initiative, premature)\n- Specific enough để engineer biết \"không cần build cái này trong v1\"\u003c\/code\u003e\u003c\/pre\u003e\n\n\u003ch2\u003eBước 4: User Stories\u003c\/h2\u003e\n\n\u003ch3\u003ePrompt viết User Stories:\u003c\/h3\u003e\n\u003cpre\u003e\u003ccode\u003eViết User Stories cho feature này.\n\nFormat: \"As a [user type cụ thể], I want [capability] so that [benefit\/value]\"\n\nYêu cầu:\n- User type phải cụ thể đủ để có nghĩa (\"enterprise admin\" không phải chỉ \"user\")\n- Capability describe WHAT they want to accomplish, không phải HOW (không prescribe UI)\n- Benefit giải thích WHY — value thực sự là gì\n\nCần bao gồm:\n1. Happy path stories: flow thông thường\n2. Edge case stories: error states, empty states, boundary conditions\n3. Different user types nếu feature serve nhiều personas\n\nSau khi viết: Flag stories nào quá lớn (cần break down thêm) và stories nào có thể combine.\u003c\/code\u003e\u003c\/pre\u003e\n\n\u003ch3\u003eVí dụ User Stories tốt:\u003c\/h3\u003e\n\u003cul\u003e\n  \u003cli\u003e\n\u003cem\u003eTốt:\u003c\/em\u003e \"As a team admin, I want to configure spending limits per department so that I can enforce budget policies without manually reviewing every expense\"\u003c\/li\u003e\n  \u003cli\u003e\n\u003cem\u003eKhông tốt:\u003c\/em\u003e \"As a user, I want a dropdown menu\" — đây là UI decision, không phải user need\u003c\/li\u003e\n  \u003cli\u003e\n\u003cem\u003eKhông tốt:\u003c\/em\u003e \"As a user, I want the product to be faster\" — quá vague\u003c\/li\u003e\n\u003c\/ul\u003e\n\n\u003ch2\u003eBước 5: Requirements phân loại theo priority\u003c\/h2\u003e\n\n\u003ch3\u003ePrompt viết Requirements:\u003c\/h3\u003e\n\u003cpre\u003e\u003ccode\u003eTừ User Stories vừa viết, hãy breakdown thành Requirements với MoSCoW framework:\n\nP0 — MUST HAVE (không ship được nếu thiếu):\n- Feature không viable không có những requirements này\n- Hỏi: \"Nếu cắt cái này, feature có còn giải quyết được core problem không?\"\n\nP1 — NICE TO HAVE (significantly improves experience, nhưng core works mà không có):\n- Thường trở thành fast follow sau khi v1 live\n\nP2 — FUTURE CONSIDERATIONS (out of scope v1, nhưng architecture cần support):\n- Document để tránh technical decisions khiến những thứ này khó làm sau\n\nVới mỗi requirement:\n1. Clear, unambiguous description về expected behavior\n2. Acceptance criteria theo format: \"Given [precondition], When [action], Then [expected outcome]\"\n3. Technical considerations nếu có\n4. Dependencies với team hoặc system khác\n\nQuan trọng: Challenge P0s. Nếu mọi thứ đều là P0, không có gì là P0. Tối đa 3-5 P0s cho v1.\u003c\/code\u003e\u003c\/pre\u003e\n\n\u003ch2\u003eBước 6: Success Metrics\u003c\/h2\u003e\n\n\u003ch3\u003ePrompt viết Success Metrics:\u003c\/h3\u003e\n\u003cpre\u003e\u003ccode\u003eViết Success Metrics cho feature này.\n\nLEADING INDICATORS (thay đổi trong days-to-weeks sau launch):\n- Adoption rate: % eligible users try the feature\n- Activation rate: % users complete core action\n- Task completion rate: % users achieve their goal\n- Time to complete: bao lâu để complete core workflow\n- Error rate: tần suất gặp lỗi\n\nLAGGING INDICATORS (thay đổi trong weeks-to-months):\n- Retention impact\n- Revenue impact\n- NPS\/satisfaction change\n- Support ticket reduction\n\nVới mỗi metric:\n- TARGET cụ thể: \"50% adoption trong 30 ngày\" không phải \"high adoption\"\n- MEASUREMENT METHOD: Tool nào, query nào, time window nào?\n- EVALUATION TIMING: Sẽ review sau 1 tuần, 1 tháng, 1 quý?\n- SUCCESS THRESHOLD vs STRETCH TARGET\n\nHỏi lại nếu targets cảm giác arbitrary — cần grounding trong baseline data hoặc benchmark.\u003c\/code\u003e\u003c\/pre\u003e\n\n\u003ch2\u003eBước 7: PRD hoàn chỉnh\u003c\/h2\u003e\n\n\u003ch3\u003ePrompt tạo PRD document:\u003c\/h3\u003e\n\u003cpre\u003e\u003ccode\u003eTổng hợp tất cả các phần vừa làm thành PRD document hoàn chỉnh:\n\n# [Tên Feature] — Product Spec\n\n**Status:** Draft | Review | Approved\n**Author:** [PM name]\n**Last updated:** [Date]\n**Reviewers:** [Engineering lead, Design lead, relevant stakeholders]\n\n## Problem Statement\n[2-3 câu, grounded in evidence]\n\n## Goals\n[3-5 measurable outcomes]\n\n## Non-Goals\n[3-5 explicitly out-of-scope items với rationale]\n\n## User Stories\n[Ordered by priority, grouped by user type]\n\n## Requirements\n### P0 — Must Have\n[Requirements + acceptance criteria]\n\n### P1 — Nice to Have\n[Requirements]\n\n### P2 — Future Considerations\n[Architectural notes]\n\n## Success Metrics\n[Leading và lagging indicators với targets]\n\n## Open Questions\n[Questions cần answer trước\/trong implementation — tag người cần trả lời]\n\n## Timeline Considerations\n[Hard deadlines, dependencies, phasing nếu có]\n\nFormat: Scannable với headers rõ. Người đọc phải hiểu được gist chỉ bằng cách đọc headers và bold text.\u003c\/code\u003e\u003c\/pre\u003e\n\n\u003ch2\u003eAcceptance Criteria viết đúng cách\u003c\/h2\u003e\n\u003cp\u003eAcceptance criteria là điều engineer và QA dùng để verify feature done. Mơ hồ ở đây = bug sau này.\u003c\/p\u003e\n\n\u003ch3\u003eFormat tốt (Given\/When\/Then):\u003c\/h3\u003e\n\u003cpre\u003e\u003ccode\u003eViết acceptance criteria cho requirement: [mô tả requirement]\n\nFormat cho mỗi scenario:\n- Given: [precondition hoặc context]\n- When: [action user thực hiện]\n- Then: [expected outcome — cụ thể, testable]\n\nCần cover:\n1. Happy path (main flow)\n2. Error cases (what happens khi có lỗi)\n3. Edge cases (boundary conditions, empty states)\n4. Negative cases (điều KHÔNG nên xảy ra)\n\nTránh từ mơ hồ: \"fast\", \"user-friendly\", \"intuitive\" — define concretely hoặc đừng dùng.\u003c\/code\u003e\u003c\/pre\u003e\n\n\u003ch2\u003eLỗi PRD phổ biến cần tránh\u003c\/h2\u003e\n\u003cul\u003e\n  \u003cli\u003e\n\u003cstrong\u003eEverything is P0\u003c\/strong\u003e: Nếu tất cả đều critical, không có gì critical. Hãy thực sự đau khi cắt P0.\u003c\/li\u003e\n  \u003cli\u003e\n\u003cstrong\u003eSuccess metrics vague\u003c\/strong\u003e: \"Improve user experience\" không phải metric. Define concretely.\u003c\/li\u003e\n  \u003cli\u003e\n\u003cstrong\u003eKhông có Non-Goals\u003c\/strong\u003e: Đây là invitation cho scope creep. \"While we're at it...\" syndrome.\u003c\/li\u003e\n  \u003cli\u003e\n\u003cstrong\u003eUser stories quá lớn\u003c\/strong\u003e: \"As a user, I want to manage my team\" — quá broad để implement trong 1 sprint.\u003c\/li\u003e\n  \u003cli\u003e\n\u003cstrong\u003eOpen questions thực ra đã có answer\u003c\/strong\u003e: Chỉ list những gì thực sự open, không phải câu hỏi bạn biết câu trả lời.\u003c\/li\u003e\n\u003c\/ul\u003e\n\n\u003ch2\u003eBước tiếp theo\u003c\/h2\u003e\n\u003cp\u003eSau khi có PRD, bước tiếp theo thường là cập nhật roadmap và communicate với team về feature mới này. Xem \u003ca href=\"\/collections\/ung-dung\"\u003eClaude cho PM: Báo cáo stakeholder\u003c\/a\u003e để biết cách present PRD mới cho engineering team và leadership một cách hiệu quả.\u003c\/p\u003e\n\n\n\u003chr\u003e\n\u003ch3\u003eBài viết liên quan\u003c\/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"\/products\/claude-cho-pm-brainstorming-y-t%C6%B0%E1%BB%9Fng-s%E1%BA%A3n-ph%E1%BA%A9m\"\u003eClaude cho PM: Brainstorming ý tưởng sản phẩm\u003c\/a\u003e\u003c\/li\u003e\n\u003cli\u003e\u003ca href=\"\/products\/claude-cho-pm-c%E1%BA%ADp-nh%E1%BA%ADt-product-roadmap\"\u003eClaude cho PM: Cập nhật Product Roadmap\u003c\/a\u003e\u003c\/li\u003e\n\u003cli\u003e\u003ca href=\"\/products\/claude-cho-pm-competitive-brief-s%E1%BA%A3n-ph%E1%BA%A9m\"\u003eClaude cho PM: Competitive Brief sản phẩm\u003c\/a\u003e\u003c\/li\u003e\n\u003cli\u003e\u003ca href=\"\/products\/claude-cho-engineering-system-design-interviews-va-planning\"\u003eClaude cho Engineering: System Design interviews và planning\u003c\/a\u003e\u003c\/li\u003e\n\u003cli\u003e\u003ca href=\"\/products\/claude-cho-design-user-research-t%E1%BB%AB-a-d%E1%BA%BFn-z\"\u003eClaude cho Design: User Research từ A đến Z\u003c\/a\u003e\u003c\/li\u003e\n\u003c\/ul\u003e","brand":"Minh Tuấn","offers":[{"title":"Default Title","offer_id":47722094690516,"sku":null,"price":0.0,"currency_code":"VND","in_stock":true}],"thumbnail_url":"\/\/cdn.shopify.com\/s\/files\/1\/0821\/0264\/9044\/files\/claude-cho-pm-vi_t-product-spec-prd_24f8580e-6fa4-4161-a701-767525b275bf.jpg?v=1774522177","url":"https:\/\/claude.vn\/products\/claude-cho-pm-vi%e1%ba%bft-product-spec-prd","provider":"CLAUDE.VN","version":"1.0","type":"link"}