สรุปหนังสือ The Lean Startup: ธุรกิจสำเร็จได้ด้วยการสร้างนวัตกรรมอย่างสม่ำเสมอ

สิ่งหนึ่งที่เราควรรู้ไว้เกี่ยวกับสตาร์ตอัปก็คือ…เราไม่สามารถประยุกต์ทฤษฎีด้านธุรกิจแบบเก่า ๆ มาใช้กับสตาร์ตอัปได้

เพราะอะไร?

หนึ่ง สตาร์ตอัปต้องดำเนินอยู่บนความไม่แน่นอนที่สูงมาก สูงกว่าบริษัททั่วไปที่คงคาดเดาได้แล้วว่าลูกค้าเป็นใคร มีตลาดใหญ่ขนาดไหน

สอง สตาร์ตอัปเป็นบริษัทใหม่เอี่ยม ยังไม่เคยมีประสบการณ์ ยังไม่มี Track Record หรือ Know-How ที่สืบทอดกันมาในบริษัท ไม่มีข้อมูลย้อนหลังที่ช่วยให้ Forecast อนาคตได้

The Lean Startup ที่เขียนโดย Eric Ries เล่มนี้ จะมาเล่าวิธีการสร้างและบริหารสตาร์ตอัป ทั้งจากประสบการณ์ของเขาและผู้คนที่เขาเคยพบเจอ เพื่อที่ว่าใครก็ตามที่อยากจะสร้างสตาร์ตอัปหรือนวัตกรรมเป็นของตัวเอง จะได้ไม่ต้องเสียเวลาทำไรที่มันสูญเปล่า

หลักการ 5 ประการของ Lean Startup ที่จะพบเจอในหนังสือเล่มนี้

1. ผู้ประกอบการ (Entrepreneurs) มีอยู่ทุกที่ จะโรงรถ ห้องพัก บริษัทขนาดใหญ่ บริษัทขนาดกลาง องค์กร NGO ใครก็ได้ที่ทำงานเกี่ยวข้องการกับสร้างสิ่งใหม่ ๆ ในสภาพแวดล้อมที่ผันผวนเอาแน่เอานอนไม่ได้
2. การประกอบการสามารถไปเคียงคู่กับการบริหารจัดการ (Management) ได้ ซึ่งการบริหารจัดการที่ว่านี้ก็ต้อง “ใหม่” สมกับที่เป็นสตาร์ตอัป
3. สตาร์ตอัปอยู่เพื่อเรียนรู้วิธีการสร้างธุรกิจให้ยั่งยืน การจะทำเช่นนี้ได้จะต้องมีการทดลองอยู่เรื่อย ๆ
4. สร้าง-วัดผล-เรียนรู้ (Build-Measure-Learn) คือสิ่งที่จำเป็นมาก ๆ
5. เรื่องน่าเบื่อ ๆ อย่างการวัดความคืบหน้า สร้าง Milestones และการจัดลำดับความสำคัญ ก็จำเป็นสำหรับสตาร์ตอัปเช่นกัน

ส่วนที่ 1: วิสัยทัศน์

จุดเริ่มต้น

โดยส่วนใหญ่แล้ว สตาร์ตอัปมักจะเริ่มจาก “วิสัยทัศน์” อันยิ่งใหญ่ก่อน ว่าอยากเปลี่ยนแปลงอะไรโลกใบนี้

จากนั้น พวกเขาก็จะคิดค้น “กลยุทธ์” ว่าต้องทำอย่างไร ต้องเล่นท่าไหน

และสุดท้ายถึงจะมี “ผลิตภัณฑ์” ออกมา สังเกตว่าผลิตภัณฑ์ไม่ได้มาเป็นอย่างแรกนะ

ในสามขั้นตอนนี้ โดยปกติแล้ววิสัยทัศน์จะไม่เปลี่ยนเท่าไร ลองคิดภาพคนคนนึงอยากเปลี่ยนโลกไปในทิศทางหนึ่ง ก็คงไม่เปลี่ยนความคิดกันง่าย ๆ หรอกจริงมะ สิ่งที่จะเปลี่ยนก็มีแต่กลยุทธ์และผลิตภัณฑ์นี่แหละ

กลยุทธ์นั้นหากลองทดสอบแล้วมันยังไม่โดน ก็อาจจะต้องเปลี่ยนทิศ (Pivot)

ผลิตภัณฑ์นั้นถ้ายังไม่โดนใจลูกค้า ก็อาจจะต้องมีการปรับเปลี่ยนให้เหมาะสมที่สุด (Optimization)

ซึ่งการจะทำแบบนี้ได้ สตาร์ตอัปจะต้องมีกระบวนการเรียนรู้ผ่านกระบวนการ Build-Measure-Learn ว่าง่าย ๆ ก็คือระหว่างทางอาจจะมีพลาดพลั้ง หน้าแตก ทำผิดไปบ้าง แต่สิ่งสำคัญคือต้องเรียนรู้และนำกลับมาคิดต่อว่าควรพัฒนายังไง แก้ไขยังไง จะทำต่อมั้ยหรือจะเปลี่ยนทางดี

การทำงานของสตาร์ตอัปนั้น ไม่ใช่การวางสมมติฐานแล้วทำตามแผนเป๊ะ ๆ แบบ 1. 2. 3. จบ แต่เป็นการค่อย ๆ ปรับ ค่อย ๆ เปลี่ยนไปตามกาลเวลา ทุก ๆ ครั้งก็จะเกิดการเรียนรู้ใหม่ ๆ

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

ความท้าทายก็คือ จะบาลานซ์ทุก ๆ อย่างยังไงนี่แหละ

คำนิยาม

ถ้าพูดถึงคำว่า “สตาร์ตอัป” หลาย ๆ คนอาจจะนึกถึงเหล่าเนิร์ดจำนวนไม่ถึง 10 คนที่ลาออกจากงาน มาร่วมสุมหัวกันทำงานในโรงรถ นั่งกินมาม่าร่วมกัน วาดฝันภาพอันสวยงามว่าเทคโนโลยีพวกเขาจะเปลี่ยนโลกยังไง

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

