เมื่อบังคับให้วิศวกรทุกคนเข้าร่วมเซลส์คอล แพลตฟอร์มก็ถูกเขียนใหม่ทั้งหมดภายใน 2 สัปดาห์

• สตาร์ทอัพแห่งหนึ่งให้ วิศวกรเข้าร่วมเซลส์คอลด้วยตัวเอง จนทำให้แนวทางการพัฒนาผลิตภัณฑ์เปลี่ยนไปอย่างรากฐาน
• ระหว่างเซลส์คอล พวกเขาพบว่าผลิตภัณฑ์ของคู่แข่ง ซับซ้อนเกินไปสำหรับผู้ใช้ที่ไม่ใช่สายเทคนิค และลูกค้าไม่ได้ต้องการล็อกหรือเมตริกมากมาย แต่แค่อยากได้ เครื่องหมายยืนยันว่าใช้งานได้ (เครื่องหมายถูกสีเขียว) และมักถามว่า "ไม่มีใครทำให้แทนได้เหรอ"
• จากสิ่งนี้ ทีมที่เคยมองจากมุมแบ็กเอนด์เป็นหลักก็เริ่มเข้าใจมุมมองของผู้ใช้ และเริ่มออกแบบสถาปัตยกรรมใหม่ด้วยตัวเองโดยไม่ต้องให้ 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 และการออกแบบ เพื่อสร้างกลยุทธ์ผลิตภัณฑ์ที่สมดุล

[meteorizer]

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

[laeyoung]

ไม่แน่ใจว่าทำไมใน Hacker News ถึงคงลิงก์ old reddit ไว้ แต่เส้นทางไปยัง UI ของ reddit ปัจจุบัน อยู่ที่นี่

[xguru]

ดูเหมือนว่าใน Hacker News เวลาลง URL ของ Reddit ส่วนใหญ่จะใช้ old reddit กัน น่าจะเป็นเพราะมันเบากว่าด้วยครับ

[cnaa97]

หากเป็นองค์กรที่มีเป้าหมายเพื่อยกระดับมาตรฐานขั้นต่ำ ก็ยอมรับได้ว่าโครงสร้างแบบแบ่งตามบทบาท เช่น ทีมที่มีแต่นักพัฒนาเว็บฟรอนต์เอนด์ หรือทีมนักพัฒนาแอป เป็นรูปแบบที่เหมาะสม

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

หลายบริษัทจัดโครงสร้างองค์กรในลักษณะ task force เช่น การแยกบริษัทออกไปหรือการตั้งทีมขึ้นมาใหม่ แต่หากเป็นเพียงการจับคน (ตามบทบาท) มารวมกัน ก็อาจเกิดการเสริมแรงทางลบได้ (เช่นรูปแบบความคิดว่า ฉันกำลังพยายามทำบางอย่างอยู่ แต่บริษัทไม่ช่วยเลย งั้นก็ต้องยอมแพ้) และสุดท้ายอาจสูญเสียแต่บุคลากรสำคัญอย่าง key member ไปเท่านั้น ดังนั้นองค์กรที่ขับเคลื่อนด้วยเป้าหมายก็จำเป็นต้องได้รับการสนับสนุนอย่างจริงจังจากองค์กรแบบแบ่งตามบทบาทเช่นกัน

[GN⁺]

ความคิดเห็นจาก Hacker News

