วิธีถามลูกค้าว่าต้องการอะไรนั้นไม่ได้ผล

 (techbooks.substack.com)
8 คะแนน โดย GN⁺ 2024-01-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในการหารือเรื่องโรดแมปผลิตภัณฑ์ ฝ่ายขาย การตลาด R&D และผู้รับผิดชอบธุรกิจต่างก็พูดถึงลูกค้า แต่หากพลาด งาน (job) ที่ลูกค้า “จ้าง” ผลิตภัณฑ์ให้ทำ เกณฑ์ตัดสินใจก็จะพร่าเลือน
  • Intuit ไล่ตาม คำขอฟีเจอร์ 150 รายการ ที่ได้จากแบบสำรวจจนตกอยู่ในภาวะ feature chase และไม่มีเข็มทิศในการแยกว่าฟีเจอร์ใดสำคัญจริง
  • ในกรณีมิลก์เชก การถามเรื่องรสชาติ ราคา และเนื้อสัมผัสไม่ได้ช่วยเพิ่มยอดขาย แต่เมื่อสังเกตสถานการณ์การซื้อ ก็พบว่า เส้นทางไปทำงานที่ยาวนานและความหิว ของผู้เดินทางตอนเช้าคือ job หลัก
  • แม้จะเป็นมิลก์เชกเหมือนกัน ตอนเช้าจะแข่งขันกับเบเกิล โปรตีนบาร์ และน้ำผลไม้ ส่วนตอนบ่ายจะแข่งขันกับตัวเลือกขนมสำหรับเด็ก ทำให้ เกณฑ์การประเมินและผลิตภัณฑ์คู่แข่ง แตกต่างกัน
  • หากต้องการค้นหา Job to be done ต้องสังเกตปัญหาใกล้ตัว ตัวเลือกที่จะไม่ทำอะไรเลย พฤติกรรมเลี่ยงทาง พฤติกรรมที่ผู้คนพยายามหลีกเลี่ยง และการใช้งานที่ผิดปกติ

เหตุผลที่คำขอลูกค้าไม่อาจเป็นเข็มทิศของโรดแมปได้

  • ในการประชุมโรดแมป แต่ละแผนกนำอินพุตจากลูกค้าที่แตกต่างกันเข้ามา
    • ฝ่ายขายมองว่าตนรู้ความต้องการที่เร่งด่วนที่สุด เพราะพูดคุยกับลูกค้าอยู่ตลอด
    • การตลาดมองว่าสามารถใช้แบรนด์เดิมทำเวอร์ชันใหม่ รสชาติใหม่ สีใหม่ และข้อเสนอพิเศษได้
    • R&D มุ่งเน้นฟีเจอร์และประโยชน์ที่มาจากเทคโนโลยีหรือการประยุกต์ใช้ใหม่
    • ผู้รับผิดชอบธุรกิจต้องการการเปิดตัวที่ช่วย P&L ได้ภายในสิ้นปี
  • แต่ละแนวทางมีเหตุผลอยู่บางส่วน แต่อาจตกอยู่ใน confirmation bias คือเห็นเฉพาะข้อมูลที่สนับสนุนมุมมองของตน
  • ปัญหาที่ใหญ่กว่าคือ ไม่มีโมเดลใดสะท้อน job ของลูกค้า โดยตรง

การไล่ตามฟีเจอร์ที่ Intuit ติดกับ

  • Intuit ทำแบบสำรวจอย่างกว้างขวางเพื่อถามลูกค้าว่าต้องการฟีเจอร์ใหม่อะไร และลูกค้าก็เสนอรายการฟีเจอร์ที่อยากได้ยาวเหยียด
  • Cook อดีต CEO ของ Intuit ระบุว่าลูกค้าขอ “ฟีเจอร์ 150 รายการ” และทีมพัฒนาถกเถียงกันอยู่นานหลายสัปดาห์ว่าฟีเจอร์ใดสำคัญกว่า
  • สมาชิกทีมทุกคนเชื่อว่านั่นเป็นทางเลือกที่เหมาะกับลูกค้า แต่ในความเป็นจริงไม่มีเกณฑ์ตัดสิน
  • หากไม่รู้ว่าลูกค้าตั้งใจจะ “จ้าง” ผลิตภัณฑ์ไปใช้ทำงานอะไร ก็ยากจะแยกฟีเจอร์ที่ถูกต้องออกมาได้ และ Cook เปรียบเทียบสถานการณ์นี้ว่าเหมือน เดินเรือโดยไม่มีเข็มทิศ