แล้วมันต่างจากสถานการณ์แรกยังไงล่ะ?

สิ่งที่ต่างคือ คำนิยามแบบที่สองนั้นไม่ได้ระบุว่าองค์กรนี้ต้องมีกี่คน แล้วต้องเป็นบริษัทแบบไหน

กล่าวง่าย ๆ คือ สตาร์ตอัปจะมีกี่คนก็ได้ จะเป็นบริษัทเพิ่งก่อตั้ง หรือบริษัทที่ใหญ่แล้วก็ได้ ขอแค่มี Mindset ของการอยากสร้างนวัตกรรมใหม่ ๆ และอยู่ภายใต้สภาวะที่คาดเดาไม่ได้ว่าจะเกิดอะไรขึ้นในอนาคต แค่นี้ก็สามารถเรียกตนว่าเป็นสตาร์ตอัปได้แล้ว

ตัวอย่างก็เช่น Intuit ซึ่งสามารถสร้างผลิตภัณฑ์เปลี่ยนโลกการคำนวณภาษีอย่าง SnapTax ตอนที่อ่านเรื่องนี้ครั้งแรก เรายังนึกเลยว่าสงสัยคงเป็นแก๊งวิศวกรไม่กี่คนที่ออกจากบริษัทมาทำร่วมธุรกิจร่วมกัน แต่เปล่าเลย พวกเขาคือทีมเล็ก ๆ ในองค์กรใหญ่อย่าง Intuit ต่างหาก

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

ฉะนั้นแล้ว ไม่ว่าจะเป็นใคร จะอยู่บริษัทใหญ่ บริษัทเล็ก หรือออกมาทำเอง ก็เป็นผู้ประกอบการสตาร์ตอัปได้ทั้งนั้น

การเรียนรู้

สำหรับสตาร์ตอัปนั้น ควรใช้วิธีการเรียนรู้แบบ Validated Learning คือเป็นการเรียนรู้แล้วนำสิ่งที่เรียนรู้นั่นแหละมาพิสูจน์ว่าเออ มันสำเร็จจริง

ปฏิเสธไม่ได้เลยว่าการทำสตาร์ตอัปนั้นต้องเจอกับความผิดพลาด เล็กบ้างใหญ่บ้าง ในเมื่อมันเป็นการทำธุรกิจบนความไม่แน่นอนที่สูงกว่าธุรกิจทั่ว ๆ ไป แต่สิ่งที่สำคัญคือ เมื่อผิดพลาดแล้วก็ต้องเรียนรู้ ต้องปรับแก้ ต้องพิสูจน์

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

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

ผลปรากฏว่าไม่มีใครโหลด IMVU มาใช้งานเลยจ้า… เงียบกริบ อยู่เฉยไม่ได้ละ ต้องรู้ให้ได้ว่าทำไมถึงเป็นงั้น ทางทีมผู้สร้างเลยเริ่มทำการเรียกลูกค้ามาสัมภาษณ์ ซึ่งพอทำ Process นี้เท่านั้นแหละ พวกเขาก็ได้เรียนรู้ว่าจริง ๆ แล้วสิ่งที่พวกเขาตั้งสมมติฐานกันแต่แรกนั้นผิด-หมด-เลย!!

เช่น ลูกค้าไม่ซีเรียสกับการเล่นแอปฯ แชตใหม่ ๆ / ลูกค้าต้องการใช้ Avatar เพื่อคุยกับเพื่อนใหม่ ไม่ใช่เพื่อนหน้าเดิม ๆ / ลูกค้ายังไม่อยาก Invite ใคร ถ้ายังไม่ได้ทดสอบเล่นเองก่อน ไม่อยากถูกมองว่าไม่คูล ถ้าดันเผลอไปแชร์อะไรที่เพี้ยน ๆ

สิ่งที่น่าเจ็บใจคือ กว่าจะได้เรียนรู้ Insight ที่มีประโยชน์เหล่านี้ ก็ต้องทุ่มเทสร้างของจริงกันถึง 6 เดือนเลย ซึ่งถือว่าใช้เวลานานมากกกก ความจริงคือถ้าค่อย ๆ ทำ Prototype หรือ MVP แล้วให้ลูกค้ามาฟีดแบ็กทีละนิด ๆ ยังน่าจะเซฟเวลาได้มากกว่า ไม่ต้องไปลงทุนลงแรงแก้บั๊กปรับฟีเจอร์อะไรที่ไม่จำเป็น อ่านแล้วพานให้นึกถึงวิธีทำ SPRINT ภายใน 5 วันที่จะเซฟเวลาหาคำตอบได้มาก

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

Validated Learning คือการค่อย ๆ เรียนรู้ และนำสิ่งที่เรียนรู้มาพัฒนาผลิตภัณฑ์ให้ดียิ่ง ๆ ขึ้น มันไม่ใช่การไปโฟกัสกับตัวเลข ยอดขาย ยอด PR หรือยอดการรับรู้ บางทีไปโฟกัสพวกนี้มากเกินไปก็อาจจะทำให้ท้อ (เพราะช่วงแรก ๆ อาจจะยังขายได้ไม่เยอะ) หรือบางทีอาจจะทุ่มงบกับตรงนี้มากไป (เช่น โปรย PR หนัก ๆ) แทนที่จะนำงบมาพัฒนาสินค้าให้ดีขึ้นจริง ๆ

การทดลอง

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

ให้คิดการทดลองไอเดียธุรกิจเป็นเหมือนการทดลองทางวิทยาศาสตร์ เริ่มต้นเราจะต้องตั้งสมมติฐานก่อน ซึ่งการทดลองก็จะช่วยเรายืนยันว่าสมมติฐานที่เราคิดนั้นเป็นจริงมั้ย