• ท้ายที่สุดแล้ว พวกเขาก็ออกแบบสถาปัตยกรรมใหม่ทั้งหมดได้โดยไม่มี “การทำ PM” จากผมเลย เหตุผลก็เพราะในที่สุดพวกเขาเข้าใจอย่างถูกต้องแล้วว่าคนที่ใช้ผลิตภัณฑ์ของเราจริง ๆ คือใคร ถ้ามองประสบการณ์นี้โดยรวม ข้อสรุปก็คือ “พอลองให้วิศวกรไปทำเซลส์คอล ปัญหาที่แท้จริงกลับกลายเป็นว่า PM สื่อสารระหว่างลูกค้ากับวิศวกรรมได้ไม่ดี และวิศวกร DevOps ต่างหากที่เป็นคนเปลี่ยนความต้องการของลูกค้าให้เป็นโซลูชันที่ใช้งานได้จริงอย่างรวดเร็ว”
  • บางครั้งวิศวกรมั่นใจในตัวเองมากจนคิดว่าผู้ใช้ใช้ผลิตภัณฑ์ผิดเอง ตามตรรกะแบบว่าเรื่องนี้เกิดขึ้นเพราะ “ผู้ใช้ทำตัวโง่” ไม่ใช่เพราะดีไซน์ที่ซับซ้อนของฉันมีปัญหา เอาแค่ฝั่ง Desktop Linux ก็มีประสบการณ์เมินคำบ่นผู้ใช้มากพอจะเขียนหนังสือได้ทั้งเล่มแล้ว ถ้าวิศวกรหัวแข็งคิดว่าตัวเองเหนือกว่า PM และผู้ใช้ ก็ไม่มีอะไรเดินหน้าได้ แต่ถ้าโยนวิศวกรแบบนั้นไปเผชิญหน้ากับผู้ใช้โดยตรง แทนที่จะเป็น PM ที่ปกติพูดจานุ่มนวล ก็จะกลายเป็นผู้ใช้ตัวจริงที่หงุดหงิดและวิจารณ์ “สิ่งประดิษฐ์สุดเจ๋ง” นี้ราวกับเป็นหนูแฮมสเตอร์เจ้าปัญหา กระบวนการนี้ทั้งน่ากลัวและทำลายอัตตาของวิศวกรด้วย ในมุมมองผม นี่ไม่ใช่การพิสูจน์ว่า PM โง่ แต่เป็นการทำให้วิศวกรถ่อมตัวลง พอเวลาผ่านไป ความหยิ่งของวิศวกรก็กลับมาอีก ดังนั้นกระบวนการนี้จึงจำเป็นต้องทำซ้ำเป็นระยะ
  • ผมเป็นคนเดียวในทีมวิศวกรรมเครื่องกลของบริษัทใหญ่ที่เขียนโค้ดได้ ทีม IT ภายในบริษัทพัฒนาซอฟต์แวร์หลายอย่างเอง แต่ในสายตาของคนในทีม ส่วนใหญ่ไม่ได้ดีนัก ดังนั้นผมเลยออกแบบมันขึ้นมาใหม่เอง หรือไม่ก็สร้างเครื่องมือมาเสริมโปรแกรม “ไม่ค่อยดี” ที่แทนไม่ได้จริง ๆ เพื่อให้ทำงานง่ายขึ้น ผมไม่ได้คิดว่าตัวเองพัฒนาเก่งกว่าทีม IT ภายใน เพียงแต่เพราะมองจากมุมผู้ใช้จริง เลยเข้าใจได้ดีกว่าว่าตัวผมเอง หรือก็คือทีมของเรา ต้องการอะไรจริง ๆ และเพราะผมเป็นคนที่ใช้ซอฟต์แวร์นี้เอง แรงจูงใจก็เลยสูงเป็นธรรมดา เพราะแบบนี้ชื่อเรื่องเลยโดนใจผม แต่ผมก็คิดว่าสิ่งที่บทความพูดถึงสามารถเกิดขึ้นในงานจริงได้เหมือนกัน ผมไม่ค่อยคุ้นกับกระบวนการพัฒนาซอฟต์แวร์/การบริหารโครงการแบบทางการ
  • ผมบริหารสตาร์ตอัปเทคเล็ก ๆ ที่มีรายได้ปีละ 2 ล้านดอลลาร์ บางครั้งเวลาทีมซัพพอร์ตคนไม่พอ ผมก็ลงไปทำฝ่ายสนับสนุนลูกค้าเองอยู่หลายวัน ทุกครั้งก็น่าแปลกใจที่ผมเจอข้อร้องเรียนจากลูกค้าจำนวนมากซึ่งปกติไม่เคยถูกส่งต่อไปถึงทีมวิศวกรเลย ฝ่ายซัพพอร์ตมักโฟกัสกับการ “แก้” ปัญหาเฉพาะหน้าเอง ทำให้การปรับปรุงที่ต้นเหตุไม่ค่อยถูกส่งต่อไปถึงฝั่งวิศวกรรม
  • สิ่งที่สังเกตได้คือไม่มีใครสงสัยเลยว่าทำไมซอฟต์แวร์ถึงเละเทะขนาดนั้น ผมไม่คิดว่าจะโยนความผิดทั้งหมดให้ PM คนเดียวได้ จริง ๆ แล้วมันเป็นปัญหาเชิงระบบจาก Agile/Scrum และแนวทางคล้ายกัน ที่ทำให้ความรับผิดชอบพร่าเลือน และนักพัฒนาต้องคอยปิดตั๋วที่เขียนมาแบบลวก ๆ ในรอบที่ถี่เกินไป จนสุดท้ายได้ซอฟต์แวร์ครึ่ง ๆ กลาง ๆ แบบนี้ออกมา นี่คือผลลัพธ์ที่พบได้บ่อยเมื่อองค์กรซอฟต์แวร์ “สมัยใหม่” ขยายใหญ่เทอะทะ
  • สิ่งแรกที่ผมนึกได้จากโพสต์นี้คือ “ก่อนที่ PM จะเข้ามาแทรกทั้งหมด ซอฟต์แวร์ก็เคยถูกสร้างแบบนี้แหละ” ถ้าจับวิศวกรไปนั่งข้างคนที่ใช้งานจริง บ่อยครั้งจะพบว่าไม่ต้องมี PM เลย และทุกคนก็มีความสุขกว่ามาก แน่นอนว่ามี PM เก่ง ๆ อยู่จริง แต่จากประสบการณ์ของผม PM มักหมกมุ่นกับการแย่งพื้นที่อำนาจ และน่าแปลกที่หลายคนก็ไม่ได้เข้าใจทั้งฝั่งวิศวกรรมหรือฝั่งลูกค้าดีนัก
