กลับไปที่คลังพรอมป์
คลังพรอมป์พรอมป์แชต

กำหนดขอบเขตข้อกำหนดผลิตภัณฑ์

แปลงไอเดียฟีเจอร์ให้เป็นร่างข้อกำหนดผลิตภัณฑ์ที่มีขอบเขตชัดเจน พร้อมเป้าหมาย สิ่งที่ไม่ทำ edge case และแผน rollout

PRDควบคุมขอบเขตข้อกำหนดผลิตภัณฑ์
ตัวอย่าง

พรอมป์แชต

โมเดลแนะนำ

Claude Sonnet 4.6

รูปแบบผลลัพธ์

PRD ที่กำหนดขอบเขตแล้ว

ตัวอย่าง

พรอมป์แชต

เธรดแชต

เราต้องการให้ผู้ใช้บันทึกพรอมป์โปรด ช่วยร่าง PRD ที่มีขอบเขตชัดเจนโดยไม่ทำให้กลายเป็นโปรเจกต์ใหญ่

Problem: ผู้ใช้สูญเสียพรอมป์ที่นำกลับมาใช้ซ้ำได้หลังจากค้นพบแล้ว Goal: บันทึกและเปิด prompt templates ที่ชื่นชอบอีกครั้งได้ Non-goals: โฟลเดอร์ การแชร์ในทีม การจัดอันดับ และ marketplace พรอมป์กำหนดเอง Requirements: ปุ่ม favorite รายการที่บันทึกไว้ empty state และ analytics events Open questions: ขีดจำกัด สถานะ auth และตำแหน่งบนมือถือ

ผลลัพธ์

ปัญหา / เป้าหมาย / non-goals / requirements / edge cases / rollout / tradeoffs

เหมาะสำหรับการกำหนดขอบเขตฟีเจอร์ สเปกผลิตภัณฑ์ และการส่งต่อให้วิศวกรรม

พรอมป์เต็ม

กำหนดขอบเขตข้อกำหนดผลิตภัณฑ์

พรอมป์ข้อกำหนดผลิตภัณฑ์สำหรับเปลี่ยนไอเดียฟีเจอร์เป็นร่าง PRD ที่มีขอบเขตชัดเจน

โมเดลแนะนำ: Claude Sonnet 4.6รูปแบบผลลัพธ์: PRD ที่กำหนดขอบเขตแล้ว
พรอมป์เต็ม
พรอมป์แชต
คุณคือผู้จัดการผลิตภัณฑ์ แปลงไอเดียฟีเจอร์ของผู้ใช้ให้เป็นร่างข้อกำหนดผลิตภัณฑ์ที่มีขอบเขตชัดเจน โดยมีส่วนเหล่านี้: Problem, User story, Goals, Non-goals, Core requirements, Edge cases, Analytics events, Rollout plan, Open questions และ Explicit tradeoffs ทำเวอร์ชันแรกให้แคบและพร้อมนำไปพัฒนา

หมายเหตุการใช้งาน

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

FAQ ของพรอมป์

ก่อนใช้พรอมป์นี้

ตรวจสอบอย่างรวดเร็วเรื่องอินพุต ความเหมาะของโมเดล และวิธีปรับเทมเพลตโดยไม่ทำให้ผลลัพธ์อ่อนลง

ควรใช้ Product Requirements Scope เมื่อใด

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

ควรปรับแต่งอะไรก่อนใช้งาน

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

ตัวอย่างเธรด

เราต้องการให้ผู้ใช้บันทึกพรอมป์โปรด ช่วยร่าง PRD ที่มีขอบเขตชัดเจนโดยไม่ทำให้กลายเป็นโปรเจกต์ใหญ่
Problem: ผู้ใช้สูญเสียพรอมป์ที่นำกลับมาใช้ซ้ำได้หลังจากค้นพบแล้ว Goal: บันทึกและเปิด prompt templates ที่ชื่นชอบอีกครั้งได้ Non-goals: โฟลเดอร์ การแชร์ในทีม การจัดอันดับ และ marketplace พรอมป์กำหนดเอง Requirements: ปุ่ม favorite รายการที่บันทึกไว้ empty state และ analytics events Open questions: ขีดจำกัด สถานะ auth และตำแหน่งบนมือถือ

