ความสำคัญของการตัดสิ่งที่ไม่จำเป็นออก
(gkogan.co)- ผลิตภัณฑ์ที่ซับซ้อนขึ้นอาจดีขึ้นได้ด้วยการ ตัดสิ่งที่ไม่จำเป็นออก มากกว่าการอธิบายเพิ่มเติม และกรณีของเครื่องคำนวณราคาของ Pinecone แสดงให้เห็นเรื่องนี้
- เครื่องคำนวณราคาถูกออกแบบมาเพื่อช่วยประเมินต้นทุนตามการใช้งานล่วงหน้า แต่เพียงข้อผิดพลาดเล็กน้อยในการป้อนข้อมูลก็ทำให้ต้นทุนที่คาดการณ์ไว้พองขึ้นได้สูงสุดถึง 1,000 เท่า จนขัดขวางการสมัครใช้งาน
- ภายในบริษัทพยายามแก้ปัญหาด้วยการเพิ่มคำอธิบายและค่าเริ่มต้น แต่การแก้ไขกลับสร้างความสับสนใหม่ ทำให้มีข้อความสะสมในช่อง Slack เฉพาะมากกว่า 550 ข้อความ
- ใน A/B test ที่เอาเครื่องคำนวณออก ผู้เยี่ยมชมที่ไม่เห็นเครื่องคำนวณมีแนวโน้มสมัครใช้งานสูงขึ้น 16% และมีแนวโน้มติดต่อสอบถามสูงขึ้น 90% โดยไม่มีทิกเก็ตซัพพอร์ตเกี่ยวกับราคาเพิ่มขึ้น
- เมื่อองค์ประกอบใดถูกเพิ่มเข้าไปแล้ว ก็มักคงอยู่แม้มูลค่าจะลดลง ดังนั้นควรพิจารณาอย่างตั้งใจถึงการตัดส่วนก้อนใหญ่ออกจากผลิตภัณฑ์ โปรเจกต์ และกระบวนการ
กรณีการเอาเครื่องคำนวณราคาของ Pinecone ออก
- Pinecone วาง เครื่องคำนวณต้นทุน ไว้บนหน้าราคา เนื่องจากในการคิดราคาตามการใช้งาน ผู้ใช้ประเมินต้นทุนจริงล่วงหน้าได้อย่างแม่นยำได้ยาก
- เมื่อไปพบและตรวจสอบกับผู้ใช้ที่มีแนวโน้มจะใช้งาน พบว่าผู้ใช้บางส่วนเห็นต้นทุนที่คาดการณ์ไว้สูงมากจากเครื่องคำนวณแล้วตัดสินใจไม่สมัคร
- เคสการใช้งานนั้นถือว่าค่อนข้างเล็กเมื่อเทียบตามมาตรฐานของ Pinecone
- เครื่องคำนวณสร้างความสับสนและไวต่อการเปลี่ยนแปลงมากกว่าที่คาดไว้มาก
- เพียงความเข้าใจผิดเล็กน้อยหรือการป้อนข้อมูลผิด ก็ทำให้ต้นทุนที่คาดการณ์ไว้ถูกขยายเกินจริงได้สูงสุดถึง 1,000 เท่า
- เครื่องคำนวณให้ความมั่นใจที่ผิดแก่ผู้ใช้ และผู้ใช้ยอมรับค่าจากเครื่องคำนวณราวกับเป็นต้นทุนจริง โดยไม่ได้ตรวจเอกสาร สอบถามทีม หรือทดลองใช้งานจริงเพื่อยืนยัน
- เพื่อรับมืออย่างรวดเร็ว ได้เพิ่มคำอธิบาย ข้อความปฏิเสธความรับผิดชอบ รายละเอียด และค่าเริ่มต้น แต่ความพยายามลดความสับสนเรื่องหนึ่งกลับก่อให้เกิดความสับสนอีกเรื่อง
- การถกเถียงภายในก็ขยายใหญ่ขึ้น โดยช่อง Slack เฉพาะมีข้อความสะสมมากกว่า 550 ข้อความ และใช้เวลาไปมากกับการประชุมและการเขียนเอกสาร
- มีคนหนึ่งถามว่า “เราจำเป็นต้องมีเครื่องคำนวณจริงหรือ?” แต่ในตอนแรกคำถามนั้นถูกกลบไปท่ามกลางความเห็นส่วนใหญ่
- หลังจากนั้นจึงทำ A/B test เพื่อตรวจสอบว่าหากเอาเครื่องคำนวณและปัญหาที่เกิดจากมันออกไป คุณค่าจะหายไปหรือไม่
- ผู้เยี่ยมชมที่ไม่เห็นเครื่องคำนวณมีแนวโน้มสมัครใช้งานสูงกว่าผู้เยี่ยมชมที่เห็นเครื่องคำนวณ 16%
- มีแนวโน้มติดต่อสอบถามสูงขึ้น 90%
- ไม่มีทิกเก็ตซัพพอร์ตเกี่ยวกับราคาเพิ่มขึ้น
- ในแบบสำรวจภายใน พนักงานบริษัท 7 ใน 10 คนคาดว่าเวอร์ชันที่มีเครื่องคำนวณจะดีกว่า แต่ผลการทดสอบออกมาตรงกันข้าม
เหตุผลที่การตัดออกทำได้ยาก
- หลายองค์กรเมื่อต้องแก้ปัญหามักนึกถึงการเพิ่มก่อนการ ลบออก
- แม้การตัดออกจะให้ประโยชน์มาก ก็ยากที่จะกลายเป็นตัวเลือกที่รู้สึกเป็นธรรมชาติ
- มีการอ้างอิงงานวิจัยที่เกี่ยวข้อง People systematically overlook subtractive changes
- ระบบการให้รางวัลโดยทั่วไปก็มักเอื้อต่อการเพิ่มบางสิ่ง และแรงจูงใจสำหรับการตัดออกพบได้น้อย
- มีการยก Negative 2000 Lines Of Code เป็นตัวอย่างว่าการตัดออกก็ควรได้รับรางวัลเช่นกัน
- คนที่เคยผลักดันอย่างหนักให้เพิ่มองค์ประกอบใดเข้ามา มักยอมรับได้ยากว่าองค์ประกอบนั้นไม่ได้เพิ่มคุณค่า
- หากพยายามเอาองค์ประกอบที่คนอื่นเคยผลักดันให้เพิ่มออก อาจดูเหมือนเป็นการโจมตีวิจารณญาณหรืองานของคนนั้น จึงมักปล่อยไว้ตามเดิมได้ง่าย
- สิ่งที่มีอยู่แล้วมักถูกสันนิษฐานว่ามีเหตุผลที่ดีให้มีอยู่ และหลายครั้งไม่ได้ถูกนำกลับมาทบทวนใหม่
- เมื่อคุ้นเคยกับสภาพปัจจุบันแล้ว ก็มักไม่อยากเปลี่ยนแปลงเสียเองก่อนที่จะคิดเรื่องการตัดออกอย่างเพียงพอ
- การทำให้เรียบง่ายด้วยการตัดองค์ประกอบที่ไม่ใช่สาระสำคัญออกอย่างเด็ดขาด อาจนำไปสู่อัตราการตอบกลับจากลูกค้าที่ดีขึ้น ระบบที่น่าเชื่อถือมากขึ้น การเติบโตและรายได้ที่เร็วขึ้น
- สิ่งที่จำเป็นไม่ใช่การตัดเล็กตัดน้อย แต่คือการเลือกเอาส่วนก้อนใหญ่ของโปรเจกต์ ผลิตภัณฑ์ หรือกระบวนการออก และยิ่งการตัดออกนั้นถูกทีมคัดค้านอย่างหนัก ก็อาจยิ่งซ่อนประโยชน์มหาศาลไว้
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ไม่รู้ว่าเครื่องคำนวณนี้ดีหรือแย่ แต่เหตุผลที่ให้มาดูเผิน ๆ ค่อนข้างไม่สมเหตุสมผล
ถ้าซ่อนความจริงที่ว่าค่าใช้จ่ายของผลิตภัณฑ์อาจสูงจากผู้ใช้ ก็ย่อมเป็นธรรมดาที่จำนวนการสมัครจะเพิ่มขึ้น ส่วนผู้ใช้จะได้รับประสบการณ์ที่ดีขึ้นจริงหรือไม่นั้นขึ้นอยู่กับภายหลังว่าพวกเขาได้รับใบแจ้งหนี้ที่ไม่น่าพอใจหรือไม่ ซึ่งไม่สามารถรู้ได้จาก A/B test สั้น ๆ บนหน้าสมัคร
ผมมักเห็นกรณีทำนองว่าเมื่อลบข้อมูลออกจาก snippet ของผลการค้นหาแล้วอัตราการคลิกเพิ่มขึ้น ก็แน่นอนว่าคลิกย่อมเพิ่ม เพราะข้อมูลที่เคยมีใน snippet ตอนนี้ต้องคลิกเข้าไปดู แต่กลับลืมไปว่าจริง ๆ แล้วแบบไหนดีกว่ากัน
โจทย์คือ “จะแก้กรณีแบบนี้อย่างไร” และคำตอบคือ “เอาเครื่องคำนวณที่เละเทะออกไปเถอะ” ไม่ใช่การซ่อนค่าใช้จ่าย 1000 เท่า แต่เป็นการหลีกเลี่ยงการเสียผู้ใช้ไปเพราะประมาณการผิดพลาด 1000 เท่า
ตัวอย่างคือดีลเลอร์รถยนต์ที่ทำให้การตรวจสอบราคาออนไลน์ทำได้ยาก แล้วชักจูงให้ส่งอีเมลหรือเดินทางไปที่ร้าน เครื่องคำนวณช่วยให้การเปรียบเทียบเพื่อซื้อทำได้ง่ายขึ้น ซึ่งหลายบริษัทไม่ชอบ ไม่ว่าจะตั้งใจหรือไม่ นี่เป็นแรงจูงใจที่ต้องนำมาพิจารณา
ถ้าทำให้โปร่งใสต่อผู้ใช้ ก็ย่อมทำให้สับสนมากขึ้น เพราะเกณฑ์เปรียบเทียบนั้นเองปฏิบัติกับผู้ใช้เหมือนปศุสัตว์โง่ ๆ ที่ถูกต้อนเข้าโรงเชือด ภายใต้เกณฑ์นี้ ฟีเจอร์ใด ๆ ที่ปฏิบัติต่อผู้ใช้ในฐานะคนที่คิดได้ จะสร้างความสับสนและทำร้าย conversion rate
แน่นอนว่าหน้าราคาดูแย่ลงมาก แต่ก็ไม่เป็นไรเพราะ “ยอดสมัครเพิ่มขึ้น” ในกรณีนี้ เครื่องคำนวณอาจทำให้คนที่ไม่คุ้นกับศัพท์รู้สึกหนักใจได้ แต่การตัดสินใจตามสัญชาตญาณว่า “จะทำให้มันเรียบง่ายขึ้นอย่างไร” ควรมาก่อน วัฒนธรรม A/B test ที่ต้องวิเคราะห์และพิสูจน์ทุกอย่างด้วยสถิติไม่ค่อยดีนัก
ถ้าผู้ใช้ไม่อยู่ต่อมาตั้งแต่แรก แล้วจะทดสอบได้อย่างไรในภายหลังว่าพวกเขาพอใจหรือไม่พอใจ ถ้าปิดลูปและเพิ่มการมีส่วนร่วม โอกาสที่จะให้ความรู้ลูกค้าอย่างถูกต้องและทำให้พวกเขาพอใจผ่านปฏิสัมพันธ์ต่อ ๆ ไปก็เพิ่มขึ้นด้วย
ผมกดโหวตเพราะอยากเผยแพร่ภูมิปัญญาสำคัญของบทความนี้ แต่เส้นแบ่งอาจพร่าเลือนได้อย่างรวดเร็ว
วิธีคิดว่า “ถ้าลบส่วนนี้ออก จะมีอะไรที่มีคุณค่าหายไปไหม” บางครั้งให้ผลตรงข้ามในโปรเจกต์ระยะแรก โดยเฉพาะเพราะโค้ดและข้อมูลประเมินมูลค่าในอนาคตได้ยาก
ครั้งหนึ่งในโปรเจกต์ใหม่ ผมสร้าง SQL schema ตั้งต้นที่มีคอลัมน์ metadata เพิ่มเติมสำหรับแท็กโพสต์ แต่สัปดาห์ถัดมา senior engineer ก็ยกหลัก YAGNI มาลบออกทั้งหมด ตอนนั้นมันไม่ได้อยู่ใน roadmap จึงถูกต้องในเชิงเทคนิค แต่งานเดิมใช้เวลาราวหนึ่งชั่วโมง และต้นทุนในการคงข้อมูลไว้แทบเป็นศูนย์
หนึ่งปีถัดมา คนที่สร้างฟีเจอร์ที่ต้องใช้คอลัมน์นั้นก็กลายเป็นผมเอง และตอนนี้ต้องทำงานเดิมซ้ำ รวมถึง migration ของ production DB ที่มีผู้ใช้อยู่แล้วด้วย ดังนั้นในทางกลับกัน ก็ควรคิดด้วยว่า “ถ้าลบส่วนนี้ออก จะเกิดอะไรที่มีคุณค่าขึ้นไหม” ในบทความนี้คำตอบชัดเจน แต่กรณีของผมไม่เป็นแบบนั้น
ผมจำได้ว่า SpaceX มีตัวชี้วัดที่จับแนวคิดคล้ายกัน คือสัดส่วนของฟีเจอร์ที่ถูกลบแล้วถูกเพิ่มกลับมาเป็นครั้งที่สอง หากฟีเจอร์ที่ลบออกทั้งหมดถูกเพิ่มกลับมา นั่นคือ อัตราการทำผิดซ้ำของฟีเจอร์ 100% แปลว่าตัดทิ้งบ่อยเกินไป และ 70% ก็สูง 30% ก็ยังสูง
แต่ 0% ก็ไม่ดีเหมือนกัน เพราะถ้าไม่พยายามลบฟีเจอร์ที่ไม่จำเป็นให้เพียงพอ สุดท้ายมันจะบวมเทอะทะ ในช่วงแรกของผลิตภัณฑ์ อัตรานี้ดูเหมือนควรสูงกว่า และเมื่อผลิตภัณฑ์สุกงอมขึ้น ก็ควรลดลงมาเป็นอัตราต่ำ ๆ ที่ไม่ใช่ศูนย์
ณ เวลาปัจจุบัน เราไม่อาจรู้ชุดฟีเจอร์ที่แน่นอนซึ่งจำเป็นต่อผลิตภัณฑ์ที่ดีที่สุดได้ ดังนั้นการใช้แนวทางเชิงความน่าจะเป็นเพื่อตัดสิ่งที่ไม่จำเป็นก็ใช้ได้ ถ้าจำเป็นค่อยเพิ่มกลับมา และตราบใดที่เรื่องแบบนั้นไม่เกิดบ่อยเกินไป ก็ไม่มีเหตุผลให้สงสัยการตัดสินใจลบออกในครั้งแรก
หรือไม่ก็ในโลกจริง แทนที่จะลองทำทั้งสองแบบแล้วดูผลลัพธ์ เราอาจประชุมกัน 6 เดือนโดยใช้ตัวชี้วัดตัวแทนของสมมติฐานและความเชื่อเดิมที่ไม่ได้พูดออกมาเป็นคำก็ได้
มันกลายเป็น “ใช้ได้ไหม? ลบได้ไหม?” และบางคนก็นึกถึง Knight Capital ที่เคยเกิดอุบัติเหตุใหญ่เพราะนำฟิลด์เก่ากลับมาใช้ซ้ำ ดังนั้นการปล่อยฟิลด์เดิมไว้จึงมักดูปลอดภัยกว่าเสมอ และสุดท้ายก็มี
metadataกับmetadata_1ปีถัดมาไม่มีใครรู้ว่าทำไมถึงมีฟิลด์ metadata สองอัน เลยยิ่งสับสนcodebase ที่แย่ที่สุดที่ผมเคยเจอถูกออกแบบโดยคำนึงถึงการใช้งานอนาคตที่ซับซ้อน ในตัวอย่างนี้ codebase ก็เพิ่งต้องใช้คอลัมน์หลังผ่านไป 1 ปี ดังนั้นผมเห็นว่าการตั้งบรรทัดฐานให้ลบโค้ดทุกชิ้นที่คาดเดาความจำเป็นในอนาคตออกไปนั้นถูกต้อง ต่อให้สุดท้ายมันกลับมาจำเป็นอีกก็ตาม
สำหรับบางคนมันคือ premature optimization แต่สำหรับอีกคนคือ “เคยเห็น pattern คล้าย ๆ กันมาก่อน และจะเพิ่มสิ่งที่ตอนนั้นอยากให้มีไว้” ดูเหมือนไม่มีวิธีแยกอย่างน่าเชื่อถือว่าฝั่งไหนถูก
สถานการณ์ที่อธิบายมีผลลัพธ์หลัก ๆ สามแบบ หนึ่ง ฟิลด์มีประโยชน์ตามวิธีที่เริ่ม implement ไว้เดิม สอง ฟีเจอร์ถูก implement แต่ใช้ฟิลด์อื่นหรือ implementation อื่น สาม ฟีเจอร์ไม่ถูก implement
ต่อให้กำหนดความน่าจะเป็นของสามทางเลือกเท่ากัน สิ่งที่สร้างไว้ตั้งแต่แรกจะถือว่าชนะก็มีเพียง 1 ใน 3 เท่านั้น และหากไม่ลบออก คุณต้องคิดด้วยว่าระหว่างนั้นมี ต้นทุนทางปัญญา มากแค่ไหนในการตรวจสอบให้ฟีเจอร์อื่น ๆ ที่ implement ไปทำงานกับคอลัมน์ metadata ได้ถูกต้อง
ครั้งนี้หมายความว่าการตัดสินของคุณถูก และคุณเข้าใจโปรเจกต์ได้ยอดเยี่ยม แต่ความถูกต้องของการตัดสินใจควรถูกประเมินจากข้อมูลที่มีอยู่ในตอนนั้น ไม่ใช่จากสถานะที่รู้ข้อมูลย้อนหลังครบทั้งหมด
ประเด็นที่ว่า “ในการโหวตภายในบริษัท 7 ใน 10 คนคิดว่าเวอร์ชันที่มีเครื่องคิดเลขน่าจะดีกว่า” น่าสนใจและเป็นพลวัตที่พบได้บ่อย
โดยรวมเป็นบทความที่ดี แต่จุดนี้ควรได้รับการเน้นมากกว่านี้ หาก 30% ของผู้เกี่ยวข้องมองว่าเครื่องคิดเลขเป็นสิ่งไม่ดี นั่นเป็นสัญญาณของปัญหาใหญ่ที่อาจเกิดขึ้น แม้เสียงส่วนใหญ่จะคิดว่าโอเคก็ตาม
เรื่องนี้ต้องระวังการเมืองภายใน คนทั่วไปมักไม่อยากวิจารณ์ทีมอื่นถ้าไม่ได้ประโยชน์ทางการเมือง ดังนั้นเมื่อถามทั้งบริษัทว่า “สิ่งที่ทีมเราทำนี้ให้ผลสุทธิเป็นบวกไหม?” คำตอบเริ่มต้นจึงมักกลายเป็น “ใช่” เพราะไม่อยากสร้างความขัดแย้งโดยไม่จำเป็น
ในสถานการณ์แบบนั้น หาก 30% ส่งสัญญาณว่าอาจทำลายคุณค่าได้ ก็สำคัญกว่าที่คิดมาก ควรขุดลึกพอสมควรว่าทำไมพวกเขาถึงมองแบบนั้น ในกรณีนี้ดูเหมือนว่าจะตระหนักถึงจุดนั้นจริง ๆ และจบลงด้วยดี แต่ผลโหวตนี้เป็นหลักฐานของปัญหาร้ายแรงมาตั้งแต่แรกแล้ว
พอมีผลประโยชน์เกี่ยวข้องก็ยิ่งซับซ้อน ฝ่ายขายอยากเปิด dark patterns ทุกแบบ ส่วนฝ่ายซัพพอร์ตลูกค้าอาจเอือมกับการต้องคืนเงินเพราะมีการต่อประกันถูกใส่ลงตะกร้าโดยอัตโนมัติ
ตอนที่บทความบอกว่าการเอาเครื่องคิดเลขออกอาจดีกับผู้ใช้ เพราะจะทำให้การขายเสร็จสิ้นมากขึ้น ผมอ่านแล้วขำ บางทีทางเลือกที่ถูกต้องอาจเป็นการให้ผู้ใช้เจอช็อกราคาที่เหมาะสมแล้วเดินจากไปก็ได้ แต่ประเด็นนั้นถูกมองข้ามไป
ลองจินตนาการว่าโค้ดเครื่องคิดเลขเละเทะเมื่อเทียบกับส่วนที่เหลือของโปรเจกต์ ใช้ไลบรารีเก่า อัปเดตแล้วพัง มีช่องโหว่ด้านความปลอดภัย ใช้ทรัพยากรมากผิดปกติ และทำให้ระบบบิลด์พัง ไม่มีใครอยากแตะมัน
ในสถานการณ์นี้ ถ้าถามว่าเป็นไอเดียที่ดีไหม คนส่วนใหญ่ก็คงตอบว่า “ไม่” และหวังว่าจะกำจัดของยุ่งเหยิงนั้นออกไป ดังนั้น 70% จึงเป็นตัวเลขที่ดีมาก แต่ในทางกลับกัน ถ้าเป็นฟีเจอร์ที่คนชอบทำงานด้วย 70% ก็เป็นตัวเลขที่แย่มากจริง ๆ
แน่นอนว่าพวกเขาอาจคิดแบบนั้นก็ได้ แต่นั่นเป็นการกระโดดไปไกลพอสมควร พวกเขาอาจมองว่าแทบไม่ต่างกัน หรืออาจคาดว่าผลงานต่ำลงเพราะมีบางกรณีที่เครื่องคิดเลขให้คำตอบผิดก็ได้
ข้อความโดยรวมก็น่าสนใจ แต่ตรงนี้ทำให้ชะงักนิดหน่อย
คำว่า “แค่เข้าใจผิดหรือกรอกผิดเล็กน้อย ค่าประมาณก็อาจถูกขยายเกินจริงได้ถึง 1000 เท่า” หมายความว่าในการใช้งานจริง ถ้าเข้าใจหรือประเมินตัวชี้วัดผิดไปนิดเดียว ก็จะต้องจ่าย ค่าใช้จ่าย 1000 เท่า จากที่วางแผนไว้หรือเปล่า?
ในระบบคิดเงินออนไลน์ เรื่องแบบนี้เป็นไปได้จริง ผมเคยตั้งค่าโปรโตไทป์บน GCP ผิด คิดว่าจะประมาณ 2–3 ดอลลาร์ แต่พอไม่ดูอยู่ไม่กี่วันก็ได้บิลเกิน 100 ดอลลาร์
พอเห็นว่าการขยับสไลเดอร์นิดเดียวทำให้ราคาประเมินพุ่งบ้าคลั่ง ก็เข้าใจได้ว่าทำไมลูกค้าถึงหนี การเอาเครื่องมือออกอาจช่วยเรื่องการสมัครใช้งาน แต่ไม่ได้ช่วยลูกค้าที่จะเจอปัญหาแบบนี้ทีหลัง
ผู้ใช้คนหนึ่งคิดว่า จำนวนคิวรีต่อวินาที คำนวณจากจำนวนการค้นหา × top-k ของแต่ละการค้นหา โดย top-k คือจำนวนผลลัพธ์ที่ต้องการให้ส่งกลับมา สมมติว่า top-k เป็น 10 เขาก็จะใส่ค่าจำนวนคิวรีต่อวินาทีสูงกว่าความจริง 10 เท่า และเห็นราคาประเมินสูงกว่าบิลจริงราว 10 เท่า
ผู้ใช้อีกคนคิดว่า จำนวนเวกเตอร์ คำนวณจากจำนวน embedding × จำนวนมิติของ embedding ค่า 1,536 เป็นจำนวนมิติที่พบได้บ่อย ดังนั้นค่าที่กรอกจึงสูงขึ้นตามตัวอักษรถึง 1,536 เท่า แต่การใช้งานจริง Pinecone คำนวณอย่างถูกต้อง จึงไม่ถูกเรียกเก็บสูงขนาดนั้น
จำนวนมิติของเวกเตอร์เป็นแนวคิดพื้นฐานสำหรับวิศวกร AI และ QPS เป็นตัวชี้วัดพื้นฐานสำหรับผู้ดูแลฐานข้อมูล แต่ Pinecone มีผู้ใช้จำนวนมากที่เพิ่งเริ่มกับ AI หรือเพิ่งเริ่มกับการดูแลฐานข้อมูล หรือทั้งสองอย่าง
ผู้เขียนควรทำตามคำแนะนำของตัวเอง เอา “Psst... Get the next post in your inbox” ที่แทรกกลางบทความออก และเอาปุ่มโง่ ๆ ที่ลอยตามตอนเลื่อนหน้าออกด้วย
ผมนับได้ว่าหน้านั้นมีวิธีสมัครรับข้อมูลถึงห้าแบบ ต้องมีถึงห้าแบบจริง ๆ หรือ? จำเป็นต้องยื่นใส่หน้ากลางเนื้อหาหรือ? คิดว่าการขัดจังหวะและทำให้คนรำคาญจะเพิ่มผู้ติดตามได้หรือ? แล้วอยากได้ผู้ติดตามแบบนั้นหรือ?
การเอาอะไรบางอย่างออกมักจะชัดเจน แค่ออกจากหลุมความคิดแบบ “เอาเพิ่ม ๆ หาเงิน ดึงลูกค้า” แล้วคิดว่า “ถ้าจะเคารพผู้ใช้ อะไรคือสิ่งที่ถูกต้อง และเราจะช่วยเขาได้อย่างไรในฐานะมนุษย์ ไม่ใช่เป้าหมายให้รีดเงินจากกระเป๋า”
ต้องจำไว้ว่าธุรกิจส่วนใหญ่มีอยู่เพื่อหาเงิน ไม่ใช่เพื่อทำให้ผู้อ่าน HN รู้สึกสบายใจ
อะไรคือการเคารพผู้ใช้เป็นอีกคำถามหนึ่ง แม้จะไม่ใช่คำถามที่ไม่เกี่ยวข้องกันเสียทีเดียว
การมีช่อง Slack เฉพาะขึ้นมา มีข้อความกว่า 550 ข้อความจากความคิดเห็นทั่วบริษัท และใช้เวลาประชุมหลายสิบชั่วโมงกับข้อความหลายพันคำเพื่อคุยว่าต้องเพิ่มอะไรเพื่อแก้เครื่องคิดเลข เป็นอาการของ การจ้างคนเกินจำเป็น
เมื่อมีคนมากเกินไป ความเป็นผู้นำจะหายไป ถ้าลืมว่าอะไรสำคัญจริง ๆ และรู้สึกว่าต้องหาฉันทามติแบบคณะกรรมการ แปลว่ามีคนมากเกินไปแล้ว
การออกแบบแบบคณะกรรมการก็ควรถูกจำกัดไว้แค่ภายในคณะกรรมการ
จะไม่ดีกว่าหรือถ้าเอา โครงสร้างราคา ที่ซับซ้อนจนลูกค้าไม่สามารถจำลองอย่างมีประโยชน์ได้ออกไปเสียเอง?
กล่าวคือ เมื่อออปชัน A ราคา x ดอลลาร์ และออปชัน B ราคา 10x ดอลลาร์ ถ้าผู้ใช้ส่วนใหญ่เผลอคิดว่าตัวเองต้องใช้ B เครื่องคิดเลขก็กลายเป็นเครื่องมือที่ก่อให้เกิดความเข้าใจผิด
ผมค่อนข้างชอบวิธี “ติดต่อสอบถามราคา” มันน่ารำคาญสำหรับผู้ใช้ที่อยากรู้ช่วงราคาแบบคร่าว ๆ อย่างรวดเร็ว แต่ช่วยระบุกรณีที่ราคามาตรฐานหรือราคาที่อธิบายออนไลน์ได้ยากอาจต่อรองได้ และยังจับผู้ใช้ที่อาจเดินผ่านไปเฉย ๆ ได้ด้วย แน่นอนว่าวิธีนี้ไม่เหมาะกับกรณีอย่างอีคอมเมิร์ซส่วนใหญ่
ที่บริษัทของเรามีผลิตภัณฑ์อยู่ราว 250 รายการ และในนั้นมี 5 รายการที่รับผิดชอบรายได้ 80%
ทีมพัฒนาของผลิตภัณฑ์ 5 รายการนั้นแค่ตามแก้บั๊กให้ทันก็แทบไม่ไหว และลำบากกับการเพิ่มฟีเจอร์ใหม่ที่สำคัญ ไม่ว่าใครจะร้องขอมา การใส่อะไรสักอย่างลงใน roadmap เองก็เป็นการต่อสู้ที่แทบเป็นไปไม่ได้
บริษัทมีนักพัฒนาหลายพันคน แต่ส่วนใหญ่ถูกผูกอยู่กับผลิตภัณฑ์ที่แทบไม่ได้มีส่วนสร้างรายได้
ถ้าจะเดินหน้าต่อ ก็ดูชัดเจนว่าควรตัดผลิตภัณฑ์ส่วนใหญ่ออก แล้วจัดทีมใหม่เพื่อผลักดัน ผลิตภัณฑ์หลักที่สร้างรายได้ ที่เหลืออยู่ แต่เรื่องแบบนั้นไม่ได้เกิดขึ้น และก็ไม่มีวี่แววหรือข่าวลือว่าจะเกิดขึ้นด้วย การเมืองในบริษัทนี่โหดจริง ๆ
เคยมีประสบการณ์คล้ายกัน บนเว็บไซต์ที่มีผลิตภัณฑ์หลายตัวที่ดูค่อนข้างคล้ายกัน เรากังวลว่าผู้คนจะตัดสินใจยากว่าควรซื้ออะไร และเพราะแบบนั้นจึงอาจไม่ซื้อเลย
เราจึงทำ แอปเพล็ตแนะนำผลิตภัณฑ์ ที่ให้ผู้ใช้ตอบคำถามไม่กี่ข้อ แล้วแนะนำผลิตภัณฑ์ที่เหมาะที่สุดหนึ่งหรือสองรายการ กว่าจะทำให้เข้าที่ก็มีงานอยู่พอสมควร แต่พอเสร็จแล้วก็ทำงานได้ดี
พอเอาขึ้นเว็บไซต์ อัตรา conversion ก็ร่วงหนัก ลองทำ A/B test แล้วก็ชัดเจนว่ามันทำให้อัตรา conversion แย่ลง ยังไม่รู้ว่าทำไมถึงเป็นแบบนั้น แต่ความจริงคือเป็นแบบนั้นจริง ๆ เราเลยย้ายมันจากหน้าแรกไปไว้ที่ส่วน FAQ แล้วก็แทบไม่มีใครใช้มันอีก
ผู้คนอาจลังเลอยู่แล้ว และมันช่วยลดความยุ่งยากในการลองผิดลองถูกเพื่อหาคำตอบด้วยตัวเอง
ถ้าเป็นบริการ กลยุทธ์แบบ Amazon Prime อาจได้ผล คือในเมื่อไม่มั่นใจก็สมัครไปก่อน แล้วหลังจากนั้นก็อาศัย ความผิดพลาดจากต้นทุนจม หรือถ้าไม่มีแอปเพล็ต ผู้ใช้อาจสมัครเพราะคาดหวังว่าเวอร์ชันที่ถูกที่สุดก็น่าจะพอ แต่แอปเพล็ตกลับดับความหวังนั้นทันที
ถ้าเป็นผลิตภัณฑ์ทางกายภาพ ก็อาจนับได้ว่าช่วยให้หลีกเลี่ยงการซื้อที่ไม่ดี
ผมไม่คาดหวังว่าคนจะไปหามันใน FAQ ถ้าเป็น footer ยังพอว่า แต่ FAQ ไม่น่าใช่
เป็นกรณีศึกษาที่น่าสนใจ แต่ผมค่อนข้างกังขาต่อความหมายในวงกว้าง Pinecone ขึ้นชื่อว่าแพงเมื่อเทียบกับบริการ vector database อื่น ๆ หากลองเทียบราคาในระดับเดียวกัน ตลาดก็มีตัวเลือกที่ดีกว่าอยู่หลายราย
การเอาเครื่องคำนวณออกไม่ได้แก้ปัญหาหลัก มันแค่ทำให้ต้นทุนพร่ามัวขึ้น และทำให้ผู้ใช้เปรียบเทียบตัวเลือกตั้งแต่แรกได้ยากขึ้น จากมุมมองของผม มันอาจลดขั้นตอนการเปรียบเทียบลง จนทำให้ผู้ใช้ที่มีข้อมูลไม่พอจำนวนมากขึ้นอัปโหลดข้อมูลโดยยังไม่เข้าใจผลกระทบด้านราคาอย่างเพียงพอ
บางครั้งการทำให้เรียบง่ายก็มีคุณค่า แต่ในกรณีนี้ดูเหมือนจะเป็นประโยชน์ต่อบริษัทมากกว่าผู้ใช้ แทนที่จะเอาเครื่องคำนวณออกไปทั้งหมด การปรับปรุงความแม่นยำและความใช้งานง่ายอาจดีกว่า โดยเฉพาะในบริการ B2B ที่ค่าใช้จ่ายอาจเพิ่มขึ้นอย่างรวดเร็ว ความโปร่งใสด้านราคา จึงสำคัญ