วิธีกำหนดขอบเขต MVP ใน 3 ชั่วโมง

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

เนื่องจากเราต้องดำเนินการบนไทม์ไลน์ที่ถูกตัดทอน ฉันจึงสร้างวิธีการที่เรียบง่ายแต่มีประสิทธิภาพในการตั้งครรภ์ ออกแบบ และสร้างผลิตภัณฑ์ขั้นต่ำ (MVP) ที่มีคุณลักษณะหลักที่ตรงกับสิ่งที่ผู้ใช้ต้องการ กระบวนการนี้ย่อขอบเขตของ MVP ให้เป็นเซสชั่นเข้มข้นสามชั่วโมงหนึ่งครั้ง—แทนที่จะเป็นวันหรือสัปดาห์—และช่วยประหยัดเวลาของทีมในการพัฒนาได้หลายเดือน

กระบวนการกำหนดขอบเขต MVP ที่เร่งรัดนี้สามารถนำมาใช้เพื่อเป็นแนวทางให้กับทีมผลิตภัณฑ์ใดๆ ก็ได้ และสามารถนำไปใช้กับการสร้างผลิตภัณฑ์แบบ Zero-to-one ใดๆ ก็ได้

ภาพรวมของกรณีการใช้งาน

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

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

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

วิธีแก้ไข: เราจำเป็นต้องพัฒนาโซลูชันที่ช่วยให้ผู้ใช้สามารถโหลดสินค้าคงเหลือของตนลงในแค็ตตาล็อกดิจิทัล จัดการสินค้าคงคลังเหล่านั้น และแตะรายการที่เลือกเพื่อเพิ่มลงในตะกร้าสินค้าของลูกค้า ทั้งหมดนี้ภายในแอป

การตัดสินใจ Design Sprint

เนื่องจากเรารู้แล้วว่าเราต้องพัฒนาผลิตภัณฑ์ใด ฉันจึงเลือกที่จะละทิ้งการออกแบบทั่วไป—การประชุมเชิงปฏิบัติการสี่ถึงห้าวันที่ทีมทำงานร่วมกันเพื่อระบุความท้าทายทางธุรกิจที่สำคัญ รวบรวมแนวคิดจากลูกค้าเกี่ยวกับวิธีการแก้ปัญหา พัฒนาแนวคิดสำหรับผลิตภัณฑ์ ออกแบบต้นแบบ และเริ่มทดสอบ

Design sprints เป็นวิธีที่มีประสิทธิภาพในการสร้าง MVPs—สำหรับผู้ที่ต้องการระบุปัญหาหลักและผู้ที่มีเวลาอันมีค่าที่พร้อมจะพัฒนาโซลูชัน อย่างไรก็ตาม ในบริษัทระยะเริ่มต้นหรือหน่วยธุรกิจใหม่ในองค์กรที่มีอยู่ ประเด็นหลักมักจะปรากฏชัด: มีการพัฒนาแนวคิด และมักจะกำหนดความเหมาะสมของผลิตภัณฑ์/ตลาดก่อนที่จะนำเข้าผู้จัดการผลิตภัณฑ์ วิศวกร และนักออกแบบ

ผังงานต่อไปนี้แบ่งขั้นตอนที่ฉันทำเมื่อตัดสินใจว่าวิธีที่ดีที่สุดในการดำเนินการโครงการนี้คือข้ามการออกแบบและเริ่มต้นด้วยเซสชั่นสามชั่วโมงหรือที่เรียกว่าการเริ่มต้นทีม ในการประชุมนั้น ผู้เข้าร่วมจะระดมสมองและสร้างแนวคิดมากมายสำหรับคุณลักษณะต่างๆ จากนั้นจึงตัดรายการให้เหลือเฉพาะสิ่งที่จำเป็นสำหรับ MVP

กระบวนการพัฒนา MVP

การตระเตรียม

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

จากนั้นสร้างงานนำเสนอสำหรับนักออกแบบและวิศวกร ควรอธิบาย:

• ปัญหาที่คุณพยายามแก้ไข
• ผลิตภัณฑ์ที่คุณกำลังสร้าง
• ผลิตภัณฑ์จะแก้ปัญหานั้นอย่างไรในแง่ของเมตริกและ UX
• ผลกระทบที่คาดการณ์ไว้ของผลิตภัณฑ์ที่มีต่อธุรกิจของคุณและลูกค้าของคุณ
• ภารกิจและวัตถุประสงค์ระดับบริษัทและทีมและผลลัพธ์ที่สำคัญ (OKR) ตลอดจนวิธีที่ผลิตภัณฑ์ช่วยให้บรรลุภารกิจเหล่านั้นและบรรลุ OKRs เหล่านั้น

