50 บทเรียนที่ได้เรียนรู้จากการสร้างผลิตภัณฑ์ให้ประสบความสำเร็จ [บทความแปล]

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

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

3. การสร้างผลิตภัณฑ์ที่ยอดเยี่ยมต้องอาศัยความไว้วางใจ การขาดความไว้วางใจเป็นหนึ่งในคอขวดที่ใหญ่ที่สุดของทีม ซึ่งมักเป็นผลจากการรับคนที่ยังไม่ถึงมาตรฐานเข้ามา หรือไม่ได้ให้ฟีดแบ็กเพื่อช่วยให้เขาปรับปรุงอย่างเหมาะสม

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

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

6. ฝ่ายบริหารควรแบ่งปันเป้าหมายของบริษัท ส่วนทีมผลิตภัณฑ์ (วิศวกร) เป็นผู้กำหนดว่าจะสร้างอะไรเพื่อไปให้ถึงเป้าหมายนั้น รวมถึงกำหนดเป้าหมายของตัวเอง ทั้งสองฝ่ายควรตรวจสอบผลกระทบจริงผ่านเมตริกและฟีดแบ็กจากผู้ใช้

7. ผลิตภัณฑ์ขึ้นอยู่กับ ideal customer profile (ICP) โดยตรง ICP คือสิ่งที่คุณกำลังสร้างให้ และเป็นปัจจัยสำคัญที่สุดในการตัดสินใจว่าจะสร้างอะไร ICP ที่แม่นยำจะนิยามไม่ใช่แค่ลูกค้าเป้าหมาย แต่รวมถึงทุกด้านของผลิตภัณฑ์และกลยุทธ์การเข้าสู่ตลาด

8. หากต้องการหา ICP ให้เริ่มจากการคาดเดาแล้วทดสอบ ตั้งคำถามตอนสมัครใช้งาน เปรียบเทียบ retention ระบุพาวเวอร์ยูสเซอร์ และทำแบบสำรวจ NPS เมื่อข้อมูลและความมั่นใจเพิ่มขึ้น ก็ค่อยเติมรายละเอียดให้มากขึ้น

9. สร้างหลักการของผลิตภัณฑ์ขึ้นมา เราใช้หลักการอย่าง “มอบเครื่องมือทุกอย่างที่จำเป็นต่อการวัดความสำเร็จ”, “ชิงพื้นที่ก่อน”, และ “ทำหน้าที่เป็นแหล่งข้อมูลจริงของลูกค้าและข้อมูลผลิตภัณฑ์” หลักการเหล่านี้ช่วยสร้างภาษากลางสำหรับการอภิปรายไอเดียและการตัดสินใจ

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

11. ผลิตภัณฑ์ไม่ใช่แค่ฟีเจอร์ แต่คือแบรนด์และประสบการณ์ของผลิตภัณฑ์ที่ส่งต่อไปยังผู้อื่น ขนาดการลงทุนในแต่ละฟีเจอร์ คนที่คุณจ้าง การตัดสินใจในการสร้าง ฟีเจอร์ที่คุณผลักดัน วิธีสื่อสารกับลูกค้า และนโยบายราคา ล้วนสร้างความเป็นเอกลักษณ์

12. เว็บไซต์คือความประทับใจแรกของผลิตภัณฑ์ เว็บไซต์ที่น่าเบื่อและดูเหมือนเทมเพลตส่งสัญญาณว่าผลิตภัณฑ์และทีมข้างหลังมันอ่อนแอ การทำเว็บไซต์ที่มีเอกลักษณ์ของตัวเองและสอดคล้องกับ ideal customer profile จะช่วยป้องกันปัญหานี้และเพิ่มการได้มาซึ่งผู้ใช้

13. บางครั้งปัญหาไม่ใช่ตัวผลิตภัณฑ์ แต่เป็นปัญหาของตลาด ตัวอย่างเช่น Tom Blomfield ผู้ก่อตั้ง Monzo และพาร์ตเนอร์ของ YC ตอนที่เขาสร้างบริการหารค่าใช้จ่ายสำหรับเพื่อนมหาวิทยาลัย เขาได้รับคำแนะนำให้หยุดสร้างก่อนแล้วไปโฟกัสที่การหาผู้ใช้ เมื่อโทรหาลูกค้าแบบ cold call อยู่ 4 สัปดาห์แล้วได้มาเพียง 1 คน เขาก็รู้ว่านั่นคือเวลาที่ควร pivot