ส่วนใหญ่แล้วสมมติฐานที่สำคัญ ๆ มีอยู่ 2 แบบด้วยกัน คือ

สมมติฐานด้านคุณค่า (Value Hypothesis) จะนำไปสู่การทดลองว่าผลิตภัณฑ์นี้ได้ส่งมอบคุณค่าให้ลูกค้าได้จริง ๆ รึเปล่า ลูกค้ามองว่ามันมีประโยชน์จริงมั้ย

สมมติฐานด้านการเติบโต (Growth Hypothesis) จะนำไปสู่การทดลองว่าลูกค้าใหม่ ๆ จะมาเจอผลิตภัณฑ์นี้ได้อย่างไร โอกาสที่มันจะไปเจอลูกค้าใหม่ ๆ นั้นเยอะแค่ไหน

ข้อดีของการทดลองโดยสร้างผลิตภัณฑ์ Prototype ขึ้นมา แทนที่จะทำ Market Research หรือ Survey ทั่ว ๆ ไป ก็คือเราจะได้เห็นปฏิกิริยาลูกค้าที่มีต่อผลิตภัณฑ์ของเราจริง ๆ ไม่มี Bias จะได้รู้ว่าจริง ๆ แล้วลูกค้าต้องการอะไรกันแน่ และบางที ลูกค้าอาจจะทำเราเซอร์ไพรส์ด้วยการเผยบางอย่างที่เราไม่คาดคิดก็ได้

(อีกอย่างคือ ทำ Market Research หรือ Survey ไปก็อาจจะไม่ได้ช่วยอะไร เพราะลูกค้ามักไม่รู้หรอกว่าตัวเองต้องการอะไร)

อย่างไรก็ดี ก่อนที่จะเริ่มลุยคิดหา Solution กัน ก็ควรเหยียบเบรกสักแป๊บ คุณ Mark Cook ซึ่งเป็น Vice President ของ Kodak Gallery แนะนำว่า ให้ตอบคำถาม 4 ข้อนี้ก่อน เพื่อป้องกันไม่ให้รีบบุ่มบ่ามสร้างผลิตภัณฑ์ที่ลูกค้าไม่ได้ต้องการ

1. ลูกค้ารู้รึเปล่าว่าพวกเขามีปัญหาที่เราอยากจะแก้ไข
2. ถ้ามี Solution ให้ลูกค้า ลูกค้าจะจ่ายเงินซื้อมั้ย
3. ลูกค้าจะซื้อกับเรามั้ย
4. เราสร้าง Solution สำหรับปัญหานั้นได้มั้ย

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

ส่วนที่ 2: การคุมทิศทาง

การเรียนรู้เพื่อสร้างสิ่งใหม่ ๆ ของสตาร์ตอัปนั้น ย่อแบบสั้น ๆ จะเหลือเพียงแค่ 3 ขั้นตอนเท่านั้น คือ Build-Measure-Learn

สิ่งนี้เป็นกลไกที่เมื่ออยู่ด้วยกันแล้วจะ powerful มาก ๆ เพราะมันช่วยให้สตาร์ตอัปสามารถวัดผลได้ว่าสิ่งที่ปรับไปนั้น มันเวิร์กจริงรึเปล่า ถ้าไม่เวิร์ก จะได้รีบปรับเปลี่ยน

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

การก้าวกระโดด

สิ่งหนึ่งที่ทำให้ Facebook ประสบความสำเร็จอย่างไวคือ พวกเขาสามารถพิสูจน์สมมติฐานหลัก 2 ข้อได้

สมมติฐานด้านคุณค่า (Value Hypothesis) ครึ่งหนึ่งของผู้ใช้กลับมาเล่นเฟซบุ๊กอีกครั้งภายในวันเดียว

สมมติฐานด้านการเติบโต (Growth Hypothesis) มีผู้ใช้ใหม่ ๆ ในรั้วมหา’ลัยเพิ่มขึ้นเร็วมาก

สองสมมติฐานนี้คือส่วนหนึ่งที่จะช่วยให้ Stakeholders ของธุรกิจรู้สึกมั่นใจกับสตาร์ตอัปนี้ขึ้นมาก ๆ หรือที่ในหนังสือเรียกว่า Leap of Faith คือเป็นความศรัทธาแบบก้าวกระโดด ในกรณีที่ถ้าสตาร์ตอัปสามารถพิสูจน์ได้ว่าสมมติฐาน 2 ข้อนี้เป็นความจริง

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

การทดสอบ

การสร้าง MVP คือหนึ่งวิธีการทดสอบสมมติฐานอย่างรวดเร็วและตรงไปตรงมา

MVP (Minimum Viable Product) คือ Solution ที่ออกแบบหรือสร้างมา “เพียงเพื่อตอบคำถามที่เราสงสัย” มันไม่จำเป็นจะต้องมีฟังก์ชั่นครบเซ็ตแบบอู้วว้าววว เอาไปขายได้เลย ตรงกันข้าม มันควรจะมีแค่อะไรที่จำเป็นต่อการตอบสมมติฐานของเราเท่านั้นก็พอ อะไรที่มากกว่านั้นถือเป็น Waste เป็นสิ่งไม่จำเป็น

โดยการทำ MVP นั้น เราจะได้ผลลัพธ์ที่ตีแสกหน้าเลยทีเดียวว่าสิ่งนี้ลูกค้าต้องการ/ไม่ต้องการ มันจะไม่เหมือนวิธีการทำรีเสิร์ชแบบ Focus Group หรือการทำการตลาดทั่วไปในห้องประชุม เพราะเราจะได้เห็นผลลัพธ์จากลูกค้าจริง ๆ เช่น ลูกค้ามีการกด Sign-Up จริง เป็นเครื่องยืนยันว่าเค้าต้องการ Solution ของเรา แปลได้ว่า Solution นี้มีคุณค่าสำหรับเค้าจริง ๆ ไม่ใช่แค่การคิดมโนว่า “อือ ถ้ามีสิ่งนี้คงจะดี…มั้ง…นะ”

