Emma·Product ManagerEmma เปลี่ยนไอเดียให้เป็น PRD ที่ทีม AI ของคุณนำไปสร้างได้ภายในวันเดียวกัน ไม่ใช่สเปกที่นอนอยู่ในเอกสารตลอดสองสปรินต์
จากไอเดียสู่ฟีเจอร์ที่กำหนดขอบเขตชัดเจนได้ในการแชทครั้งเดียว
PRD อยู่ใน Notion โค้ดอยู่ใน GitHub และตัวโปรดักต์อยู่ในระบบจริง พอถึงสปรินต์ 2 ทั้งสามอย่างก็เล่าเรื่องคนละแบบ Emma เก็บ PRD ไว้ในเวิร์กสเปซเดียวกับโค้ด เพื่อให้มันยังคงเป็นแหล่งข้อมูลหลัก
เครื่องมือ PRD ที่ทำงานเดี่ยว ๆ จะเขียนทุกอย่างตามที่คุณขอ Emma จะเสนอขอบเขต v1 ที่เหมาะสม และคอยทักท้วงเมื่อขอบเขตเริ่มไหล แทนที่จะปล่อยให้ฟีเจอร์ที่ควรใช้เวลา 2 สัปดาห์ กลายเป็นโปรเจกต์ 2 เดือนแบบเงียบ ๆ
Productboard รวบรวมรายการฟีดแบ็กได้เป็นพันรายการ แต่การเปลี่ยนสิ่งเหล่านั้นให้เป็นสเปกที่ทีมของคุณส่งมอบได้จริง ก็ยังเป็นหน้าที่ของคนอยู่ดี Emma รับทั้งงานวิจัยของ Iris หรือไอเดียตั้งต้น แล้วเขียนเป็น user stories ที่ทีมวิศวกรนำไปพัฒนาต่อได้
ตั้งแต่พรอมป์แรกของคุณไปจนถึงผลลัพธ์ที่พร้อมปล่อยใช้งาน — นี่คือวิธีที่ Emma ทำงานจริง
Emma เริ่มจากโอกาสที่มีอยู่จริงและผ่านการตรวจสอบแล้ว — ไม่ใช่แบบ "ฉันมีไอเดียตอนอาบน้ำ"
ส่งต่องานให้ Irisใครทำอะไร เมื่อไหร่ และเราจะรู้ได้อย่างไรว่ามันได้ผล? ชัดเจนพอที่วิศวกรจะนำไปสร้างได้
จำกัดสเปกให้อยู่ที่เวอร์ชันเล็กที่สุดที่พิสูจน์สมมติฐานได้ — การขยายขอบเขตจะถูกจับได้ตรงนี้
มีการนำการแลกเปลี่ยนด้านสถาปัตยกรรมและเวลาในการ build มาพิจารณาก่อนล็อกสเปก — จึงไม่มีเรื่องไม่คาดคิดกลางทาง
ส่งต่องานให้ BobPRD จะเข้าสู่คิวการพัฒนาโดยตรง — เป็นอาร์ติแฟกต์ชิ้นเดียวกันที่ PM, ฝ่ายสถาปัตยกรรม และวิศวกรรมใช้ร่วมกัน
ปัญหา เป้าหมาย ผู้ใช้ ขอบเขต สิ่งที่อยู่นอกขอบเขต และตัวชี้วัดความสำเร็จในรูปแบบที่สม่ำเสมอทุกครั้ง
แต่ละสตอรีสามารถนำไปพัฒนาและทดสอบได้ ไม่ใช่เพียงความต้องการฟีเจอร์ที่คลุมเครือ
Emma จะระบุข้อกำหนดที่คลุมเครือและเสนอการตัดขอบเขตสำหรับเวอร์ชัน v1 แทนการเขียนทุกอย่างที่คุณขอ
ดึงข้อมูลเชิงลึกจาก Iris เมื่อมี เพื่อให้ PRD ตั้งอยู่บนข้อมูลเชิงลึกที่แท้จริง
Alex อ่าน PRD เป็นแหล่งข้อมูลอ้างอิงหลักสำหรับการพัฒนา โดยไม่ต้องมีชั้นการแปลความ
PRD อยู่ใน Editor ถัดจากโค้ด จึงทำให้การอัปเดตมองเห็นได้สำหรับทั้งทีม
ปรับระดับความละเอียดตั้งแต่สเปกเครื่องมือภายในแบบรวดเร็วไปจนถึง PRD ฟีเจอร์แบบเต็ม ตามสิ่งที่คุณต้องการจริง ๆ
เวิร์กโฟลว์ที่ประกอบขึ้นเองแบบแมนนวลนั้นช้า ต้องใช้แรงคน และพึ่งพาเครื่องมือมากเกินไป ลากเมาส์ไปเหนือการ์ดใดก็ได้เพื่อดูว่าทำไมแต่ละประโยชน์จึงสำคัญ
ย้ายมาจาก ChatPRD ใช่ไหม? นี่คือจุดที่ Emma เหนือกว่า
ChatPRD สร้าง PRD ที่ขัดเกลามาอย่างดีและอยู่ใน Notion ตลอดไป สเปกของ Emma จะถูกส่งตรงไปยังภาพร่างสถาปัตยกรรมของ Bob และแผนพัฒนาของ Alex — เอกสารที่คุณเขียนจะกลายเป็นผลิตภัณฑ์ได้ภายในไม่กี่วัน ไม่ใช่ไตรมาสหน้า
เครื่องมือ PRD ส่วนใหญ่มักตอบรับทุกไอเดียฟีเจอร์ Emma จะถามว่า "เวอร์ชันที่เล็กที่สุดซึ่งพิสูจน์ได้ว่าสิ่งนี้ใช้ได้คืออะไร?" แล้วเขียนสเปกสำหรับสิ่งนั้น ปัญหาขอบเขตงานบานปลายจึงถูกจับได้ตั้งแต่ในสเปก ไม่ใช่หลังจากทีมวิศวกรรมเริ่มงานไปแล้ว
Notion AI อยู่ในวิกิของคุณ Emma ทำงานร่วมกับ Iris (research), Bob (architecture), Alex (engineering) และ Mike (approvals) — ดังนั้น PRD จึงได้รับการตรวจทานโดยทีมที่จะลงมือสร้างมัน ก่อนที่คุณจะใช้เวลาวิศวกรรมไปแม้แต่ชั่วโมงเดียว
| ฟีเจอร์ | Atoms แนะนำ | ChatPRD |
|---|---|---|
| ผลลัพธ์ | สเปกที่นำไปสร้างได้จริง | เอกสารที่ขัดเกลาแล้ว |
| เชื่อมต่อกับทีมวิศวกรรม | ส่งต่องานให้ Alex | อยู่ใน Notion |
| มีวินัยด้านขอบเขตงานในตัว | แนวคิดแบบ v1 | ตอบรับทุกไอเดีย |
| ดึงสถาปนิกเข้ามาร่วมประเมินความเป็นไปได้ | ก่อนล็อกสเปก | คุณต้องถามแยกกัน |
| เกณฑ์การยอมรับ | ต่อเรื่องราวผู้ใช้ | ต่อเรื่องราวผู้ใช้ |
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 ได้ภายในวันเดียวกัน
