20 prompt product manager giúp thấy rõ các đánh đổi

01. Viết PRD từ một bản brief lộn xộn và liệt kê các câu hỏi còn bỏ ngỏ

Bạn có một chuỗi Slack, một ghi chú cuộc gọi và một deadline, nhưng chưa có spec.

Biến bản brief lộn xộn này thành một tài liệu yêu cầu sản phẩm (PRD).

[dán brief, chuỗi trao đổi, ghi chú cuộc gọi hoặc bất cứ thứ gì bạn có]

Các phần, theo thứ tự: vấn đề và ai đang gặp vấn đề đó, bằng chứng chúng ta có, mục tiêu với kết quả đo được, những gì nằm trong phạm vi, những gì nằm ngoài phạm vi, luồng người dùng theo các bước đánh số, các yêu cầu đánh dấu MUST hoặc SHOULD, và các phụ thuộc vào đội khác.

Chỉ dùng những gì brief nói. Chỗ nào brief không nói, hãy viết [OPEN: câu hỏi] thay vì tự điền vào.

Sau đó liệt kê mọi câu hỏi còn bỏ ngỏ ở cuối, nhóm theo người có thể trả lời (tôi, thiết kế, kỹ thuật, pháp lý, khách hàng), với ba câu đang chặn việc xây dựng đặt lên đầu.

02. Tách một tính năng thành user story kèm tiêu chí chấp nhận

Ngày mai là buổi refinement mà tính năng vẫn là một ticket khổng lồ.

Tách tính năng này thành các user story mà một đội có thể xây dựng và phát hành từng cái một.

Tính năng: [nó làm gì]
Người dùng: [ai dùng và họ đang muốn hoàn thành việc gì]
Ràng buộc: [nền tảng, deadline, những thứ đã xây xong]

Với mỗi story:
1. Là một [người dùng], tôi muốn [hành động], để [kết quả].
2. Tiêu chí chấp nhận theo dạng Given / When / Then, từ ba đến sáu tiêu chí mỗi story, mỗi tiêu chí có thể được kiểm thử bởi người không viết ra nó.
3. Ước lượng kích cỡ S, M hoặc L và một điều khiến nó chưa chắc chắn.

Sắp xếp các story sao cho story đầu tiên phát hành được thứ mà người dùng thật có thể dùng, dù nhỏ. Đánh dấu story nào thực ra là hai story, và story nào chỉ có nghĩa khi một story khác đã phát hành.

03. Tìm các trường hợp biên mà PRD của bạn bỏ sót

Spec trông đã xong và tuần sau đội kỹ thuật bắt đầu.

Hãy đọc PRD này với tư cách kỹ sư sẽ nhận các báo cáo lỗi sau khi ra mắt.

[dán PRD hoặc spec]

Liệt kê các trường hợp biên mà nó chưa bao phủ, nhóm theo: trạng thái trống và lần đầu sử dụng, lỗi và hết thời gian chờ, quyền và vai trò, giới hạn (rất dài, rất nhiều, bằng không, trùng lặp), đồng thời (hai người cùng sửa, bấm đúp, thử lại), dữ liệu có từ trước khi tính năng này tồn tại, và khả năng tiếp cận.

Với mỗi trường hợp: kịch bản trong một dòng, điều spec hiện tại ngụ ý sẽ xảy ra, và câu hỏi tôi cần trả lời. Xếp hạng năm trường hợp hàng đầu theo khả năng người dùng thật gặp phải trong tháng đầu tiên. Đừng bịa ra yêu cầu; hãy hỏi.

Mở khóa 17 prompt còn lại miễn phí

Đăng ký nhận bản tin của Whizi để đọc phần còn lại của bộ prompt này.

4. Chấm điểm backlog bằng RICE và trình bày cách tính
5. Biến ghi chú phỏng vấn thành công việc cần làm, nỗi đau và trích dẫn
6. Viết bộ câu hỏi phỏng vấn khám phá về những gì mọi người đã làm, không phải những gì họ muốn
7. Nhóm ticket hỗ trợ thành các vấn đề sản phẩm đáng sửa
8. Viết spec một trang để kỹ sư xây dựng theo
9. Chọn một chỉ số thành công và chỉ số đối trọng giữ cho nó trung thực
10. Thiết kế một thử nghiệm và trả lời các câu hỏi về cỡ mẫu trước
11. Lập checklist ra mắt với người phụ trách cho mỗi đội
12. Viết release notes mà người dùng thực sự đọc
13. Viết bản cập nhật cho các bên liên quan, mở đầu bằng điều đã thay đổi
14. Viết phần diễn giải lộ trình nói rõ điều bạn không làm
15. Từ chối một yêu cầu tính năng, kèm lý do và bước tiếp theo
16. Chạy pre-mortem trước khi bản ra mắt được phát hành
17. Mổ xẻ trang sản phẩm của đối thủ từng tuyên bố một
18. Viết một mục tiêu sprint từ một danh sách ticket dài
19. Biến một giải pháp được yêu cầu thành vấn đề đằng sau nó
20. Nhờ một mô hình thứ hai rà soát PRD của mô hình đầu tiên