• ผมเคยเจอหลายครั้งมากที่วิศวกรไม่สอดคล้องกับตัวผลิตภัณฑ์ บางทีเพื่อนร่วมงานก็แอบเพิ่มอะไรบางอย่างโดยไม่มีใครรู้ ทำให้ UI ชวนสับสน หรือบางครั้งเนื้อหาบนเว็บไซต์ก็ไม่ตรงกับผลิตภัณฑ์จริง อีกทั้งลูปยาวแบบ [ผลิตภัณฑ์ -> PM -> ระบบติดตามบั๊ก -> วิศวกร -> แก้ไข -> QA -> ผลิตภัณฑ์] ทำให้ของสำคัญได้รับการแก้ แต่ความไม่สะดวกเล็ก ๆ น้อย ๆ กลับไม่ถูกแก้อยู่นานมาก ถ้าเหลือแค่ [ผลิตภัณฑ์ <-> วิศวกร] ผลผลิตอาจเพิ่มขึ้นอย่างน่าทึ่ง วิศวกรจำนวนมากไม่เคยลองประสบการณ์การใช้งานทั้งผลิตภัณฑ์จริง ๆ ด้วยซ้ำ และไม่ค่อยรู้ด้วยว่าปีนี้ต่างจากปีก่อนอย่างไร
  • ผมก็มีประสบการณ์คล้ายกัน และน่าแปลกที่เรื่องแบบนี้เกิดบ่อยกว่าในที่ที่มี PM เยอะ ประสบการณ์แย่ที่สุดที่ผมเคยเจอคือมีบริษัทหนึ่งพยายามกำหนดสัดส่วนบังคับให้มี PM และ “Product Designer” เท่ากับจำนวนวิศวกร พอรวมดีไซเนอร์ ฝ่ายผลิตภัณฑ์ โปรเจกต์ และโปรแกรมทั้งหมดแล้ว มีมากกว่าวิศวกรเสียอีก สุดท้ายยิ่งสร้างสถานการณ์ที่เลวร้ายกว่าเดิม การคอยหลบเลี่ยงระบบราชการของ PM และความกังวลว่าพวกเขาจะล้ำเส้นบทบาทของผมก็เป็นงานอย่างหนึ่ง PM เก่ง ๆ มีคุณค่ามากจริง แต่ทุกวันนี้ตำแหน่ง Product Management ดูเหมือนดึงดูดคนที่เป็นระบบราชการและหมกมุ่นกับกระบวนการมากเกินไป พวกอินฟลูเอนเซอร์ด้าน Product Management ก็ยิ่งทำให้ปัญหาหนักขึ้น
  • แต่ผมก็ไม่คิดว่าการบังคับให้วิศวกรไปลงเซลส์คอลคือคำตอบเช่นกัน การจะคุยโทรศัพท์หนึ่งสายให้สำเร็จต้องใช้ soft skills หลายอย่าง ซึ่งวิศวกรไม่ได้ถูกฝึกมาในด้านนั้น และตอนรับเข้าทำงานก็ไม่ได้ใช้เป็นเกณฑ์พิจารณา (คำว่า ‘เซลส์คอล’ ในที่นี้หมายถึงคอลพูดคุยเบื้องต้นก่อนเดโมหรือ PoC ส่วนเดโม presales ที่ซับซ้อน ถึงแม้วิศวกรจะเข้าร่วมด้วย ผมก็คิดว่าตามหลักแล้วบทบาทนั้นควรเป็นหน้าที่ของฝั่งผลิตภัณฑ์)
  • สิ่งที่ผิดพลาดได้มีหลากหลายมาก และผมเคยเห็นมาครบแทบทุกแบบ เช่น ปล่อยให้ PM หรือ PO ผูกขาดการสื่อสารกับลูกค้าทั้งหมด หรือลูกค้าหลีกเลี่ยงการคุยกับนักพัฒนาโดยตรงแล้วส่งต่อแค่การตีความความต้องการของผู้จัดการผู้ใช้มาให้ นักพัฒนาเองก็อาจอยากเขียนแต่โค้ดอย่างเดียว หรือองค์กรอาจบังคับให้ทุกการสื่อสารต้องผ่าน PM และ bug tracker เท่านั้น อีกทั้งเวลาต้องใช้แพลตฟอร์มซอฟต์แวร์เชิงพาณิชย์ ข้อจำกัดทางเทคนิคก็อาจทำให้เวิร์กโฟลว์แย่มากได้ จะมีปัจจัยบางอย่างที่ปิดกั้นการสื่อสารอยู่เสมอ และไม่ว่าจะเป็นลูกค้า ผู้จัดการระดับกลาง หรือผู้พัฒนา ใครก็อาจเป็นคนขวางได้ บางครั้งถึงขั้นเริ่มต้นจากโซลูชันที่ผิดตั้งแต่แรก โดยที่นักพัฒนาหรือผู้ใช้ไม่รู้รายละเอียดอะไรเลย เส้นทางสู่การไม่สามารถสร้างระบบที่ดีให้ผู้ใช้นั้นมีอยู่มากจริง ๆ
  • ผมคิดว่าสำคัญมากที่วิศวกรต้องเข้าใจตัวผลิตภัณฑ์อย่างลึกซึ้ง จุดที่ยากกว่าพื้นฐานทางวิศวกรรมคือการทำให้มิติด้านผลิตภัณฑ์ลงตัว ผลิตภัณฑ์ส่วนใหญ่ที่ผมเคยเจอสุดท้ายล้มเหลวด้วยเหตุผลด้านผลิตภัณฑ์ ดังนั้นการปรับจุดแข็งของทีมไปทางนี้จึงดูสมเหตุสมผลกว่า
