“The Lean Startup — Eric Ries” Bible สำคัญแห่งวงการ Startups

ผมอยู่ในวงการ Startups มาปีนี้ก็กำลังเข้าปีที่ 3 แล้วครับ สัมผัสทั้งฝั่ง Business และ Tech แต่ก็ไม่รู้เพราะอะไร ยังไม่มีโอกาสได้อ่านเล่มนี้สักที ทั้งที่เก็บหนังสือชั้นครูอย่าง Zero To One — Peter Thiel หรือหนังสือ How nerds rule the world อย่าง How Google Works — Eric Schmidt, Jonathan Rosenberg เรียบร้อยไปนานแล้ว

สำหรับเล่มนี้ ความรู้สึกหลังอ่านจบหน่ะเหรอ? … ตามนี้

“Every founding team should stop for forty-eight hours and read The Lean Startup. Seriously, stop and read this book now.” — Scott Case, CEO, Startup America Partnership

ที่เคยเข้าใจมา ที่เคยทำมา มันไม่ถูกต้องซะทีเดียวเลยนี่หว่า

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

Build-Measure-Learn คืออะไรกันแน่ มันไม่ใช่แค่ Just do it

moregameslike.com/imvu/

ย้อนกลับไปปี 2004 Eric Ries ผู้เขียนหนังสือเล่มนี้ได้ก่อนตั้ง Startups ชื่อ IMVU เล่าง่ายๆคือเป็นโปรดักซ์ให้คนสามารถสร้าง Avatar หรือตัวละครของตัวเองในโลกเสมือนได้ เพื่อมาติดต่อปฏิสัมพันธ์กับผู้อื่น ทางบริษัทก็เตรียมแผนการสู่ตลาดอย่างชาญฉลาดโดยใช้ช่องทาง Instant Message App (พวก MSN ICQ สมัยก่อนครับ) โดยมองว่าถ้าสร้างเป็น IM App ใหม่ การจะให้ผู้ใช้มาสมัคร App ใหม่ไปเลยแล้วเริ่มเล่นเนี่ย มี Switching Cost ที่สูง ว่าง่ายๆ ถ้าเพื่อนผมใช้ MSN กันอยู่ ผมจะอยู่ๆย้ายมาใช้ AOL Messenger นี่ ต้องไปวิงวอนแกมบังคับไอ้เพื่อนๆให้มาเล่นกับผมให้หมด ไม่งั้นได้ Online เดี่ยวๆ หัวเดียวกระเทียมลีบแน่ๆ

ทางออกคือการทำเจ้า Product เราเป็น Plugins ให้กับ IM ที่มีอยู่แล้ว

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

ฟังดู Sound good พอเพื่อนมาเห็นเราใช้ Avatar เพื่อนก็ยิ่งอยากใช้ตาม น่าจะทำให้ Product กระจายตัวไปอย่าง ไวรัล สบายๆ (Network Effect) ดูเป็นแผนการที่จะ Work พอตัวอยู่เลยนะ หลังจากวางแผนกันเสร็จ ทีมงานก็ใช้เวลา 6 เดือนรวด รีบเข็น Version แรกออกมาให้เสร็จ แม้กระนั้นก็ยังมีข้อจำกัดของตัวแอพมากมาย พร้อม Bug อีกมหาศาลถึงขั้นต้องคิดว่า Bug ตัวไหนรุนแรง ตัวไหนปล่อยไปก่อน เจ้าตัว Eric Ries ถึงกับมีความกังวลในแง่ว่าจะต้องเอา Product ที่ยังไม่เสร็จนี่ไปขายผู้ใช้หรอเนี่ย

ถึงเวลาปล่อย App สู่ตลาด