ทีนี้ มันจะมีกำแพงที่ต้องก้าวข้ามผ่านไป สำหรับใครที่เป็น Perfectionist ชนิดที่ว่า ยอมไม่ได้ที่จะเป็นสินค้าไม่สมบูรณ์แบบ อันนี้ก็ต้องปรับ Mindset กันนิดนึง คือ MVP เนี่ยเรานำออกไปเพื่อเรียนรู้ ไม่ได้เพื่อนำไปขายทันที ยิ่งเราเรียนรู้ได้เร็วเท่าไร เราก็ยิ่งพัฒนาแก้ไข (หรือแม้กระทั่งเปลี่ยนทิศ) ได้เร็วเท่านั้น

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

อีกอย่าง ส่วนใหญ่ MVP มักจะถูกนำไปเทสต์กับ Early Adopters หรือพวกที่พร้อมจะใช้นวัตกรรมใหม่ ๆ แก๊งนี้เค้าไม่สนใจเท่าไรว่าของจะเพอร์เฟ็กต์ 100% เค้าแค่อยากลองของใหม่ให้เร็วที่สุดก่อนใคร ๆ และพวกเค้าพร้อมที่จะให้ฟีดแบ็ก

อีกเรื่องตลกร้ายคือ เราไม่ต้องกลัวว่าไอเดียที่นำไป MVP นั้นจะโดนก๊อป เพราะส่วนใหญ่แล้วชื่อเสียงหรือฐานลูกค้าของสตาร์ตอัปเบื้องต้นจะเล็กมากจนน่าเศร้า คือว่าง่าย ๆ แทบไม่มีใครมาสนใจเรา ยิ่งบริษัทใหญ่ ๆ เค้าก็มีภาระล้นเหลืออยู่แล้ว ผู้เขียนถึงขั้นท้าว่าลองเอา Solution ไปประเคนหน้าบริษัทใหญ่ ๆ สิ ส่วนใหญ่ไม่เหลียวมองเราหรอก

และนี่คือตัวอย่าง MVP ของผลิตภัณฑ์ที่ประสบความสำเร็จ

Dropbox: สร้าง VDO ขึ้นมาเพื่อให้คนเห็นภาพว่าการทำงานเชื่อมต่อข้อมูลแบบ Seamless มันเจ๋งยังไง ถ้าสนใจใช้บริการแบบนี้ก็คลิก Sign-Up เลยจ้า (แน่นอนว่า ณ จุดนี้ยังไม่ได้สร้างระบบกันจริง ๆ ด้วยซ้ำ)

Groupon: สร้างหน้า WordPress ขึ้นมาขายคูปองสิ่งต่าง ๆ เช่น ร้านพิซซ่า เพื่อเทสต์ว่าคนมากดซื้อคูปองจริงมั้ย (คูปองทำมือแล้วส่งเข้าเมล)

Food on the Table: CEO และ VP of Product ออกไปคุยกับลูกค้าเอง ไปเลือกเมนู ไปซื้อของที่ซูเปอร์ฯ ไปส่งของให้ที่บ้าน เพื่อเทสต์ว่าลูกค้าต้องการบริการนี้มั้ย (เมื่อผลลัพธ์ออกมาว่าลูกค้าชอบ ก็ค่อยสเกลโดยใช้ระบบ Automation เข้ามาช่วย)

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

การวัดผล

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

ในการวัดผลแบบบริษัททั่วไป สมมติว่าเป็นบริษัทผลิตสินค้าขายของตามซูเปอร์ฯ ทั่วไป ก็คงวัดความสำเร็จด้านการเติบโตจากกำไรต่อหัวลูกค้า/ต้นทุนในการหาลูกค้าใหม่/การกลับมาซื้อใหม่ของลูกค้า แต่สมมติว่าเป็นบริษัทสตาร์ตอัปที่สร้างแพลตฟอร์มการซื้อขายของออนไลน์ เช่น eBay ก็คงใช้ตัววัดเดียวกันนี้ไม่ได้แน่นอน โดย eBay นั้นอาจจะต้องวัดการเติบโตจาก Network Effect ว่าคนขายกับคนซื้อเพิ่มจำนวนขึ้นเท่าไร ว่าคนขายกับคนซื้อกลับมาใช้งานเรื่อย ๆ มั้ย

Innovation Accounting มี 3 Learning Milestones

1. สร้าง Baseline ขึ้นมา เพื่อหาว่าตัวเลขที่แท้จริงตอนนี้เป็นเท่าไร อาจทำสิ่งนี้ด้วยการลองปล่อย MVP ออกไปเพื่อให้เห็นตัวเลขจริง จะได้นำมาเป็น Benchmark ได้
2. ค่อย ๆ ปรับการสร้างชิ้นงานให้มีผลใกล้เคียงกับเป้าหมายที่เราต้องการ
3. ตัดสินใจว่าจะไปต่อหรือล้มเลิก ถ้าปรับแก้แล้วตัวเลขไปได้ดี ถึงเป้าหมาย นี่แหละคือทางที่ใช่ แต่ถ้าทำแล้วไม่เห็นผล ก็เห็นทีจะต้องล้มเลิกแล้วหาทางใหม่

ที่ IMVU นั้น ทีมเคยใช้ Cohort Analysis ในการดูว่าลูกค้าแต่ละ Funnel เพิ่มขึ้น/ลดลงอย่างไรบ้างในระหว่างที่พวกเขาทำการทดลองปรับแก้สิ่งต่าง ๆ โดยกราฟนี้จะแบ่งกลุ่มคนออกเป็นแต่ละเดือน และแตกออกมาเลยว่าในเดือนนั้น ๆ มีอัตราลูกค้าอยู่ที่แต่ละ Funnel คิดเป็นจำนวนกี่ % เมื่อแสดงผลออกมาแบบนี้ ก็จะทำให้เห็นชัดว่า Segment ไหนพัฒนาได้ดี Segment ไหนยังติดแหง็กอยู่ที่เดิม

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