• ในอีกด้านหนึ่ง ก็มีกรณีที่วิศวกรสุดท้ายกลายเป็นฝ่ายซัพพอร์ตเทคนิคไปเลย เมื่อคอยช่วยลูกค้าแต่ละรายโดยตรง ก็จะมีแต่ hotfix และโซลูชันเฉพาะรายเพิ่มขึ้นเรื่อย ๆ ทุกอย่างเหล่านี้ก็ทดสอบไม่ทั่วถึง สุดท้ายมีแต่หนี้เทคนิคพอกพูน แล้วพอคู่แข่งรายใหญ่ที่มีเงินทุนดีสร้างผลิตภัณฑ์ที่ดีกว่า ก็ถูกทิ้งห่างอย่างรวดเร็ว ผมคิดว่านี่เป็นความล้มเหลวด้านการจัดการผลิตภัณฑ์แบบคลาสสิก หมายถึง PM ไม่สามารถส่งต่อความต้องการของลูกค้าให้วิศวกรได้ดี หรือผลักกลับในทางตรงกันข้ามก็ไม่ได้ การให้วิศวกรไปทำเซลส์คอลเป็นวิธีที่ไม่ scalable เมื่อฐานลูกค้าโตและเริ่มมีความเป็นผู้ใหญ่พอสมควร ถ้าผู้จัดการผลิตภัณฑ์อยากให้วิศวกรทำเซลส์คอลจริง อย่างน้อยวิศวกรคนนั้นก็ควรได้ส่วนแบ่งคอมมิชชันของแต่ละบัญชีด้วยถึงจะยุติธรรม ผมไม่มีวันรับทำเซลส์คอลโดยไม่ได้คอมมิชชัน
• สำหรับสภาพแวดล้อมแบบสตาร์ตอัป ที่ทุกคนในทีมต้องเข้าถึงและเข้าใจความต้องการของลูกค้าอย่างลึกซึ้ง นี่เป็นกลยุทธ์ที่ยอดเยี่ยมมาก ตอนที่ผมมีส่วนร่วมกำหนด product requirements จริง ๆ และเข้าใจงานภาคปฏิบัติอย่างทะลุปรุโปร่ง อัตราความสำเร็จของโครงการสูงกว่ามาก ผลลัพธ์ก็ดีกว่าตอนที่ผมแค่ “รับ” requirements มาแล้วลงมือทำตามนั้นอย่างเดียวมาก
  • หมายถึงเพราะคุณเป็นคนเขียนแนวทางเอง เลยทำตามได้ง่ายกว่า หรือหมายถึงการมีส่วนร่วมโดยตรงทำให้ UX ออกมาดีกว่ากันแน่