บริษัทได้ทำการปล่อย App ออกสู่ตลาด พร้อมทั้งพัฒนา App ไปต่อเรื่อยๆ เพิ่ม Feature แก้ Bug บ้าง รายได้สามเดือนแรกทั้งหมด $300- $350-$400 ตามลำดับ คือเรียกได้ว่าน้อยมากๆ เอาไปกินข้าวแกงหน้าเซเว่นคนเดียวยังใช้ไม่พอเลย ส่วนเรื่องคนจะร้องเรียนเรื่อง Bug ไม่ต้องซีเรียสครับ มันแทบไม่มีคนใช้ แม้จะพัฒนา Product ให้ดีขึ้นทุกวัน แต่พฤติกรรมผู้บริโภคก็เหมือนเดิม คือ ไม่ใช้!

ตรวจดูสิเกิดอะไรขึ้น

สังเกตว่าแผนการข้างบนที่คิดมานั้น ตั้งอยู่บนสมมติฐานดังนี้

1. ลูกค้าไม่ต้องการที่จะเล่น IM เพิ่มอีกแล้ว เพราะต้องเรียนรู้ IM ใหม่ และ ยุ่งยากที่จะชวนเพื่อนมาเล่นด้วย อยากใช้กับ IM ที่เล่นอยู่แล้ว
2. ลูกค้าอยากใช้ Avatar เล่นกับเพื่อนที่คุยกันอยู่แล้ว

ฟังดูก็ Make Sense อยู่นะ จนกระทั่ง บริษัทเริ่มเรียกคนใช้มาสัมภาษณ์ดู ตอนผมอ่านถึงตรงนี้ก็จินตนาการว่า Eric Ries น่าจะนั่งสัมภาษณ์โดยผู้โชคร้ายคนแรกเป็นเด็กสาวอายุ 17 ขอเอามาเล่าใหม่เปลี่ยนตัวละคร

โปรแกรมเมอร์เจ้าปัญหา: โอเครครับ มาลองใช้ Product กัน มันเรียกว่า IMVU
สาวน้อยผู้โชคร้าย: โอเคร ให้เริ่มยังไงคะ

หลังจาก โปรแกรมเมอร์เจ้าปัญหา ให้เธอเริ่มลองสร้าง Avatar และลองปรับแต่งตามต้องการ

unilad.co.uk

สาวน้อยผู้โชคร้าย: ว้าว นี่มันสนุกมากเลย ทำเสร็จแล้วยังไงต่ออ่ะ
โปรแกรมเมอร์เจ้าปัญหา: ถึงเวลาที่จะดาวน์โหลด Instant Messaging Add-on แล้ว
สาวน้อยผู้โชคร้าย: What the heck มันคืออีหยั๋ง หนูไม่เคยได้ยิน เพื่อนก็ไม่น่าจะรู้จัก ต้องทำไงนะ
โปรแกรมเมอร์เจ้าปัญหา: ใจร่มๆ อีหนูมันคือโปรแกรมไว้ลง เพื่อให้ใช้ได้กับ IM ที่ใช้อยู่แล้ว… (อธิบายไปเรื่อยๆ)

ถัดมาเล่นไปสักพัก โปรแกรมเมอร์เจ้าปัญหา ก็เริ่มให้ลองกด Invite เพื่อนเข้ามาร่วมแชท

สาวน้อยผู้โชคร้าย: เดี๋ยวๆ ไม่มีทาง หนูยังไม่รู้ว่ามัน Cool หรือเปล่าเลย Babe ถ้ามามันกาก พวกเพื่อนจะคิดว่าหนูกากหน่ะสิ ไม่เอา!

โปรแกรมเมอร์เจ้าปัญหา เริ่มฉุน บอกเฮ้ย เอ็ง แค่คนเดียวจะมาสรุปทั้งหมดว่ามันแย่ได้ไง พี่แกก็เลยไปชวนคนมาอีกหลายๆคน ลองทำแม้กระทั่งมีโหมด Single-Player ดู Avatar คนเดียวก่อน แต่สุดท้ายพอจะ Multiplayer ชวนเพื่อนเล่นก็ไม่มีใครทำอยู่ดี