การใช้ตัววัดผลแบบนี้มีแต่จะทำให้เราเห็นภาพลวงตาว่าธุรกิจกำลังเติบโตได้ดี (เพราะกราฟก็จะขึ้นสวย ๆ เผลอ ๆ เป็น Hockey Stick ให้ดีใจเล่น) ยิ่งถ้าไปโฟกัสแค่กับตัวเลขนี้ สุดท้ายเราก็จะติดกับอยากทำให้ตัวเลขมันสวย ๆ เราก็จะไปใช้วิธีซื้อ Ads ซื้อ Keyword หรือโปรย PR แต่งหน้าเค้กให้สวย ๆ เอา ทั้งที่งบพวกนี้ถ้าไปลงกับการพัฒนาผลิตภัณฑ์ ยังจะมีประโยชน์กับการสร้างความยั่งยืนให้บริษัทมากกว่า

แน่นอนว่าเป็นหน้าที่ของ Product Manager ที่จะต้องทำการเรียงลำดับความสำคัญของงาน อะไรควรออกก่อนออกหลัง แล้วตอนนี้ทีมมี Effort มากน้อยแค่ไหน อีกหนึ่งวิธีที่สามารถช่วยได้คือการใช้ Kanban Board ในการโอนถ่ายงาน ดูจากตารางด้านล่าง สมมติว่าได้กำหนดไว้ว่าแต่ละคอลัมน์ต้องมีไม่เกิน 3 งานในช่วงเวลาเดียวกันเพื่อไม่ให้ทีมล้นเกิน คอลัมน์หรือขั้นตอนไหนที่เต็ม ก็ไม่สามารถเอางานเข้าคอลัมน์นั้นได้ ต้องต่อคิวรอไป

คอลัมน์ที่สำคัญและห้ามขาดคือ Validated ซึ่งเป็นส่วนที่จะทำให้เราได้เรียนรู้ว่าสิ่งที่เราพยายามสร้างกันมานั้นได้ผลจริงมั้ย มันเป็นกึ่ง ๆ ตัวเบรกด้วย ว่าถ้ายังไม่ Validated งานพวกนี้ เอ็งก็ห้ามเอางานอื่นเข้ามาใน Sprint นะ

ดังนั้น สิ่งที่สำคัญคือ การวัดผลที่แม่นยำและตรงประเด็น ตอบโจทย์สิ่งที่เราอยากเรียนรู้ และต้องมีการทำอย่างสม่ำเสมอเพื่อวัดผลในทุก ๆ สิ่งที่เราทำการเปลี่ยนแปลง ปรับแก้ เพิ่มเติมหรือเอาออก นอกจาก Cohort Analysis เราอาจจะใช้วิธีการทดลองแบบ A/B Testing หรือ Split Test ในการแบ่งกลุ่มลูกค้าเพื่อทดสอบว่าของใหม่ที่เราทำนั้นต่างจากของเดิมแค่ไหน ไม่แน่ว่าสิ่งที่ทีมคิดว่าดี ลูกค้าอาจจะเฉย ๆ ก็ได้

3 องค์ประกอบของการวัดผลที่ดี

Actionable (สามารถนำไปปฏิบัติตามได้): การวัดผลควรบอกชัดเจนว่าอะไรคือสาเหตุ และอะไรคือผลลัพธ์

Accessible (สามารถเข้าถึงได้): ทุก ๆ คนในองค์กรสามารถเข้าถึงรายการการวัดผลได้ และสามารถเข้าใจได้ง่าย ๆ ไม่ใช้ศัพท์เทคนิคประหลาด ๆ และไม่ใช่ตัววัดที่คลุมเครือ เช่น แทนที่จะวัดเป็นจำนวนคลิกเข้าเว็บไซต์ (ซึ่งคำว่า “คลิก” ตีความได้หลายแบบ) ก็อาจจะวัดเป็นจำนวนคนเข้าเว็บไซต์แทน

Auditable (สามารถสร้างความน่าเชื่อถือ): หากไม่มีหลักฐานการวัดผลที่ชัดเจน อาจเกิดปัญหาการกล่าวโทษกันได้ อาจจะใช้วิธีการ Cross-Check กับลูกค้าแล้วบันทึกข้อมูลไว้

การเปลี่ยนทิศ (Pivot) หรือทนต่อไป (Presevere)

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

อันที่จริงแล้วการเปลี่ยนทิศไม่ได้หมายความว่าให้เราละทิ้งทุกอย่างแล้วกลับไปนอนร้องไห้ แต่มันคือการปรับเปลี่ยนพื้นฐานบางอย่างของธุรกิจต่างหาก (ซึ่งสิ่งนี้ก็ต้องการการทดลองสมมติฐานเช่นกัน) นั่นหมายความว่าเราไม่ต้องพับเสื่อเก็บของทั้งหมด เพียงแต่อาจจะต้องเปลี่ยนบางสิ่งบางอย่าง เพื่อดูว่ามันจะส่งผลลัพธ์ดีขึ้นมั้ย

ตัวอย่างของการเปลี่ยนทิศ เช่น