14. ถ้าจะ pivot ก็ให้ทำครั้งใหญ่ Stewart Butterfield เปลี่ยนบริษัทเกมสองแห่งให้กลายเป็น Flickr และ Slack Reid Hoffman ผู้ร่วมก่อตั้ง LinkedIn กล่าวว่า หากผู้ก่อตั้งสตาร์ตอัปจะ pivot จากความล้มเหลวไปสู่ความสำเร็จ พวกเขาต้อง ‘slash and burn’ ธุรกิจส่วนที่เหลือ หากมันยังดูคล้ายของเดิมเกินไป ก็จงไปให้ไกลกว่านั้น

15. อย่างที่ Jason Fried แห่ง 37signals พูดไว้ว่า “คุณไม่สามารถตรวจสอบไอเดียได้ เพราะมันยังไม่มีอยู่จริง คุณต้องสร้างมันขึ้นมาจริง ๆ แล้วตลาดจะเป็นผู้ตรวจสอบให้”

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

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

18. ลดงานที่กำลังทำอยู่ PR ควรจบภายในวันเดียว เริ่มต้นวันด้วยการตอบรีวิวจากคนอื่น merge ได้ทุกเมื่อ ปล่อยผ่าน feature flag และทดสอบบน production ทั้งหมดนี้ช่วยลดภาระด้านบริบทของงาน

19. การปล่อยอย่างรวดเร็วเป็นแกนหลักของปรัชญาการพัฒนาผลิตภัณฑ์ของเรา แต่ก็มี trade-off เช่น การจัดหาเทคโนโลยี การประชุมวางแผน พิธีกรรมแบบ Agile และการทบทวนเมตริก จะถูกลดความสำคัญลง การทำงานแบบ asynchronous ช่วยให้สิ่งนี้เป็นไปได้มากขึ้น

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

21. เดดไลน์ที่สร้างขึ้นเองไม่ได้ทำให้ทีมเร็วขึ้น ตรงกันข้าม มันมักก่อให้เกิดลูปหายนะของหนี้เทคนิคกองโตและภาวะหมดไฟ จงลบกระบวนการที่ทำให้ทีมช้าลง และให้อิสระกับทีมเล็กในการปล่อยของอย่างรวดเร็ว

22. อีกวิธีหนึ่งในการปล่อยให้เร็วขึ้นคือยกเลิกการทำดีไซน์พื้นฐาน เมื่อมี design system ที่พร้อมใช้งานแล้ว ก็ให้วิศวกรลงมือสร้างได้เลย หากจำเป็นค่อยใช้การรีวิวดีไซน์มาปรับสิ่งที่ปล่อยไปแล้ว

23. feature flag ช่วยให้วิศวกรผลิตภัณฑ์ปล่อยการเปลี่ยนแปลงได้เร็ว ทดสอบบน production และรับฟีดแบ็กจากผู้ใช้จริง อีกทั้งยังช่วยลดความเสี่ยงด้วยการทำหน้าที่เป็น kill switch เมื่อสิ่งต่าง ๆ ไม่ทำงานตามคาด

24. ที่ PostHog การสื่อสารที่ดีที่สุดคือ pull request ต่างจากข้อความหรือ issue ตรงที่มันเปลี่ยนฟีดแบ็กให้กลายเป็นผลลัพธ์ได้ทันที สอดคล้องกับวัฒนธรรมที่เน้นการลงมือทำ และสร้างลูปฟีดแบ็กที่กระชับกว่า

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

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

27. แทนที่จะควบคุมวิศวกร ผู้จัดการผลิตภัณฑ์ควรให้บริบทแก่ทีมผลิตภัณฑ์ผ่าน product analytics การวิจัยผู้ใช้ และการสำรวจคู่แข่ง