หลังจากนั้น IMVU ก็เริ่มพัฒนา Product สร้าง Feature ใหม่ชื่อ “ChatNow” ไว้สุ่มคนมาคุยด้วย ตอน Test ก็เริ่มจะดูดี

สาวน้อยผู้โชคร้าย คนที่ 2 หลังจากสุ่มเจอหนุ่มหน้าตาดีมาคนนึง: เฮ้ คนนี้ดูเรียบร้อยดีนะ คุยถูกคอ ขอ Add ลง Buddy List ดีกว่า เอ…. ไหนหล่ะ Buddy List
โปรแกรมเมอร์เจ้าปัญหา: ไม่มีหน่ะสิ มันสามารถ Add ลง List MSN เธอได้เลย เจ๋งใช่ไหมล่าา
สาวน้อยผู้โชคร้าย คนที่ 2: จะบ้าหรอ จะให้ Add คนแปลกหน้าลง List MSN ของหนูเนี่ยนะ ฝันไปเถอะ!!…
โปรแกรมเมอร์เจ้าปัญหา: ไม่ดีหรอ ไม่งั้นเธอต้องมี IM ตัวใหม่มาเล่นอีกนะ
สาวน้อยผู้โชคร้าย คนที่ 2: นี่ลุง รู้เปล่าหนูมี IM กี่ตัวตอนนี้
โปรแกรมเมอร์เจ้าปัญหา: ไม่รู้อ่ะ 2… 3 ตัวมั้ง
สาวน้อยผู้โชคร้าย คนที่ 2: โน 8 ว้อย!

มาถึงตรงนี้สังเกตได้ว่าสมมติฐานที่ดูจะ Make Sense ทั้งสองอันมันผิดหมดเลย ลูกค้าอยากได้ IM ตัวใหม่ไปเลย Barrier เรื่องย้าย IM ไม่ได้มีผลมากนักและการเอาเพื่อนไปด้วยก็ดูจะไม่เป็นเรื่องใหญ่ เพราะลูกค้าต้องการไปสร้าง Network ใหม่ ในที่ใหม่อยู่แล้ว Avatar ก็ไม่ได้อยากใช้กับ IM เดิม

ตรงนี้หมายความว่าไง หมายความว่า 6 เดือนที่ผ่านมาทำ Product กันโดยมีสมมติฐานที่ผิดหมดเลย ถ้ารู้อย่างงี้ตั้งแต่เดือนแรก อาจไม่ทำ Plugins เลย เอาเวลาไปมุ่งเน้นทำ IM Standalone ตัวใหม่เลยก็ได้ และนี่แหล่ะครับ ผมคิดว่าเป็นหนึ่งในจุดเริ่มต้นที่ Eric Ries อยากที่จะเขียนหนังสือเล่มนี้ขึ้นมา… เราจะมีทางไหมที่ลดการเสียโอกาสเหล่านี้ได้… เราจะมีทางไหมที่ทำให้ Effort คนในโลกเสียเปล่าน้อยลง… ไม่ไปทำอะไรที่แม้จะเจ๋ง แม้จะคูล แต่สุดท้ายไม่มีใครใช้อยู่ดี

สมัยก่อนการจะทำ Product ต้องวางแผน มี Market Research ซึ่งในปัจจุบันดูจะเป็นหนทางที่พลังน้อยลงไปทุกที หนังสือเล่มนี้ให้เหตุผลว่า User จริงๆ ไม่ได้รู้หรอกว่าเขาต้องการอะไร เราต้องวัดผ่านการให้ลองใช้แล้วสังเกตพฤติกรรมดูต่างหาก ในหนังสือยังกล่าวอีกว่าบางทีขนาด Industry Best-practice ยังไม่ Work เลยยังมี

