Claude cho PM: Viết Product Spec (PRD)

PRD tốt là tài liệu engineering muốn đọc

Product 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 cả team aligned về: chúng ta đang build gì, tại sao, và done trông như thế nào. 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.

Bước 1: Xác định feature và thu thập context

Claude 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.

Prompt khởi đầu:

Tôi cần viết Product Spec cho:
[Mô tả feature — có thể là: tên tính năng / user problem / user request / ý tưởng mơ hồ]

Context tôi có:
- User problem: [Ai đang gặp vấn đề gì? Tần suất? Evidence?]
- Target users: [Segment nào?]
- Success sẽ trông như thế nào: [Metric nào sẽ thay đổi?]
- Constraints: [Technical / timeline / regulatory / dependencies]
- Prior art: [Đã thử gì chưa? Tài liệu nào đã có?]

Hã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.

Bước 2: Viết Problem Statement mạnh

Problem statement là nền tảng của mọi PRD. Nếu không clear về problem, mọi thứ sau đó đều shaky.

Prompt viết Problem Statement:

Từ context tôi đã share, hãy viết Problem Statement cho PRD này.

Tiêu chí Problem Statement tốt:
- 2-3 câu, không dài hơn
- Ai đang gặp vấn đề này và tần suất như thế nào?
- Cost của việc KHÔNG giải quyết vấn đề là gì? (user pain, business impact, competitive risk)
- Grounded in evidence — quote data/research nếu có, không phải assumption

Sau 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?

Ví dụ Problem Statement tốt:

"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."

Bước 3: Goals và Non-Goals

Non-goals quan trọng không kém goals — chúng ngăn scope creep trong lúc development.

Prompt viết Goals:

Hãy viết Goals cho PRD này.

Tiêu chí Goals tốt:
- 3-5 goals specific, measurable
- Mix giữa user goals (user được gì) và business goals (business được gì)
- Outcomes, không phải outputs ("giảm time-to-first-value xuống <5 phút" không phải "build onboarding wizard")
- Mỗi goal có thể trả lời: "Làm sao biết feature này succeed?"

Sau khi viết Goals: Hãy viết Non-Goals.

Non-Goals cần:
- 3-5 items explicitly out of scope
- Brief rationale cho từng (tại sao out of scope: không đủ impact, quá phức tạp, separate initiative, premature)
- Specific enough để engineer biết "không cần build cái này trong v1"

Bước 4: User Stories

Prompt viết User Stories:

Viết User Stories cho feature này.

Format: "As a [user type cụ thể], I want [capability] so that [benefit/value]"

Yêu cầu:
- User type phải cụ thể đủ để có nghĩa ("enterprise admin" không phải chỉ "user")
- Capability describe WHAT they want to accomplish, không phải HOW (không prescribe UI)
- Benefit giải thích WHY — value thực sự là gì

Cần bao gồm:
1. Happy path stories: flow thông thường
2. Edge case stories: error states, empty states, boundary conditions
3. Different user types nếu feature serve nhiều personas

Sau khi viết: Flag stories nào quá lớn (cần break down thêm) và stories nào có thể combine.

Ví dụ User Stories tốt:

• Tốt: "As a team admin, I want to configure spending limits per department so that I can enforce budget policies without manually reviewing every expense"
• Không tốt: "As a user, I want a dropdown menu" — đây là UI decision, không phải user need
• Không tốt: "As a user, I want the product to be faster" — quá vague

Bước 5: Requirements phân loại theo priority

Prompt viết Requirements:

Từ User Stories vừa viết, hãy breakdown thành Requirements với MoSCoW framework:

P0 — MUST HAVE (không ship được nếu thiếu):
- Feature không viable không có những requirements này
- Hỏi: "Nếu cắt cái này, feature có còn giải quyết được core problem không?"

P1 — NICE TO HAVE (significantly improves experience, nhưng core works mà không có):
- Thường trở thành fast follow sau khi v1 live

P2 — FUTURE CONSIDERATIONS (out of scope v1, nhưng architecture cần support):
- Document để tránh technical decisions khiến những thứ này khó làm sau