28. คนส่วนใหญ่ไม่ใช่ Steve Jobs พวกเขาไม่ได้มีวิสัยทัศน์ที่ “รู้เอง” ตั้งแต่ต้นว่าจะต้องสร้างอะไร และไม่ได้มองเห็นภาพใหญ่ทั้งหมด แต่พวกเขาปล่อยของ ส่งให้ผู้ใช้ และวนลูปกับฟีดแบ็กแทน ยิ่งทำวงจรนี้ได้เร็วเท่าไร ผลิตภัณฑ์ก็ยิ่งดีขึ้น

29. จ้างและพึ่งพา product engineer พวกเขามีทั้งทักษะ full-stack ที่จำเป็นต่อการสร้างผลิตภัณฑ์ และความหมกมุ่นกับลูกค้า พวกเขาควรพูดคุยกับผู้ใช้ ทำสัมภาษณ์ หาคนทดสอบฟีเจอร์ใหม่ เก็บฟีดแบ็ก รับมือซัพพอร์ต และตอบสนองต่อ incident

30. อ่าน The Mom Test หนังสือเล่มนี้สอนวิธีพูดคุยกับผู้ใช้เป้าหมายเกี่ยวกับปัญหาของพวกเขา ประเด็นสำคัญคือการสัมภาษณ์ผู้ใช้มี 2 แบบ: การสำรวจปัญหา และการตรวจสอบโซลูชัน แบบแรกช่วยชี้นำการตัดสินใจของผลิตภัณฑ์ในอนาคต แบบหลังช่วยปรับปรุงงานที่กำลังทำอยู่

31. หากต้องการให้การสัมภาษณ์ผู้ใช้ได้ผลสูงสุด ให้รู้ล่วงหน้าว่าผู้ใช้ (ICP) คือใคร ใช้ผลิตภัณฑ์อย่างไร และสิ่งถัดไปที่จะสร้างคืออะไร วิธีนี้จะช่วยให้การสัมภาษณ์ทำให้ขั้นตอนถัดไปชัดเจนขึ้น แทนที่จะสร้างความสับสน

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

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

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

35. การใช้ผลิตภัณฑ์ของตัวเอง (dogfooding) ช่วยเพิ่มความเร็วในการปล่อย ป้องกันปัญหาก่อนถึงมือผู้ใช้ เข้าใจผลิตภัณฑ์ได้ลึกขึ้น และสร้างความเห็นอกเห็นใจผู้ใช้ แต่ก็ไม่สามารถทดแทนการพูดคุยกับผู้ใช้ ฟีดแบ็กจริง และการติดตามเมตริกการใช้งานได้

36. เช่นเดียวกับที่ทีมผลิตภัณฑ์ของเราแก้ความต้องการของตัวเองด้วย interview popup การแก้ปัญหาความต้องการภายในด้วยผลิตภัณฑ์ของตัวเองเป็นวิธีที่ดีในการตรวจสอบ use case หากคุณควรใช้ผลิตภัณฑ์ของตัวเองแต่กลับไม่ใช้ นั่นคือสัญญาณว่ามีบางอย่างผิดและควรแก้ไข

37. นักสร้างผลิตภัณฑ์ชั้นยอดมักอยู่ในโหมดทำต้นแบบและทดลองเสมอ พวกเขาต้องคุ้นเคยกับการสร้าง MVP และ proof of concept ปล่อยงานที่ยังไม่สมบูรณ์ รวบรวมฟีดแบ็ก และ pivot เมื่อมันล้มเหลว อีกทั้งยังต้องมีทักษะครบตั้งแต่โครงสร้างพื้นฐานไปจนถึงดีไซน์ เพื่อสร้างสิ่งต่าง ๆ จากศูนย์

38. การทำ A/B test ให้สำเร็จต้องมีสมมติฐานที่ดีซึ่งอธิบายทั้งสิ่งที่กำลังทดสอบและเหตุผลที่ทดสอบ ควรรวมบริบทของการทดสอบ สิ่งที่เปลี่ยน เมตริก และผลลัพธ์ที่คาดหวัง

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