อีกประเด็นที่อยากจะหยิบยกมาพูด บางคน แม้แต่ ตัวผมเอง เข้าใจว่า Lean Way คือการทำๆไปก่อนลองไปก่อน (Just do it แบบ Nike) แต่ที่จริงแล้ว ถ้าการทำๆไปก่อนนั้น ไม่ได้ช่วยให้ตอบคำถาม สมมติฐานบางอย่างที่ตั้งไว้ในแผน หรือ ไม่ได้มีสมมติฐานตั้งแต่ต้นเลย มันก็ไม่ช่วยให้เรารู้ว่าควรแก้ไขหรือปรับปรุง Product เราต่อไปอยู่ดี ดังนั้นส่วนตัวคิดว่าควรวางแผนทั้ง สมมติฐาน Product เวอร์ชั่นตัวเล็กๆ(MVP นั่นเอง) รวมไปถึงการวัดผลให้เรียบร้อยก่อน

MVP ไม่จำเป็นต้องเป็น App ไม่จำเป็นต้องเป็น Website ไม่จำเป็นต้องเกี่ยวกับ Tech ด้วยซ้ำ

hackernoon.com

ในการ Test สมมติฐานตาม Build Measure Learn เนี่ยเราอาจจะทำ Product Version เล็ก Version บาง แล้วแต่จะเรียก แบบใช้ได้คร่าวๆไปก่อน แต่ทั้งนี้ Feature หลักสำคัญที่เราต้องการต้องอยู่ครบเพื่อ Test สมมติฐานและควรที่จะเป็นสมมติฐานที่ Risky ที่สุด ที่ถ้าไม่ผ่านแล้ว อันอื่นไม่ต้องทำเลย เหมือนในรูปที่หยิบยกขึ้นมาถ้าสมมติฐานคือคนอยากเดินทางด้วยพาหนะ สิ่งที่ทำคือเริ่มสร้างสเก็ตบอร์ดขึ้นมาแล้วต่อยอดมันไป ไม่ใช่แค่สร้างล้ออย่างเดียวที่ทำอะไรไม่ได้

อย่างไรก็ตามคนชอบติดภาพ App / Website ซึ่งเป็นสิ่งที่ไม่ถูกต้องซะทีเดียว บาง Product สามารถ Test กันก่อนได้เลยผ่านช่องทางบ้านๆนี่หล่ะ ตัวอย่างเช่น

• Dropbox MVP คือ Video ที่อธิบายว่ามันคืออะไร เจ้าของพากย์เองนั่นหล่ะ
• Food on the Table บริษัทจาก Austin — Texas Product คือสร้างรายการอาหารประจำสัปดาห์และ List วัตถุดิบจากอาหารที่คุณหรือครอบครัวต้องการ จากนั้นนำ List นี้ไปหา Best Deals ที่ดีที่สุดจากร้านค้าในละแวก เริ่ม Test MVP โดย CEO กับ VP of Product เนี่ย นั่งโทรไปหาลูกค้า แล้วไปเยี่ยมบ้านลูกค้าเองถึงบ้าน สัมภาษณ์ถามว่า ต้องการกินอะไรบ้าง จากนั้นพี่แกก็ไปซื้อของ มาส่งให้ลูกค้าเองเลย

จะเห็นได้ว่าไม่มี Code สักบรรทัดอยู่ใน MVP เลยครับ

การวัดผล เรื่องที่เหมือนจะง่าย แต่ไม่ง่าย

projectbi.net

พอเราทำ MVP ของเราเสร็จ การจะวัดผลเป็นเรื่องละเอียดอ่อน ในบริษัทอาจจะอยู่ในภาวะดังนี้

1. มีทีม Business Intelligence หรือ Data Warehouse ที่พร้อมจะดึงข้อมูลทุกอย่างมาแสดงและประมวลผล
2. มี MVP หลาย Product กำลังลอง Test กับลูกค้า

