MVP ที่ผมพูดถึงวันนี้ ไม่ใช่ Most Valuable Player
แต่มันคือ Minimum Viable Product
และผมคิดว่ามันกำลังกลับมาสำคัญมากขึ้นในยุค Vibe Coding
ไม่ใช่เพราะการสร้าง Software ยากขึ้น
แต่เพราะมัน ง่ายขึ้นมาก
วันนี้นักการตลาดที่ไม่ใช่ Developer ก็สามารถใช้ AI Coding Tools ช่วยสร้าง Landing Page, Internal Tool, Dashboard หรือแม้แต่ Application ได้เร็วกว่าเมื่อก่อนมาก
ตลาดของเครื่องมือกลุ่มนี้ก็เติบโตขึ้นจริง ทั้ง Cursor, Lovable, Replit และเครื่องมือ AI App Building อื่น ๆ กำลังทำให้การสร้าง Software เข้าถึงคนที่ไม่ได้มีพื้นฐาน Engineering มากขึ้น
แต่ตรงนี้เองที่ผมคิดว่าเราต้องระวัง
เพราะเมื่อ Build ง่ายขึ้น
เราอาจไม่ได้สร้างสิ่งที่ดีขึ้น
เราอาจแค่สร้าง สิ่งที่ไม่ควรถูกสร้างเร็วขึ้น
เมื่อก่อน Software มี Constraint ที่ AI กำลังเอาออกไป
ลองนึกภาพการทำ Software เมื่อก่อน
อยากเพิ่ม Feature หนึ่งอย่าง ต้องคุยกับ Developer
ต้อง Estimate
ต้องเข้า Sprint
ต้องเขียน Code
ต้อง Test
ต้อง Deploy
แค่คิดจะเพิ่ม Feature ก็มี “ต้นทุน” บางอย่างมาขวางเราไว้แล้ว
ต้นทุนเหล่านี้บางครั้งน่ารำคาญมาก
แต่ในอีกมุมหนึ่ง มันทำหน้าที่เหมือน แรงเสียดทาน
มันบังคับให้คนทำ Product ถามว่า
“Feature นี้จำเป็นจริงไหม?”
วันนี้สถานการณ์เปลี่ยนไป
AI Coding ทำให้การเพิ่ม Feature หลายอย่างง่ายขึ้นมาก
อยากเพิ่ม Form ก็ Prompt
อยากเพิ่ม Dashboard ก็ Prompt
อยากเพิ่ม Login ก็ Prompt
อยากเพิ่ม Workflow ก็ Prompt
อยากให้ AI Refactor Code ก็ Prompt
และนี่คือสิ่งที่ผมว่าน่าสนใจ
เมื่อการ Build ถูกลง เรามีโอกาส Build เยอะขึ้นโดยไม่รู้ตัว
Research ที่ผมใช้ประกอบบทความนี้พบประเด็นเดียวกันว่า AI Coding Tools สามารถลดแรงเสียดทานในการเพิ่ม Feature จนแต่ละ Feature ดูเหมือน “ถูกพอที่จะทำ” แต่เมื่อสะสมกัน Product กลับขยายออกจาก Scope เดิมอย่างรวดเร็ว
ปัญหาจึงไม่ได้เกิดจาก AI สร้าง Code ไม่เก่ง
แต่เกิดจาก
AI สร้างสิ่งที่เราไม่ควรสร้างได้เร็วเกินไป
MVP คืออะไร และทำไมมันไม่ใช่ Product เวอร์ชันกาก ๆ
ถ้าคุณเคยได้ยินคำว่า MVP มาก่อน คุณอาจเข้าใจว่า
MVP = Product ที่มี Feature น้อยที่สุด
ผมว่าความเข้าใจนี้ไม่ผิดทั้งหมด
แต่ ยังไม่ถึงแก่น
MVP ไม่ได้ถูกสร้างขึ้นมาเพื่อให้เราได้ Product ที่ “เล็ก”
มันถูกสร้างขึ้นมาเพื่อให้เราได้ Learning ที่เร็ว
Eric Ries อธิบาย MVP ว่าเป็น Version ของ Product ที่ทำให้ทีมสามารถเก็บ Validated Learning จากลูกค้าได้มากที่สุดด้วยความพยายามน้อยที่สุด
และกฎที่ผมชอบมากคือแนวคิดของ Ries ที่ว่า Feature, Process หรือ Effort ใดก็ตามที่ไม่ได้ช่วยให้เราเรียนรู้สิ่งที่ต้องการพิสูจน์ ก็ควรถูกตัดออก
นี่ทำให้คำว่า Minimum เปลี่ยนความหมายไปเลย
Minimum ไม่ได้แปลว่า
“ทำให้น้อยที่สุด”
แต่คือ
“ทำเท่าที่จำเป็นต่อการเรียนรู้”
สองประโยคนี้ดูคล้ายกัน
แต่เวลาเอาไปทำ Product จริง ต่างกันมาก
เป้าหมายของ MVP ไม่ใช่ Product แต่คือ Learning
ผมชอบคิดแบบนี้
สมมติเรามี Idea หนึ่ง
เราเชื่อว่า
“ถ้าสร้าง App นี้ขึ้นมา คนจะใช้”
ประโยคนี้ยังไม่ใช่ Fact
มันคือ Hypothesis
และปัญหาคือหลายทีมเอา Hypothesis ไปปฏิบัติเหมือนมันเป็น Fact
จากนั้นก็เริ่ม Build
เดือนที่ 1 — Build
เดือนที่ 2 — Build
เดือนที่ 3 — เพิ่ม Feature
เดือนที่ 4 — แก้ UX
เดือนที่ 5 — เพิ่มระบบหลังบ้าน
เดือนที่ 6 — Launch
แล้วค่อยพบว่า
ไม่มีใครใช้
สิ่งที่เสียไปไม่ใช่แค่เงิน
แต่คือเวลา
Opportunity
แรงของทีม
และที่สำคัญคือ เวลาในการเรียนรู้
Steve Blank จึงเน้นเรื่องการ Validate สมมติฐานกับลูกค้าจริง และชี้ว่า Product ที่สร้างในช่วงแรกควรมีเป้าหมายเพื่อทดสอบ Product/Market Fit ไม่ใช่เพียงสร้าง Product ให้เสร็จ
เพราะฉะนั้นก่อนถามว่า
“เราสร้าง App นี้ได้ไหม?”
ผมว่าคำถามที่สำคัญกว่าคือ
“เราจะพิสูจน์ได้อย่างไรว่า App นี้ควรถูกสร้าง?”
นี่คือจุดที่ MVP เข้ามา
Evolution แทน Completion
เวลาทำ Product ผมชอบคิดเป็น Flow แบบนี้
Idea
สิ่งที่เราเชื่อว่าน่าจะมีคนต้องการ
↓
POC
พิสูจน์ว่าแนวคิดนี้ทำได้จริง
↓
MVP Phase 1
สร้าง Minimum ที่มากพอให้คนจริงได้ลอง
↓
User Feedback
เรียนรู้จากการใช้งานจริง
↓
MVP Phase 2
เพิ่มสิ่งที่หลักฐานบอกว่าควรเพิ่ม
↓
MVP Phase 3
เรียนรู้เพิ่มเติมและปรับ Product
↓
Complete Product
เมื่อความมั่นใจมากพอ จึงค่อยขยาย Product ให้สมบูรณ์
ผมเรียกวิธีคิดนี้ว่า
Evolution แทน Completion
มันต่างจากการคิดแบบเดิมอย่างไร?
Completion คิดว่า
“เราจะทำ Product ให้เสร็จเมื่อไหร่?”
Evolution คิดว่า
“เราจะรู้อะไรเพิ่มขึ้นเมื่อไหร่?”
นี่เป็นคนละ Mental Model
และผมคิดว่ายิ่ง AI ทำให้ Build เร็วเท่าไร Mental Model แบบหลังยิ่งสำคัญ
Steve Blank เองก็อธิบายว่า MVP ที่เราต้องใช้ในแต่ละช่วงอาจแตกต่างกัน เพราะสิ่งที่เรากำลังทดสอบเปลี่ยนไปตามสิ่งที่เราเรียนรู้
ดังนั้น MVP ไม่จำเป็นต้องเป็น Product รุ่นเดียวที่ค่อย ๆ เติม Feature จนเสร็จ
มันอาจเป็น ชุดของการทดลอง ที่เปลี่ยนไปตามคำถามที่เรายังตอบไม่ได้
ลองสมมติว่าเรากำลังสร้าง Motorcycle คันแรก
นี่เป็นวิธีคิดที่ผมชอบมาก
สมมติเรามี Idea ว่า
“คนต้องการพาหนะที่ช่วยเดินทางจาก A ไป B ได้สะดวกขึ้น”
ถ้าเราใช้วิธีคิดแบบ Completion
เราก็อาจเริ่มสร้าง Motorcycle ทันที
เครื่องยนต์
ระบบเบรก
ระบบไฟ
ระบบส่งกำลัง
โครงสร้าง
หน้าปัด
ระบบความปลอดภัย
แล้วใช้เวลามหาศาลกว่าจะได้ Product ที่สมบูรณ์
แต่คำถามคือ
เราจำเป็นต้องพิสูจน์ทั้งหมดนั้นพร้อมกันหรือไม่?
ถ้าสิ่งที่เราต้องการรู้ใน Phase แรกคือ
“คนต้องการเดินทางจาก A ไป B ด้วยพาหนะรูปแบบนี้จริงหรือเปล่า?”
บางที
จักรยานก็พอ
จากนั้นถ้าพบว่าคนต้องการ
เราอาจเพิ่มความสามารถ
จักรยาน
↓
จักรยานไฟฟ้า
↓
Scooter
↓
Motorcycle
สิ่งสำคัญไม่ใช่ว่าโลกจริงต้องพัฒนายานพาหนะตามลำดับนี้
เพราะนี่เป็น Analogy สำหรับวิธีคิดเรื่อง Product Development
สิ่งที่ผมต้องการสื่อคือ
**ทุก Phase ไม่จำเป็นต้องสร้าง Product ให้เสร็จ
แต่ต้องสร้างหลักฐานให้มากขึ้น**
ทุกครั้งที่เราเพิ่ม Phase
เราไม่ได้เพิ่มแค่ Feature
แต่เพิ่ม
ความมั่นใจ
ว่าเรากำลังสร้างสิ่งที่ตลาดต้องการ
Case จริง: Dropbox พิสูจน์ Demand ก่อนสร้าง Product เต็ม
หนึ่งในตัวอย่างที่ผมชอบคือ Dropbox
เพราะมันทำให้เห็นว่า MVP ไม่จำเป็นต้องเป็น Software ที่สมบูรณ์ด้วยซ้ำ
Drew Houston ไม่ได้เริ่มต้นด้วยการสร้าง Product ที่สมบูรณ์แล้วค่อยถามว่ามีคนใช้ไหม
เขาทำ Demo Video เพื่อแสดงให้เห็นว่า Dropbox จะทำงานอย่างไร
TechCrunch รายงานว่า Video ประมาณ 3 นาทีของ Dropbox ทำให้ Beta Waiting List เพิ่มจากประมาณ 5,000 คนเป็น 75,000 คนในชั่วข้ามคืน
สิ่งที่น่าสนใจคือ
สิ่งที่ถูก Validate ในตอนนั้นไม่ใช่ Code
แต่คือ
คนสนใจ Experience นี้หรือเปล่า?
นี่เป็นตัวอย่างที่ดีมากของ MVP
เพราะ MVP ไม่ได้บอกว่า
“ต้องสร้าง App ที่เล็กที่สุด”
แต่ถามว่า
“วิธีที่ถูกที่สุดในการเรียนรู้สิ่งสำคัญที่เรายังไม่รู้คืออะไร?”
ถ้าคำถามคือ Technical Feasibility
POC อาจเพียงพอ
ถ้าคำถามคือ Demand
Landing Page หรือ Demo Video อาจเพียงพอ
ถ้าคำถามคือ User Experience
Prototype อาจเหมาะกว่า
แต่ถ้าต้องการรู้ว่า User จริงจะใช้ Product จริงหรือไม่
MVP ที่ให้คนใช้งานจริงย่อมให้ Evidence คนละระดับ
นี่คือเหตุผลที่ MVP กับ POC ไม่ควรถูกใช้แทนกัน
MVP ไม่ได้ช่วยแค่ Developer แต่มันช่วย User ด้วย
นี่เป็นอีกมุมที่ผมคิดว่าน่าสนใจมาก
เวลาพูดถึง MVP คนมักคิดถึง
Developer ประหยัดเวลา
แต่จริง ๆ แล้ว MVP มีประโยชน์กับ User ด้วย
เพราะ User เองก็ต้องเรียนรู้ Product
ลองคิดว่า
ถ้าคุณเปิด App ใหม่ขึ้นมา
แล้วหน้าแรกมี
30 เมนู
15 Dashboard
20 Setting
ระบบ Automation
ระบบ Report
ระบบ AI
ระบบ Integration
ระบบ Notification
และอีกสารพัด Feature
Product อาจ “เก่ง” มาก
แต่ User อาจไม่ได้คิดว่า
“เก่งจัง”
เขาอาจคิดว่า
“แล้วฉันต้องเริ่มตรงไหน?”
นี่คือเหตุผลที่ Product Development ไม่ควรมองแค่
Build → Launch
แต่ต้องคิดถึง
Build → User Learn → User Adopt
ความสามารถที่เราเพิ่มเข้าไปใน Product จึงมีต้นทุนอีกด้านหนึ่ง
คือ ต้นทุนทางความเข้าใจของ User
งานวิจัยด้าน Feature Overload ก็ชี้ว่าความซับซ้อนและจำนวน Feature ที่มากเกินไปสามารถเพิ่ม Cognitive Load และสัมพันธ์กับการเลื่อนการตัดสินใจหรือความตั้งใจเปลี่ยนไปใช้บริการอื่นได้
ในทางปฏิบัติ สิ่งนี้เห็นได้ง่ายมากใน Onboarding
ถ้า User เปิด Product แล้วต้องเรียนรู้ทุกอย่างพร้อมกัน
Product จะถูกตีความว่า “ยาก”
ทั้งที่จริง ๆ แล้ว Product อาจไม่ได้ยาก
มันแค่ให้ User เรียนรู้เร็วเกินไป
Feature ที่ดี ไม่ได้แปลว่า Feature ที่ควรออกวันนี้
นี่คือจุดที่ผมคิดว่านักการตลาดควรเอาไปใช้มากที่สุด
เวลาคุยกับทีม Product เรามักถามว่า
“Feature นี้ดีไหม?”
ผมว่าเปลี่ยนคำถามเป็น
“Feature นี้ควรออกตอนนี้ไหม?”
จะมีประโยชน์กว่า
เพราะ Feature หนึ่งอาจมีประโยชน์มาก
แต่ยังไม่ใช่เวลาของมัน
User ยังไม่พร้อม
Product ยังไม่มี Context
ทีมยังไม่รู้ว่า Core Value จริง ๆ คืออะไร
หรือ Feature นั้นยังไม่มี Evidence ว่าคนต้องการ
การมี Feature เยอะจึงไม่ได้ทำให้ Product Mature เสมอไป
บางครั้งมันแปลว่า
Product ยังไม่รู้ว่าอะไรสำคัญที่สุด
Steve Blank เองก็เตือนเรื่องการสร้างตาม Feature Request แบบตรง ๆ เพราะการทำทุกอย่างที่ลูกค้าร้องขอไม่ได้แปลว่าจะได้ Product ที่ดีขึ้น สิ่งสำคัญกว่าคือการกลับไปดู Hypothesis และหลักฐานว่าปัญหานั้นสำคัญจริงหรือไม่
สิ่งที่ AI เปลี่ยนจริง ๆ คือความหมายของ “เร็ว”
ผมคิดว่านี่คือประเด็นที่สำคัญที่สุดของเรื่องนี้
เมื่อก่อนเราอาจพูดว่า
“ทำให้เร็วขึ้น”
แล้วหมายถึง
เขียน Code ให้เร็วขึ้น
แต่วันนี้ AI กำลังทำให้เรื่องนั้นเร็วขึ้นมากอยู่แล้ว
ดังนั้น “ความเร็ว” ที่มีค่ากว่าอาจเปลี่ยนไป
จาก
Build Fast
เป็น
Learn Fast
จาก
Feature เร็ว
เป็น
Feedback เร็ว
จาก
Launch Product เร็ว
เป็น
Validate Idea เร็ว
และจาก
Complete เร็ว
เป็น
รู้เร็วว่าอะไรควรทำต่อ
นี่คือเหตุผลที่ผมไม่คิดว่า AI ทำให้ MVP สำคัญน้อยลง
ผมกลับคิดว่า
AI ทำให้ MVP สำคัญกว่าเดิม
เพราะเมื่อ AI ทำให้เราสามารถสร้าง Product ได้ง่ายขึ้น
สิ่งที่กลายเป็นคอขวดไม่ใช่ความสามารถในการสร้าง
แต่คือ ความสามารถในการตัดสินใจว่าอะไรควรสร้าง
MVP คือ Constraint ใหม่ในยุค Vibe Coding
ผมกลับไปคิดถึงเรื่องนี้อีกทีแล้วรู้สึกว่า
เมื่อก่อนเรามี Constraint จากการ Development
อยากสร้างอะไรต้องใช้เวลา
อยากเปลี่ยนอะไรต้องใช้เงิน
อยากเพิ่ม Feature ต้องผ่านทีม
Constraint เหล่านี้ทำให้เราต้องคิด
วันนี้ AI กำลังเอา Constraint เหล่านั้นออกไป
มันเป็นเรื่องดี
แต่ก็ทำให้เกิดปัญหาใหม่
เพราะถ้าเราสามารถสร้างได้แทบทุกอย่าง
คำถามจึงไม่ใช่
“สร้างได้ไหม?”
แต่เป็น
“ควรสร้างไหม?”
และคำถามต่อมาคือ
“เราจะพิสูจน์อย่างไรว่าควรสร้าง?”
ตรงนี้เองที่ MVP กลับมามีความหมาย
MVP จึงไม่ใช่แค่เครื่องมือของ Startup
และไม่ใช่แค่เทคนิคของ Product Manager
มันเป็น Decision Constraint
ที่ช่วยบอกเราว่า
ก่อนจะเพิ่ม Feature
เราต้องได้ Learning อะไรเสียก่อน?
ถ้าคุณเป็น Marketer ที่กำลัง Vibe Code ลองเปลี่ยนคำถามนี้
ถ้าวันนี้คุณกำลังใช้ Cursor, Lovable, Replit หรือ AI Coding Tool ตัวไหนก็ตามสร้าง App อยู่
ผมไม่ได้บอกว่า
อย่าสร้าง
ตรงกันข้าม
ผมว่าควรสร้างให้เร็วมาก ๆ
แต่ก่อนสร้าง ผมอยากให้คุณตอบ 5 คำถามนี้:
หนึ่ง — เรากำลังพิสูจน์อะไร?
ถ้าตอบไม่ได้ แปลว่าอาจยังไม่รู้ว่าจะสร้างไปทำไม
สอง — User คนแรกคือใคร?
อย่าเริ่มด้วย “ทุกคน”
เพราะถ้าทุกคนคือ Target User สุดท้ายจะไม่รู้ว่าต้อง Optimize ให้ใคร
สาม — Minimum ที่ทำให้ User ได้รับ Value คืออะไร?
ไม่ใช่ Feature ที่เราอยากมี
แต่คือสิ่งที่ User ต้องมีเพื่อสัมผัส Value
สี่ — เราจะรู้ได้อย่างไรว่ามันเวิร์ก?
กำหนด Signal ก่อน Build
อาจเป็นการสมัคร
การใช้งานซ้ำ
การจ่ายเงิน
การทำ Action บางอย่าง
หรือพฤติกรรมอื่นที่สัมพันธ์กับ Hypothesis
ห้า — ถ้าไม่เวิร์ก เราจะทำอะไรต่อ?
นี่สำคัญมาก
MVP ไม่ได้มีไว้เพื่อพิสูจน์ว่า Idea ของเราถูกเสมอ
มันต้องเปิดโอกาสให้คำตอบเป็น
“ไม่ใช่”
ด้วย
เพราะถ้าไม่ใช่
เราจะได้ Pivot
และ Pivot เร็วกว่าเดิม
อย่ากลัวการสร้าง Product ที่ “ไม่สมบูรณ์”
สิ่งหนึ่งที่ผมอยากเปลี่ยน Mindset ของคนทำ Vibe Coding คือ
อย่าคิดว่า Product รุ่นแรกต้องดูเหมือน Product รุ่นสุดท้าย
MVP ที่ดีอาจดูต่างจาก Complete Product มาก
เพราะหน้าที่ของมันต่างกัน
Complete Product มีหน้าที่สร้าง Value อย่างเต็มรูปแบบ
แต่ MVP มีหน้าที่สร้าง Evidence
Evidence ว่า
- คนมีปัญหานี้จริง
- คนสนใจ Solution นี้
- คนใช้ Solution นี้
- คนกลับมาใช้
- คนยอมจ่าย
- หรือในทางกลับกัน คนไม่ได้สนใจเลย
คำตอบทุกแบบมีคุณค่า
เพราะมันทำให้เรารู้ว่า
ควร Build ต่อหรือไม่
จาก Build Fast สู่ Learn Fast
ผมคิดว่าเรากำลังเข้าสู่ช่วงที่คำว่า “สร้าง Software เร็ว” ไม่ได้เป็น Advantage ใหญ่เหมือนเดิม
เพราะถ้าทุกคนมี AI ที่ช่วยสร้าง Software ได้เร็วขึ้น
ความเร็วในการ Build จะกลายเป็นเรื่องที่ทุกคนมีใกล้ ๆ กัน
สิ่งที่ต่างกันจึงเป็น
ใครเรียนรู้จากตลาดได้เร็วกว่า
คนหนึ่งอาจใช้ AI สร้าง App 50 Feature ภายในหนึ่งสัปดาห์
อีกคนอาจสร้างแค่ 3 Feature
แต่เอาให้ User จริงใช้
เก็บ Feedback
ดู Behavior
ตัด Feature ที่ไม่จำเป็น
แล้ว Build ต่อจาก Evidence
ถ้าเป็นผม
ผมเลือกคนที่สอง
เพราะเขาไม่ได้แค่ Build Product
เขากำลัง ลดความไม่แน่นอนของธุรกิจ
และนี่คือคุณค่าที่แท้จริงของ MVP
Takeaway — ในยุค AI คนที่ชนะอาจไม่ใช่คนที่ Build เร็วที่สุด
ผมคิดว่า AI กำลังเปลี่ยนบทบาทของคนทำ Software
และกำลังเปลี่ยนบทบาทของ Marketer ด้วย
เมื่อก่อนเราอาจต้องถาม
“Developer ทำให้ได้ไหม?”
วันนี้คำถามนั้นกำลังมีความสำคัญน้อยลง
เพราะ AI ทำให้เราทดลองสิ่งต่าง ๆ ได้เร็วขึ้น
คำถามที่สำคัญกว่าคือ
“เราควรสร้างอะไร?”
และคำถามที่สำคัญที่สุดคือ
“เราจะรู้ได้อย่างไรว่าเรากำลังสร้างสิ่งที่ถูก?”
สำหรับผม
นี่คือเหตุผลที่ MVP ไม่ได้เก่าเลย
ตรงกันข้าม
ในยุค Vibe Coding มันอาจสำคัญกว่าเดิมด้วยซ้ำ
เพราะ AI เอา Constraint ของการ Build ออกไปแล้ว
เราจึงต้องสร้าง Constraint ของการตัดสินใจขึ้นมาเอง
และหนึ่งใน Constraint ที่ดีที่สุดคือ
MVP
ไม่ใช่เพื่อทำ Product ให้เล็กที่สุด
แต่เพื่อ
**เรียนรู้ให้เร็วที่สุดว่า
เรากำลังสร้างสิ่งที่ควรสร้างจริงหรือเปล่า**
เพราะในยุคที่ AI ทำให้ทุกคน Build ได้เร็วขึ้น
ผมไม่คิดว่า
คนที่ชนะคือคนที่สร้างได้เร็วที่สุด
แต่คือคนที่
รู้เร็วที่สุดว่าอะไรควรสร้างต่อ
References
- Eric Ries — What Is an MVP? (Lean Startup Co.)
https://leanstartup.co/resources/articles/what-is-an-mvp/ - Eric Ries — Minimum Viable Product: A Guide
https://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html - Steve Blank — The Secret to the Minimum Viable Product
https://steveblank.com/2021/04/20/the-secret-to-the-minimum-viable-product/ - Steve Blank — An MVP is not a Cheaper Product, It’s about Smart Learning
https://steveblank.com/2013/07/22/an-mvp-is-not-a-cheaper-product-its-about-smart-learning/ - a16z — Most People Can’t Vibe Code. Here’s How We Fix That.
https://a16z.com/most-people-cant-vibe-code-heres-how-we-fix-that/ - a16z — The AI Application Spending Report: Where Startup Dollars Really Go
https://a16z.com/the-ai-application-spending-report-where-startup-dollars-really-go/ - TechCrunch — How Dropbox Started as a Minimal Viable Product
https://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/ - Adobe Blog — Move Quickly, Design Effectively: When a Minimum Viable Product (MVP) Becomes A UX Designer’s Best Friend
https://blog.adobe.com/en/publish/2017/10/10/move-quickly-design-effectively-when-a-minimum-viable-product-mvp-becomes-a-ux-designers-best-friend - ScienceDirect — On the nature, origins and outcomes of Over Featuring in the new product development process
https://www.sciencedirect.com/science/article/pii/S0923474822000157 - ScienceDirect — Feature fatigue analysis in product development using Bayesian networks
https://www.sciencedirect.com/science/article/pii/S0957417411003332 - Steve Blank — Killing Your Startup By Listening to Customers
https://steveblank.com/2012/02/27/killing-your-startup-by-listening-to-customers/