ผลลัพธ์

ปัญหา / เป้าหมาย / non-goals / requirements / edge cases / rollout / tradeoffs

พรอมป์เพิ่มเติมในโหมดนี้

เธรดแชต

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

สมมติฐานปัญหา: ทีมอีคอมเมิร์ซขนาดเล็กเสียเวลาในการเปลี่ยนภาพสินค้าดิบให้เป็นแอสเซ็ตแคมเปญพร้อมใช้ในแต่ละช่องทาง สมมติฐานที่เสี่ยงที่สุด: คุณภาพภาพสูงพอ ทีมเชื่อถือการสร้างรูปแบบแอสเซ็ตด้วย AI และเวลาตรวจทานคือคอขวดจริง คำถามวิจัย: ใครเป็นเจ้าของการสร้างแอสเซ็ตแคมเปญ การแก้ไขติดขัดตรงไหน และมาตรฐานคุณภาพใดที่ขวางการเผยแพร่ แผนตรวจสอบ: สัมภาษณ์ operator 5 คน ทดสอบ flow สร้างแอสเซ็ตด้วยพรอมป์ต์ 3 แบบ และเปรียบเทียบเวลาจนได้แอสเซ็ตที่อนุมัติครั้งแรก เกตตัดสินใจ: ไปต่อเฉพาะเมื่อทีมสามารถได้ดราฟต์ที่เผยแพร่ได้เร็วกว่ากระบวนการปัจจุบัน

เธรดแชต

เรากำลังสำรวจผลิตภัณฑ์โน้ต AI ใหม่สำหรับที่ปรึกษาเดี่ยว ช่วยเปลี่ยนเรื่องนี้ให้เป็นบรีฟวิจัย

วัตถุประสงค์: ระบุว่าที่ปรึกษาเดี่ยวต้องการ workspace โน้ต AI หรือเลเยอร์ติดตามลูกค้าที่เบากว่า สมมติฐานที่ใช้ทำงาน: พวกเขาจดโน้ตอยู่แล้ว แต่การสังเคราะห์และร่างขั้นตอนถัดไปยังไม่สม่ำเสมอ กลุ่มเป้าหมาย: ที่ปรึกษาเดี่ยวที่มีสายคุยลูกค้าซ้ำและมีซัพพอร์ตด้านปฏิบัติการจำกัด คำถามหลัก: โน้ตแบบใดกลายเป็นงานที่คิดเงินได้ อะไรตกหล่นหลังการคุย และเครื่องมือ CRM หนักเกินไปตรงไหน แผนวิจัย: สัมภาษณ์ 6 คน ทบทวนเวิร์กโฟลว์โน้ตการโทรล่าสุด 10 ชุด และทดสอบต้นแบบบรีฟติดตามผลหนึ่งแบบ

เธรดแชต

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

คำมั่นหลัก: มองเห็นได้แล้ว แต่ยังถูกวางกรอบเหมือนฟีเจอร์มากกว่าผลลัพธ์ที่เป็นรูปธรรมสำหรับผู้ใช้ จุดที่ไม่ชัดเจน: หน้าเว็บยังไม่ได้อธิบายว่าใครจะได้รับคุณค่าก่อน และเวิร์กโฟลว์จะเปลี่ยนไปอย่างไรหลังสมัครใช้งาน ช่องว่างของตัวอย่าง: เพิ่มตัวอย่างก่อน-หลัง ตัวอย่างผลลัพธ์จากโมเดล และสัญญาณความน่าเชื่อถือสั้นๆ ใกล้ส่วน Hero ปัญหา CTA: การกระทำหลักปรากฏหลังคำอธิบายมากเกินไป ควรย้าย CTA ที่เน้นการใช้งานให้เข้าใกล้ส่วนเริ่มใช้เร็ว แผนแก้ไข: ทำให้ Hero คมขึ้น เพิ่มการ์ดผลลัพธ์ แล้วเขียนส่วนจัดการข้อโต้แย้งใหม่ก่อนขัดเกลาภาพ