เหตุผลที่ยอดขายมิลก์เชกไม่เพิ่มขึ้น

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

job ของมิลก์เชกยามเช้าที่เปิดเผยผ่านการสังเกต

  • เปลี่ยนคำถามเป็น “ผู้คนมาที่ร้านนี้และจ้างมิลก์เชกเพื่อแก้ปัญหาอะไร”
  • ทีมสังเกตลูกค้าในร้านเป็นเวลา 18 ชั่วโมงตลอดทั้งวัน
    • ซื้อมิลก์เชกเมื่อไร
    • แต่งตัวอย่างไร
    • มาคนเดียวหรือไม่
    • ซื้ออาหารอื่นด้วยหรือไม่
    • ดื่มในร้าน หรือขึ้นรถแล้วออกไป
  • มิลก์เชกขายได้มากก่อน 9 โมงเช้า และผู้ซื้อมักมาคนเดียว ซื้อแค่มิลก์เชก แล้วขับรถออกไป
  • job ร่วมของลูกค้าตอนเช้าคือการทนกับ เส้นทางไปทำงานที่ยาวนานและน่าเบื่อ และหลีกเลี่ยงความหิวช่วงสาย
  • มีทางเลือกคู่แข่งอยู่ แต่ไม่มีทางเลือกใดสมบูรณ์แบบ
    • กล้วยกินหมดเร็วเกินไป ทำให้หิวอีกครั้งช่วงสาย
    • โดนัทมีเศษร่วงและทำให้นิ้วเหนียว จนเสื้อผ้าและพวงมาลัยสกปรก
    • เบเกิลมักแห้งและไม่อร่อย อีกทั้งมีปัญหาที่ต้องทาครีมชีสหรือแยมขณะขับรถ
  • มิลก์เชกต้องใช้เวลานานในการดูดเครื่องดื่มข้นผ่านหลอดเล็ก จึงช่วยเติมเวลา ทำให้อิ่มได้ตลอดช่วงเช้า และใส่ใน ที่วางแก้ว ได้

ผลิตภัณฑ์เดียวกันก็แข่งขันกับสิ่งต่างกันในแต่ละช่วงเวลา

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

