Emma, AI Product Manager — AtomsEmma·Product Manager

เอเจนต์ผู้จัดการผลิตภัณฑ์ AI ที่เขียน PRD ที่คุณนำไปใช้งานได้จริง

Emma เปลี่ยนไอเดียให้เป็น PRD ที่ทีม AI ของคุณนำไปสร้างได้ภายในวันเดียวกัน ไม่ใช่สเปกที่นอนอยู่ในเอกสารตลอดสองสปรินต์

จากไอเดียสู่ฟีเจอร์ที่กำหนดขอบเขตชัดเจนได้ในการแชทครั้งเดียว

ได้รับความไว้วางใจจากบิลเดอร์ที่
ทีม AI ของคุณผู้เชี่ยวชาญ 8 คน เวิร์กโฟลว์เดียว

เหตุใด PRD จึงอยู่ในเอกสารแทนที่จะถูกส่งมอบ

  • PRD ที่ไม่มีใครนำไปพัฒนาได้จริง

    ChatPRD เขียนเอกสารที่ดูดีเรียบร้อย แต่ทีมวิศวกรของคุณยังต้องตีความใหม่ แยกเป็นทิกเก็ต และคอยตามอุดช่องโหว่ Emma เขียน PRD ที่ Alex อ่านแล้วใช้เป็นแหล่งข้อมูลหลักได้เลย โดยไม่ต้องมีชั้นการแปลความอีกต่อไป

  • สเปกกับโค้ดเริ่มไม่ตรงกันตั้งแต่วันแรก

    PRD อยู่ใน Notion โค้ดอยู่ใน GitHub และตัวโปรดักต์อยู่ในระบบจริง พอถึงสปรินต์ 2 ทั้งสามอย่างก็เล่าเรื่องคนละแบบ Emma เก็บ PRD ไว้ในเวิร์กสเปซเดียวกับโค้ด เพื่อให้มันยังคงเป็นแหล่งข้อมูลหลัก

  • ขอบเขตงานบานปลายโดยไม่มีใครเตือน

    เครื่องมือ PRD ที่ทำงานเดี่ยว ๆ จะเขียนทุกอย่างตามที่คุณขอ Emma จะเสนอขอบเขต v1 ที่เหมาะสม และคอยทักท้วงเมื่อขอบเขตเริ่มไหล แทนที่จะปล่อยให้ฟีเจอร์ที่ควรใช้เวลา 2 สัปดาห์ กลายเป็นโปรเจกต์ 2 เดือนแบบเงียบ ๆ

  • เครื่องมือรวมฟีดแบ็กที่ไม่เคยกลายเป็น PRD ได้จริง

    Productboard รวบรวมรายการฟีดแบ็กได้เป็นพันรายการ แต่การเปลี่ยนสิ่งเหล่านั้นให้เป็นสเปกที่ทีมของคุณส่งมอบได้จริง ก็ยังเป็นหน้าที่ของคนอยู่ดี Emma รับทั้งงานวิจัยของ Iris หรือไอเดียตั้งต้น แล้วเขียนเป็น user stories ที่ทีมวิศวกรนำไปพัฒนาต่อได้

หนึ่งวันกับ Emma

ตั้งแต่พรอมป์แรกของคุณไปจนถึงผลลัพธ์ที่พร้อมปล่อยใช้งาน — นี่คือวิธีที่ Emma ทำงานจริง

  1. 01

    รับทิศทางที่ผ่านการตรวจสอบแล้วจาก Iris

    Emma เริ่มจากโอกาสที่มีอยู่จริงและผ่านการตรวจสอบแล้ว — ไม่ใช่แบบ "ฉันมีไอเดียตอนอาบน้ำ"

    Iris, AI Deep Researcherส่งต่องานให้ Iris
  2. 02

    กำหนด user stories และเกณฑ์การยอมรับ

    ใครทำอะไร เมื่อไหร่ และเราจะรู้ได้อย่างไรว่ามันได้ผล? ชัดเจนพอที่วิศวกรจะนำไปสร้างได้

  3. 03

    ลดขอบเขตให้เหลือ v1 ที่ชนะได้

    จำกัดสเปกให้อยู่ที่เวอร์ชันเล็กที่สุดที่พิสูจน์สมมติฐานได้ — การขยายขอบเขตจะถูกจับได้ตรงนี้

  4. 04

    ดึง Bob และ Alex เข้ามาร่วมคุยเรื่องความเป็นไปได้

    มีการนำการแลกเปลี่ยนด้านสถาปัตยกรรมและเวลาในการ build มาพิจารณาก่อนล็อกสเปก — จึงไม่มีเรื่องไม่คาดคิดกลางทาง

    Bob, AI Architectส่งต่องานให้ Bob
  5. 05

    ล็อกสเปกและส่งต่อให้ทีมพัฒนา

    PRD จะเข้าสู่คิวการพัฒนาโดยตรง — เป็นอาร์ติแฟกต์ชิ้นเดียวกันที่ PM, ฝ่ายสถาปัตยกรรม และวิศวกรรมใช้ร่วมกัน

