ผลิตภัณฑ์ที่ใช้งานได้ขั้นต่ำ (Minimum Viable Product หรือ MVP) คือเวอร์ชันที่เล็กที่สุดของผลิตภัณฑ์ที่ช่วยให้ทีมเรียนรู้สิ่งสำคัญเกี่ยวกับความต้องการของลูกค้า ซึ่งเป็นแนวคิดที่ Eric Ries ได้นำเสนอในหนังสือ The Lean Startup คุณสมบัติที่สำคัญไม่ใช่ขนาดที่เล็กหรือราคาถูก แต่เป็นการสร้างขึ้นเพื่อตอบคำถามเฉพาะเจาะจง และคำถามนั้นเกี่ยวข้องกับการเรียนรู้ที่ได้รับการตรวจสอบแล้วเกี่ยวกับพฤติกรรมของลูกค้า มากกว่าความคิดเห็นภายในเกี่ยวกับความเป็นไปได้
การใช้คำผิดที่พบบ่อยที่สุดคือการมองว่ามันเป็นคำพ้องความหมายกับการปล่อยเวอร์ชันแรกที่มีฟีเจอร์น้อยกว่า ภายใต้แรงกดดันเรื่องกำหนดเวลา ทีมงานมักลดขอบเขตงาน ปล่อยสิ่งที่ยังไม่สมบูรณ์ เรียกมันว่า MVP (Minimum Viable Product) แล้วก็ไม่ได้วัดผลอะไรเป็นพิเศษ ซึ่งทำให้ไม่ได้ทั้งผลิตภัณฑ์ที่ดีและบทเรียนที่มีประโยชน์ คำถามที่สำคัญคือ การปล่อยเวอร์ชันนี้จะทดสอบสมมติฐานอะไร และผลลัพธ์แบบไหนที่จะทำให้ทีมเปลี่ยนทิศทาง หากไม่มีคำตอบ การปล่อยเวอร์ชันนั้นก็เป็นเพียงผลิตภัณฑ์ขนาดเล็ก ไม่ใช่ผลิตภัณฑ์ขั้นต่ำที่ใช้งานได้จริง (Minimum Viable Product)
ส่วนที่สำคัญของคำว่า "ใช้งานได้จริง" มักถูกมองข้ามไป เวอร์ชันที่เรียบง่ายแต่ใช้งานไม่ได้ หรือล้มเหลวในสิ่งที่ควรทำนั้น แสดงให้เห็นถึงปัญหาในการนำไปใช้มากกว่าความต้องการของลูกค้า การที่ลูกค้าปฏิเสธผลิตภัณฑ์เพราะมันช้า ชำรุด หรือใช้งานยาก ไม่ได้บอกอะไรทีมเลยว่าข้อเสนอพื้นฐานนั้นมีคุณค่าหรือไม่ สิ่งที่รวมอยู่จะต้องดีพอที่จะทดสอบไอเดียได้อย่างยุติธรรม แม้ว่าขอบเขตโดยรอบจะลดลงอย่างมากก็ตาม
รูปแบบที่ได้รับการยอมรับหลายรูปแบบสามารถตอบคำถามเกี่ยวกับความต้องการได้โดยไม่ต้องสร้างผลิตภัณฑ์เต็มรูปแบบ วิธีการแบบ Concierge จะให้บริการแก่ลูกค้ากลุ่มแรกด้วยตนเองเพื่อเรียนรู้ว่าพวกเขาต้องการอะไรอย่างแท้จริงก่อนที่จะทำการอัตโนมัติใดๆ การใช้งานแบบ Wizard-of-Oz จะนำเสนออินเทอร์เฟซที่ใช้งานได้จริงโดยมีมนุษย์เป็นผู้ดำเนินการเบื้องหลัง การทดสอบหน้า Landing Page จะวัดว่ามีใครตอบสนองต่อข้อเสนอหรือไม่ก่อนที่จะเริ่มการพัฒนา แต่ละวิธีเหล่านี้สร้างหลักฐานเชิงพฤติกรรม ซึ่งแข็งแกร่งกว่าความตั้งใจที่ระบุไว้ซึ่งรวบรวมได้จากแบบสำรวจและการสัมภาษณ์เกี่ยวกับผลิตภัณฑ์สมมุติฐานมาก
แนวทางนี้เหมาะสมกับบางบริบทมากกว่าบริบทอื่นๆ ในอุตสาหกรรมที่มีการควบคุม ในระบบที่สำคัญต่อความปลอดภัย และในการขายระดับองค์กรที่ความประทับใจแรกที่ไม่ดีเพียงครั้งเดียวอาจทำให้เสียตลาดไปหลายปี การส่งมอบซอฟต์แวร์ที่ไม่สมบูรณ์โดยเจตนาจะมีต้นทุนที่มากกว่าบทเรียนที่ได้รับ ในสถานการณ์เหล่านี้ ตรรกะเดียวกันนี้จึงเหมาะสมกว่าหากนำไปใช้ผ่านต้นแบบ โครงการนำร่องกับผู้เข้าร่วมที่มีความรู้ และการเปิดตัวทีละขั้นตอนกับกลุ่มเป้าหมายที่จำกัด มากกว่าการเปิดตัวผลิตภัณฑ์ขั้นต่ำสู่สาธารณะ
การตัดสินใจล่วงหน้าว่าผลลัพธ์ใดที่จะทำให้ทีมหยุดการทำงาน คือสิ่งที่ทำให้การทดสอบมีความหมาย และเป็นขั้นตอนที่ถูกละเลยมากที่สุด หากไม่มีเกณฑ์ที่ตกลงกันไว้ล่วงหน้า ผลลัพธ์ใดๆ ก็สามารถตีความได้ว่าเป็นเรื่องที่น่ายินดี: การใช้งานต่ำกลายเป็นปัญหาด้านการตลาด การรักษาผู้ใช้งานต่ำกลายเป็นปัญหาด้านการเริ่มต้นใช้งาน และโครงการก็จะดำเนินต่อไปได้ด้วยคำอธิบายใดๆ ก็ตามที่ช่วยรักษาโครงการไว้ การเขียนลงไปก่อนเปิดตัวว่าระดับการใช้งานหรือการรักษาผู้ใช้งานระดับใดที่จะทำให้ดำเนินการต่อ ระดับใดที่จะทำให้เปลี่ยนแนวทาง และระดับใดที่จะทำให้หยุดการทำงานโดยสิ้นเชิง จะเปลี่ยนการเปิดตัวให้เป็นการทดสอบที่แท้จริง นอกจากนี้ยังช่วยปกป้องทีมด้วย เนื่องจากเกณฑ์ที่บันทึกไว้และตกลงกันโดยผู้มีส่วนได้ส่วนเสียนั้นง่ายต่อการนำมาใช้มากกว่าการตัดสินใจที่เกิดขึ้นหลังจากนั้น
หากนำไปใช้อย่างเหมาะสม แนวคิดนี้จะช่วยให้ทีมเข้าใจความแตกต่างระหว่างการสร้างและการเรียนรู้ได้อย่างตรงไปตรงมา และมีคุณค่าอย่างยิ่งในกรณีที่ความไม่แน่นอนเกี่ยวกับความต้องการอยู่ในระดับสูง ในทางปฏิบัติ สมมติฐานและมาตรฐานหลักฐานจะถูกกำหนดขึ้นผ่าน การวิจัยผลิตภัณฑ์โครงสร้างนี้ตั้งอยู่กับ การพัฒนาผลิตภัณฑ์และวินัยในการกำหนดล่วงหน้าว่าผลลัพธ์ใดที่จะกระตุ้นให้เกิดการเปลี่ยนแปลงทิศทาง คือสิ่งที่ทำให้แนวทางนี้แตกต่างจากการเริ่มต้นดำเนินการก่อนกำหนดเพียงอย่างเดียว สำหรับ ที่เพิ่งเริ่มต้น โดยเฉพาะอย่างยิ่ง วินัยดังกล่าวจะเป็นตัวกำหนดว่าเวลาอันจำกัดนั้นจะถูกใช้ไปกับการเรียนรู้หรือเพียงแค่ใช้ไปเปล่าๆ