ปลายสัปดาห์หลังจากปล่อย Product ให้ลูกค้า ทุกคนที่เกี่ยวข้องไปจนถึง CEO เข้ามาประชุมในห้องแล้วทีม BI ก็เปิดข้อมูลแสดงจำนวน User สมัครใหม่ จำนวน User ที่จ่ายเงิน จำนวนเวลาที่ User อยู่ใน Site ของเรา ถ้าคุณโชคดีตัวเลขมันอาจจะดูดีทั้งหมด แต่โชคร้ายก็อาจคงที่หรือแย่ลง แล้วไงต่อหล่ะ… เราจะรู้ได้ไงว่า Product ตัวนี้ก่อให้เกิดผลอย่างไรต่อตัวเลขที่พูดมาข้างตน มันอาจจะช่วยเพิ่มยอด User ก็ได้นะ ขณะที่อีกตัวทำให้ User Signup ได้มากขึ้น คุณในฐานะ Product Manager ก็รอเสียบว่าตรงไหน พอพูดอวยๆมา Product ตัวเองได้ก็ซัดเลย

ปัญหาคือ มันไม่ได้ตอบโจทย์ในการพิสูจน์สมมติฐานอะไรของเราเลย

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

ในเล่มนี้ Eric ได้แนะนำการวัดเบื้องต้นสองแบบง่ายๆคือ

1. A/B Testing แบ่งกลุ่มลูกค้าออกเป็นสองกลุ่ม (ให้เยอะพอที่จะ Assume ว่าสองกลุ่มนี้ Identical) กลุ่มแรกให้ลองไปเจอ Product ใหม่ / Landing Page ใหม่ ส่วนกลุ่มที่สองเจออย่างเดิม แล้ววัดผลที่เกิดขึ้นระหว่างทั้งสองกลุ่มนี้
2. Cohort Analysis แบ่งกลุ่มลูกค้าตามช่วงเวลาต่างๆ คิดง่ายๆ อาจแบ่งตาม Version การ Release ของ App เช่นกลุ่มแรกใช้ App Version 1.0 มี Conversion เท่านี้ เทียบกับ กลุ่มที่สองคือกลุ่มที่ใช้ App Version 2.0 มี Conversion อย่างไร ซึ่งจะเห็นพัฒนาการ Conversion ใน Release ต่างๆ

การเอาลูกค้าเข้ามาลองใช้ Product ในปัจจุบันก็ง่ายดาย เดี๋ยวนี้มี Adwords ลองยิงวันละ 100 คนเข้ามาลองใช้ก็ได้ใช่ไหมครับ

Adopting Lean Startup in the Enterprise — Slide by David Bland

อีกประเด็นที่หนังสือพูดถึงดูจะเป็นการ Control ด้าน Management นิดหน่อยคือการใช้ Concept Kanban Board โดยงานต่างๆแต่ละช่วงจะอยู่ในแต่ละช่องและบังคับว่าแต่ละช่องห้ามมีเกิน 3 (เปลี่ยนแปลงได้ตามบริษัท) ลองคิดภาพตามงี้ครับ

1. Business คิด Product Feature ขึ้นมาหนึ่งตัว วางไว้ใน Todo
2. พอ Tech Team ว่างทำก็หยิบมาไว้ที่ In Progress
3. ทำเสร็จ Tech Team จะลากไปไว้ที่ Done เพื่อรอให้ทีม BI ไปตรวจสอบวัดผล Feature ให้เรียบร้อย
4. เมื่อ BI เริ่มวัดผลก็ลากไปไว้ที่ Validate ว่า Feature นี้สมควรได้ไปต่อ ยกเลิก หรือ Pivot(ปรับปรุงขนานใหญ่)

ถ้ายัง Validate ไม่เสร็จ ยังช่องเต็ม 3 อัน ก็จะทำให้ไม่สามารถลากงานจาก Done ไป Validate ได้ ทั้ง Process ต้องช้าลง เพื่อตรวจสอบให้เสร็จสิ้นก่อน

ทำอย่างนี้ ดูจะเป็นทางให้เกิด Build-Measure-Learn ที่ดีครับ แต่สำหรับผมอาจต้องว่ากันเรื่องการประยุกต์ใช้ตามความเร็ว และ ขนาดของบริษัทอีกทีหนึ่ง

