CB Insights เผยแพร่การวิเคราะห์ประจำปีเกี่ยวกับสาเหตุที่สตาร์ทอัพล้มเหลว มาหลายปีแล้วที่สาเหตุอันดับหนึ่งยังคงเหมือนเดิม: "ไม่มีความต้องการจากตลาด" ไม่ใช่เพราะดำเนินการได้ไม่ดี ไม่ใช่เพราะเงินหมด ไม่ใช่เพราะทีมไม่เก่ง แต่เพราะผลิตภัณฑ์ไม่ได้แก้ปัญหาที่คนใส่ใจมากพอจะเปลี่ยนพฤติกรรมเพื่อมัน
สถิตินี้น่าตกใจมากเมื่อพิจารณาว่ามีความพยายามเท่าไรในการสร้างผลิตภัณฑ์ ทีมงานใช้เวลาเป็นเดือน บางครั้งเป็นปี ออกแบบระบบ เขียนโค้ด ถกเรื่องสถาปัตยกรรม และปรับปรุงการไหลของงาน แต่สาเหตุที่พบบ่อยที่สุดที่พวกเขาล้มเหลวคือไม่มีใครถามว่าสิ่งที่ทำอยู่นั้นแก้ปัญหาจริงๆ หรือเปล่า
การสร้างผลิตภัณฑ์ที่คนอยากได้จริงๆ ไม่ใช่พรสวรรค์ มันคือวินัย มีวิธีการ และวิธีการนั้นเรียนรู้ได้
ความผิดพลาดด้านผลิตภัณฑ์ที่พบบ่อยที่สุดคือการหลงรักทางแก้ปัญหาก่อนที่จะเข้าใจปัญหาอย่างลึกซึ้ง สิ่งนี้เกิดขึ้นเกือบทั่วไปในหมู่ผู้ก่อตั้งมือใหม่ และพบได้บ่อยอย่างน่าแปลกใจในหมู่ผู้มีประสบการณ์ รูปแบบมักเป็นเหมือนกันเสมอ: มีคนมีไอเดีย พวกเขาพบว่ามันน่าสนใจ แล้วก็เริ่มสร้าง ลูกค้าเป็นเรื่องที่คิดทีหลัง ไม่ใช่คนที่ต้องเข้าใจ แต่เป็นคนที่ต้องโน้มน้าว
วิธีแก้ไม่ซับซ้อนแต่ต้องใช้วินัย: ใช้เวลากับปัญหามากกว่าที่คิดว่าจำเป็น ก่อนที่จะคิดถึงทางแก้เลย คุยกับคนที่มีปัญหานั้น ดูพวกเขาทำงาน เข้าใจวิธีแก้ปัญหาชั่วคราวที่พวกเขาใช้อยู่ในวันนี้และทำไมมันไม่สมบูรณ์แบบ ก็ต่อเมื่อนั้นคุณถึงจะมีบริบทเพียงพอในการออกแบบสิ่งที่ตรงจริงๆ
การพัฒนาผลิตภัณฑ์ที่ดีไม่ใช่เส้นตรง แต่เป็นวงจร การวนรอบแต่ละครั้งคือโอกาสในการแทนที่สมมติฐานด้วยหลักฐาน ทีมที่สร้างผลิตภัณฑ์ที่คนอยากได้คือทีมที่วนรอบนี้ได้อย่างรวดเร็วและบ่อยครั้ง
วงจรนี้ไม่ใช่พิธีกรรม แต่ละขั้นตอนมีผลลัพธ์เฉพาะที่กลายเป็นข้อมูลนำเข้าสำหรับขั้นตอนถัดไป การข้ามขั้นตอน โดยเฉพาะการข้ามจากปัญหาไปสู่การสร้างโดยตรง คือสิ่งที่ทำให้ผลิตภัณฑ์พลาดเป้า
ไม่ใช่ทุกปัญหาที่คุ้มค่าแก้ ปัญหาผลิตภัณฑ์ที่ดีมีสามคุณสมบัติ: เกิดขึ้นบ่อย (ส่งผลกระทบต่อคนบ่อย ไม่ใช่นานๆ ครั้ง), รุนแรง (คนรู้สึกถึงมันมากพอที่จะต้องการบรรเทา), และทางแก้ที่มีอยู่ยังไม่เพียงพอจริงๆ (ไม่ใช่แค่ต่างจากสิ่งที่คุณจะสร้างเล็กน้อย)
ความผิดพลาดคือการมุ่งเน้นคุณสมบัติแรกและละเลยอีกสองข้อ "คนเสียเวลาในการประชุม" เกิดขึ้นบ่อย แต่ถ้าความเจ็บปวดต่ำ ถ้าคนพบวิธีแก้ที่พอใช้ได้แล้ว ปัญหาอาจไม่คุ้มแก้ในเชิงพาณิชย์ และถ้ามีเครื่องมืออยู่สิบสองตัวแล้วที่ทำสิ่งที่คุณต้องการทำ คุณต้องมีเหตุผลเฉพาะมากว่าทำไมของคุณถึงจะถูกเลือก
การวิจัยมีชื่อเสียงไม่ดีในวงการผลิตภัณฑ์ มักเชื่อมโยงกับที่ปรึกษาช้า รายงานหนา และผลการค้นพบที่ไม่มีใครอ่าน นั่นคือความล้มเหลวของการดำเนินการ ไม่ใช่ของแนวปฏิบัติ การวิจัยผลิตภัณฑ์ที่ดีนั้นรวดเร็ว เฉพาะเจาะจง และเปลี่ยนแปลงสิ่งที่คุณสร้าง
เป้าหมายของการวิจัยไม่ใช่เพื่อยืนยันว่าปัญหานั้นจริง คุณควรเชื่อสิ่งนั้นก่อนที่จะลงทุนหนักกับการวิจัย เป้าหมายคือเข้าใจปัญหาอย่างลึกพอที่จะรู้ว่าทางแก้ที่ดีหน้าตาเป็นอย่างไร: ใครเฉพาะที่มีปัญหา ในบริบทใด พวกเขาลองทำอะไรไปแล้ว คำศัพท์ที่ใช้อธิบายมัน และ "แก้ได้แล้ว" หน้าตาเป็นอย่างไรสำหรับพวกเขา
สมมติฐานคือการทำนายที่เฉพาะเจาะจงและสามารถพิสูจน์ว่าผิดได้เกี่ยวกับสิ่งที่คุณเชื่อว่าเป็นจริง มันบังคับให้มีความชัดเจน ถ้าคุณเขียนสมมติฐานที่ชัดเจนไม่ได้ คุณยังไม่เข้าใจปัญหาดีพอที่จะสร้างทางแก้
สมมติฐานผลิตภัณฑ์ที่มีประโยชน์มีสามส่วน:
สัญญาณคือส่วนที่สำคัญที่สุด และที่ถูกละเว้นบ่อยที่สุด หากไม่มีสัญญาณที่ตั้งไว้ล่วงหน้า ทุกการทดลอง "ได้ผลพอสมควร" ทีมหาวิธีตีความข้อมูลที่คลุมเครือในเชิงบวก สมมติฐานที่ไม่มีเงื่อนไขพิสูจน์ว่าผิดก็แค่ความปรารถนา
ขั้นตอนการสร้างคือจุดที่ทีมส่วนใหญ่ใช้เวลามากเกินไป เป้าหมายไม่ใช่สร้างผลิตภัณฑ์ แต่สร้างสิ่งขั้นต่ำที่จะให้สัญญาณเกี่ยวกับสมมติฐาน นี่คือวัตถุประสงค์ที่ต่างกัน และผลลัพธ์ที่แตกต่างกันมาก
สำหรับสมมติฐานในช่วงแรกๆ สิ่งขั้นต่ำมักน้อยกว่าที่ทีมคิดมาก คุณทำสิ่งที่ซอฟต์แวร์จะทำด้วยมือสำหรับสิบคนเพื่อทดสอบว่าพวกเขาให้คุณค่ากับผลลัพธ์ได้ไหม? คุณต่อเครื่องมือที่มีอยู่เข้าด้วยกันและทดสอบขั้นตอนการทำงานก่อนสร้างโครงสร้างพื้นฐานใหม่ได้ไหม? คุณร่างต้นแบบและพาผ่านกับผู้ใช้ห้าคนก่อนเขียนโค้ดได้ไหม?
วินัยที่นี่คือการถาม ก่อนสร้างอะไรก็ตาม: "ฉันกำลังพยายามเรียนรู้อะไร?" และ "สิ่งขั้นต่ำที่จะทำให้ฉันเรียนรู้มันคืออะไร?" คำตอบมักเล็กกว่าสิ่งที่ทีมต้องการสร้างเสมอ
หลังจากเปิดตัว ไม่ว่าจะเป็นต้นแบบ นักบินแบบ manual หรือฟีเจอร์ที่ deploy แล้ว ขั้นตอนการวัดผลคือจุดที่ทีมมักหลอกตัวเองมากที่สุด พวกเขาถามผู้ใช้ว่าชอบไหม ผู้ใช้บอกว่าใช่ ทีมทำเครื่องหมายว่าการทดลองได้รับการยืนยัน
ความรู้สึกไม่ใช่สัญญาณ สัญญาณที่เชื่อถือได้เพียงอย่างเดียวคือพฤติกรรม: คนทำสิ่งนั้นไหม? พวกเขากลับมาไหม? พวกเขาจ่ายไหม? พวกเขาบอกคนอื่นไหม?
สำหรับการวัดเชิงปริมาณ ให้ติดตั้งเครื่องมือก่อนเปิดตัว รู้ว่าคุณกำลังติดตามการกระทำเฉพาะใด ตั้งค่าเกณฑ์ล่วงหน้า "เราจะถือว่าสิ่งนี้ได้รับการยืนยันถ้า X% ของผู้ใช้ทำ Y ภายใน Z วัน" สำหรับการวัดเชิงคุณภาพ ทำการสัมภาษณ์ติดตามที่มีโครงสร้าง ไม่ใช่แบบสำรวจความพึงพอใจแบบเปิด
ขั้นตอนการเรียนรู้เกี่ยวกับการอัปเดตโมเดลทางจิตของคุณเกี่ยวกับผู้ใช้และปัญหา ไม่ใช่แค่ตัดสินใจว่าจะสร้างอะไรต่อ ทีมที่ข้ามขั้นตอนนี้รวบรวมข้อมูลแต่ไม่สะสมความเข้าใจ พวกเขาดำเนินการได้เร็วแต่ไม่พัฒนาวิจารณญาณตามกาลเวลา
การเรียนรู้ที่ดีถามว่า: เราทำนายอะไร? อะไรเกิดขึ้นจริงๆ? ช่องว่างบอกอะไรเกี่ยวกับสมมติฐานของเรา? สิ่งที่สำคัญที่สุดที่เราไม่รู้ตอนนี้คืออะไร?
ผลลัพธ์ของขั้นตอนการเรียนรู้คือการนิยามปัญหาที่คมชัดขึ้น สมมติฐานที่ปรับปรุงแล้ว หรือถ้าการทดลองล้มเหลวอย่างชัดเจน การตัดสินใจที่จะดำเนินการในทิศทางอื่น ผลลัพธ์ทั้งหมดเหล่านี้มีคุณค่า ผลลัพธ์ที่แย่ที่สุดคือความคลุมเครือ: "เราเรียนรู้บางอย่างแต่ไม่แน่ใจว่าควรทำอะไรต่อ" นั่นคือสัญญาณว่าการทดลองไม่เฉพาะเจาะจงพอ
การพัฒนาผลิตภัณฑ์ไม่มีขั้นตอนที่คุณหยุดวนรอบนี้ คำถามเปลี่ยนไป ในช่วงแรกคุณยืนยันว่าปัญหานั้นจริงไหม ต่อมาคุณยืนยันว่าองค์ประกอบทางแก้เฉพาะทำงานได้ไหม แต่โครงสร้างมักเหมือนเดิมเสมอ สังเกต ตั้งสมมติฐาน ทดสอบ เรียนรู้
ทีมที่สร้างผลิตภัณฑ์ที่คนอยากได้ไม่ใช่ทีมที่มีข้อมูลเชิงลึกเริ่มต้นที่ฉลาดที่สุด พวกเขาคือทีมที่วนรอบได้เร็วที่สุดและซื่อสัตย์ที่สุด ความเร็วในการเรียนรู้ ไม่ใช่ความเร็วในการส่งมอบ คือความได้เปรียบในการแข่งขัน