20 พรอมต์สำหรับ Product Manager ที่ทำให้เห็นข้อแลกเปลี่ยนชัดเจน
AI เขียน PRD ได้อย่างมั่นใจในไม่กี่วินาที โดยแต่งผู้ใช้ ข้อมูล และขอบเขตขึ้นมาเอง พรอมต์เหล่านี้ทำให้ AI ทำงานจากบรีฟ บันทึก และตัวเลขของคุณ แสดงวิธีคำนวณ และระบุคำถามที่ยังเปิดอยู่ก่อนทีมวิศวกรรมเริ่มงาน
แทนที่ทุกอย่างใน [วงเล็บเหลี่ยม] ด้วย บรีฟ บันทึก ตั๋ว หรือตัวเลขของคุณ
01. เขียน PRD จากบรีฟที่ยุ่งเหยิงและระบุคำถามที่ยังเปิดอยู่
คุณมีเธรด Slack บันทึกการโทร และเดดไลน์ แต่ยังไม่มีสเปก
ช่วยเปลี่ยนบรีฟที่ยุ่งเหยิงนี้ให้เป็นเอกสารความต้องการของผลิตภัณฑ์ (PRD) [วางบรีฟ เธรด บันทึกการโทร หรือข้อมูลทั้งหมดที่มี] หัวข้อตามลำดับนี้: ปัญหาและใครคือคนที่เจอปัญหา หลักฐานที่เรามี เป้าหมายพร้อมผลลัพธ์ที่วัดได้ สิ่งที่อยู่ในขอบเขต สิ่งที่อยู่นอกขอบเขต ขั้นตอนการใช้งานของผู้ใช้แบบเป็นข้อที่มีเลขกำกับ ความต้องการที่ระบุว่า MUST หรือ SHOULD และสิ่งที่ต้องพึ่งพาทีมอื่น ใช้เฉพาะสิ่งที่บรีฟระบุไว้ ตรงไหนที่บรีฟไม่ได้พูดถึง ให้เขียน [OPEN: คำถาม] ไว้ตรงนั้นแทนการเติมเอง จากนั้นสรุปคำถามที่ยังเปิดอยู่ทั้งหมดไว้ท้ายเอกสาร จัดกลุ่มตามผู้ที่ตอบได้ (ฉัน ดีไซน์ วิศวกรรม ฝ่ายกฎหมาย ลูกค้า) โดยเรียงสามข้อที่ขวางการพัฒนาไว้ก่อน
02. แตกฟีเจอร์เป็น user story พร้อมเกณฑ์การยอมรับ
พรุ่งนี้มีการ refinement แต่ฟีเจอร์ยังเป็นตั๋วใบใหญ่ใบเดียว
ช่วยแตกฟีเจอร์นี้เป็น user story ที่ทีมสร้างและส่งมอบได้ทีละเรื่อง ฟีเจอร์: [ฟีเจอร์ทำอะไร] ผู้ใช้: [ใครใช้ และพวกเขาพยายามทำอะไรให้สำเร็จ] ข้อจำกัด: [แพลตฟอร์ม เดดไลน์ สิ่งที่สร้างไปแล้ว] สำหรับแต่ละ story: 1. ในฐานะ [ผู้ใช้] ฉันต้องการ [การกระทำ] เพื่อที่ [ผลลัพธ์] 2. เกณฑ์การยอมรับในรูปแบบ Given / When / Then เรื่องละสามถึงหกข้อ โดยแต่ละข้อต้องเป็นสิ่งที่คนที่ไม่ได้เขียนทดสอบได้ 3. ขนาดโดยประมาณเป็น S, M หรือ L และสิ่งหนึ่งที่ทำให้ประมาณการไม่แน่นอน เรียง story ให้เรื่องแรกส่งมอบสิ่งที่ผู้ใช้จริงใช้งานได้ แม้จะเล็กก็ตาม ทำเครื่องหมาย story ที่จริงๆ แล้วเป็นสองเรื่อง และเรื่องที่จะสมเหตุสมผลก็ต่อเมื่อ story อื่นส่งมอบแล้ว
03. หา edge case ที่ PRD ของคุณตกหล่น
สเปกดูเสร็จแล้วและสัปดาห์หน้าทีมวิศวกรรมจะเริ่มงาน
อ่าน PRD นี้ในฐานะวิศวกรที่จะต้องรับรายงานบั๊กหลังเปิดตัว [วาง PRD หรือสเปก] ระบุ edge case ที่เอกสารยังไม่ครอบคลุม โดยจัดกลุ่มตามหัวข้อ: สถานะว่างและการใช้งานครั้งแรก ข้อผิดพลาดและการหมดเวลา สิทธิ์และบทบาท ขีดจำกัด (ยาวมาก มีจำนวนมาก ศูนย์ ซ้ำ) การทำงานพร้อมกัน (สองคนแก้ไขพร้อมกัน การคลิกซ้ำสองครั้ง การลองใหม่) ข้อมูลจากก่อนที่ฟีเจอร์นี้จะมี และการเข้าถึง แต่ละข้อให้ระบุ: สถานการณ์ในหนึ่งบรรทัด สิ่งที่สเปกปัจจุบันบ่งชี้ว่าจะเกิดขึ้น และคำถามที่ฉันต้องตอบ จัดอันดับห้าข้อแรกตามโอกาสที่ผู้ใช้จริงจะเจอในเดือนแรก อย่าแต่งความต้องการขึ้นเอง ให้ถามแทน
ปลดล็อกอีก 17 พรอมต์ ฟรี เพียงสมัครรับจดหมายข่าว
สมัครรับจดหมายข่าวของ Whizi เพื่ออ่านพรอมต์ที่เหลือในชุดนี้
- ให้คะแนน backlog ด้วย RICE และแสดงวิธีคำนวณ
- เปลี่ยนบันทึกสัมภาษณ์เป็น job, pain และคำพูดอ้างอิง
- เขียนแนวสัมภาษณ์ discovery ที่ถามว่าผู้คนทำอะไรไปแล้ว ไม่ใช่ว่าต้องการอะไร
- จัดกลุ่มตั๋วซัพพอร์ตเป็นปัญหาของผลิตภัณฑ์ที่ควรแก้
- เขียนสเปกหนึ่งหน้าที่วิศวกรสร้างตามได้
- เลือกตัวชี้วัดความสำเร็จและตัวชี้วัดคู่ตรงข้ามที่คอยกำกับความซื่อตรง
- ออกแบบการทดลองโดยตอบคำถามเรื่องขนาดตัวอย่างก่อน
- สร้างเช็กลิสต์เปิดตัวที่มีเจ้าของงานของทุกทีม
- เขียนบันทึกการอัปเดตที่ผู้ใช้อ่านจริง
- เขียนอัปเดตสำหรับผู้มีส่วนได้ส่วนเสียที่เริ่มด้วยสิ่งที่เปลี่ยนไป
- เขียนเรื่องเล่าของโรดแมปที่บอกว่าคุณจะไม่ทำอะไร
- ปฏิเสธคำขอฟีเจอร์พร้อมเหตุผลและขั้นตอนถัดไป
- ทำ pre-mortem ก่อนเปิดตัว
- แกะหน้าผลิตภัณฑ์ของคู่แข่งทีละข้อกล่าวอ้าง
- เขียนเป้าหมายสปรินต์เดียวจากตั๋วจำนวนมาก
- เปลี่ยนวิธีแก้ที่ถูกขอให้เป็นปัญหาที่อยู่เบื้องหลัง
- ให้โมเดลตัวที่สองรีวิว PRD ของตัวแรก