Pivot ถอยหลังเพื่อไปต่อข้างหน้าให้ไกลกว่าเดิม

medium.com/@Chargify

เมื่อมาถึงจุดนึงหลังเรา Validate เรียบร้อย ถ้าพบว่าสมมติฐานสำคัญของเราไม่ถูกต้อง Customer ไม่ตอบรับกับ Product เราเท่าที่ควร มีสองทางที่จะเลือกคือ

1. Persevere ยืนยัน Product ตัวเดิม แต่ Optimize และเพิ่ม Feature ต่างๆให้ดียิ่งขึ้น
2. Pivot ปรับปรุง Product ครั้งใหญ่ ลองกันใหม่ เปลี่ยนสมมติฐานแล้วตรวจสอบใหม่

ซึ่งมันมักจะเป็นการตัดสินใจที่ยากเสมอ บางทีมเมื่อต้องเลือกทางเลือกที่ 2 ก็อาจจะเกิดปัญหาด้านกำลังใจ เหมือนต้องล้ม Product ที่ทำมาทั้งหมดทิ้งเกือบหมด หรือ บางทีก็ไม่กล้าตัดสินใจที่จะเลือกทางนี้เพราะยังยึดติดกับ Metrics บางอย่างที่ไม่ได้สะท้อนปัญหาที่เกิดขึ้นจริงๆ (ในหนังสือเรียกว่า Vanity Metrics) เช่น บริษัทต้องการคนใช้ที่จ่ายเงินเข้ามาจริงๆ แต่สุดท้ายไป Focus กับจำนวนลูกค้าที่ Signup เข้ามาจนยังไม่กล้าตัดสินใจเปลี่ยนแปลง Product ใดๆไป

ในการ Pivot นั้นในหนังสือก็มีแบ่งทางเลือกย่อยลงไปอีก ยกตัวอย่างมาดังนี้

1. Zoom in — เลือกมา 1 Feature ที่ User ชอบแล้วลองพัฒนา Feature นั้นให้ดีไปเลย
2. Zoom out — Product ทั้งหมดที่ทำมาเป็นแค่ 1 Feature ใน Product ใหม่ที่กำลังจะสร้าง
3. Customer segment — Product ของเราตอบโจทย์ Pain Point User นะแต่ผิดกลุ่ม ไม่ใช่กลุ่มที่เรามีสมมติฐานไว้แต่แรก
4. Customer need — Product ที่ทำอาจไม่ได้ตอบโจทย์ Pain Point ของ User หรือ มันสำคัญพอ
5. Platform — เปลี่ยน Product เราเป็น Platform ให้ Third-Parties เข้ามาใช้งานแทน
6. Business Architect- เปลี่ยน Product ในเชิง Architect เช่นปกติ Product เป็น Product Specialise ทำขายบริษัทใหญ่ๆ (เน้น High Margin, Low Volume) เปลี่ยนมาเป็น Product Consumer (เน้น Low Margin, High Volume)
7. Value Capture- เปลี่ยนวิธีเก็บเงินเช่นจาก Subscription มาเป็นจ่ายรายครั้งที่ใช้
8. Engine growth pivot- เปลี่ยนรูปแบบการเติบโตของบริษัทอันนี้จะขยายความในบทความต่อไปครับ
9. Channel pivot- เปลี่ยนหนทางการกระจายสินค้าเช่น Salesman เปลี่ยนไปทาง Internet
10. Tech pivot- เปลี่ยนเทคโนโลยีหลังบ้าน เพื่อให้รองรับการใช้งานที่มากขึ้น หรือ Optimize ด้านความเร็ว มักเกิดในบริษัทที่ Establish แล้วระดับนึง

Case Study ใหญ่ที่อยากจะหยิบยกมาคือบริษัท Wealthfront ซึ่งปัจจุบันเป็นบริษัท FinTech ชั้นนำของโลกประกอบธุรกิจดูแลเงินลงทุนผ่านกองทุนรวมโดยผู้บริหารกองทุนมืออาชีพ

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

