Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Business Writing (Docs, RFCs, PRDs)

Communication

Business writing cho product work: meeting notes, PRDs, RFCs, strategy memos, board updates, BLUF, decision logs và templates giúp teams ra quyết định rõ hơn.

Bạn đang ở đâu với kỹ năng này?

Làm bài Đánh giá Kỹ năng Giao tiếp cho PM/BA — 5 người đã làm. Một lần làm chấm điểm cho tất cả kỹ năng trong nhóm Communication, không chỉ kỹ năng này.

Làm bài đánh giá Trung bình cộng đồng ở kỹ năng này: 67/100

Roadmap — Cách học và đạt kỹ năng

Đã đọc 0/12 mục · còn khoảng 4 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Skill này nằm ở đâu trong roadmap?

Business Writing, RFCs & PRDs xuất hiện từ BA Intern đến CPO vì writing là operating system cho product thinking. Ở entry level, writing là meeting notes rõ owner/next step. Ở Associate PM, writing là PRD. Ở Senior PM, writing là strategy memo. Ở Lead/Director, writing là executive communication. Ở CPO, writing là board narrative.

Good writing không phải viết dài. Good writing làm cho quyết định dễ hơn, giảm ambiguity và tạo shared memory cho team.

Document decision flow

Meeting NotesFacts + owners PRDProblem + scope RFCProposal + feedback Strategy MemoChoices + bets Decision LogWhat, why, owner, date, revisit trigger

Keyword definitions

DocumentPurposeWhen to useWhat good looks like
Meeting notesCapture facts, decisions, owners and next steps.After stakeholder/user/team meetings.No ambiguity about who does what by when.
PRDAlign problem, users, scope, UX, requirements, metrics and release plan.Feature/product change with engineering work.Engineering can build, QA can test, stakeholders know trade-offs.
RFCRequest feedback on proposal before commitment.High ambiguity, technical/product architecture, cross-team impact.Options, recommendation, open questions, decision deadline.
Strategy memoExplain diagnosis, choices, bets, metrics and non-goals.Quarterly/annual planning, major portfolio choice.Leaders understand what gets cut and why.
Board updateExecutive narrative for company-level product progress and risks.CPO/VP level communication.Concise, metric-backed, focused on decisions and risks.

PRD template you can follow

SectionQuestions to answerCommon mistake
ProblemWho has the problem? How painful/frequent? What evidence?Starting with solution.
Goals / non-goalsWhat outcome will change? What are we not solving?Scope keeps expanding.
User storiesWhat jobs must users complete?Writing internal tasks as user value.
RequirementsFunctional, data, permissions, edge cases, performance.Ignoring error/empty states.
MetricsSuccess metric, guardrail, events/properties.No analytics until after launch.
RolloutExperiment, beta, migration, enablement, support readiness.Assuming launch equals adoption.

Real-world scenario: PRD for AI resume scoring

Weak PRD: "Build AI CV scoring so recruiters can rank candidates."

Better PRD:

  1. Problem: Recruiters spend 6-8 minutes per CV and miss candidates with transferable skills.
  2. Target user: Recruiters hiring PM/BA roles with 50+ applicants per job.
  3. Success metric: reduce first-pass screening time by 40% without reducing interview quality.
  4. Requirements: parse PDF/DOCX, score skill match, explain score, flag missing evidence, allow recruiter override.
  5. Guardrails: no protected attributes in scoring, confidence score shown, audit log for score changes.
  6. Rollout: beta with 3 recruiters, compare AI shortlist with human shortlist, review false positives/negatives weekly.

RFC template

Use RFC when: decision has high cross-team impact, technical/product ambiguity, or disagreement. RFC should create feedback before the team commits.

SectionContent
SummaryBLUF recommendation in 3-5 sentences.
ContextProblem, constraints, users, business impact.
OptionsAt least 2-3 options with pros/cons.
RecommendationChosen option and why.
RisksTechnical, product, UX, legal, operational risks.
Open questionsWho needs to answer by when.
Decision dateWhen feedback closes and owner decides.

Writing examples: beginner vs senior

Beginner status update: "We worked on upload, parser, and UI. There are some bugs."

Senior status update: "Bottom line: launch is yellow. Parser accuracy is 82% vs 90% target; if not improved by Friday, we should launch beta to admins only. Decision needed: accept beta scope or delay 1 week. Owner: PM to recommend by Thursday EOD."

Executive memo rule: conclusion first, then evidence. If the reader only reads the first 6 lines, they should know the recommendation, why it matters, and what decision is needed.

Tools to use

  • Notion / Confluence / Google Docs: PRDs, RFCs, strategy memos, decision logs.
  • Linear / Jira: connect requirements to engineering tickets and release status.
  • Figma: link UX flows, states, prototypes and design decisions.
  • Amplitude / PostHog: define events, metrics and validation plan in the PRD.
  • Grammarly / Claude / ChatGPT: tighten structure, rewrite for BLUF, test if memo is clear.

Roadmap keyword coverage - các wording trên roadmap nghĩa là gì?

Roadmap dùng skill này ở nhiều level: meeting notes cho BA, PRD cho Associate PM, strategy memo cho Senior PM, executive/board communication cho leadership.

