- สตาร์ทอัพแห่งหนึ่งให้ วิศวกรเข้าร่วมเซลส์คอลด้วยตัวเอง จนทำให้แนวทางการพัฒนาผลิตภัณฑ์เปลี่ยนไปอย่างรากฐาน
- ระหว่างเซลส์คอล พวกเขาพบว่าผลิตภัณฑ์ของคู่แข่ง ซับซ้อนเกินไปสำหรับผู้ใช้ที่ไม่ใช่สายเทคนิค และลูกค้าไม่ได้ต้องการล็อกหรือเมตริกมากมาย แต่แค่อยากได้ เครื่องหมายยืนยันว่าใช้งานได้ (เครื่องหมายถูกสีเขียว) และมักถามว่า "ไม่มีใครทำให้แทนได้เหรอ"
- จากสิ่งนี้ ทีมที่เคยมองจากมุมแบ็กเอนด์เป็นหลักก็เริ่มเข้าใจมุมมองของผู้ใช้ และเริ่มออกแบบสถาปัตยกรรมใหม่ด้วยตัวเองโดยไม่ต้องให้ PM เข้ามาแทรก
- ภายในเวลาเพียง 2 สัปดาห์ พวกเขา ตัดฟีเจอร์ออก 60%, เพิ่ม แถบความคืบหน้า, สร้าง การเชื่อมต่อกับ Slack และฟีเจอร์ เวิร์กโฟลว์แบบทำให้เสร็จแทน จนสุดท้าย ตั๋วซัพพอร์ตลดลง 70%
- บทเรียนจากประสบการณ์นี้คือ ผู้ใช้ต้องการแค่การแก้ปัญหา ไม่ได้สนใจโค้ดที่สวยงาม และทุกฟีเจอร์ก็มีต้นทุน ไม่ใช่ในรูปของจำนวนโค้ด แต่เป็น ความสับสนของผู้ใช้
พื้นหลังและการทดลอง
- วิศวกรอาวุโสฝั่ง DevOps เคยคัดค้านการเข้าร่วมเซลส์คอล แต่ก็ยอมภายใต้เงื่อนไขว่าลองอย่างน้อย 5 คอล
- ผู้ก่อตั้งมองว่าถ้าวิศวกรไม่ได้ยินภาษาและปัญหาของลูกค้าด้วยตัวเอง การออกแบบผลิตภัณฑ์ก็จะไม่เปลี่ยน
อินไซต์ที่ได้จากเซลส์คอล
- ลูกค้าบอกว่าผลิตภัณฑ์ของคู่แข่ง ซับซ้อนเกินไปสำหรับผู้ใช้ที่ไม่ใช่สายเทคนิค
- ลูกค้าต้องการการยืนยันที่เข้าใจง่ายอย่าง เครื่องหมายถูกสีเขียว มากกว่าตัวชี้วัดที่ซับซ้อน
- ลูกค้าจำนวนมากขอ "บริการแบบทำแทน" เพราะไม่ได้ต้องการแค่ใช้งานเอง แต่อยากจ้างให้มีคนแก้ปัญหาให้เลย
ผลลัพธ์จากการเขียนผลิตภัณฑ์ใหม่
- ทีม ลบฟีเจอร์เดิมออก 60% และโฟกัสเฉพาะสิ่งที่จำเป็น
- เพิ่ม แถบความคืบหน้า แบบเรียบง่ายเพื่อปรับปรุงประสบการณ์ใช้งาน
- ทำ Slack integration เพื่อให้ขั้นตอนการสอบถามลื่นไหลขึ้น
- เพิ่ม Done-for-you workflow เพื่อสะท้อนความต้องการของลูกค้าโดยตรง
- ท้ายที่สุด ตั๋วซัพพอร์ตลดลง 70% และการใช้งานรวมถึงความพึงพอใจต่อผลิตภัณฑ์ก็ดีขึ้นอย่างมาก
บทเรียนสำคัญ
- ผู้ใช้ไม่ได้ต้องการทางออกเชิงเทคนิคที่สวยหรู แต่ต้องการให้ปัญหาถูกแก้จริง
- ความเข้าใจผู้ใช้สำคัญกว่าความแม่นยำทางเทคนิค
- ทุกฟีเจอร์มีต้นทุน ไม่ใช่เป็นโค้ด แต่เป็นความสับสนของผู้ใช้
การเปลี่ยนแปลงด้านวัฒนธรรมทีม
- หลังจากนั้น บริษัทกำหนดให้ วิศวกรทุกคนต้องเข้าร่วมเซลส์คอล 5 ครั้งต่อไตรมาส
- การที่วิศวกรได้ฟังความเหนื่อยล้าของลูกค้าด้วยตัวเอง และได้ยินคำขอแบบ "ขอแค่ให้มันทำงานได้ดีก็พอ" กลายเป็นส่วนหนึ่งของวัฒนธรรมที่ช่วยสร้างสัญชาตญาณด้านผลิตภัณฑ์
สรุปประเด็นสำคัญจากคอมเมนต์ใน Reddit
- ข้อถกเถียงเรื่องบทบาท PM
- บางคนชี้ว่าปัญหาคือการไม่มี Product Manager ที่ดี และมองว่าการให้วิศวกรต้องคุยกับลูกค้าเองเป็นเรื่องไม่มีประสิทธิภาพ
- ขณะที่อีกฝ่ายแย้งว่า “PM เป็นแค่ตัวแปล” และผลลัพธ์ที่ดีที่สุดเกิดขึ้นเมื่อวิศวกรรับผิดชอบปัญหาของลูกค้าโดยตรง
- คุณค่าของการสัมผัสลูกค้าโดยตรง
- หลายคอมเมนต์เน้นว่าประสบการณ์ที่วิศวกรได้ ฟังเสียงผู้ใช้โดยตรง ให้อินไซต์ที่ทรงพลังมาก
- ยังมีความเห็นว่าในสตาร์ทอัพระยะเริ่มต้นหรือทีมขนาดเล็ก วิศวกรมักทำหน้าที่ PM ไปพร้อมกันบางส่วน เป็นเรื่องปกติ
- มุมมองเชิงวิจารณ์
- มีคำวิจารณ์ว่า “นี่คือการผลัก ความล้มเหลวของผู้นำ/วัฒนธรรม ไปให้วิศวกรรับแทน”
- บางคนก็ตั้งคำถามว่า “การตัดฟีเจอร์และทำให้ง่ายลงคือการปรับปรุงจริงหรือ” พร้อมเตือนว่าระยะยาวอาจ มองข้ามผู้ใช้ระดับสูงและความต้องการฟีเจอร์ขั้นสูง
- การแชร์กรณีเชิงบวก
- มีหลายประสบการณ์จากอุตสาหกรรมอย่างธนาคารและอุปกรณ์การแพทย์ ที่ใช้แนวทางให้ พนักงานทุกคนลองทำงานซัพพอร์ตหรืองานขายกับลูกค้า
- หลายคนเห็นตรงกันว่า “Dogfooding” หรือ “การได้ยืนอยู่ต่อหน้าลูกค้าด้วยตัวเอง” ช่วยทั้งคุณภาพผลิตภัณฑ์และวัฒนธรรมทีม
- ข้อสรุปโดยรวม
- การทำให้ทีมได้สัมผัสปัญหาของลูกค้าโดยตรงเป็น เครื่องมือการเรียนรู้ที่ทรงพลัง
- แต่ในระยะยาว ประเด็นสำคัญคือจำเป็นต้องผสานสิ่งนี้เข้ากับ ความเชี่ยวชาญด้าน PM, UX และการออกแบบ เพื่อสร้างกลยุทธ์ผลิตภัณฑ์ที่สมดุล
ยังไม่มีความคิดเห็น