Emma·Product ManagerEmma เปลี่ยนไอเดียให้เป็น PRD ที่ทีม AI ของคุณนำไปสร้างได้ภายในวันเดียวกัน ไม่ใช่สเปกที่นอนอยู่ในเอกสารตลอดสองสปรินต์
จากไอเดียสู่ฟีเจอร์ที่กำหนดขอบเขตชัดเจนได้ในการแชทครั้งเดียว
PRD อยู่ใน Notion โค้ดอยู่ใน GitHub และตัวโปรดักต์อยู่ในระบบจริง พอถึงสปรินต์ 2 ทั้งสามอย่างก็เล่าเรื่องคนละแบบ Emma เก็บ PRD ไว้ในเวิร์กสเปซเดียวกับโค้ด เพื่อให้มันยังคงเป็นแหล่งข้อมูลหลัก
เครื่องมือ PRD ที่ทำงานเดี่ยว ๆ จะเขียนทุกอย่างตามที่คุณขอ Emma จะเสนอขอบเขต v1 ที่เหมาะสม และคอยทักท้วงเมื่อขอบเขตเริ่มไหล แทนที่จะปล่อยให้ฟีเจอร์ที่ควรใช้เวลา 2 สัปดาห์ กลายเป็นโปรเจกต์ 2 เดือนแบบเงียบ ๆ
Productboard รวบรวมรายการฟีดแบ็กได้เป็นพันรายการ แต่การเปลี่ยนสิ่งเหล่านั้นให้เป็นสเปกที่ทีมของคุณส่งมอบได้จริง ก็ยังเป็นหน้าที่ของคนอยู่ดี Emma รับทั้งงานวิจัยของ Iris หรือไอเดียตั้งต้น แล้วเขียนเป็น user stories ที่ทีมวิศวกรนำไปพัฒนาต่อได้
ตั้งแต่พรอมป์แรกของคุณไปจนถึงผลลัพธ์ที่พร้อมใช้งาน นี่คือวิธีที่ Emma ทำงานจริง
Emma เริ่มจากโอกาสที่มีอยู่จริงและผ่านการยืนยันแล้ว ไม่ใช่ "ฉันมีไอเดียตอนอาบน้ำ"
ส่งต่อให้ Irisใครทำอะไร เมื่อไหร่ และเราจะรู้ได้อย่างไรว่ามันได้ผล? ชัดเจนพอที่วิศวกรจะนำไปสร้างได้
จำกัดสเปกให้อยู่ในเวอร์ชันที่เล็กที่สุดซึ่งพิสูจน์สมมติฐานได้ — การขยายขอบเขตจะถูกจับได้ตรงนี้
มีการนำข้อแลกเปลี่ยนด้านสถาปัตยกรรมและเวลาในการพัฒนามาพิจารณาก่อนล็อกสเปก ไม่มีเรื่องไม่คาดคิดระหว่างการพัฒนา
ส่งต่อให้ BobPRD จะเข้าสู่คิว build ได้ทันที เป็นอาร์ติแฟกต์เดียวกันที่ PM, architecture และ engineering ใช้ร่วมกัน
ปัญหา เป้าหมาย ผู้ใช้ ขอบเขต สิ่งที่อยู่นอกขอบเขต และตัวชี้วัดความสำเร็จในรูปแบบที่สม่ำเสมอทุกครั้ง
แต่ละสตอรีสามารถนำไปพัฒนาและทดสอบได้ ไม่ใช่เพียงความต้องการฟีเจอร์ที่คลุมเครือ
Emma จะระบุข้อกำหนดที่คลุมเครือและเสนอการตัดขอบเขตสำหรับเวอร์ชัน v1 แทนการเขียนทุกอย่างที่คุณขอ
ดึงข้อมูลเชิงลึกจาก Iris เมื่อมี เพื่อให้ PRD ตั้งอยู่บนข้อมูลเชิงลึกที่แท้จริง
Alex อ่าน PRD เป็นแหล่งข้อมูลอ้างอิงหลักสำหรับการพัฒนา โดยไม่ต้องมีชั้นการแปลความ
PRD อยู่ใน Editor ถัดจากโค้ด จึงทำให้การอัปเดตมองเห็นได้สำหรับทั้งทีม
ปรับระดับความละเอียดตั้งแต่สเปกเครื่องมือภายในแบบรวดเร็วไปจนถึง PRD ฟีเจอร์แบบเต็ม ตามสิ่งที่คุณต้องการจริง ๆ
เวิร์กโฟลว์ที่ทำขึ้นเองแบบแมนนวลนั้นช้า ต้องทำด้วยมือ และพึ่งพาเครื่องมือจำนวนมาก วางเมาส์เหนือการ์ดใดก็ได้ เพื่อดูว่าทำไมแต่ละประโยชน์ถึงสำคัญ
ย้ายมาจาก ChatPRD ใช่ไหม? นี่คือจุดที่ Emma เหนือกว่า
ChatPRD สร้าง PRD ที่เรียบเรียงอย่างดีและอยู่ใน Notion ตลอดไป สเปกของ Emma จะถูกส่งต่อไปยังภาพร่างสถาปัตยกรรมของ Bob และแผนการพัฒนาของ Alex โดยตรง เอกสารที่คุณเขียนจะกลายเป็นผลิตภัณฑ์ภายในไม่กี่วัน ไม่ใช่ไตรมาสหน้า
เครื่องมือ PRD ส่วนใหญ่มักตอบตกลงกับทุกไอเดียฟีเจอร์ Emma จะถามว่า "เวอร์ชันที่เล็กที่สุดที่พิสูจน์ได้ว่าสิ่งนี้ใช้ได้คืออะไร?" และเขียนสเปกสำหรับสิ่งนั้น Scope creep จะถูกจับได้ตั้งแต่ในสเปก ไม่ใช่หลังจากที่วิศวกรรมเริ่มไปแล้ว
Notion AI อยู่ในวิกิของคุณเลย Emma ทำงานร่วมกับ Iris (research), Bob (architecture), Alex (engineering) และ Mike (approvals) ดังนั้น PRD จึงได้รับการตรวจทาน โดยทีมที่จะเป็นผู้สร้างมัน ก่อนที่คุณจะใช้เวลาสร้างไปหนึ่งชั่วโมงเสียอีก
| ฟีเจอร์ | Atoms แนะนำ | ChatPRD |
|---|---|---|
| ผลลัพธ์ | สเปกที่นำไปสู่การสร้างจริง | เอกสารที่ขัดเกลาแล้ว |
| เชื่อมต่อกับทีมวิศวกรรม | ส่งต่อให้ Alex | อยู่ใน Notion |
| มีวินัยด้านขอบเขตงานในตัว | แนวคิดแบบ v1 | ตอบตกลงกับทุกไอเดีย |
| ดึงสถาปนิกเข้ามาร่วมประเมินความเป็นไปได้ | ก่อนที่สเปกจะถูกล็อก | คุณต้องถามแยกกัน |
| เกณฑ์การยอมรับ | ต่อ user story | ต่อ user story |
Emma ไม่ได้ทำงานเพียงลำพัง นี่คือวิธีที่การส่งต่องานเกิดขึ้น เมื่อคุณสร้างร่วมกับทีมเต็มรูปแบบ
PRD ของ Emma ไปสู่ภาพร่างสถาปัตยกรรมของ Bob ได้โดยตรง ไม่มีการที่วิศวกรต้องมานั่งถอดความทีหลังว่า "PM หมายถึงอะไร?"
ดูว่าเป็นอย่างไร? Bob ใช้งานได้
Emma รับผิดชอบว่าอะไรและทำไม ส่วน Alex ลงมือสร้างว่าจะทำอย่างไร สเปกถูกแปลงเป็นโค้ดโดยไม่มีข้อมูลสูญหายตอนส่งต่องาน
ดูว่าเป็นอย่างไร? Alex ใช้งานได้Iris ตรวจสอบความเป็นไปได้ของตลาดเฉพาะกลุ่ม ส่วน Emma กำหนดขอบเขตของผลิตภัณฑ์ที่จะชนะในตลาดนั้น
ดูว่าเป็นอย่างไร? Iris ใช้งานได้ผลงานชิ้นงานที่เป็นรูปธรรมที่ Emma สร้างขึ้น และส่งตรงไปยังทีมวิศวกรรม
PRD ฉบับเต็มสำหรับหนึ่งฟีเจอร์ พร้อมปัญหา ขอบเขต เรื่องราวผู้ใช้ และเกณฑ์การยอมรับ
กำหนดว่าสิ่งใดจะรวมอยู่ใน v1 และสิ่งใดจะรอไปก่อน เพื่อให้คุณเปิดตัวสิ่งที่มีประโยชน์แทนที่จะรอความสมบูรณ์แบบ
เรื่องราวผู้ใช้พร้อมเกณฑ์การยอมรับที่ชัดเจน เพื่อให้วิศวกรของคุณนำไปพัฒนาและทดสอบได้
แบ่งฟีเจอร์ออกเป็นส่วนย่อยที่พร้อมส่งมอบ เพื่อให้แต่ละสปรินต์สร้างสิ่งที่คุณสามารถเดโมได้
PRD แบบกระชับสำหรับเครื่องมือภายในที่ต้องการขอบเขตชัดเจน แต่ไม่จำเป็นต้องเข้มงวดเท่าผลิตภัณฑ์ที่ลูกค้าใช้งาน
กำหนดความหมายของคำว่าเสร็จสมบูรณ์ก่อนเปิดตัว เพื่อไม่ให้พลาดสิ่งสำคัญในช่วงปล่อยใช้งาน
@Emma เขียน PRD สำหรับโปรแกรมแนะนำต่อสำหรับ SaaS ของเรา โดยดึงงานวิจัยกลุ่มเป้าหมายของ Iris มากำหนดปัญหา ขอบเขต สิ่งที่อยู่นอกขอบเขต และเมตริกของ v1 จากนั้นเขียน user stories พร้อม acceptance criteria ที่ Alex สามารถนำไปพัฒนาต่อได้
@Emma ฉันต้องการเปิดตัว SaaS สำหรับติดตามเวลาทำงานของฟรีแลนซ์ภายใน 4 สัปดาห์ ถามคำถามเพื่อเก็บรายละเอียดที่ถูกต้อง จากนั้นเสนอขอบเขต v1 ที่สามารถส่งมอบสิ่งที่มีประโยชน์ได้จริง พร้อมรายการที่ชัดเจนว่าสิ่งใดควรรอไว้สำหรับ v2
@Emma PRD ของระบบการแจ้งเตือนปัจจุบันมี user stories 14 เรื่อง และเรามีเวลาวิศวกรเพียง 1 สัปดาห์ ตัดให้เหลือ 3 เรื่องที่ส่งมอบคุณค่าหลัก ระบุสิ่งที่เราจะเสียไป และเขียนเอกสารใหม่
@Emma เราจะเปิดตัวโมดูลการออกใบแจ้งหนี้ในวันพฤหัสบดีหน้า เขียนเช็กลิสต์การเปิดตัวโดยครอบคลุม acceptance criteria, tracking spec ของ David, สถานะหน้าแลนดิ้งเพจของ Sarah และความพร้อมของแคมเปญของ Adrian
ไม่มีเอเจนต์คนใดทำงานลำพัง แตะเพื่อนร่วมทีมคนใดก็ได้เพื่อดูว่าพวกเขาจัดการส่วนของผลิตภัณฑ์คุณอย่างไร
ได้รับความไว้วางใจจากลูกค้าจาก
เลิกเขียน PRD ที่ไม่มีใครอ่าน ให้ Emma เขียนสเปกที่ทีม AI ของคุณนำไปสร้างใน Atoms ได้ภายในวันเดียวกัน