• Zoom-In Pivot: การเปลี่ยนจาก solution ที่ทำหลาย ๆ อย่างได้ ไปโฟกัสแค่ฟีเจอร์ชิ้นเดียวที่ได้รับคำนิยม
• Zoom-Out Pivot: สลับกับด้านบน หากฟีเจอร์เดียวไม่เพียงพอ ก็อาจจะต้องเพิ่มฟีเจอร์มากขึ้น
• Customer Segment Pivot: เปลี่ยนฐานลูกค้า
• Customer Need Pivot: เปลี่ยนไปตอบความต้องการอื่นของลูกค้า
• Platform Pivot: เปลี่ยน Platform เช่น จากแอปฯ เป็นแพลตฟอร์ม
• Business Architecture Pivot: เปลี่ยนโครงสร้างธุรกิจ เช่น จาก B2B เป็น B2C
• Value Capture Pivot: เปลี่ยนวิธีเรียกรายได้และกำไร
• Engine of Growth Pivot: เปลี่ยนวิธีสร้างการเติบโตให้บริษัท (มักจะกระทบวิธี Value Capture ด้วย)
• Channel Pivot: เปลี่ยนช่องทางการขาย
• Technology Pivot: เปลี่ยนเทคโนโลยีที่ใช้พัฒนา

บางครั้งธุรกิจอาจจะหลงระเริงไปกับตัวเลขทบต้นที่สูงเอา ๆ และลืมไปว่าสุดท้ายแล้วมันอาจจะตัน มันไม่สามารถโตไปได้ตลอด หรือบางธุรกิจที่เพิ่งเริ่ม อาจจะทำโปรดักต์ออกมาตอบโจทย์ Early Adopters มาก แต่สุดท้ายการจะเติบโตก็ต้องพยายามกุมใจลูกค้า Mainstream ให้ได้ จึงเป็นสาเหตุให้ธุรกิจต้อง Pivot ตัว Customer Segment จะเห็นได้ว่าการ Pivot นั้นไม่ใช่แค่ในกรณีที่เห็นผลลัพธ์แย่ แต่ในกรณีที่ผลลัพธ์ดูเหมือนจะดี ก็ต้องคอยเฝ้าระวังเหมือนกัน

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

ส่วนที่ 3: เร่งเครื่อง

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

การทำไปทีละนิด

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

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

บทนี้ได้นำเสนอระบบการทำงานแบบ Small-Batch คือค่อย ๆ ทำทีละนิด ถ้าเปรียบเทียบกับการผลิตสิ่งของ ก็คือทำทีละชิ้นให้เสร็จไปเป็นชิ้น ๆ ไม่ใช่สร้างทุกชิ้นส่วนในคราวเดียว แล้วค่อยประกอบกันในภายหลัง (Large-Batch)

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

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

ในมุมของการทำงานแบบ Lean การทำ Small-Batch ก็คือการค่อย ๆ หยิบทีละอย่างไปเทสต์ ค่อย ๆ ปล่อยออกมาทีหลังฟังก์ชั่น หากจะสร้าง Prototype ก็ทำออกมาแค่พอดี ไม่ต้องโหมกระหน่ำเล่นใหญ่ การทำ Small-Batch คือทำให้เพียงพอที่จะรู้คำตอบของโจทย์ที่ต้องการไข

ในอีกกรณีนึง การทำงานแบบนี้ต้องการทีมที่มีความ Cross-Functional หรือก็คือสมาชิกจากทีมต่าง ๆ มาร่วมทำงานด้วยกัน ณ ตรงนั้นเลย ไม่ใช่ว่าทีมหนึ่งทำให้เสร็จก่อนแล้วค่อยส่งต่อให้อีกทีมหนึ่ง การทำงานด้วยกันเลยจะช่วยให้เห็นข้อผิดพลาดต่าง ๆ ได้ไว ได้ฟีดแบ็กรวดเร็ว

หากยังใช้วิธีแบบทำเสร็จค่อยส่งต่อ ก็จะเกิดปัญหาประมาณเช่น ทีมดีไซน์ออกแบบดีไซน์มาทั้งหมด 30 แบบ ส่งต่อให้ทีมนักพัฒนา ทีมดีไซน์ก็หันไปทำโปรเจ็กต์อื่นต่อ แต่ทีมนักพัฒนาก็ทักมาว่า “เฮ้ ดีไซน์นี้ไม่เวิร์ก ส่วนดีไซน์นี้ไม่แน่ใจว่าต้องสร้างยังไง” งานก็จะกลับมาที่ทีมดีไซน์อีกครั้ง แก้กันไปแก้กันมา วน ๆ กันไป ทั้ง ๆ ที่ปัญหานี้จะแก้ได้เร็วมากถ้าจับทีมดีไซน์กับทีมนักพัฒนามาสุมหัวกันตั้งแต่แรก

การทำงานแบบ Small-Batch ยังช่วยลดของคงค้างด้วย ถ้าในแง่ของการสินค้า ก็จะเรียกได้ว่ามี Inventories น้อยลง ประหยัดค่าขนส่ง ค่าเก็บรักษา ถ้าในแง่ของการทำงาน ก็จะกระตุ้นให้เกิดการทำงานที่เห็นผลลัพธ์จริง ๆ เช่น เราต้องการทำ Build-Measure-Learn หากเรามองปลายทางออกว่าเราต้องการเรียนรู้อะไร เราก็สามารถมองกลับไปได้ว่าเราต้องวัดผลยังไง และสุดท้ายก็จะรู้ว่าต้องสร้างสินค้าชิ้นไหนเพื่อตอบโจทย์การเรียนรู้ (วิธีนี้เรียกว่าการ Pull คือดึง Resources จากต้นทางมาใช้เป็นลำดับไป)

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

การเติบโต

หลาย ๆ บริษัทเมื่ออยู่มาสักพักแล้วอาจจะเริ่มเผชิญภาวะนิ่ง ๆ ที่อัตราการเติบโตไม่สูงเหมือนเคย สิ่งที่บริษัทต้องการคือการเติบโตอย่างยั่งยืน ซึ่งจะต่างจากการเติบโตเป็นแบบครั้งเดียวที่มักจะได้จากการโฆษณาหรือ PR หนัก ๆ

การเติบโตอย่างยั่งยืนนั้น อธิบายแบบง่าย ๆ คือ การที่ลูกค้าใหม่มาจากการกระทำอะไรบางอย่างของลูกค้าเก่า

การเติบโตมาจากไหนได้บ้าง?