การนำเสนอควรให้นักออกแบบและวิศวกรเข้าใจผลิตภัณฑ์อย่างถ่องแท้เพื่อดำเนินการกำหนดขอบเขต MVP

การประชุมแจ้งกำหนดการสามชั่วโมง

กำหนดการควรเกี่ยวข้องกับทีมพัฒนาทั้งหมด ทำให้พวกเขามีส่วนร่วมในทุกขั้นตอนของกระบวนการ ตั้งแต่ความคิดและการสร้างเรื่องราวไปจนถึงการพัฒนาแนวคิด MVP ซึ่งรวมถึงผู้จัดการผลิตภัณฑ์อาวุโส รุ่นน้อง และรอง เจ้าของผลิตภัณฑ์ โอกาสในการขายผลิตภัณฑ์ (ถ้ามี) นักออกแบบ UX; วิศวกรซอฟต์แวร์ และวิศวกรควบคุมคุณภาพ

เคล็ดลับด่วน: แม้ว่าจะไม่ใช่เรื่องปกติ แต่ฉันแนะนำให้รวมวิศวกรก่อนขั้นตอนการสร้าง พวกเขามักจะให้แนวคิดที่ดีและมีความหลงใหลในผลิตภัณฑ์ที่พวกเขาพยายามปรับปรุง ส่วนใหญ่สนุกกับการมีส่วนร่วมในการกำหนดขอบเขต MVP ช่วยให้พวกเขาลงทุนในโครงการมากขึ้นและให้คุณค่ากับทีมอื่นๆ

รวบรวมทุกคนในห้องประชุมหรือพื้นที่ทำงานเสมือนจริง ในกรณีของเรา เรามี 10 คน ปิดกั้นสามชั่วโมง

ผลิตภัณฑ์และการเดินทางของผู้ใช้ (60 นาที)

1. นำเสนอผลงาน. (15 นาที)

2. เริ่มระบุตัวตนของผู้ใช้ทั้งหมดสำหรับผลิตภัณฑ์ของคุณ แม้ว่าคุณจะยังไม่ได้ระบุโฟลว์หรือการทำงานของฟีเจอร์ใดๆ คุณสามารถกำหนดจำนวนของโฟลว์ที่จำเป็นต้องสร้างได้ (10 นาที)

   เคล็ดลับง่ายๆ: อย่าปรับโครงสร้างให้มากเกินไปโดยเพิ่มบุคลิกที่เกินความจำเป็น หลังจากการเปิดตัว MVP ความคิดเห็นของลูกค้าจะเปิดเผยว่าคุณต้องการบทบาทเพิ่มเติมหรือไม่

   ตัวอย่างกรณีการใช้งาน: เรามีสามบุคคล: ผู้จัดการร้าน (หรือผู้ดูแลระบบ) แคชเชียร์ และลูกค้าปลายทาง อาจมีบุคคลระดับอาวุโสอื่น ๆ เช่นเจ้าของร้าน แต่สำหรับวัตถุประสงค์ของ MVP ผู้ดูแลระบบอาจครอบคลุมถึงสิ่งเหล่านี้

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

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

   ตัวอย่างการใช้งาน: นี่คือรายการคุณลักษณะสำหรับแคชเชียร์ของเรา:

   • เปิดแอป ณ จุดขาย
   • ลงชื่อเข้าใช้ด้วย PIN
   • ระบุรายการแรกสำหรับลูกค้าที่ซื้อ
   • ระบุปริมาณสำหรับรายการ
   • ระบุรายการเพิ่มเติมสำหรับการซื้อของลูกค้า
   • เพิ่มส่วนลดสำหรับสินค้า (ถ้ามี)
   • รวมต้นทุนของสินค้าทั้งหมดในตะกร้าสินค้า ( ณ จุดนี้ ราคาซื้อเต็ม รวมภาษีขาย จะแสดงขึ้น)
   • ดำเนินการชำระเงินและชำระเงินให้เสร็จสิ้น
   • ยืนยันการซื้อ
   • อนุญาตให้ลูกค้าเพิ่มเคล็ดลับ
   • ปิดการขายครับ.
   • แสดงยอดรวมของยอดขายรายวันทั้งหมด
   • หมดเวลาหลังจากไม่มีการใช้งานเป็นระยะเวลาที่กำหนดไว้ (เช่น ห้านาที)

   หมายเหตุ: รายการนี้ให้รายละเอียดเกี่ยวกับคุณลักษณะส่วนใหญ่ที่เรานึกถึงสำหรับบุคคลนี้ เราพบคุณลักษณะทั้งหมดประมาณ 60 รายการในทุกบุคคล โดยมีความเหลื่อมล้ำน้อยที่สุด ในฐานะแคชเชียร์ ผู้จัดการร้าน และลูกค้าปลายทาง ต่างมีส่วนร่วมกับแอปพลิเคชันในรูปแบบต่างๆ ขึ้นอยู่กับประเภทของผลิตภัณฑ์ที่คุณกำลังพัฒนา อาจมีคุณลักษณะที่ทับซ้อนกันมากขึ้นอย่างมากในประเภทผู้ใช้

   