• “รีไรต์เสร็จใน 2 สัปดาห์ ตัดฟีเจอร์ออก 60% เพิ่ม progress bar แบบง่าย ๆ สร้างการเชื่อมต่อ Slack และมีเวิร์กโฟลว์แบบ done-for-you -> ตั๋วซัพพอร์ตลดลง 70%” ถ้าเรื่องนี้จริง แสดงว่ามีอะไรผิดปกติอย่างร้ายแรง
  • Reddit ขึ้นชื่อเรื่องโพสต์แต่งจำนวนมหาศาล และเรื่องนี้เองไม่ว่าจะได้แรงบันดาลใจจากเรื่องจริงหรือแต่งขึ้นล้วน ๆ ก็เต็มไปด้วยองค์ประกอบการเขียนแบบ Reddit ผสมกลิ่นอายการเล่าเรื่องธุรกิจแบบ LinkedIn อย่างชัดเจน
  • ผมมองว่านี่คือกรณีของ B2B SaaS ที่ pivot มาหลายรอบและยังมีเอกสารแนะนำด้านผลิตภัณฑ์ที่อ่อนมาก แน่นอนว่าเรื่องจะพังด้วยวิธีแบบนี้เกิดขึ้นบ่อยกว่าที่คิดมาก
  • ดูจากสำนวนประโยคสั้น ๆ แบบ LinkedIn ที่ปิดท้ายอย่างดราม่าซ้ำ ๆ ก็จับได้ไม่ยากว่านี่เป็นเรื่องแต่ง
  • ก็ Reddit นี่นะ แน่นอนว่าแต่งขึ้น ผมไม่เข้าใจเลยว่าทำไมโพสต์แบบนี้ถึงกลายเป็นประเด็นได้
