Product Manager: Viết PRD từ vấn đề người dùng, mục tiêu và ràng buộc thực tế
PRD không chỉ là danh sách tính năng. Hãy dùng tài liệu này để làm rõ vấn đề người dùng, mục tiêu, giả định, phạm vi và các câu hỏi cần cả đội cùng giải quyết.
Một yêu cầu như “cải thiện luồng này” có thể dẫn cả đội đi theo nhiều hướng khác nhau.
Designer cần hiểu vấn đề cần giải. Developer cần biết điều gì là bắt buộc và điều gì còn mở. Stakeholder cần thấy công việc này phục vụ mục tiêu nào. Nếu PRD chỉ là danh sách tính năng, mỗi người sẽ tự điền phần bối cảnh còn thiếu bằng giả định riêng.
Vì vậy, việc của Product Manager không phải là viết tài liệu thật dài. Việc quan trọng hơn là tạo ra sự hiểu biết chung đủ rõ để cả đội cùng ra quyết định.
PRD là gì?
Theo Atlassian, Product Requirements Document (PRD) xác định sản phẩm cần được xây dựng: mục đích, tính năng, chức năng và hành vi của sản phẩm.
PRD giúp tạo một nguồn tham chiếu chung cho các nhóm liên chức năng, từ product, design, development đến stakeholder. Tài liệu này làm rõ nhu cầu người dùng, kỳ vọng và tiêu chí thành công để đội ngũ giữ được sự thống nhất trong quá trình phát triển.
Trong môi trường Agile, PRD không nhất thiết phải mô tả mọi chi tiết trước khi bắt đầu triển khai. Trọng tâm là sự hiểu biết chung về khách hàng và vấn đề, để đội có thể cùng hoàn thiện giải pháp khi có thêm thông tin.
Đừng bắt đầu bằng tính năng
Một PRD yếu thường mở đầu bằng giải pháp:
> Xây tính năng X để tăng Y.
Cách viết này có thể khiến đội bỏ qua câu hỏi quan trọng hơn: vấn đề thực sự của người dùng là gì, và vì sao vấn đề đó đáng được ưu tiên?
Trước khi viết yêu cầu, hãy làm rõ chuỗi lập luận:
Vấn đề người dùng: Người dùng nào đang gặp khó khăn gì?
Bối cảnh: Họ gặp khó khăn ở thời điểm hoặc tình huống nào?
Mục tiêu: Việc giải quyết vấn đề này đóng góp thế nào cho mục tiêu sản phẩm hoặc kinh doanh?
Giả định: Đội đang tin điều gì là đúng nhưng chưa được xác nhận?
Ràng buộc: Phạm vi, thời gian, nguồn lực hoặc phụ thuộc nào cần được tính đến?
Yêu cầu: Sản phẩm cần có hành vi gì để hỗ trợ người dùng?
Ví dụ, thay vì chỉ viết:
> Thêm chức năng lưu giỏ hàng.
Hãy bắt đầu từ vấn đề:
> Người mua quay lại hành trình mua sắm có thể không nhớ những sản phẩm đã cân nhắc trước đó. Sản phẩm cần hỗ trợ họ tiếp tục quá trình này trong phạm vi đã thống nhất.
Cách viết này chưa áp đặt giải pháp giao diện hay cách triển khai. Nó tạo điều kiện để design, development và các bên liên quan cùng bàn về phương án phù hợp.
PRD Agile: định hướng rõ, không đặc tả cứng
Atlassian nhấn mạnh rằng yêu cầu trong Agile dựa trên sự hiểu biết chung về khách hàng giữa product owner, designer và đội phát triển.
Khi cả đội cùng hiểu người dùng, Product Manager có thể tập trung vào yêu cầu ở cấp độ sản phẩm thay vì cố gắng định nghĩa trước toàn bộ chi tiết triển khai. Đội kỹ thuật và thiết kế sẽ có không gian để đóng góp chuyên môn vào cách giải quyết vấn đề.
Hãy phân biệt hai nhóm nội dung trong PRD:
Những điều cần làm rõ
Vấn đề cần giải quyết.
Người dùng hoặc nhóm khách hàng liên quan.
Mục tiêu của công việc.
Phạm vi thực hiện.
Những điều không thuộc phạm vi.
Các giả định và rủi ro cần theo dõi.
Những điều cần cùng khám phá
Phương án trải nghiệm phù hợp.
Chi tiết triển khai kỹ thuật.
Các tình huống cần cân nhắc thêm.
Những câu hỏi chưa có đủ thông tin để kết luận.
PRD không thay thế trao đổi trực tiếp. Nó giúp các cuộc trao đổi bắt đầu từ cùng một bối cảnh.
Khung PRD “vừa đủ” cho đội sản phẩm
Atlassian khuyến nghị dùng một cấu trúc nhất quán để mọi người dễ đọc, phản hồi và cập nhật. Mục tiêu không phải là tạo ra tài liệu nặng nề, mà là cung cấp đủ ngữ cảnh để hiểu yêu cầu và tác động của công việc.
1. Thông tin dự án
Mở đầu PRD bằng các thông tin giúp người đọc nắm nhanh tình hình:
Participants: Product owner, thành viên đội ngũ và stakeholder liên quan.
Status: Trạng thái hiện tại, chẳng hạn đúng tiến độ, có rủi ro, chậm hoặc hoãn.
Target release: Mốc phát hành dự kiến.
Phần này giúp đội biết ai liên quan, công việc đang ở giai đoạn nào và đâu là mốc cần theo dõi.
2. Mục tiêu đội ngũ và mục tiêu kinh doanh
Nêu mục tiêu ngắn gọn, rõ ràng và đủ cụ thể để hạn chế diễn giải khác nhau.
Bạn có thể trả lời các câu hỏi:
Công việc này hướng đến thay đổi nào?
Mục tiêu kinh doanh hoặc sản phẩm nào đang được hỗ trợ?
Kết quả nào sẽ cho thấy đội đang đi đúng hướng?
Mục tiêu cần giúp stakeholder hiểu lý do đầu tư, đồng thời giúp đội có căn cứ khi phải lựa chọn giữa các phương án.
3. Bối cảnh và mức độ phù hợp với chiến lược
Phần bối cảnh giải thích động lực của tính năng hoặc sản phẩm: vì sao công việc này quan trọng và nó giải quyết vấn đề nào.
Đồng thời, hãy kết nối công việc với định hướng rộng hơn của tổ chức. Khi hiểu được mức độ phù hợp chiến lược, đội sẽ dễ tập trung vào những giá trị quan trọng thay vì chỉ hoàn thành một danh sách đầu việc.
4. Giả định
Giả định là những điều đội đang dựa vào để lập kế hoạch hoặc ra quyết định, chẳng hạn giả định về nhu cầu kinh doanh, hành vi người dùng hoặc yếu tố kỹ thuật.
Viết rõ giả định giúp đội:
Nhìn thấy các yếu tố đang ảnh hưởng đến quyết định.
Nhận diện điểm nào có rủi ro.
Biết điều gì cần được xem xét lại khi có thông tin mới.
Đừng trình bày giả định như một sự thật đã được xác nhận. Việc tách riêng hai phần này giúp PRD đáng tin cậy và dễ cập nhật hơn.
5. User story và yêu cầu ở mức hành vi
User story giúp kết nối yêu cầu với nhu cầu của người dùng. Một cấu trúc quen thuộc là:
> Với vai trò là <người dùng>, tôi muốn <thực hiện việc gì> để <nhận được giá trị gì>.
Sau user story, mô tả điều sản phẩm cần hỗ trợ ở mức hành vi. Hãy tránh biến PRD thành chỉ dẫn chi tiết về cách code hoặc ép đội vào một phương án thiết kế quá sớm.
Mục tiêu là để cả đội hiểu:
Người dùng cần hoàn thành việc gì.
Giá trị mong đợi là gì.
Sản phẩm cần phản hồi hoặc hoạt động ra sao trong những tình huống chính.
6. Thiết kế, phạm vi ngoài dự kiến và câu hỏi mở
Atlassian khuyến nghị PRD nên có nội dung về thiết kế và các hạng mục ngoài phạm vi.
Phần out of scope đặc biệt hữu ích. Nó xác định rõ những gì chưa được giải quyết trong lần triển khai hiện tại. Đây không phải là lời từ chối vĩnh viễn với một ý tưởng; đó là ranh giới để đội giữ được trọng tâm.
Bên cạnh đó, hãy lưu lại các câu hỏi mở. Một câu hỏi chưa có đáp án rõ ràng tốt hơn một kết luận được đưa ra quá sớm.
Đừng viết PRD một mình
Atlassian khuyến nghị mời thành viên design và development tham gia phỏng vấn khách hàng khi phù hợp. Việc nghe trực tiếp giúp họ hiểu khách hàng tốt hơn, có cơ hội hỏi sâu hơn và không chỉ phụ thuộc vào phần diễn giải từ Product Manager.
Tương tự, việc xây dựng persona nên là nỗ lực chung của đội. Mỗi thành viên có góc nhìn riêng, và sự hiểu biết chung về persona sẽ ảnh hưởng đến các quyết định sản phẩm sau đó.
Triage công việc và backlog grooming cũng nên có sự tham gia của cả đội. Đây là cơ hội để mọi người hiểu vì sao một hạng mục được ưu tiên, thay vì chỉ nhận yêu cầu đã được quyết định sẵn.
Các anti-pattern cần tránh
Atlassian chỉ ra một số dấu hiệu cho thấy quy trình yêu cầu đang trở nên kém linh hoạt:
Toàn bộ dự án được đặc tả quá chi tiết trước khi engineering bắt đầu.
Mọi nhóm phải phê duyệt cứng trước khi công việc được triển khai.
Designer và developer không biết khi nào yêu cầu đã thay đổi.
Yêu cầu không được cập nhật sau khi đã được phê duyệt.
Product owner viết yêu cầu mà không có sự tham gia của đội.
Các cách làm này dễ khiến PRD trở thành tài liệu đóng băng. Trong khi đó, một PRD hiệu quả cần được xem lại và cập nhật khi đội hiểu hơn về vấn đề, khách hàng hoặc các ràng buộc thực tế.
Checklist trước khi chia sẻ PRD
[ ] Có nêu rõ vấn đề và bối cảnh của người dùng chưa?
[ ] Mục tiêu đội ngũ và mục tiêu kinh doanh đã đủ rõ chưa?
[ ] Công việc có được kết nối với định hướng sản phẩm hoặc tổ chức không?
[ ] Các giả định đã được viết tường minh chưa?
[ ] User story có thể hiện giá trị người dùng cần nhận được không?
[ ] Phạm vi và phần ngoài phạm vi đã được xác định chưa?
[ ] Các câu hỏi mở đã được ghi lại chưa?
[ ] Designer, developer và stakeholder liên quan đã có cơ hội phản hồi chưa?
[ ] Tài liệu có cơ chế được cập nhật khi yêu cầu thay đổi không?
PRD tốt không phải là tài liệu dài nhất hay chi tiết nhất. Nó là tài liệu giúp cả đội trả lời nhất quán ba câu hỏi: chúng ta đang giải vấn đề gì, vì sao điều này quan trọng, và cần thống nhất điều gì trước khi tiếp tục?