Roadmap wordingÝ nghĩa khi học skill nàyArtifact / evidenceBài tập thực hành
Ghi meeting notes rõ owner và next stepCapture facts, decisions, owners, deadline và open questions.Meeting notes / decision notesSau meeting, gửi recap dưới 10 dòng với owner/date.
Viết PRDMô tả problem, user, scope, requirements, metrics, rollout và risks.PRDViết PRD mini cho một feature có success metric.
Viết Strategy memoExplain diagnosis, choices, bets, non-goals và metrics.Strategy memoViết memo 1 trang: context, diagnosis, recommendation, risks.
Executive communicationBLUF, concise narrative, decision needed, risk và business impact.Exec updateRewrite roadmap status cho VP trong 6 bullets.
Board communicationCompany-level product narrative: progress, bets, risks, asks.Board product updateDraft 1 slide narrative: what changed, why it matters, ask.
Executive narrativeStoryline giúp leaders understand trade-off and decide.Narrative memoTurn a messy project update into conclusion -> reasons -> evidence.

Sai lầm thường gặp và cách xử lý

Sai lầmVì sao xảy raXử lý
Tài liệu dài nhưng không ai đọcViết theo thứ tự mình nghĩ ra, không theo thứ tự người đọc cầnKết luận và đề xuất lên đầu; lập luận và chi tiết xuống dưới
Không rõ người đọc cần làm gì sau khi đọcViết để ghi chép, không để tạo hành độngCâu đầu tiên nói rõ: tôi cần bạn quyết gì, hoặc biết gì
Trộn lẫn sự thật, giả định và ý kiếnViết liền mạch cho trôi chảyTách rõ ba loại; người đọc cần biết phần nào có bằng chứng
Viết bằng ngôn ngữ hệ thốngQuen dùng thuật ngữ nội bộDùng từ người đọc dùng; nếu họ gọi là "phiếu" thì đừng viết "ticket entity"
Xin ý kiến khi tài liệu đã hoàn chỉnhMuốn trình bày bản đẹp nhấtXin ý kiến khi còn nháp; bản hoàn chỉnh chỉ nhận được lời góp ý về câu chữ
Không nêu phần ngoài phạm viNghĩ là hiển nhiênMục "không thuộc phạm vi lần này" tiết kiệm nhiều tranh luận hơn bất kỳ mục nào khác

Vì sao vai trò của bạn cần cái này

Vai tròBạn dùng nó để
Product Owner / PMTài liệu là cách bạn mở rộng ảnh hưởng tới những phòng họp bạn không có mặt
Business AnalystViết rõ là phần lớn giá trị bạn tạo ra; tài liệu mơ hồ sinh ra sản phẩm mơ hồ
EngineerRFC là cách bạn xin phản biện trước khi bỏ ba tuần đi sai hướng
Team LeadQuyết định viết ra là quyết định người vắng mặt vẫn theo được
Đội làm từ xaViết tốt là điều kiện để làm việc không đồng thời

Definition of done

  • Câu đầu tiên nói rõ người đọc cần quyết gì hoặc biết gì.
  • Kết luận và đề xuất nằm ở đầu, không nằm ở cuối.
  • Sự thật, giả định và ý kiến được tách rõ.
  • Có mục nêu phần không thuộc phạm vi lần này.
  • Đã xin ý kiến khi còn là bản nháp, không phải khi đã hoàn chỉnh.
  • Dùng từ ngữ của người đọc, không dùng thuật ngữ nội bộ.

Tự kiểm 3 câu

Đọc xong rồi thì thử xem — đúng cả ba là đạt.
1. Phần nào nên đứng đầu một PRD?
2. Một PRD tốt có nên ghi “ngoài phạm vi” (non-goals) không?
3. Nguyên tắc BLUF trong viết tài liệu là gì?

Khóa học liên quan (9)

Sử dụng trong vai trò

Thảo luận & tài liệu thêm 0

Chia sẻ kinh nghiệm, đặt câu hỏi, hoặc đính kèm tài liệu/YouTube giúp người khác học kỹ năng này.

Hãy là người đầu tiên chia sẻ kinh nghiệm cho kỹ năng này.

Kiểm tra kỹ năng này

Bài kiểm tra của các khóa dạy kỹ năng này
1 Chẩn đoán

Đánh giá Kỹ năng Giao tiếp cho PM/BA

Chấm riêng từng chiều của kỹ năng này.

5 người đã làm
Làm bài này
2 Quiz

Kiểm tra Module 1: Chọn đúng loại tài liệu

Bài kiểm tra của một khóa dạy kỹ năng này.

3 người đã làm
Làm bài này
3 Quiz

Kiểm tra Module 3: Viết Problem và Goals sắc bén

Bài kiểm tra của một khóa dạy kỹ năng này.

2 người đã làm
Làm bài này
4 Quiz

Kiểm tra Module 6: Spec cho mobile và AI

Bài kiểm tra của một khóa dạy kỹ năng này.

2 người đã làm
Làm bài này

Học kỹ năng này ở đâu?

Có 9 khóa dạy đúng phần này, miễn phí và bằng tiếng Việt.

Bắt đầu học