• ถ้าผลออกมาแบบนี้ ก็ควรไล่ PM, PO และทีมการตลาดออกเดี๋ยวนั้นเลย มีสองอย่างที่ชัดเจน หนึ่ง คนพวกนั้นไม่รู้ว่าลูกค้าต้องการอะไรจริง ๆ หรือไม่ก็สื่อสารความต้องการนั้นไปยังทีมพัฒนาไม่ได้ หรือทั้งสองอย่าง สอง พวกเขาคิดแบบเป็นระบบมากเกินไปจนบางทีการลบขั้นตอนกลางทั้งหมดระหว่างลูกค้ากับทีมพัฒนาออกไปเลยอาจจะดีกว่า
• ที่ทำงานเก่าของผม วิศวกรก็เข้าร่วมเซลส์คอลอย่างสม่ำเสมอเหมือนกัน การได้เห็นว่าลูกค้าบางรายต้องการอะไร และผลิตภัณฑ์ของเราถูกขายอย่างไรนั้นน่าสนใจ แต่ไม่ได้ถึงขั้นพลิกโลก ฟีเจอร์ที่ลูกค้าต้องการมีอยู่ใน roadmap อยู่แล้ว และมีฟีเจอร์หนึ่งที่สับสนจริง แต่ก็ถูกออกแบบแบบนั้นเพราะความต้องการเฉพาะของลูกค้ารายใหญ่ที่สุด ทีมพัฒนาอยากทำให้มันง่ายกว่านี้ แต่ถ้าทำแบบนั้นก็จะตอบโจทย์ลูกค้ารายใหญ่ไม่ได้ สุดท้ายเลยทำเวอร์ชัน “light” ที่ใช้งานง่ายกว่าแยกออกมา และให้ทุกคนใช้อันนั้นได้ยกเว้นลูกค้ารายใหญ่ แต่การเปลี่ยนแปลงนี้ก็ไม่ได้เกิดจากการเข้าเซลส์คอลไปด้วย เพียงแต่ทุกคนรู้ตั้งแต่แรกแล้วว่ามันยาก และเปลี่ยนไม่ได้จนกว่าจะถึงคิวใน roadmap
• ผมอินมากกับประโยคที่ว่า “ในที่สุดก็เข้าใจแล้วว่าใครคือผู้ใช้ตัวจริง” หลายคนชอบพูดว่า “ปัญหาใหญ่ที่สุดของวิศวกรส่วนมากคือ over-engineering” แต่ในความเป็นจริง over-engineering มักเกิดจากการไม่เข้าใจ use case ของลูกค้าอย่างถ่องแท้มากกว่า นี่ต่างหากคือปัญหาที่เป็นแก่น ผมเองในฐานะวิศวกร สิ่งที่อึดอัดที่สุดที่เจอบ่อยคือวิศวกรคนอื่นไม่พยายามทำความเข้าใจว่าผลิตภัณฑ์อะไรที่ขายได้จริง เหตุผลอาจเป็นเรื่องความเหมาะสมกับงาน อัตตา หรือส่วนใหญ่ก็มาจากวัฒนธรรมองค์กรและโครงสร้างแรงจูงใจ
• ผมเคยอยู่บริษัทที่ทำโซลูชัน robocall สำหรับ CRM แล้วในงาน offsite มีการบอกให้ทุกคนลอง cold call ด้วยตัวเองและทำตามสคริปต์ดู พวกเขาไม่เข้าใจและไม่สนใจเลยว่านี่สร้างความกังวลแค่ไหนให้คนที่ไม่ใช่สายเซลส์ หลังจากเหตุการณ์นั้น ผมก็เริ่มคิดเรื่องย้ายงาน
• ผมเคยเห็นสถานการณ์คล้าย ๆ กันมาก่อน ทีมมอนิเตอร์ริ่งยืนกรานว่า “ทุก alert ต้องให้วิศวกรด่านหน้าสร้างตั๋วเองโดยตรง” แต่มี alert มากกว่า 10,000 รายการต่อชั่วโมง ปัญหาสำคัญทั้งหมดเลยจมหายไปใน ‘noise’ จนผู้บริหารก็เหนื่อยล้า สุดท้ายมีครั้งหนึ่งที่มีการบังคับว่า ‘ทีมมอนิเตอร์ริ่งลองเป็นคนเปิดตั๋วและแก้ทั้งหมดเองดูสิ’ วันถัดมา พอตัด alarm ที่สำคัญต่ำออก จำนวน alert แบบไม่ซ้ำก็เหลือเพียงสิบกว่ารายการต่อชั่วโมง และที่เหลือก็ค่อย ๆ ปิดได้ทั้งหมด ตอนนั้นเองที่ “บอร์ดเขียวหมด” กลายเป็นเรื่องจริง (ก่อนหน้านั้นเป็นแค่การทาสีเขียวหลอก ๆ ไว้ให้สื่อกับ Gartner Group ดูเท่านั้น)