ในจังหวะที่เปิดตัว kaChing มีผู้เล่นเข้าใช้งานกว่า 450,000 คน ด้วย Platform การแข่งขันสุดเจ๋งและการวัดผลผู้เล่นที่เหนือชั้น อย่างไรก็ตามเมื่อถึงจังหวะที่ kaChing จะเปิดตัว Product ที่เริ่มให้ลูกค้าเข้ามาจ่ายเงิน มีเพียงผู้เล่น 7 คนเท่านั้นที่ Qualified ผ่าน และไม่ต้องสงสัย Conversion rate ของคนที่จ่ายเงินแทบจะเข้าใกล้ 0

ทีมงานพยายามที่จะปรับเปลี่ยน Product พัฒนารูปแบบต่างๆ แต่ดูไม่มีสิ่งไหนที่จะช่วยสถานการณ์ของบริษัทได้เลย สุดท้ายจึงเลือกจะ Pivot ล้มเลิก Platform เกมส์ทั้งหมด(ซึ่งเป็นการตัดสินใจที่ Drama มาก) เปลี่ยนชื่อทั้งหมด แต่อย่างไรก็ตาม The most valuable work ของบริษัทที่สร้างเครื่องมือในการวัดผลความสามารถของผู้จัดการกองทุนยังได้ใช้อยู่ ซึ่งเป็นเหมือน Kernel สำหรับธุรกิจใหม่ที่กำลังจะสร้างต่อจากนี้ ปัจจุบัน (2010 ณ เวลาที่หนังสือเขียน) บริษัทเปลี่ยนธุรกิจเป็นการให้คนทั่วไปสามารถนำเงินเข้ามาลงทุนกับผู้จัดการกองทุนมืออาชีพได้ ผลที่ตามมาคือเงินกว่า 180 ล้านเหรียญ ณ เวลานั้น ได้รับการดูแลจากผู้จัดการกองทุนมืออาชีพกว่า 40 คน

Type of Engine Growth ดูให้รู้ว่าบริษัทเราโตอย่างไร

Growth Tribe: Alistair Croll startup workshop Lean Analytics & Growth Hacking

ย้อนกลับมาเรื่องการวัดอีกนิดนึง ในเมื่อบริษัทแต่ละบริษัทมี Business Model และ Product ที่แตกต่างกัน ทำอย่างไรเราถึงจะสร้าง Metrics ที่วัดการเติบโตของบริษัทที่สมเหตุสมผลได้ ในที่นี้จะยกตัวอย่าง Engine of Growth ของบริษัทตามแต่ละประเภทดังนี้

Sticky Model

เหมาะสำหรับบริษัทที่มี Product ที่เน้นความ Sticky ติดหนึบกับผู้ใช้ ตัวอย่างเห็นได้ชัดก็พวกธุรกิจประเภทที่มี Subscription เช่น Spotify, Netflix เป็นต้น การที่ลูกค้าจะมีการยกเลิกไม่ใช้ย่อมเกิดจากสองสาเหตุหลักๆคือ 1) ไม่พอใจกับตัวสินค้าอย่างรุนแรง 2) ย้ายไปใช้บริการจากคู่แข่ง

ดังนั้นเราสามารถวัดการเติบโตง่ายๆ โดยเอา อัตราการเติบโตของลูกค้าใหม่ ลบด้วยอัตราการยกเลิกใช้ของลูกค้า (Churn rate)

สิ่งที่บริษัทประเภทนี้ควรทำคือทำยังไงก็ได้ให้ลูกค้ากลับมาใช้สินค้าเรื่อยๆ และมีความพึงพอใจไม่ย้ายไปใช้สินค้าของคู่แข่ง (ลด Churn Rate)

Viral Model

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