เบาะแส 5 ข้อในการค้นหา Job to be done

  • 1. ค้นหา job ใกล้ตัว

    • แม้ในโลกที่ขับเคลื่อนด้วยข้อมูล นวัตกรรมใหญ่บางส่วนก็เริ่มจากสัญชาตญาณเกี่ยวกับ Job to be done
    • Khan Academy เริ่มจากการที่ Sal Khan อยากช่วยให้ลูกพี่ลูกน้องเรียนคณิตศาสตร์โดยไม่เครียด และมีคนจำนวนมากที่รู้สึกเจ็บปวดแบบเดียวกัน

  • 2. แข่งขันกับตัวเลือกที่จะไม่ทำอะไรเลย

    • หากผู้บริโภคหาโซลูชันที่ตอบสนอง job ของตนไม่ได้ ก็อาจเลือกไม่ทำอะไรเลย
    • บริษัทไม่ควรมองแค่วิธีแย่งส่วนแบ่งจากคู่แข่งเดิม แต่ควรมองด้วยว่าความต้องการที่มองไม่เห็นอยู่ที่ไหน
    • ตามคำกล่าวของ Chip Conley หัวหน้าฝ่าย hospitality และกลยุทธ์ระดับโลกของ Airbnb “แขก” ของ Airbnb 40% ตอบว่าหากไม่มี Airbnb พวกเขาคงไม่เดินทาง หรือไม่ก็พักกับครอบครัว

  • 3. ดูพฤติกรรมเลี่ยงทางและพฤติกรรมชดเชย

    • OpenTable เกิดจาก พฤติกรรมเลี่ยงทาง เก่าแก่ที่อยู่รอบการจองร้านอาหาร
    • หลังจากนัดเวลาที่เพื่อนๆ สะดวกตรงกันแล้วโทรหาร้านอาหาร แต่หากไม่มีที่ว่าง ก็ต้องติดต่อเพื่อนๆ อีกครั้งและวนหาทางเลือกร้านอื่นซ้ำไปมา
    • OpenTable แก้ job ด้านการจองนี้

  • 4. ค้นหาสิ่งที่ผู้คนไม่อยากทำ

    • Clayton Christensen เรียกสิ่งนี้ว่า negative jobs และ job เชิงลบอาจเป็นโอกาสด้านนวัตกรรมที่ดี
    • Rick Krieger ศิษย์เก่า Harvard Business School และพาร์ตเนอร์ของเขาเริ่ม QuickMedx หลังจากต้องรอหลายชั่วโมงในห้องฉุกเฉินเพื่อตรวจคออักเสบของลูกชาย ซึ่งต่อมากลายเป็นต้นแบบของ CVS MinuteClinics
    • CVS MinuteClinic สามารถดูแลผู้ป่วยที่ไม่ได้จองทันที และพยาบาลเวชปฏิบัติสามารถสั่งยาให้โรคทั่วไป เช่น เยื่อบุตาอักเสบ หูติดเชื้อ และคออักเสบได้
    • เพราะมีคนจำนวนมากที่ไม่อยากไปพบแพทย์หากไม่จำเป็น MinuteClinic จึงเกิดขึ้นในร้านขายยา CVS มากกว่า 1,000 แห่งใน 33 รัฐ

  • 5. ดูการใช้งานที่ผิดปกติ

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

