Project Intake ไม่ใช่เอกสารรายละเอียดฉบับสมบูรณ์ แต่เป็นข้อตกลงว่ารุ่นแรกกำลังช่วยใคร ในสถานการณ์ใด จะทำให้ชีวิตเขาดีขึ้นอย่างไร และเราจะตรวจได้อย่างไรว่างานไปถูกทาง ใช้เวลาร่าง 15–20 นาที แล้วอธิบายให้คนอื่นฟังภายใน 60 วินาที
ตัวอย่างที่ทำเสร็จแล้ว: ProudVault
1. Primary user
- คนที่ซื้อและสะสมหนังสือของตัวเอง
2. Trigger moment และ pain
- Trigger moment: ยืนอยู่ในร้านหนังสือและกำลังตัดสินใจซื้อ
- Pain: จำไม่ได้ว่ามีหนังสือเล่มนี้อยู่แล้วหรือยัง จึงเสียเวลาค้นหรือซื้อซ้ำ
- Current workaround: พยายามจำ ค้นรูปในโทรศัพท์ หรือยอมเสี่ยงซื้อไปก่อน
3. Desired outcome
ตรวจได้ทันทีว่าหนังสือเล่มนี้อยู่ในชั้นของตัวเองหรือไม่ แล้วตัดสินใจซื้อได้อย่างมั่นใจ
Problem statement
เมื่อเจ้าของหนังสือกำลังตัดสินใจซื้อ เขาต้องการค้นชั้นหนังสือของตัวเองจากชื่อหรือ ISBN เพื่อรู้ว่ามีเล่มนี้แล้วหรือยัง โดยไม่ต้องพึ่งความจำ
4. Primary Success Path
Product หนึ่งมี Success Path ได้หลายเส้น แต่ Project Intake นี้ลงรายละเอียดเพียง Primary Success Path ที่พิสูจน์คุณค่าหลักของรุ่นแรกก่อน เส้นนี้เรียงตามลำดับที่ผู้ใช้ได้รับคุณค่า ไม่ใช่ลำดับการพัฒนา
เลือกก่อนว่าอะไรคือผลลัพธ์สำคัญของผู้ใช้ เพื่อไม่ให้หลงสร้างสิ่งที่ไม่จำเป็น — แต่ตอนพัฒนา เราอาจต้องเริ่มจากระบบพื้นฐานหรือเส้นทางสนับสนุนที่ผลลัพธ์นั้นต้องพึ่ง
- ผู้ใช้เห็นหนังสือที่สนใจในร้าน
- ค้นหาด้วยชื่อหนังสือหรือ ISBN
- เห็นผลว่า “มีแล้ว”
- ตัดสินใจไม่ซื้อหนังสือซ้ำ
End state: ผู้ใช้ตัดสินใจไม่ซื้อหนังสือที่มีอยู่แล้วได้อย่างมั่นใจ
5. รุ่นแรกต้องมี
Must-have คือสิ่งที่ถ้าตัดออกแล้ว Primary Path จะไปไม่ถึงผลลัพธ์
- Primary Path: ค้นด้วยชื่อหรือ ISBN — ทำให้ตรวจเล่มที่กำลังตัดสินใจซื้อได้
- Primary Path: เห็นผลว่ามีเล่มนี้อยู่แล้วหรือยัง — เป็นคำตอบที่ใช้ตัดสินใจ
- Precondition: มี account และเข้าสู่ระบบแล้ว — ทำให้ระบบรู้ว่ากำลังตรวจชั้นของใคร
- Supporting path: เพิ่มหนังสือที่ยังไม่มี — เตรียมข้อมูลให้การค้นครั้งต่อไป
- Enabling work: แยกข้อมูลตามเจ้าของ — ป้องกันข้อมูลข้ามผู้ใช้
6. ตั้งใจยังไม่ทำ
Non-goals เป็นไอเดียที่มีประโยชน์แต่รุ่นแรกยังพิสูจน์คุณค่าได้โดยไม่มีมัน ไม่ได้แปลว่าจะไม่มีวันทำ
- Recommendation — ยังไม่จำเป็นต่อการตอบว่า “มีเล่มนี้แล้วหรือยัง”
- Social feed หรือ review community — เป็นผลลัพธ์อีกเรื่องหนึ่ง
- การยืมคืนระหว่างเพื่อน — ต้องมีกฎและเส้นทางยืมคืนแยก
- AI import — ช่วยกรอกเร็วขึ้น แต่รุ่นแรกเพิ่มเองได้
- Native mobile app — web app บนมือถือพิสูจน์ flow แรกได้ก่อน
7. ถ้าระบบผิดพลาด อะไรอาจเสียหาย
- Risk 1 · Primary outcome: ผลค้นหาอาจบอก “ยังไม่มี” ทั้งที่มีอยู่ หรือบอก “มีแล้ว” ทั้งที่ไม่มี ทำให้ผู้ใช้ตัดสินใจผิดและอาจซื้อซ้ำ
- Risk 2 · ความเสี่ยงสำคัญ: Account A อาจเห็นหรือแก้ชั้นหนังสือของ Account B ทำให้ข้อมูลข้ามผู้ใช้
8. Evidence ว่ารุ่นแรกสำเร็จ
Evidence ของ ProudVault เป็นตัวอย่างวิธีคิด ไม่ใช่รายการที่ project อื่นควรคัดลอก:
- Risk 1 → Evidence 1: เตรียมหนังสือตัวอย่างที่รู้แน่ว่ามีและไม่มี แล้วค้นด้วยชื่อและ ISBN ผลต้องแสดง “มีแล้ว” และ “ยังไม่มี” ตรงกับข้อมูลจริง หลักฐานนี้พิสูจน์ Primary outcome ด้วย
- Risk 2 → Evidence 2: Account A ต้องเปิดดูหรือแก้ข้อมูลของ Account B ไม่ได้ ทั้งผ่าน flow ปกติและการเข้าถึงรายการโดยตรง
ในขั้นนี้ยังไม่ต้องมีผลทดสอบจริง เพียงนิยามให้ชัดว่า Evidence แบบใดจึงนับ ตัวอย่าง ProudVault ไม่มีความเสี่ยงสำคัญที่ยังหาวิธีพิสูจน์ไม่ได้ เพราะทั้งสองข้อกำหนด Evidence ได้แล้ว ส่วนการเก็บผลทดสอบจริงจะเกิดขึ้นหลังสร้างระบบ
จาก Risk กว้าง ๆ ไปสู่ Evidence ที่ตรวจได้
- กว้างเกินไป: ข้อมูลต้องปลอดภัย
- เฉพาะเจาะจงและสังเกตได้: Account A ต้องไม่เห็นหรือแก้ชั้นหนังสือของ Account B
- นิยาม Evidence ได้: ทดลองเปิดดูและแก้รายการของ Account B ด้วย Account A ทั้งผ่าน flow ปกติและการเข้าถึงรายการโดยตรง แล้วต้องทำไม่ได้ทุกกรณี
สรุปตัวอย่าง ProudVault ภายใน 60 วินาที
เรากำลังสร้าง ProudVault สำหรับคนที่ซื้อและสะสมหนังสือ เพื่อใช้ตอนยืนอยู่ในร้านและไม่แน่ใจว่าเคยซื้อเล่มที่สนใจแล้วหรือยัง เขาจะตรวจชั้นหนังสือของตัวเองและตัดสินใจได้อย่างมั่นใจ รุ่นแรกจะพาเขาค้นด้วยชื่อหรือ ISBN เห็นสถานะว่ามีเล่มนั้นแล้วหรือยัง และตัดสินใจไม่ซื้อซ้ำ จึงต้องมี account ชั้นหนังสือที่แยกตามเจ้าของ การเพิ่มหนังสือ และการค้นหา แต่ยังไม่ทำระบบแนะนำ social feed การยืมคืน AI import หรือ native mobile app ความเสี่ยงหลักคือผลค้นหาอาจผิดและข้อมูลอาจข้ามผู้ใช้ เราจะถือว่ารุ่นแรกผ่านเมื่อหนังสือตัวอย่างที่รู้สถานะคืนผลถูกต้อง และ Account A ไม่สามารถดูหรือแก้รายการของ Account B ได้
สร้าง Project Intake ของคุณ
กรอกทีละส่วนให้คำตอบทั้ง 8 ข้อต่อกันเป็นเรื่องเดียว ไม่ต้องเขียนให้สวยตั้งแต่รอบแรก คำตอบจะบันทึกไว้เฉพาะใน browser เครื่องนี้ และจะไม่ถูกส่งขึ้น server