1. ปากต่อปาก (Word-of-Mouth): ปกติแล้วถ้าสินค้าดี มันจะกระตุ้นให้คนบอกต่ออยู่แล้ว
2. ผลข้างเคียงของการใช้สินค้า: เหมือนลูกค้าโปรโมตสินค้าให้เราแบบไม่รู้ตัว เช่น การใส่เสื้อผ้าสวย ๆ รุ่นใหม่ล่าสุด ก็ทำให้คนอื่นอยากซื้อตาม หรือแพลตฟอร์มอย่าง Facebook ก็ถือว่าอยู่ในหมวดนี้
3. การซื้อโฆษณา: การที่จะให้ส่วนนี้ยั่งยืนได้นั้น ต้นทุนการหาลูกค้าใหม่ควรจะน้อยกว่ารายได้ที่ลูกค้านั้นให้เรา
4. การกลับมาใช้ซ้ำ: บางสินค้าถูกออกแบบมาเพื่อให้เราใช้ต่อไปเรื่อย ๆ เช่น เครือข่ายมือถือ อินเตอร์เน็ต แม้กระทั่งอาหารหรือหลอดไฟก็ถือว่าอยู่ในหมวดนี้

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

3 เครื่องยนต์การเติบโต

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

เครื่องยนต์แบบติดหนึบ (Sticky)

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

(แน่นอนว่าคงเปลี่ยนก็ต่อเมื่อของเดิมมันแย่ หรือของคู่แข่งดีกว่าแบบเห็นได้ชัด)

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

เครื่องยนต์แบบไวรัล (Viral)

เครื่องยนต์รูปแบบนี้จะเกิดขึ้นกับบริษัทที่สร้างอะไรก็ตามที่พอลูกค้าใช้แล้ว มันเหมือนเป็นการ tie-in ให้บริษัทไปกลาย ๆ (แม้ว่าลูกค้าจะไม่ได้ตั้งใจบอกต่อก็เถอะ) ตัวอย่างก็ง่าย ๆ เช่น Facebook ที่พอเพื่อน ๆ เล่น เราก็อาจจะอยากเล่นตาม หรือในกรณีของ Hotmail ที่แอบแนบข้อความเชิญชวนเปิดเมลฟรีไปใน Footer อีเมลของลูกค้าที่ใช้ส่งหาคนอื่น ๆ ก็ทำให้ได้รับผู้ใช้มากมาย

การที่จะวัดผลว่าเครื่องยนต์นี้ทำงานได้ดีแค่ไหน ก็คือต้องวัด Viral Loop ซึ่งความเร็วของมันจะถูกวัดด้วย Viral Coefficient ยิ่งค่านี้สูงเท่าไร สินค้าของเราก็ยิ่งแผ่ขยายไปไกลได้เร็วเท่านั้น โดยไอ้ตัว Viral Coefficient จะวัดว่าจะมีลูกค้าของเรากี่คนที่พาเพื่อนมาด้วย ถ้าสูงกว่า 1 แปลว่าลูกค้าแต่ละคนมีแนวโน้มจะบอกต่อเพื่อนมากกว่า 1 คน

วิธีคำนวณ Viral Coefficient
Source: https://www.cobloom.com/blog/how-to-work-out-your-saas-viral-coefficient-and-why-you-should

เครื่องยนต์แบบจ่ายเงิน (Paid)

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

ตัวเลขที่ชี้เป็นชี้ตายเครื่องยนต์นี้ก็คือ Lifetime Value (LTV) ซึ่งเป็นการคาดการณ์กำไรทั้งหมดที่เราจะได้จากลูกค้าคนหนึ่งในช่วงที่เค้ายังเป็นลูกค้ากับเรา ซึ่งถ้าค่า LTV นี้สูงกว่าค่าใช้จ่ายเฉลี่ยต่อหัวในการดึงลูกค้าเข้ามา ก็ถือว่าเครื่องยนต์นี้ประสบความสำเร็จ

การปรับตัว

อย่างที่เกริ่นตอนต้น สิ่งที่จำเป็นมาก ๆ ต่อกลยุทธ์แบบ Lean Startup นี่คือวัฒนธรรมขององค์กรที่เปิดใจยอมรับความเปลี่ยนแปลงอันรวดเร็วนี้ การที่แต่ละคนสามารถตอบสนองต่อความเปลี่ยนแปลงได้ไว เจอปัญหาปุ๊บก็หาทางแก้ไขเลย คือองค์กรที่สามารถปรับตัวได้ดี (Adaptive Organization)

แต่ก็ไม่ใช่ว่าการทำอะไรเร็ว ๆ จะดีเสมอไป เพราะบางทีมันก็ทำให้เราพลาดสร้างปัญหาได้ ทางที่ดีคือมันควรจะมีระบบอะไรสักอย่างที่คอยแตะเบรกให้เราบ้างเมื่อมันมีปัญหา เพื่อจะได้แก้ปัญหาได้ทัน

The 5 Whys

นี่คือหนึ่งวิธีที่บทนี้นำเสนอ มันเป็นการถามคำถามว่า “ทำไม” 5 ครั้งเพื่อหาต้นตอของปัญหาที่แท้จริง

ทำไมต้องถามถึง 5 ครั้ง? นั่นก็เพราะถ้าเราไม่ขุดไปเรื่อย ๆ บางทีเราไปแก้ปัญหาที่ปลายเหตุ ซึ่งถึงแก้ไปสุดท้ายแล้วถ้าต้นตอไม่ถูกแก้ ปัญหาเดิม ๆ ก็จะเกิดซ้ำอีก

ตัวอย่างการใช้คำถามว่าทำไม 5 ครั้ง เช่น

