Sáng nay bạn mở một trang Notion có tiêu đề "PRD: [tên tính năng]." Ba tiếng sau, nó vẫn ghi "PRD: [tên tính năng]."
Bạn hiểu rõ vấn đề. Bạn biết giải pháp. Hôm qua bạn đã giải thích cặn kẽ cho engineering lead đến hai lần. Vậy mà cứ ngồi xuống để viết ra, bạn lại đứng hình.
Đây không phải vấn đề về tư duy. Đây là vấn đề về việc gõ phím.
PM không được trả lương để gõ phím. Bạn được trả lương để ra quyết định xây cái gì và vì sao. PRD chỉ là tài liệu ghi lại quyết định đó để engineering, design và lãnh đạo có thể hành động. Ở đâu đó giữa lúc biết phải viết gì và lúc hoàn thành tài liệu, hàng giờ đồng hồ biến mất.
Có một con đường nhanh hơn. PRD là một trong những loại tài liệu phù hợp với giọng nói nhất mà một PM phải viết. Về bản chất, nó chính là những gì bạn sẽ nói khi đứng trước bảng trắng để giải thích tính năng. Khi bạn ngừng gõ PRD và bắt đầu đọc chính tả, thời gian viết bản nháp giảm hẳn.
Cái giá viết lách của PM mà ít ai nói tới
Mỗi PRD bạn viết đều phải cạnh tranh với một cuộc họp, một buổi review roadmap, một thread Slack với stakeholder. Việc viết thực sự chỉ diễn ra trong những khe nửa tiếng tranh thủ được hoặc sau bữa tối.
Phép tính rất tàn nhẫn. Người bình thường gõ khoảng 40 từ mỗi phút. Người bình thường nói khoảng 150. Khoảng cách đó đã gần 3,5 lần, chưa tính tới mọi ma sát khiến việc viết khó hơn: xóa lùi, đổi câu chữ, hoài nghi một câu ba lần trước khi đi tiếp.
Một PRD 1.500 từ mất 90 phút để gõ chỉ tốn khoảng 25 phút để nói. Tư duy vẫn vậy. Kết quả vẫn vậy. Chỉ có công cụ thay đổi.
Vì sao PRD hợp với giọng nói gần như hoàn hảo
Hầu hết tài liệu trừng phạt người dùng dictation vì đòi hỏi độ chính xác cao: code, bảng biểu, mô hình tài chính. PRD thì ngược lại. Nó là tài liệu kể chuyện.
Hãy nghĩ về PRD gần nhất bạn viết. Phần "Vấn đề" là hai đoạn giải thích vì sao chuyện đó quan trọng. Phần "Giải pháp" mô tả cách thứ đó hoạt động. Phần "User Stories" gồm các câu theo mẫu "Là một X, tôi muốn Y, để Z." Phần "Edge Cases" là danh sách các kịch bản "chuyện gì xảy ra khi..."
Không phần nào trong số đó đòi hỏi độ chính xác khi gõ phím. Tất cả đều là kiểu nội dung bạn sẽ nói trong một cuộc họp. Định dạng vốn đã trùng khớp với cách một PM thực sự truyền đạt công việc.
Quy trình viết nháp PRD trong 30 phút
Đây là cấu trúc thực sự hiệu quả: 1. Mở một tài liệu trống đã có sẵn các tiêu đề mục: vấn đề, giải pháp, user stories, acceptance criteria, edge cases, ngoài phạm vi, câu hỏi mở. 2. Đi từng phần. Đọc chính tả mỗi phần như thể bạn đang giải thích cho một engineer mới gia nhập team. 3. Đừng vừa nói vừa sửa. Việc chuyển qua lại giữa vai "người nói" và "biên tập viên" là thứ làm bạn chậm nhất. 4. Sau khi đọc xong tất cả các phần, đọc lại toàn bộ bản nháp từ đầu đến cuối một lần. Gọt câu chữ. Sửa những chỗ thực sự sai. 5. Gửi đi review.
Kỷ luật nằm ở bước ba. Nếu cứ dừng lại để sửa câu, bạn sẽ không có được lợi ích về tốc độ. Bạn lại quay về tốc độ gõ phím trong một bộ áo khác.
Từng phần một: cách đọc chính tả mỗi mục của PRD
Có những phần dễ đọc chính tả hơn các phần khác. Đây là cách tiếp cận từng phần.
Mô tả vấn đề
Đây là phần dễ đọc chính tả nhất. Thuần kể chuyện. Bạn đang giải thích cái gì hỏng, hỏng với ai, và vì sao việc đó quan trọng ngay lúc này.
Hãy nói như đang brief cho một đồng đội mới tại buổi stand-up. Nhắc tới phân khúc người dùng, ma sát họ gặp phải, chỉ số bị ảnh hưởng. Đừng lo lắng về sự bay bổng của câu chữ. Đó là việc của khâu biên tập.
Tổng quan giải pháp
Diễn giải giải pháp đề xuất như đang phác họa trên bảng trắng. "Người dùng nhấn vào đây, thấy cái này, rồi sau đó..." Giọng nói xử lý phần này rất trôi chảy vì nó trùng với cách bạn vẫn giải thích miệng.
User stories
User stories nghe có vẻ máy móc vì cấu trúc "Là một X, tôi muốn Y, để Z", nhưng nếu bạn cam kết với định dạng đó thì đọc chính tả vẫn rất tốt. Hãy nói mỗi story thành một câu, rồi chuyển sang câu tiếp theo.
Nếu có mười story, đọc cả mười trong một lượt. Đừng đánh số khi nói. Hãy để trình soạn thảo hoặc bước AI dọn dẹp lo phần định dạng.
Acceptance criteria
Danh sách là phần khó nhằn nhất khi dictation, nhưng vẫn làm được. Có hai cách:
Cách thứ nhất là đọc các tiêu chí thành câu hoàn chỉnh và để AI biến chúng thành danh sách. Bạn nói kiểu như: "Người dùng nên có thể lọc kết quả theo ngày, theo người dùng và theo trạng thái. Trạng thái bộ lọc nên được giữ giữa các phiên. Trạng thái rỗng nên hiển thị một gợi ý."
Cách thứ hai là đọc rõ cấu trúc bullet ra mồm: "Gạch đầu dòng một, lọc theo ngày. Gạch đầu dòng hai, lọc theo người dùng. Gạch đầu dòng ba, giữ qua các phiên." Chọn cách nào ít gượng miệng hơn với bạn.
Edge cases
Đây là chỗ giọng nói thực sự tỏa sáng. Edge cases là kiểu nội dung suy nghĩ-thành-tiếng, ra rất gọn khi nói nhưng vụng về khi gõ. Những câu hỏi như "chuyện gì xảy ra nếu người dùng offline" hay "còn những trường hợp dữ liệu cũ thì sao" tuôn ra tự nhiên hơn nhiều khi nói thay vì khi viết.
Hãy đọc mọi edge case bạn nghĩ ra được, kể cả những cái có vẻ hiển nhiên. Bạn có thể tỉa bớt ở khâu biên tập.
Ngoài phạm vi
Ba câu. Có khi là bốn. Giọng nói xử lý phần này trong chưa đầy một phút.
Câu hỏi mở
Phần này bị đánh giá thấp. Đa số PM bỏ qua vì không muốn trông có vẻ thiếu chắc chắn. Đừng. Phần câu hỏi mở chính là nơi engineering, design và sếp trên một cấp tóm được những thứ bạn còn chưa nghĩ thấu.
Giọng nói là công cụ phù hợp cho việc đó. Câu hỏi mở chính là những suy nghĩ nửa vời ra rất ổn khi nói nhưng nặng nề kỳ lạ khi cố gõ ra. Hãy đọc ra mọi nghi vấn, kể cả những cái bạn đoán đã có câu trả lời hiển nhiên. Một nửa sẽ được giải quyết ngay trong buổi standup tới. Nửa còn lại sẽ cứu cả đợt launch của bạn.
Khớp tone với từng phần
PRD không được viết bằng một giọng duy nhất. Phần tóm tắt cho cấp điều hành ở đầu nên ngắn gọn và mang tính chiến lược. Phần technical spec phải chính xác. Phần "câu hỏi mở" có thể thoải mái hơn.
Khi đọc chính tả, bạn tự nhiên đổi register. Giọng bạn trở nên trang trọng khi nói về chiến lược và mềm hơn khi điểm qua các edge case. Vấn đề là hầu hết công cụ dictation đều cho ra cùng một bản phiên âm phẳng bất kể ngữ cảnh.
Đây chính là chỗ Smart Rules của Voicr phát huy tác dụng. Bạn có thể đặt style "spec chuyên nghiệp, sạch sẽ" cho trình soạn thảo tài liệu, style "brainstorming thoải mái" cho các thread Slack, và style "rõ ràng kỹ thuật" cho engineering wiki. Voicr phát hiện app đang hoạt động và áp style phù hợp một cách tự động, nên cùng một câu nói ra sẽ hạ cánh khác nhau tùy theo điểm đến.
Riêng với PRD, hãy tạo một rule yêu cầu văn xuôi chuyên nghiệp sạch sẽ, bỏ các từ đệm và cấu trúc thành bullet list ở những chỗ bạn ra hiệu. Bạn nói một lần. Tài liệu đọc lên như thể bạn đã viết rất cẩn thận.
Những chỗ giọng nói không giúp được
Nói thẳng: không phải phần nào của PRD cũng hưởng lợi từ giọng nói.
Bảng biểu và ma trận vẫn nhanh hơn nếu gõ. Nếu PRD của bạn có lưới so sánh tính năng, ma trận phân quyền hay bảng ước lượng kích thước, hãy gõ.
Các chuỗi kỹ thuật chính xác cũng vậy. Tên API endpoint, tên cột database, số phiên bản — bạn có thể đọc vòng quanh chúng ("endpoint là, gạch chéo, users, gạch chéo, ID") nhưng nó rất gượng. Hãy gõ ra.
Sơ đồ thì hiển nhiên không thể đọc chính tả. Hãy vẽ trong công cụ bạn thích rồi nhúng vào.
Còn lại — phần kể chuyện, user stories, edge cases, quyết định, lập luận — giọng nói thắng về tốc độ, và thắng cả ở chỗ bạn không bị kẹt giữa câu vì cố phát biểu cho hoàn hảo.
Chuyển dịch tư duy: nghĩ ra mồm, biên tập sau
Lợi ích lớn nhất khi đọc chính tả PRD không phải phép tính từ trên phút. Nó là việc bạn ngừng đánh bóng trong lúc đang viết.
Khi gõ, bạn xóa lùi. Bạn viết lại một câu hai lần. Bạn nhìn chằm chằm một đoạn "gần ổn" trong mười phút. Đó là nơi PRD đi vào ngõ cụt: ở khoảng trống giữa soạn thảo và biên tập, nơi cả hai đều không diễn ra trọn vẹn.
Khi đọc chính tả, bạn buộc phải cam kết. Bạn nói một câu, nó nằm trên trang, bạn đi tiếp. Lượt đầu sẽ lộn xộn hơn so với gõ. Nhưng bạn hoàn thành bản nháp. Và một bản nháp lộn xộn nhưng đã xong hữu ích hơn rất nhiều so với một bản đánh bóng nhưng dở dang.
Một khi bản nháp đã có, biên tập là một việc khác và nhanh hơn nhiều. Bạn sẽ thường tốn nhiều thời gian gọt giũa hơn cả lúc đọc chính tả, và điều đó hoàn toàn ổn. Gọt một tài liệu hoàn chỉnh là một việc đã biết cách làm. Nhìn vào một trang trắng thì không.
Thử ngay trên PRD tiếp theo của bạn
Chọn một PRD bạn đang trì hoãn. Mở tài liệu, đặt sẵn các tiêu đề mục, rồi đọc chính tả từ trên xuống dưới mà không sửa. Đặt đồng hồ 25 phút. Xem bạn nhận được gì.
Lần đầu làm chuyện này sẽ cảm thấy kỳ lạ. Bạn sẽ lo kết quả không đủ tốt. Hãy kìm lại sự thôi thúc sửa giữa chừng. Cứ làm cho xong.
Nếu bạn muốn phần dictation ra đủ sạch để gần như không cần sửa, Voicr tự lo phần đánh bóng đó. Giữ FN ở bất cứ đâu trên Mac, nói qua một phần, thả ra và dán phần văn bản đã được dọn vào tài liệu. Nó loại bỏ từ đệm, sửa ngữ pháp và sắp xếp suy nghĩ trước khi chúng vào clipboard. Bản nháp PRD từng tốn cả buổi chiều giờ chỉ cần một lần ngồi.
PRD sẽ không tự viết. Nhưng chúng cũng không nhất thiết phải được gõ ra.