ทุกสิ่งที่ Emma ต้องการเพื่อส่งมอบสเปกที่ชัดเจน

เทมเพลต PRD ที่มีโครงสร้าง

ปัญหา เป้าหมาย ผู้ใช้ ขอบเขต สิ่งที่อยู่นอกขอบเขต และตัวชี้วัดความสำเร็จในรูปแบบที่สม่ำเสมอทุกครั้ง

User story พร้อมเกณฑ์การยอมรับ

แต่ละสตอรีสามารถนำไปพัฒนาและทดสอบได้ ไม่ใช่เพียงความต้องการฟีเจอร์ที่คลุมเครือ

ธงเตือนด้านขอบเขตและความเสี่ยง

Emma จะระบุข้อกำหนดที่คลุมเครือและเสนอการตัดขอบเขตสำหรับเวอร์ชัน v1 แทนการเขียนทุกอย่างที่คุณขอ

การผสานรวมงานวิจัย

ดึงข้อมูลเชิงลึกจาก Iris เมื่อมี เพื่อให้ PRD ตั้งอยู่บนข้อมูลเชิงลึกที่แท้จริง

ส่งต่องานให้ Engineer ได้โดยตรง

Alex อ่าน PRD เป็นแหล่งข้อมูลอ้างอิงหลักสำหรับการพัฒนา โดยไม่ต้องมีชั้นการแปลความ

สเปกที่อัปเดตต่อเนื่องภายในโปรเจกต์

PRD อยู่ใน Editor ถัดจากโค้ด จึงทำให้การอัปเดตมองเห็นได้สำหรับทั้งทีม

เทมเพลตแบบกระชับ

ปรับระดับความละเอียดตั้งแต่สเปกเครื่องมือภายในแบบรวดเร็วไปจนถึง PRD ฟีเจอร์แบบเต็ม ตามสิ่งที่คุณต้องการจริง ๆ

อะไรจะเปลี่ยนไปเมื่อ Emma อยู่ในทีมของคุณ

เวิร์กโฟลว์ที่ประกอบขึ้นเองแบบแมนนวลนั้นช้า ต้องใช้แรงคน และพึ่งพาเครื่องมือมากเกินไป ลากเมาส์ไปเหนือการ์ดใดก็ได้เพื่อดูว่าทำไมแต่ละประโยชน์จึงสำคัญ

ทำไมเหล่าบิลเดอร์จึงเลือก Emma แทนตัวเลือกอื่น

เปรียบเทียบกับ

ย้ายมาจาก ChatPRD ใช่ไหม? นี่คือจุดที่ Emma เหนือกว่า

01

สเปกที่นำไปสร้างได้จริง ไม่ใช่สเปกที่ถูกวางทิ้งไว้

ChatPRD สร้าง PRD ที่ขัดเกลามาอย่างดีและอยู่ใน Notion ตลอดไป สเปกของ Emma จะถูกส่งตรงไปยังภาพร่างสถาปัตยกรรมของ Bob และแผนพัฒนาของ Alex — เอกสารที่คุณเขียนจะกลายเป็นผลิตภัณฑ์ได้ภายในไม่กี่วัน ไม่ใช่ไตรมาสหน้า

02

ควบคุมขอบเขตงานไว้ ไม่ปล่อยให้บานปลาย

เครื่องมือ PRD ส่วนใหญ่มักตอบรับทุกไอเดียฟีเจอร์ Emma จะถามว่า "เวอร์ชันที่เล็กที่สุดซึ่งพิสูจน์ได้ว่าสิ่งนี้ใช้ได้คืออะไร?" แล้วเขียนสเปกสำหรับสิ่งนั้น ปัญหาขอบเขตงานบานปลายจึงถูกจับได้ตั้งแต่ในสเปก ไม่ใช่หลังจากทีมวิศวกรรมเริ่มงานไปแล้ว

03

เชื่อมต่อกับทีมที่ส่งมอบงาน

Notion AI อยู่ในวิกิของคุณ Emma ทำงานร่วมกับ Iris (research), Bob (architecture), Alex (engineering) และ Mike (approvals) — ดังนั้น PRD จึงได้รับการตรวจทานโดยทีมที่จะลงมือสร้างมัน ก่อนที่คุณจะใช้เวลาวิศวกรรมไปแม้แต่ชั่วโมงเดียว

Atoms เทียบกับ ChatPRD: เปรียบเทียบฟีเจอร์ ราคา และความสามารถ

ฟีเจอร์
Atoms
แนะนำ
ChatPRD
ผลลัพธ์
สเปกที่นำไปสร้างได้จริง
เอกสารที่ขัดเกลาแล้ว
เชื่อมต่อกับทีมวิศวกรรม
ส่งต่องานให้ Alex
อยู่ใน Notion
มีวินัยด้านขอบเขตงานในตัว
แนวคิดแบบ v1
ตอบรับทุกไอเดีย
ดึงสถาปนิกเข้ามาร่วมประเมินความเป็นไปได้
ก่อนล็อกสเปก
คุณต้องถามแยกกัน
เกณฑ์การยอมรับ
ต่อเรื่องราวผู้ใช้
ต่อเรื่องราวผู้ใช้