Với mỗi requirement:
1. Clear, unambiguous description về expected behavior
2. Acceptance criteria theo format: "Given [precondition], When [action], Then [expected outcome]"
3. Technical considerations nếu có
4. Dependencies với team hoặc system khác

Quan 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.

Bước 6: Success Metrics

Prompt viết Success Metrics:

Viết Success Metrics cho feature này.

LEADING INDICATORS (thay đổi trong days-to-weeks sau launch):
- Adoption rate: % eligible users try the feature
- Activation rate: % users complete core action
- Task completion rate: % users achieve their goal
- Time to complete: bao lâu để complete core workflow
- Error rate: tần suất gặp lỗi

LAGGING INDICATORS (thay đổi trong weeks-to-months):
- Retention impact
- Revenue impact
- NPS/satisfaction change
- Support ticket reduction

Với mỗi metric:
- TARGET cụ thể: "50% adoption trong 30 ngày" không phải "high adoption"
- MEASUREMENT METHOD: Tool nào, query nào, time window nào?
- EVALUATION TIMING: Sẽ review sau 1 tuần, 1 tháng, 1 quý?
- SUCCESS THRESHOLD vs STRETCH TARGET

Hỏi lại nếu targets cảm giác arbitrary — cần grounding trong baseline data hoặc benchmark.

Bước 7: PRD hoàn chỉnh

Prompt tạo PRD document:

Tổng hợp tất cả các phần vừa làm thành PRD document hoàn chỉnh:

# [Tên Feature] — Product Spec

**Status:** Draft | Review | Approved
**Author:** [PM name]
**Last updated:** [Date]
**Reviewers:** [Engineering lead, Design lead, relevant stakeholders]

## Problem Statement
[2-3 câu, grounded in evidence]

## Goals
[3-5 measurable outcomes]

## Non-Goals
[3-5 explicitly out-of-scope items với rationale]

## User Stories
[Ordered by priority, grouped by user type]

## Requirements
### P0 — Must Have
[Requirements + acceptance criteria]

### P1 — Nice to Have
[Requirements]

### P2 — Future Considerations
[Architectural notes]

## Success Metrics
[Leading và lagging indicators với targets]

## Open Questions
[Questions cần answer trước/trong implementation — tag người cần trả lời]

## Timeline Considerations
[Hard deadlines, dependencies, phasing nếu có]

Format: Scannable với headers rõ. Người đọc phải hiểu được gist chỉ bằng cách đọc headers và bold text.

Acceptance Criteria viết đúng cách

Acceptance criteria là điều engineer và QA dùng để verify feature done. Mơ hồ ở đây = bug sau này.

Format tốt (Given/When/Then):

Viết acceptance criteria cho requirement: [mô tả requirement]

Format cho mỗi scenario:
- Given: [precondition hoặc context]
- When: [action user thực hiện]
- Then: [expected outcome — cụ thể, testable]

Cần cover:
1. Happy path (main flow)
2. Error cases (what happens khi có lỗi)
3. Edge cases (boundary conditions, empty states)
4. Negative cases (điều KHÔNG nên xảy ra)

Tránh từ mơ hồ: "fast", "user-friendly", "intuitive" — define concretely hoặc đừng dùng.

Lỗi PRD phổ biến cần tránh

• Everything is P0: Nếu tất cả đều critical, không có gì critical. Hãy thực sự đau khi cắt P0.
• Success metrics vague: "Improve user experience" không phải metric. Define concretely.
• Không có Non-Goals: Đây là invitation cho scope creep. "While we're at it..." syndrome.
• User stories quá lớn: "As a user, I want to manage my team" — quá broad để implement trong 1 sprint.
• Open questions thực ra đã có answer: 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.

Bước tiếp theo

Sau 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 Claude cho PM: Báo cáo stakeholder để biết cách present PRD mới cho engineering team và leadership một cách hiệu quả.

Bài viết liên quan

• Claude cho PM: Brainstorming ý tưởng sản phẩm
• Claude cho PM: Cập nhật Product Roadmap
• Claude cho PM: Competitive Brief sản phẩm
• Claude cho Engineering: System Design interviews và planning
• Claude cho Design: User Research từ A đến Z