คุณสมบัติที่สำคัญของการเดินทางของผู้ใช้ (45 นาที)

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

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

   ตัวอย่างกรณีการใช้งาน: สำหรับแอปของเรา เรามีชุดคุณลักษณะ 12 ชุด ณ จุดนี้ ซึ่งครอบคลุมการโหลดสินค้าลงในแค็ตตาล็อกสินค้าคงคลัง กำหนดราคา เลือกรายการที่จะเพิ่มลงในรถเข็นของลูกค้า เช็คเอาท์และปิดการขาย การเรียงลำดับสินค้าคงคลังต่ำ และอื่น ๆ. ในที่สุด เราก็ลดจำนวนชุดคุณลักษณะลงเหลือสี่ชุด

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

2. ปรับแต่งรายการคุณสมบัติ ถาม “ถ้าละเว้น ผลิตภัณฑ์จะยังทำงานอยู่ไหม” ถ้าคำตอบคือใช่ ให้ปล่อยฟีเจอร์นั้นออกจาก MVP—บันทึกไว้สำหรับการทำซ้ำของผลิตภัณฑ์ในภายหลัง หากคำตอบคือไม่ คุณต้องรวมคุณสมบัตินั้นไว้ใน MVP เมื่อสิ้นสุดกระบวนการนี้ คุณจะรู้ว่าสิ่งใดจำเป็นอย่างแท้จริงในการทำให้ผลิตภัณฑ์ของคุณทำงานได้ บ่อยครั้งจะประกอบด้วยคุณสมบัติเพียงสามหรือสี่อย่างสำหรับแต่ละชุด (15 นาที)

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

การออกแบบผลิตภัณฑ์ การทดสอบ และวิศวกรรม (75 นาที)

1. ให้นักออกแบบรวมคุณสมบัติหลักเข้ากับการออกแบบโครงลวดของ MVP ซึ่งวิศวกรจะใช้เพื่อสร้างสถาปัตยกรรมของผลิตภัณฑ์ (45 นาที)

2. อนุญาตให้ผู้เชี่ยวชาญด้านผลิตภัณฑ์และนักออกแบบทำงานร่วมกันในการทดสอบ UX แบบเบาของการออกแบบโครงลวด (15 นาที)

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

3. มอบโครงลวดที่ออกแบบไว้ให้กับวิศวกรเพื่อให้พวกเขาเริ่มสร้างสถาปัตยกรรมของ MVP พวกเขาไม่มีทุกสิ่งที่ต้องการ—หรือเวลา—ในการสร้างโซลูชันเต็มรูปแบบ แต่พวกเขาสามารถเริ่มต้นได้ และสถาปัตยกรรมที่พวกเขาสร้างจะถูกนำมาใช้เมื่อสำเร็จ MVP ในขณะเดียวกัน ทีมผลิตภัณฑ์และทีมออกแบบสามารถทดสอบโครงลวดต่อกับสมาชิกในทีมภายใน หรือเพื่อนและครอบครัวที่ทำหน้าที่เป็นผู้ใช้ การมีทีมทำงานพร้อมกันในขั้นตอนนี้จะช่วยประหยัดเวลา (15 นาที)

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

ผลลัพธ์และประเด็นสำคัญ

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

ตลอดกระบวนการสร้าง MVP เราได้สร้างชุดคุณลักษณะหลักสี่ชุด ซึ่งทั้งหมดมีขอบเขตน้อยที่สุดแต่มีคุณภาพสูง ผู้ใช้สามารถ:

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

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

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

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

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

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