40. การทดลองกับผลิตภัณฑ์สามารถทำแบบ “ทื่อ ๆ” กว่าที่คุณคิดได้มาก แทนที่จะสร้างฟีเจอร์เต็มรูปแบบ ให้ลองทำ fake door test เช่น เพิ่มตัวเลือกหรือปุ่มที่ยังไม่มีอะไรอยู่ข้างหลัง แล้วดูว่ามีคนคลิกหรือไม่

41. ความล้มเหลวของการทดลองกับผลิตภัณฑ์ไม่ใช่จุดจบของโลก ที่ Google การทดลอง 80-90% “ล้มเหลว” แม้มันอาจดูเหมือนเสียเวลา แต่ในระดับขนาดใหญ่ ความสำเร็จ 10% ก็ชดเชยความล้มเหลวทั้งหมดได้ เช่น A/B test เรื่องการแสดงหัวข้อใน Bing ที่เพิ่มรายได้ 12% (มากกว่า $100 ล้าน)

42. เมื่อโฟกัสการเติบโต ให้คิดและจัดลำดับความสำคัญแบบ growth engineer ระบุพื้นที่เป้าหมาย เลือกเมตริกตัวแทน ตั้งสมมติฐานการปรับปรุง และสร้างการทดลองขนาดเล็กที่สุดที่เป็นไปได้เพื่อทดสอบมัน

43. การใส่ระบบ analytics แทบไม่มีคำว่าเร็วเกินไปเลย มันอาจเร็วเกินไปสำหรับผลิตภัณฑ์ก่อนเปิดตัว แต่การปล่อยโดยไม่มี analytics ด้วยเหตุผลว่า “ยังเร็วเกินไป” เป็นการประหยัดที่ไม่คุ้ม หลังเปิดตัว ลำดับความสำคัญจะเปลี่ยนจากการปล่อยให้เร็วที่สุด ไปเป็นการปล่อย “สิ่งที่ถูกต้อง” ให้เร็วที่สุด

44. เมื่อเริ่มต้นกับ analytics ให้เริ่มเล็ก ๆ เลือกผลิตภัณฑ์หรือฟีเจอร์หนึ่งอย่าง ใช้ autocapture เพื่อติดตามการใช้งาน แสดงผลด้วยกราฟแนวโน้มและ retention แล้วลองปล่อยฟีเจอร์ที่ช่วยปรับปรุงมัน “modern data stack industrial complex” ทำให้เรื่องนี้ดูซับซ้อนกว่าความเป็นจริง

45. ถ้าคุณไม่รู้ว่าจะเริ่มที่เมตริกไหน ขอแนะนำ activation เพราะมันอยู่เหนือเมตริกอื่น ๆ วิศวกรมีอิทธิพลต่อมันได้โดยตรง และมันมีประโยชน์ต่อทั้งองค์กร

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

47. เมื่อต้องวัด product-market fit ให้ดูว่าการมีส่วนร่วมของผู้ใช้เพิ่มขึ้นแบบทวีคูณเร็วกว่าการเติบโตของผู้ใช้หรือไม่ และ retention เริ่มราบตัวหรือไม่ (มากกว่า 0%) จากนั้นค่อยดูว่าผู้ใช้ในกลุ่ม ICP มี retention ที่โดดเด่นหรือไม่ และลูกค้าที่จ่ายเงินอยู่ในกลุ่ม ICP หรือไม่

48. การทบทวนการเติบโตช่วยตรวจสอบว่าสิ่งที่ทีมสร้างมีผลกระทบต่อเมตริกสำคัญ เช่น รายได้ product analytics และฟีดแบ็กจากผู้ใช้หรือไม่ ที่ PostHog นี่คือหนึ่งในความรับผิดชอบหลักของ product manager

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

50. จงยึดติดกับผลิตภัณฑ์ที่น่าสนใจ อย่างที่ James ผู้ร่วมก่อตั้ง PostHog เขียนไว้ในไกด์ product-market fit ว่า “ถ้ามันไม่น่าสนใจ ก็ pivot แค่นั้นเอง เมื่อคุณยึดติดกับงานที่ให้ความรู้สึกว่าเป็นของคุณจริง ๆ คุณจะทำผลงานได้ดีกว่า”