Emma ทำงานร่วมกับทีม AI ที่เหลือของคุณอย่างไร

Emma ไม่ได้ทำงานเพียงลำพัง นี่คือวิธีที่การส่งต่องานเกิดขึ้นเมื่อคุณสร้างร่วมกับทีมครบชุด

เอ็มมาเขียนอะไรให้ทีมผลิตภัณฑ์

ผลงานชิ้นงานที่เป็นรูปธรรมที่ Emma สร้างขึ้น และส่งตรงไปยังทีมวิศวกรรม

  1. PRD ฟีเจอร์

    PRD ฉบับเต็มสำหรับหนึ่งฟีเจอร์ พร้อมปัญหา ขอบเขต เรื่องราวผู้ใช้ และเกณฑ์การยอมรับ

    เขียน PRD ฟีเจอร์
  2. เอกสารกำหนดขอบเขต MVP

    กำหนดว่าสิ่งใดจะรวมอยู่ใน v1 และสิ่งใดจะรอไปก่อน เพื่อให้คุณเปิดตัวสิ่งที่มีประโยชน์แทนที่จะรอความสมบูรณ์แบบ

    กำหนดขอบเขต MVP
  3. ชุดเรื่องราวผู้ใช้

    เรื่องราวผู้ใช้พร้อมเกณฑ์การยอมรับที่ชัดเจน เพื่อให้วิศวกรของคุณนำไปพัฒนาและทดสอบได้

    เขียนเรื่องราวผู้ใช้
  4. การกำหนดขอบเขตสปรินต์

    แบ่งฟีเจอร์ออกเป็นส่วนย่อยที่พร้อมส่งมอบ เพื่อให้แต่ละสปรินต์สร้างสิ่งที่คุณสามารถเดโมได้

    กำหนดขอบเขตสปรินต์
  5. สเปกเครื่องมือภายใน

    PRD แบบกระชับสำหรับเครื่องมือภายในที่ต้องการขอบเขตชัดเจน แต่ไม่จำเป็นต้องเข้มงวดเท่าผลิตภัณฑ์ที่ลูกค้าใช้งาน

    กำหนดขอบเขตเครื่องมือ
  6. เช็กลิสต์การเปิดตัว

    กำหนดความหมายของคำว่าเสร็จสมบูรณ์ก่อนเปิดตัว เพื่อไม่ให้พลาดสิ่งสำคัญในช่วงปล่อยใช้งาน

    วางแผนการเปิดตัว

ลองใช้พร้อมต์เหล่านี้กับ Emma

เขียน PRD สำหรับฟีเจอร์ใหม่

@Emma เขียน PRD สำหรับโปรแกรมแนะนำต่อสำหรับ SaaS ของเรา โดยดึงงานวิจัยกลุ่มเป้าหมายของ Iris มากำหนดปัญหา ขอบเขต สิ่งที่อยู่นอกขอบเขต และเมตริกของ v1 จากนั้นเขียน user stories พร้อม acceptance criteria ที่ Alex สามารถนำไปพัฒนาต่อได้

กำหนดขอบเขต MVP จากประโยคเดียว

@Emma ฉันต้องการเปิดตัว SaaS สำหรับติดตามเวลาทำงานของฟรีแลนซ์ภายใน 4 สัปดาห์ ถามคำถามเพื่อเก็บรายละเอียดที่ถูกต้อง จากนั้นเสนอขอบเขต v1 ที่สามารถส่งมอบสิ่งที่มีประโยชน์ได้จริง พร้อมรายการที่ชัดเจนว่าสิ่งใดควรรอไว้สำหรับ v2

ตัดฟีเจอร์ที่ขอบเขตกว้างเกินไป

@Emma PRD ของระบบการแจ้งเตือนปัจจุบันมี user stories 14 เรื่อง และเรามีเวลาวิศวกรเพียง 1 สัปดาห์ ตัดให้เหลือ 3 เรื่องที่ส่งมอบคุณค่าหลัก ระบุสิ่งที่เราจะเสียไป และเขียนเอกสารใหม่

วางแผนเช็กลิสต์การเปิดตัว

@Emma เราจะเปิดตัวโมดูลการออกใบแจ้งหนี้ในวันพฤหัสบดีหน้า เขียนเช็กลิสต์การเปิดตัวโดยครอบคลุม acceptance criteria, tracking spec ของ David, สถานะหน้าแลนดิ้งเพจของ Sarah และความพร้อมของแคมเปญของ Adrian

พบกับสมาชิกทีม AI คนอื่น ๆ ของ Emma

ไม่มีเอเจนต์คนไหนทำงานลำพัง แตะเพื่อนร่วมทีมคนใดก็ได้เพื่อดูว่าพวกเขาจัดการส่วนของผลิตภัณฑ์ของคุณอย่างไร

คำถามที่พบบ่อย

ให้ Emma เริ่มทำงาน

เลิกเขียน PRD ที่ไม่มีใครอ่าน ให้ Emma เขียนสเปกที่ทีม AI ของคุณนำไปสร้างใน Atoms ได้ภายในวันเดียวกัน