1. ทำไมเครื่องจักรถึงหยุดทำงาน (เพราะมันทำงานหนักไป ฟิวส์เลยขาด)
2. ทำไมมันถึงทำงานหนักไปล่ะ (ตลับลูกปืนไม่ได้รับการหล่อลื่นที่เพียงพอ)
3. ทำไมมันถึงไม่หล่อลื่นที่เพียงพอ (เพราะปั๊มหล่อลื่นทำงานได้ไม่เต็มที่)
4. ทำไมปั๊มหล่อลื่นถึงทำงานได้ไม่เต็มที่ (เพราะเพลาของปั๊มเริ่มผุพัง)
5. ทำไมเพลาถึงผุพัง (เพราะไม่ได้ติดเครื่องกรองไว้ เศษเหล็กเลยหลุดเข้าไป)

เนี่ย ถ้าไม่ถามทำไม 5 ครั้ง เราอาจจะแก้ปัญหาด้วยการเปลี่ยนฟิวส์ หรือเปลี่ยนเพลา แทนที่จะไปติดเครื่องกรองให้เรียบร้อย

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

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

ถ้าสมมติว่า 5 Whys เป็นอะไรที่ยากเกินไป ก็ลองเริ่มจากกฏ 2 ข้อนี้ก่อน

1. อดทนต่อความผิดพลาดครั้งแรก
2. อย่าให้เกิดความผิดพลาดแบบเดิมซ้ำสอง

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

การสร้างนวัตกรรม

ความเข้าใจผิดของหลาย ๆ คนคือ ยิ่งบริษัทโตเท่าไร ก็ยิ่งยากที่จะคงไว้ซึ่งวัฒนธรรมแห่งการกล้าสร้างอะไรใหม่ ๆ

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

สิ่งที่จำเป็นเบื้องต้นต่อการสร้าง Disruptive Innovation

ทรัพยากรที่ไม่ต้องเยอะมาก แต่ต้องมีความมั่นคง: เพราะสตาร์ตอัปนั้นถ้าพลาดนิดเดียวอาจจะล้มหายตายจากได้เลย การมั่นใจว่ามีทรัพยากรที่เพียงพอ ไม่น้อยไม่มากเกินไป สามารถบริหารได้นั้นเป็นสิ่งสำคัญ

สมาชิกทีมมีอิสระในการตัดสินใจ: ไม่ควรมีขั้นตอนอะไรเยอะแยะวุ่นวายกว่าจะได้ทำการทดลองชิ้นหนึ่ง

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

สร้าง Sandbox สำหรับการสร้างนวัตกรรมใหม่ ๆ โดยเฉพาะ

ใครเคยดูซีรีส์เรื่อง Start-up น่าจะคุ้นเคยกับ Sandbox ดี โดยในซีรีส์นั้นเป็นชื่อของบริษัท Accelerator ผู้ช่วยหนุนกำลังและให้คำแนะนำสตาร์ตอัปหน้าใหม่ ด้วยคอนเซ็ปต์ของ Sandbox หรือ กระบะทราย ที่ว่าการล้มในนี้น่ะไม่เป็นอันตราย เป็น Safe-Zone สำหรับการทดลองทำสิ่งต่าง ๆ ก่อนออกไปสู่โลกจริง

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

ข้อปฏิบัติของ Sandbox

1. ไม่ว่าทีมไหนก็ทำการทดลองได้ทั้งนั้น โดยเป็นการทดลองที่ระบุเจาะจงบางส่วนของสินค้าหรือบริการ และระบุเจาะจงกลุ่มลูกค้าแล้ว
2. ทีมต้องอยู่ดูแลการทดลองตั้งแต่ต้นจนจบ
3. การทดลองจะต้องอยู่ในขอบเขตเวลาที่ได้กำหนดไว้ (โปรเจ็กต์เล็ก ๆ อาจจะสักไม่กี่สัปดาห์)
4. การทดลองจะต้องไม่กระทบลูกค้ากลุ่มอื่นนอกเหนือจากที่กำหนดไว้ (นับเป็นสัดส่วน % ของลูกค้าหลักทั้งหมด)
5. ทุก ๆ การทดลองจะต้องมีตัววัดเป็น Actionable Metrics ประมาณ 5-10 ตัว
6. ทุก ๆ ทีมและทุก ๆ โปรดักต์ที่อยู่ภายใต้ Sandbox จะต้องใช้ Metrics ตัวเดียวกันในการวัดความสำเร็จ
7. ต้องคอยมอนิเตอร์ metrics และฟีดแบ็กของลูกค้าระหว่างการทดลอง และต้องหยุดทดลองทันทีถ้ามีอะไรผิดพลาด

สรุป

และนี่ก็คือทั้งหมดที่เราอยากจะสรุปสำหรับ The Lean Startup สิ่งที่เราชอบคือหลาย ๆ แนวทางสามารถนำไปปรับใช้กับการทำงานได้จริง ไม่จำเป็นต้องอยู่ในแผนก Product Development เราก็เชื่อว่ากลเม็ดต่าง ๆ ในหนังสือเล่มนี้น่าจะสามารถนำไปประยุกต์ได้ และน่าจะได้ผลลัพธ์ที่ต่างออกไปจากที่เคย ๆ ทำกันมา

โดยสุดท้ายแล้ว ใจความสำคัญของ The Lean Startup ก็ไม่ได้มีอะไรมากไปกว่าการมุ่งเน้นทำในสิ่งที่เกิด Value จริง ๆ ตอบโจทย์ลูกค้าและบริษัทจริง ๆ ผ่านการเรียนรู้และพัฒนาที่รวดเร็ว ไม่คิดเองเออเอง ไม่ยึดติดกับตัวเลขสวยหรูที่ใช้ทำอะไรต่อไม่ได้

สำหรับใครที่อยู่ในแวดวงสตาร์ตอัป (แน่นอนว่าไม่จำเป็นต้องเป็นบริษัทเล็กจิ๋วเพิ่งเกิด จะเป็นสตาร์ตอัปในองค์กรก็ได้) หนังสือเล่มนี้น่าจะช่วยปรับวิธีการทำงานได้ไม่มากก็น้อยเลยละ