ขนาดของ Backlog แปรผกผันกับความถี่ในการพูดคุยกับลูกค้า

 (bitbytebit.substack.com)
13 คะแนน โดย GN⁺ 2024-01-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ยิ่งพูดคุยกับลูกค้าบ่อยเท่าไร ขนาดของ backlog ก็ยิ่งเล็กลง
  • สิ่งสำคัญคือการแทนที่เวลาที่ใช้วางแผนด้วยการพูดคุยกับลูกค้า
  • ยิ่งมีคนกลางระหว่างนักพัฒนากับลูกค้ามากเท่าไร ผลิตภัณฑ์ก็ยิ่งไม่สามารถตอบสนองความต้องการของลูกค้าได้
  • backlog ที่ใหญ่หมายถึงมีสมมติฐานที่ยังไม่ได้รับการตรวจสอบจำนวนมาก และมีโอกาสสร้างคุณค่าให้ลูกค้าได้ต่ำ

ควรโฟกัสที่การออกแบบองค์ประกอบทางเทคนิคมากกว่าการออกแบบ UI

  • อย่าใช้เวลากับการออกแบบ UI มากเกินไป แต่ควรปล่อย UI พื้นฐานออกมาอย่างรวดเร็ว แล้วปรับปรุง UI ผ่าน feedback จากลูกค้า
  • ต้องรักษา technical debt ให้อยู่ในระดับต่ำ เพื่อให้สามารถเปลี่ยนแปลงตามที่ลูกค้าต้องการได้อย่างรวดเร็ว

วิธีที่ผู้คนคิดว่าจะใช้แอป กับวิธีที่ใช้จริงนั้นต่างกัน

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

การทำ Account Spoofing

  • การลงทุนกับฟีเจอร์ account spoofing มีความสำคัญ เพื่อทำความเข้าใจว่าลูกค้าแต่ละรายกำลังเห็นหน้าจอแบบใดอยู่จริง
    • Account Spoofing คือฟีเจอร์ที่ทำให้ผู้ดูแลระบบสามารถใช้งานแอปราวกับเป็นผู้ใช้จริงใน production ได้
  • วิธีนี้ช่วยให้วินิจฉัยปัญหาได้อย่างมีประสิทธิภาพ และลดการพึ่งพา test data

ความสำคัญของหน้าแรก

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

ลูกค้าคือนักการตลาดที่สำคัญที่สุด

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

MVP ไม่มีความหมายหากไม่มีการปรับปรุงซ้ำอย่างต่อเนื่อง

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

ความเห็นของ GN⁺

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

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

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

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

  • ความเห็นเกี่ยวกับวิธีจัดระเบียบฟีเจอร์/รายการปรับปรุง

    • จากประสบการณ์ กลยุทธ์ที่เปลี่ยนทุกไอเดียให้เป็นตั๋วงานนั้นไม่มีประสิทธิภาพ เพราะจะทำให้เกิด "icebox" ที่เต็มไปด้วยไอเดียซึ่งจะไม่ถูกนำมาใช้เลย
    • แม้แต่ตอนที่ต้องใช้ไอเดียใน icebox เพื่อปิดดีลสำคัญ ก็ยังมักจำไม่ได้ว่าไอเดียนั้นมีอยู่แล้ว จึงสร้างตั๋วงานใหม่ขึ้นมาอีก
    • ชอบเก็บเฉพาะตั๋วงานที่มีโอกาสทำได้จริงในระยะสั้นหรือระยะกลาง ส่วนไอเดียอื่นเก็บแยกไว้ต่างหาก
    • ทีมวิศวกรรมเก็บรายการ technical debt ที่อยากแก้ ส่วน PM เก็บรายการโอกาสในการปรับปรุงแยกตามโปรเจกต์
    • สำหรับฟีเจอร์/โปรดักต์ใหม่ จะเขียน PRD แต่จะยังไม่แปลงเป็นตั๋วงานทันที
    • แบ็กล็อกขนาดมหึมาที่สุดท้ายแทบไม่ได้ทำ ส่วนใหญ่มักเป็นสัญญาณของ PM ที่อ่อนแอและกลัวการพูดว่า "ไม่"

  • ความสัมพันธ์ระหว่างขนาดของแบ็กล็อกกับอัตราการเปลี่ยน PM

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

  • ความเห็นคัดค้านเรื่องการดูแลแบ็กล็อกที่อิงจากลูกค้า

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

  • ความจำเป็นที่ PM ต้องมีที่สำหรับบันทึกความต้องการของลูกค้า

    • PM ต้องมีที่สำหรับบันทึกความต้องการของลูกค้า
    • ถ้าไม่มีเครื่องมือเฉพาะ ความต้องการเหล่านั้นส่วนใหญ่ก็จะไปจบลงเป็นตั๋วงานใน Jira
    • มีสองแนวทางคือ ProductBoard และ Jira Product Discovery
    • ProductBoard ใช้แนวทางแบบ CRM โดยบันทึกทุกปฏิสัมพันธ์กับลูกค้า แล้วค่อยแยกออกมาเป็น requirement และ wishlist ภายหลัง
    • Jira Product Discovery เริ่มจากไอเดีย แล้วบังคับให้ต้องแตกทุกอย่างที่ได้ยินจากลูกค้าออกมาเป็นรายการ requirement และ wishlist ยาว ๆ ทันที
    • ข้อดีของ Jira Product Discovery คือแยกรายการไอเดียออกจากแบ็กล็อกของนักพัฒนา แต่ก็สร้างรายการยาวอีกชุดหนึ่งขึ้นมาแทน
    • ถ้าต้องการวิเคราะห์ลำดับความสำคัญของโปรดักต์จากบทสนทนากับลูกค้า ProductBoard เป็นเครื่องมือด้าน product discovery ที่ดีกว่า

  • ความสำคัญของแบ็กล็อกที่ถูกขัดเกลาด้วยฟีดแบ็กจากลูกค้า

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

  • การจัดการแบ็กล็อกผ่านการพูดคุยกับลูกค้าในชีวิตประจำวัน

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

  • ความสำคัญของการสังเกตผู้ใช้แอป

    • การเฝ้าดูลูกค้าใช้งานแอปเป็นสิ่งสำคัญ
    • แม้จะติดตามเมตริกได้ทุกอย่าง แต่การเห็นผู้ใช้เลื่อนหาสิ่งบางอย่าง กดปุ่มย้อนกลับ หรือพยายามคลิกสิ่งที่คลิกไม่ได้ เป็นประสบการณ์ที่รับรู้ได้ชัดเจนมาก
    • อยากให้ทุกบริษัทอย่าง Apple, Google และอื่น ๆ เฝ้าดูผู้ใช้หลายครั้งต่อวัน

  • ความไร้ประโยชน์ของแบ็กล็อกขนาดใหญ่

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

  • คำเตือนเกี่ยวกับการทำ account spoofing

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

  • โครงสร้างแบบต้นไม้ของการวางแผนโปรดักต์

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