การวัดสามารถใช้ Concept “Viral Coefficient” วัดความเร็วในการกระจายตัวของ User สมมติง่ายๆ
ถ้าค่าเฉลี่ยลูกค้าหนึ่งคน จะ Refer เพื่อนต่ออีกคน Coefficient ตัวนี้ก็จะมีค่า 1
ถ้าลูกค้าหนึ่งคน Refer ต่อ 3 Coefficient ก็จะเท่ากับ 3 เป็นต้น

บริษัทก็ควรจะทำอย่างไรก็ได้เพื่อทำให้ User Refer Friend มากขึ้นและลด Friction ในการ Refer หรือ Signup ให้หมดเป็นต้น

Paid Engine Model

สำหรับธุรกิจที่จำเป็นต้องจ่ายเงินซื้อโฆษณา หรือ Support User ให้มาลองใช้ Product ก่อน

การวัดสามารถใช้สัดส่วนระหว่างมูลค่าที่ User จะสามารถ Generate ให้แก่บริษัทได้ กับ ค่าใช้จ่ายที่ต้องจ่ายออกไปเพื่อให้ได้ User คนนั้นเข้ามาใช้

Customer Lifetime Value(CLV) / Acquisition Cost

คุณอาจจะทำ Dashboard โชว์ Metrics ทั้งหมดทั้งสามแบบเลยก็ได้ แต่เชื่อเถอะ ลองดูดีๆ Product หนึ่งอันมันจะมี Engine ในการเติบโตไม่เกิน 1–2 Metrics หลักแน่นอน

การที่ทีมแต่ละทีม Archive Target ที่ตั้งไว้ อาจไม่ได้เกี่ยวข้องกับ Company Progress

ข้อหนึ่งสำคัญในด้าน Culture ของบริษัทคือการระวังให้ไม่เกิดเหตุการณ์ไซโลขึ้นระหว่างแผนก ยกตัวอย่าง Team Engineer มุ่งเน้นแต่เรื่อง Product Quality — Code ไม่มี Bug, Architech สวยหรูเป็นใช้ได้ ปล่อยให้เรื่องว่า Product ออกมา จะมีคนใช้ไหม มีคนชอบไหมเป็นเรื่องของทีม Business ไป ถ้าเกิดเหตุการณ์นี้ขึ้นแปลว่าแต่ละทีมมุ่งเน้นแต่เป้า Archive ของตัวเองและไม่ได้มุ่งเน้น Company Progress หรือเรียกว่าไม่ได้ “อิน” กับ Product อย่างจริงจัง ตรงนี้ต้องหาทางแก้ไม่ว่าจะเป็นการให้ทีมไปพบปะลูกค้ามากขึ้น ให้มีส่วนร่วมตั้งแต่ช่วงกำหนด Requirement

Entrepreneur is a job title

ในแต่ละช่วงของ Product มักมีความต้องการทีมหรือคนที่มีความสามารถแตกต่างกันออกไป บางคนเป็น Natural Inventors อาจชอบที่จะทำงานโดยไม่มีแรงกดดันและความคาดหวังใน Phrase ที่ Product เริ่มมีผู้ใช้งานเยอะๆ บางคนเก่งที่จะสานต่องาน Product ที่ Establish ดีแล้ว ทำการ Outsource และ Optimize มันได้อย่างดี

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

ก็ประมาณนี้ครับ สำหรับประเด็นที่ผมอยากหยิบยกขึ้นมาเล่าสู่กันฟัง หลายๆเรื่องเป็นเรื่องที่เราต้องรู้จัก Unlearn และ Relearn ใหม่ ให้เข้ากับสถานการณ์ต่างๆ ยังมีอีกหลายแง่คิด หลายประเด็นที่ผมไม่ได้พูดถึง ฉะนั้นอยากให้ทุกคนที่สนใจด้านนี้ ลองหามาอ่านกันดูครับ แล้วคุณอาจเปลี่ยนแปลง Startups บริษัทของคุณหรือแนวคิดของคุณไปเลย

TiMeFF — timeff.io