คำถามที่ดีกว่า

  • W. Edwards Deming กล่าวว่า “ถ้าไม่รู้จักตั้งคำถามที่ถูกต้อง คุณก็จะค้นพบอะไรไม่ได้เลย”
  • คำถามที่ดีกว่าไม่ใช่การถามลูกค้าว่าต้องการอะไร แต่คือการถามว่า “คุณจ้างผลิตภัณฑ์นั้นให้ทำงานอะไร”

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-01-01
ความเห็นจาก Hacker News

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

    • ปัญหาคือไม่มีใครขุดลงไปถึงต้นตอจริง ๆ และเพราะแบบนั้นจึงมองว่าผู้รับผิดชอบผลิตภัณฑ์ 80% ให้ผลสุทธิติดลบ
      ถ้าใครเรียกร้องอะไรสักอย่าง ต้องไล่ถามเหตุผล สมมติว่ามีคนไปอู่แล้วบอกให้เปลี่ยนไดชาร์จ ถ้าช่างเปลี่ยนให้เลย ลูกค้าก็อาจยังไม่พอใจ แต่ถ้าถามว่า “ทำไมต้องเปลี่ยน” แล้วพบว่าปัญหาจริงคือโซลินอยด์ การแก้ตรงนั้นก็จะตอบโจทย์เป้าหมายจริงคือการเดินทางได้
      เพราะแบบนี้ นักพัฒนาอาวุโส จึงมักมีเซนส์ด้านผลิตภัณฑ์ดีกว่าคนดูแลผลิตภัณฑ์เสียอีก คนที่เขียนโค้ดมา 1-2 ปีแล้วไปสอบใบรับรองก่อนย้ายสายมาทำงานผลิตภัณฑ์ ยากจะสู้ความลึกของคนมากประสบการณ์ได้
      ไม่ว่าสมมติฐานจะเป็นอะไร ถ้าไม่คุยและไม่ขุดให้ลึก ก็จะลงเอยด้วยการตัดสินใจที่ด้อยกว่า
    • ถ้าจะหาตัวอย่างโต้แย้งอุปมาเรื่อง “ม้าที่เร็วขึ้น” ก็ให้นึกถึง Segway คนอาจต้องการวิธีเดินทางในเมืองที่เร็วกว่าเดินจริง ๆ ก็ได้
      เห็นด้วยเต็มที่กับการใช้การวิจัยผู้ใช้เพื่อทำความเข้าใจทั้งพื้นที่ของปัญหาและพื้นที่ของฟีเจอร์ แต่ในความเป็นจริงกลับเห็นคนทำ Segway มากกว่านักประดิษฐ์รถยนต์เสียอีก
      หลายครั้งมันถูกสร้างจากสัญชาตญาณของผู้ก่อตั้งหรือการวิจัยผู้ใช้ที่แย่มาก แล้วก็มองข้ามคำขอของลูกค้าแบบเบา ๆ ว่าเป็นแค่ “ม้าที่เร็วขึ้น” ฉันไม่มีทั้งเวลา พลังงาน หรือความตั้งใจจะไปปรับตัวเข้ากับเวิร์กโฟลว์แบบสั่งทำที่ถูกเพิ่มเข้ามาโดยตั้งอยู่บนสมมติฐานว่าฉันไม่รู้จักงานของตัวเอง
      ระหว่าง B2C กับ B2B น่าจะมีความต่างอยู่ แต่เวลาเห็นคำแนะนำแบบนี้กลับแทบไม่เห็นการแยกแยะนั้น ฉันรู้ว่าเจตนาไม่ใช่ให้เพิกเฉยต่อฟีดแบ็กผู้ใช้ แต่เห็นคนตีความแบบนั้นบ่อยเกินไปจนคิดว่าน่าจะต้องมีอุปมาใหม่แล้ว
    • สรุปคือมันใกล้เคียงกับ “อย่าฟังสิ่งที่ลูกค้าพูดอย่างเดียว แต่ให้สังเกตลูกค้า”
      แน่นอนว่าไม่ควรรับมาแบบตรงตัวทั้งหมด แต่การ สังเกตพฤติกรรม ของผู้ใช้มักให้มุมมองที่ลึกกว่าการถามว่าพวกเขาต้องการอะไร เพียงแต่ต้องออกแบบสภาพแวดล้อมการสังเกตให้ดี เพื่อจะได้รู้ว่ากำลังพยายามเรียนรู้อะไร
    • วิดีโอเกมก็เป็นตัวอย่างที่ดี เกมเมอร์ โดยเฉพาะในเกมจำลองสถานการณ์ มักเสนอไอเดียที่ตอนแรกดูเท่มากแต่จริง ๆ แล้วไม่สนุก
      เช่น “ควรเดินไปมาภายในยานอวกาศได้ และออกไปเดินอวกาศเพื่อซ่อมตัวถังหลังโดนไมโครอุกกาบาตชน” อะไรทำนองนั้น
      ในทางกลับกัน บริษัทหรือผู้พัฒนาก็มักใช้ตรรกะนี้เกินเลย แล้วไปโทษว่าผู้เล่นที่ไม่สนุกกับเกมของตัวเองเป็นฝ่ายผิด
    • ปัญหาการเชื่อความต้องการลูกค้าที่พนักงานขายเล่ามาแบบตรง ๆ นั้น พบได้บ่อยมาก และก็ยากจะป้องกันในระดับองค์กร
      เพราะฝ่ายขายเป็นกลุ่มที่สัมผัสผู้ใช้มากที่สุด ผู้จัดการผลิตภัณฑ์จึงมักเผลอตามสิ่งที่พวกเขาพูดไปตรง ๆ

  • ถ้าทำงานซัพพอร์ตทางอีเมลเยอะ ๆ จะเจอกรณีที่ ปัญหา XY ปลอมตัวมาเป็นคำขอฟีเจอร์บ่อยมาก https://en.m.wikipedia.org/wiki/XY_problem
    มีคนขอฟีเจอร์เข้ามา และส่วนใหญ่ก็มักเพิ่มได้ไม่ยาก แต่ก่อนอื่นต้องพยายามเข้าใจปัญหารากก่อน ลูกค้ามักไม่ได้บอกปัญหา แต่บอกวิธีแก้ของตัวเอง และวิธีนั้นอาจเป็นแนวทางที่แย่หรือผิดไปเลยก็ได้
    ถ้าจะเพิ่มฟีเจอร์อย่างสวยงามและทำเอกสารให้คนอื่นใช้ประโยชน์ต่อได้ด้วย ก็จำเป็นต้องเข้าใจความเจ็บปวดจริงที่ฟีเจอร์นั้นกำลังแก้อยู่
    “หาความเจ็บปวดแล้วกำจัดมัน” ก็เป็นเทคนิคการขายที่ทรงพลังด้วย บางครั้งฟีเจอร์ถูกเพิ่มเพราะความเจ็บปวดของทีมขายเอง ไม่ใช่ของลูกค้า และฟีเจอร์ที่ลูกค้าตัวจริงไม่ใช้ก็อาจถูกใส่มาเพียงเพราะผู้มีอำนาจตัดสินใจคิดว่าสำคัญและมันเดโมได้ดี

    • ในบรรดาคำขอที่มาจากในองค์กรเอง ก็มีไม่น้อยที่ฝั่งธุรกิจอธิบายไม่ได้ด้วยซ้ำว่าต้องการไปทำไม แค่ประมาณว่า “น่าจะต้องเช็กไว้ ก็เลยเช็ก”
      โดยเฉพาะตอน เปลี่ยนซอฟต์แวร์ legacy จะมีแรงกดดันให้ย้ายของจุกจิกที่แทบมั่นใจได้ว่าไม่มีใครใช้แล้ว และต้นทุนในการทำก็สูงกว่าคุณค่าที่ได้เสมอ
      ตัวอย่างเช่น มีคนฝั่งธุรกิจที่ปล่อยรายงานบางชุดซึ่งไม่มีใครอ่านจริง ๆ ไม่ลง

  • บทความดี แต่เกลียดชื่อเรื่องจริง ๆ มีเรื่องให้ต้องถามลูกค้าเยอะมาก แต่มีน้อยมากที่ควร รับตามตัวอักษร
    การเอาฟีเจอร์ที่ลูกค้าขอไปทำตรง ๆ คือทางลัดสู่ความล้มเหลว และต้องถามต่อ ขุดต่อ ให้เกินกว่าประโยค “ช่วยให้ทำ X ได้”
    ถ้าจะพูดอย่างเป็นธรรม ตัวบทความเองก็พูดเรื่องนี้อยู่เหมือนกัน แต่เบื่อชื่อแนวซ้ำ ๆ แบบนี้แล้ว
    เห็นด้วยกับคำแนะนำให้อ่าน Christensen และ Deming และอยากเพิ่ม Sidney Dekker ด้วย โดยเฉพาะ "Field Guide to Human Error" ดีมาก และเล่มอื่น ๆ ของเขาก็น่าจะดีเหมือนกัน

    • ต้องฟังลูกค้าเยอะ ๆ แต่แทบไม่ควรรับตามตัวอักษรเลย ข้อยกเว้นคือคำถามอย่าง “จะเซ็นใบสั่งซื้อเดี๋ยวนี้เลยไหม?”
      หนึ่งในวิธีที่ดีที่สุดในการตรวจสอบว่าโซลูชันนั้นเป็นของจริงและขายลูกค้าได้หรือไม่ คือถามว่า “คุณจะซื้อสิ่งนี้ตอนนี้ไหม?” ถ้าคำตอบคือ “ครับ ส่งใบแจ้งหนี้มาแล้วดำเนินการสั่งซื้อกันเลย” ก็แปลว่าได้ตรวจสอบอะไรบางอย่างแล้ว
      ในทางกลับกัน ถ้าเป็นปฏิกิริยาแบบ “อืม น่าจะนะ เดี๋ยวจะไปคุยกับคณะกรรมการจัดซื้อก่อน” ก็แปลว่ายังคลำทางอยู่
      ถึงแม้ผลิตภัณฑ์จะยังไม่พร้อมขายจริง อย่างที่ Steve Blank พูดไว้ ก็ยังถามต่อได้ว่า “ถ้าต้องจ่ายหนึ่งล้านดอลลาร์ตอนนี้ จะจ่ายไหม?”, “งั้นจะจ่ายเท่าไร?”, “ถ้าให้ฟรี จะนำไปใช้ทันทีไหม?” คำตอบเหล่านี้ช่วยบอกได้ว่าสิ่งนั้นมีสถานะจริง ๆ แค่ไหนในสายตาลูกค้า
      https://www.amazon.com/Four-Steps-Epiphany-Steve-Blank/dp/09...
    • ต้องฟังลูกค้า เรียนรู้ธุรกิจของพวกเขา และช่วยให้มันดีขึ้น การถามแล้วทำตามตรง ๆ กับการ ฟังแล้วสังเคราะห์ เป็นคนละเรื่องกัน
    • ยังไม่ค่อยพอใจกับชื่อเรื่องเท่าไร การหาชื่อที่ทั้งสะดุดตาและยังใกล้เคียงความจริงนั้นยาก เลยสงสัยว่าชื่อแบบไหนจะเหมาะดี

  • จากประสบการณ์ ลูกค้าไม่รู้ว่าตัวเองต้องการอะไร จึงมีเหตุผลที่ผู้ก่อตั้งอยากสร้างบางอย่างที่แก้ปัญหานั้นได้ดีกว่า
    ฉันเกลียดคำแนะนำที่ว่า “อย่าสร้างก่อนจะตรวจสอบ” จริง ๆ สำหรับฉันมันไม่เคยได้ผลเลยแม้แต่ครั้งเดียว และเหมือนกับการถามนำไปพร้อมกับยิงเท้าตัวเอง
    ต้องมี ความมั่นใจ ว่าทำสิ่งนี้ไปเพื่ออะไร ถ้าเป็นคนที่กระโดดเข้าไปในอุตสาหกรรมที่ตัวเองไม่รู้อะไรเลย โอกาสล้มเหลวคือ 99% ถ้ารู้ว่าตัวเองกำลังทำอะไร โอกาสสำเร็จก็ควรจะเกิน 60%
    สินค้าที่คนเข้าใจได้ตั้งแต่แรกเห็นว่ามันช่วยแก้ปัญหาได้ ขายได้ง่าย เพราะคุณเคยเจอปัญหาเดียวกันและลงมือจะแก้มัน

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

  • คำพูดซ้ำซากที่ว่า “ถ้า Henry Ford ถามผู้คนว่าต้องการอะไร พวกเขาคงตอบว่าอยากได้ม้าที่วิ่งเร็วขึ้น” ไม่ได้กลายเป็นคำพูดซ้ำซากโดยไร้เหตุผล คนส่วนใหญ่ไม่รู้ว่าตัวเองต้องการอะไร จึงเป็นเหตุผลว่าทำไมนักออกแบบผลิตภัณฑ์ที่เก่งถึงได้รับค่าตอบแทนสูง
    สิ่งที่ต้องแยกให้ออกคือ วิสัยทัศน์ของผลิตภัณฑ์ กับวิธีรับฟังฟีดแบ็ก
    การออกแบบผลิตภัณฑ์ใหม่ที่แก้ปัญหาให้ผู้คนไม่มีสูตรลับอะไร มันเป็นทักษะที่ผสมกันระหว่างประสบการณ์ สัญชาตญาณ ความเข้าใจเทคโนโลยี การสังเกตทางเลือกที่มีอยู่เดิม และการคาดการณ์การเปลี่ยนแปลงทางเทคนิค เศรษฐกิจ และสังคม
    ส่วนการรับฟังฟีดแบ็กคือการตรวจว่าของที่ออกแบบมาทำงานตามที่ตั้งใจไว้หรือไม่ อะไรทำให้ผู้ใช้สับสน และอะไรเป็นอุปสรรค ตรงนี้วิธีคลาสสิกอย่างการสังเกตผู้ใช้ การทดสอบ และแบบสำรวจยังมีประโยชน์
    มันดูเหมือนง่าย แต่จริง ๆ ไม่ง่ายเลย ฉันเห็นนักออกแบบจำนวนมากที่ไม่ยอมผ่อนหลักการของตัวเองแม้ความเป็นจริงจะขัดกับอุดมการณ์ และเห็นบริษัทที่ไม่ยอมแก้บั๊กซึ่งผู้ใช้ส่วนใหญ่เจอและโกรธกันในฟอรัมซัพพอร์ตกับโซเชียลมีเดียอย่าง inexplicably
    ทักษะสองอย่างนี้ต่างกันมาก อย่างหนึ่งก็ยากจะทำให้เก่งอยู่แล้ว และยิ่งยากกว่าอีกถ้าจะเก่งทั้งคู่ บทความใช้ Intuit เป็นกรณีศึกษา แต่กลไกที่ทำงานได้ยอดเยี่ยมในธุรกิจที่ล็อบบี้รัฐบาลให้คงพิษไว้แล้วค่อยขายยาถอนพิษนั้น ปล่อยให้ผู้อ่านคิดต่อเอง

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

  • ลูกค้าต้องการลดความเจ็บปวดจากการยื่นภาษี แต่ Intuit กลับล็อบบี้รัฐบาลเพื่อให้ความเจ็บปวดนั้นยังคงอยู่แบบเข้มข้น

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

  • กับดักที่พบบ่อยซึ่งบทความไม่ได้พูดถึงคือการไปฟัง ลูกค้าส่วนน้อยที่เสียงดัง
    ถ้าคุณอ่านแค่ Hacker News หรือแพลตฟอร์มที่เป็นมิตรกับสายเทคโนโลยีอื่น ๆ ก็ไม่แปลกที่จะคิดว่ามีความต้องการมหาศาลสำหรับ iPhone ที่จอเล็กแต่แรง
    แต่ในความเป็นจริง ยอดขาย iPhone mini น่าผิดหวัง นั่นหมายความว่าคนที่เขียนเรื่องฮาร์ดแวร์เทคโนโลยีออนไลน์มายาวนานไม่ได้เป็นตัวแทนของฐานลูกค้า iPhone ทั้งหมด

    • ฉันไม่รู้ว่าใครกันแน่ที่มองว่ายอดขาย iPhone mini น่าผิดหวัง มันขายได้มากกว่าโทรศัพท์ Android ส่วนใหญ่ และมากกว่า iPhone รุ่นแรก ๆ หลายเท่าด้วยซ้ำ iPhone 3G, 3GS, 4 ก็น่าผิดหวังเหมือนกันหรือ
      สัดส่วนที่ต่ำไม่ได้แปลว่า จำนวนเครื่องที่จัดส่ง ต่ำ
      ตามความเป็นจริง ไม่ว่าคุณจะสร้างบริษัทแบบไหน ก็มีแนวโน้มว่าจะขายได้น้อยกว่า iPhone Mini มาก ถ้าอย่างนั้นเพียงเพราะยอดขายน่าผิดหวังตามมาตรฐานของ Apple บริษัทนั้นควรโดนไล่ออกและล้มละลายหรือ? บริษัทที่ขายได้ต่ำกว่า 20 ล้านเครื่องควรถูกชำระบัญชีทั้งหมดหรือ? บริษัทที่เจาะฐานลูกค้าเล็กกว่ายอดจัดส่งของ iPhone ขนาดเล็กไม่ควรมีอยู่ และควรถูกแทนที่ด้วยผลิตภัณฑ์กลาง ๆ สำหรับคนทั่วไปหรือ? Mac Studio, จอ XDR และ MacBook 15 นิ้วราคา 4,000 ดอลลาร์ก็ควรหายไปด้วยหรือ?
    • หมายถึงน่าผิดหวังตามมาตรฐานของ Apple นั่นแหละ คือขายได้แค่ระดับหลายสิบล้านเครื่อง
      ฉันรู้จักคนอยู่ไม่กี่คนที่พอใจกับ iPhone mini มาก และตอนนี้พวกเขาไม่มีอะไรให้อัปเกรดแล้ว ถึงอย่างนั้นฝั่งนี้ก็ยังถูกกว่าอยู่ดี

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

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