เช้านี้คุณเปิดหน้า Notion ที่ตั้งชื่อว่า "PRD: [ชื่อฟีเจอร์]" สามชั่วโมงผ่านไป มันก็ยังเขียนว่า "PRD: [ชื่อฟีเจอร์]" อยู่อย่างนั้น
คุณรู้ว่าปัญหาคืออะไร คุณรู้ว่าทางแก้คืออะไร เมื่อวานคุณเพิ่งอธิบายให้ engineering lead ฟังไปสองรอบ แต่พอนั่งลงจะเขียนจริงๆ คุณก็ติดขัด
นี่ไม่ใช่ปัญหาด้านการคิด แต่เป็นปัญหาด้านการพิมพ์
PM ไม่ได้รับเงินมาเพื่อพิมพ์ คุณรับเงินมาเพื่อตัดสินใจว่าจะสร้างอะไรและทำไม PRD เป็นเพียงเอกสารที่บันทึกการตัดสินใจนั้น เพื่อให้ engineering, design และ leadership ทำงานต่อได้ แต่ระหว่างที่รู้ว่าต้องเขียนอะไรกับเขียนเอกสารให้เสร็จ เวลาหลายชั่วโมงหายไปเฉยๆ
มีทางที่เร็วกว่านี้ PRD เป็นหนึ่งในเอกสารที่เหมาะกับเสียงมากที่สุดเท่าที่ PM ต้องเขียน เพราะมันคือสิ่งที่คุณจะพูดเวลายืนหน้ากระดานไวท์บอร์ดอธิบายฟีเจอร์อยู่แล้ว ทันทีที่คุณเลิกพิมพ์ PRD แล้วเริ่มพูดให้มันบันทึก เวลาที่ใช้ร่างก็ลดฮวบ
ภาษีการเขียนของ PM ที่ไม่ค่อยมีใครพูดถึง
PRD ทุกฉบับที่คุณเขียนต้องแย่งเวลากับมีตติ้ง การรีวิว roadmap และเธรด Slack ของ stakeholder การเขียนจริงๆ เกิดขึ้นในช่วงเวลาครึ่งชั่วโมงที่ขโมยมา หรือไม่ก็หลังมื้อค่ำ
ตัวเลขมันโหดร้าย คนเฉลี่ยพิมพ์ได้ราวๆ 40 คำต่อนาที แต่พูดได้ราวๆ 150 คำต่อนาที นั่นคือช่องว่างประมาณ 3.5 เท่า ก่อนที่จะนับรวมแรงเสียดทานทุกอย่างที่ทำให้การเขียนยากขึ้น เช่น การลบ การหาคำใหม่ การตั้งคำถามกับประโยคเดิมซ้ำสามรอบก่อนจะเดินหน้าต่อ
PRD ความยาว 1,500 คำที่ใช้เวลาพิมพ์ 90 นาที จะใช้เวลาพูดประมาณ 25 นาที กระบวนการคิดเหมือนเดิม ผลลัพธ์เหมือนเดิม สิ่งที่เปลี่ยนคือกลไกเท่านั้น
ทำไม PRD ถึงเหมาะกับเสียงอย่างพอเหมาะพอดี
เอกสารส่วนใหญ่ลงโทษการพูดบันทึก เพราะต้องการความแม่นยำ เช่น โค้ด ตาราง โมเดลทางการเงิน แต่ PRD ตรงข้าม มันคือเอกสารเชิงเล่าเรื่อง
ลองนึกถึง PRD ฉบับล่าสุดที่คุณเขียน หัวข้อ "Problem" คือสองย่อหน้าอธิบายว่าทำไมเรื่องนี้ถึงสำคัญ หัวข้อ "Solution" คือคำอธิบายว่าสิ่งนี้ทำงานยังไง หัวข้อ "User Stories" คือประโยครูปแบบ "As a X, I want Y, so that Z" หัวข้อ "Edge Cases" คือลิสต์สถานการณ์ "จะเกิดอะไรขึ้นถ้า..."
ไม่มีส่วนไหนเลยที่ต้องการความแม่นยำในการกดคีย์บอร์ด ทุกส่วนคือสิ่งที่คุณจะพูดในมีตติ้งอยู่แล้ว รูปแบบของมันตรงกับวิธีที่ PM ใช้สื่อสารงานในชีวิตจริง
เวิร์กโฟลว์ร่าง PRD ใน 30 นาที
นี่คือโครงสร้างที่ใช้ได้ผล: 1. เปิดเอกสารเปล่าและใส่หัวข้อให้ครบไว้ก่อน ได้แก่ problem, solution, user stories, acceptance criteria, edge cases, out of scope, open questions 2. ทำทีละหัวข้อ พูดบันทึกแต่ละส่วนเหมือนกำลังอธิบายให้วิศวกรใหม่ที่เพิ่งเข้าทีมฟัง 3. อย่าแก้ระหว่างที่กำลังพูด การสลับสมองระหว่าง "คนพูด" กับ "คนแก้" คือสิ่งที่ทำให้คุณช้าที่สุด 4. หลังพูดครบทุกหัวข้อแล้ว อ่านร่างทั้งฉบับรวดเดียวจากบนลงล่าง กระชับสำนวน แก้สิ่งที่ผิดจริงๆ 5. ส่งให้รีวิว
วินัยอยู่ที่ขั้นที่สาม ถ้าคุณยังหยุดเป็นพักๆ เพื่อแก้ประโยค คุณก็ไม่ได้รับประโยชน์ด้านความเร็ว แต่กลับไปอยู่ที่ความเร็วการพิมพ์ในชุดเครื่องแต่งกายใหม่เท่านั้นเอง
ทีละหัวข้อ: วิธีพูดบันทึก PRD แต่ละส่วน
บางหัวข้อพูดบันทึกง่ายกว่าหัวข้ออื่น นี่คือวิธีรับมือกับแต่ละส่วน
Problem statement
นี่คือหัวข้อที่พูดบันทึกง่ายที่สุด เป็นการเล่าเรื่องล้วนๆ คุณกำลังอธิบายว่าอะไรพัง พังสำหรับใคร และทำไมถึงสำคัญตอนนี้
พูดเหมือนกำลังบรีฟเพื่อนร่วมทีมใหม่ตอน stand-up เอ่ยถึง user segment แรงเสียดทานที่พวกเขาเจอ และเมตริกที่มันส่งผลกระทบ อย่ากังวลเรื่องความสละสลวยของสำนวน นั่นเป็นหน้าที่ของขั้นตอนการแก้
Solution overview
เดินผ่านโซลูชันที่เสนอเหมือนกำลังร่างบนกระดานไวท์บอร์ด "ผู้ใช้คลิกตรงนี้ เห็นสิ่งนี้ แล้วจากนั้น..." เสียงจัดการเรื่องนี้ได้คล่อง เพราะมันตรงกับวิธีที่คุณจะอธิบายออกมาดังๆ อยู่แล้ว
User stories
User stories ฟังดูเป็นกลไก เพราะรูปแบบ "As a X, I want Y, so that Z" แต่มันพูดบันทึกได้ดีถ้าคุณยอมยึดรูปแบบ พูดแต่ละ story เป็นหนึ่งประโยค แล้วเดินหน้าไปอันถัดไป
ถ้ามีสิบ stories ก็พูดทั้งสิบรวดเดียว อย่าใส่หมายเลขระหว่างที่พูด ปล่อยให้ตัวแก้ไขเอกสารหรือ AI cleanup จัดการรูปแบบให้
Acceptance criteria
ลิสต์เป็นส่วนที่ยากที่สุดของการพูดบันทึก แต่ก็ยังทำได้ มีสองแนวทาง
แนวทางแรก คือพูดเงื่อนไขเป็นประโยคเต็มๆ แล้วให้ AI ขัดเกลาเปลี่ยนเป็นลิสต์ พูดประมาณว่า "ผู้ใช้ควรกรองผลลัพธ์ได้ด้วยวันที่ ด้วยผู้ใช้ และด้วยสถานะ สถานะการกรองควรค้างไว้ข้าม session หน้าจอตอนไม่มีข้อมูลควรแสดงคำแนะนำ"
แนวทางที่สอง คือพูดโครงสร้าง bullet ออกมาตรงๆ "บูลเล็ตหนึ่ง กรองด้วยวันที่ บูลเล็ตสอง กรองด้วยผู้ใช้ บูลเล็ตสาม คงสถานะข้าม session" เลือกอันที่รู้สึกไม่ขัดปากกว่า
Edge cases
นี่คือจุดที่เสียงเปล่งประกายจริงๆ Edge cases เป็นเนื้อหาแบบคิดออกมาดังๆ ที่ออกมาเรียบเมื่อพูด แต่เก้กังเมื่อพิมพ์ คำถามเช่น "ถ้าผู้ใช้ออฟไลน์จะเกิดอะไรขึ้น" หรือ "แล้วถ้าข้อมูลเก่าล่ะ" ไหลออกมาเป็นธรรมชาติทางคำพูดมากกว่าทางการเขียน
พูดบันทึก edge case ทุกอันที่คิดออก แม้แต่อันที่ดูชัดเจน คุณตัดทิ้งตอนแก้ได้
Out of scope
สามประโยค หรือสี่ก็ได้ เสียงจัดการเรื่องนี้ได้ในไม่ถึงหนึ่งนาที
Open questions
หัวข้อนี้ถูกประเมินค่าต่ำเกินไป PM ส่วนใหญ่ข้ามมันเพราะไม่อยากดูไม่แน่ใจ อย่าทำแบบนั้น หัวข้อ open questions คือจุดที่ engineering, design และหัวหน้าระดับเหนือคุณจับสิ่งที่คุณยังไม่ได้คิดทะลุไว้
เสียงคือเครื่องมือที่ใช่สำหรับงานนี้ Open questions คือความคิดครึ่งๆ กลางๆ ที่ออกมาดูดีเมื่อพูด แต่หนักอึ้งอย่างประหลาดเมื่อพยายามพิมพ์ พูดความไม่แน่ใจทุกอย่างออกมา แม้แต่อันที่คุณคิดว่ามีคำตอบชัดอยู่แล้ว ครึ่งหนึ่งจะถูกเคลียร์ใน stand-up รอบหน้า อีกครึ่งจะช่วยคุณรอดในวันลอนช์
จับคู่โทนเสียงให้เข้ากับแต่ละหัวข้อ
PRD ไม่ได้เขียนด้วยน้ำเสียงเดียว สรุปผู้บริหารด้านบนควรกระชับและเชิงกลยุทธ์ ข้อกำหนดทางเทคนิคควรแม่นยำ ส่วน "open questions" จะลำลองกว่าได้
เวลาคุณพูดบันทึก คุณจะเปลี่ยนระดับภาษาเองโดยอัตโนมัติ น้ำเสียงจะเป็นทางการตอนพูดเรื่องกลยุทธ์ และผ่อนคลายลงตอนเดินผ่าน edge cases ปัญหาคือเครื่องมือพูดบันทึกส่วนใหญ่ส่งออกเป็นการถอดเสียงแบบแบนๆ เหมือนกันหมดไม่ว่าบริบทจะเป็นอะไร
นี่คือจุดที่ Smart Rules ของ Voicr เข้ามาเป็นพระเอก คุณตั้งสไตล์ "clean professional spec" ไว้สำหรับตัวแก้ไขเอกสาร สไตล์ "casual brainstorming" ไว้สำหรับเธรด Slack และสไตล์ "technical clarity" ไว้สำหรับวิกิของวิศวกรได้ Voicr ตรวจจับแอปที่กำลังใช้งานอยู่และใส่สไตล์ที่เหมาะสมให้อัตโนมัติ ความคิดเดียวกันที่พูดออกไปจึงลงจอดต่างกันขึ้นอยู่กับว่าปลายทางคือที่ไหน
สำหรับ PRD โดยเฉพาะ ตั้งกฎที่ขอสำนวนสะอาดในระดับมืออาชีพ ตัดคำเยิ่นเย้อ และจัดเป็นลิสต์ตรงจุดที่คุณส่งสัญญาณ คุณพูดครั้งเดียว เอกสารอ่านเหมือนคุณเขียนมาอย่างพิถีพิถัน
ส่วนที่เสียงช่วยไม่ได้
ขอพูดตรงๆ ไม่ใช่ทุกส่วนของ PRD ที่ได้ประโยชน์จากเสียง
ตารางและเมทริกซ์ยังพิมพ์เร็วกว่า ถ้า PRD ของคุณมีตารางเปรียบเทียบฟีเจอร์ เมทริกซ์สิทธิ์การเข้าถึง หรือตารางประมาณการขนาด พิมพ์เอาเถอะ
สตริงทางเทคนิคที่ต้องเป๊ะก็พิมพ์เร็วกว่า ชื่อ API endpoint ชื่อคอลัมน์ฐานข้อมูล หมายเลขเวอร์ชัน คุณพูดเลี่ยงได้ ("endpoint คือ สแลช users สแลช ID") แต่มันเก้กัง พิมพ์อันพวกนั้นไปเถอะ
ไดอะแกรมพูดบันทึกไม่ได้อยู่แล้ว วาดในเครื่องมือที่ถนัดแล้ว embed เข้าไป
นอกจากนั้น ทั้งเรื่องเล่า user stories edge cases การตัดสินใจ และเหตุผล เสียงชนะในเรื่องความเร็ว และในข้อที่ว่าคุณจะไม่ติดอยู่กลางประโยคพยายามเรียบเรียงคำให้สมบูรณ์แบบ
การปรับชุดความคิด: คิดออกมาดังๆ แก้ทีหลัง
กำไรก้อนใหญ่ที่สุดจากการพูดบันทึก PRD ไม่ใช่คณิตศาสตร์เรื่อง WPM แต่คือการที่คุณหยุดขัดเกลาระหว่างกำลังเขียน
เวลาพิมพ์ คุณกด backspace คุณเขียนประโยคใหม่สองรอบ คุณจ้องย่อหน้าที่ "เกือบใช่" อยู่สิบนาที นั่นคือที่ที่ PRD ไปตาย ในช่องว่างระหว่างการร่างกับการแก้ ซึ่งไม่มีอันไหนทำสำเร็จเต็มที่
เวลาพูดบันทึก คุณ commit คุณพูดประโยคหนึ่ง มันลงบนหน้า แล้วคุณก็เดินหน้าต่อ ร่างแรกออกมารกกว่าตอนที่คุณพิมพ์ แต่คุณร่างเสร็จ และร่างที่เสร็จแล้วแม้จะรกก็มีประโยชน์ดราม่ามากกว่าร่างขัดเกลาที่ยังไม่จบ
พอร่างมีอยู่แล้ว การแก้ก็เป็นคนละกิจกรรมที่เร็วกว่าเยอะ บ่อยครั้งคุณจะใช้เวลาขัดเกลามากกว่าเวลาพูดบันทึก และนั่นก็โอเค การขัดเกลาเอกสารที่เสร็จแล้วคืองานที่รู้กันอยู่ การจ้องหน้าเปล่าๆ ไม่ใช่
ลองทำกับ PRD ฉบับถัดไปของคุณ
เลือก PRD ที่คุณดองไว้ เปิดเอกสาร ใส่หัวข้อให้ครบ แล้วพูดบันทึกจากบนลงล่างโดยไม่แก้ ตั้งเวลา 25 นาที ดูว่าได้อะไรออกมา
ครั้งแรกที่ทำจะรู้สึกแปลกๆ คุณจะกังวลว่าผลลัพธ์ไม่ดีพอ ต้านความอยากที่จะแก้กลางทาง พูดให้จบไปก่อน
ถ้าอยากให้สิ่งที่พูดออกมาสะอาดพอจนแทบไม่ต้องแก้ Voicr จัดการขัดเกลาให้อัตโนมัติ กด FN ค้างจากที่ไหนก็ได้บน Mac พูดผ่านหนึ่งหัวข้อ ปล่อย แล้ววางข้อความที่ขัดเกลาแล้วลงในเอกสาร มันตัดคำเยิ่นเย้อ แก้ไวยากรณ์ และจัดโครงสร้างความคิดของคุณก่อนถึงคลิปบอร์ด ร่าง PRD ที่เคยใช้เวลาทั้งบ่ายเหลือนั่งครั้งเดียว
PRD ของคุณจะไม่เขียนตัวมันเอง แต่ก็ไม่จำเป็นต้องพิมพ์เหมือนกัน