สิ่งที่ได้เรียนรู้จากการทำ SaaS คนเดียวมา 1 ปี
(onlineornot.com)- ประสบการณ์สร้างและเปิดตัว OnlineOrNot เครื่องมือตรวจสอบ uptime ด้วย Next.js + AWS Lambda ภายใน 7 วัน และดูแลให้บริการต่อเนื่องตลอด 1 ปี
เคล็ดลับในการรักษาบริการไว้ได้ แม้จะมีคู่แข่งมากถึง 200 รายคืออะไร?
- ทำงานแค่วันละ 2 ชั่วโมงในวันธรรมดา
- โฟกัสที่ฟีเจอร์ซึ่งช่วยแก้ปัญหาความเจ็บปวดของลูกค้า
- ทำซ้ำอย่างเข้มงวด (ruthlessly) ถ้าทำฟีเจอร์ให้เสร็จใน 2 ชั่วโมงไม่ได้ ก็ลดขอบเขตลงแล้วปล่อยขึ้นระบบ จากนั้นทำแบบนี้ซ้ำไปเรื่อย ๆ
✓ บทเรียนที่ได้ตลอด 1 ปี
สิ่งที่ขายไม่ใช่ SaaS subscription แต่คือการแก้ปัญหา
- คิดจากมุมของลูกค้า
- ไม่ใช่ "ถ้าสร้างฟีเจอร์นี้ ลูกค้าจะเข้ามาเอง!" แต่ต้องเป็น "เราต้องช่วยแก้ปัญหาน่าหงุดหงิดนี้ของลูกค้า"
- SaaS เป็นเพียงหนึ่งในหลายวิธีในการแก้ปัญหา
เอกสารเป็นส่วนหนึ่งของประสบการณ์ผู้ใช้
- หลายคนพูดว่า "นักพัฒนาไม่อ่านเอกสาร" ซึ่งถูกแค่บางส่วน
- พวกเขาไม่อ่านละเอียด แต่จะ ไล่ดูหัวข้อ
สร้างโดยคำนึงถึงมือถือ
- ตรงข้ามกับความเชื่อทั่วไปเกี่ยวกับ B2B SaaS ผู้คนทำงานผ่านโทรศัพท์กันมาก
- ผู้ใช้ของ OnlineOrNot ประมาณ 50% มาจากมือถือ
- พวกเขามักจะสร้างบัญชีและเพิ่มหน้าที่ต้องการมอนิเตอร์อย่างรวดเร็วบนมือถือ แล้วค่อยกลับมาเช็กเป็นครั้งคราวบนโน้ตบุ๊ก/เดสก์ท็อป
- ช่วง 6 เดือนแรกยังไม่รองรับมือถือ ทำให้คนที่สมัครผ่านโทรศัพท์เลิกใช้อย่างรวดเร็ว
- สุดท้ายพอทำหน้าแบบ responsive สำหรับมือถือ ตอนนี้ผู้ใช้มือถือใหม่ก็เพิ่มขึ้นต่อเนื่อง
ถามผู้คนว่าพวกเขารู้จักคุณได้อย่างไร
- หนึ่งในการเปลี่ยนโค้ดที่มีค่ามากที่สุดคือการถามผู้ใช้ที่สมัครว่า "คุณรู้จัก OnlineOrNot ได้อย่างไร?"
- ช่องทางในการดึงดูดลูกค้าที่มีศักยภาพมีหลายแบบ และต้องรู้ว่าควรเน้นช่องทางไหน
บางครั้งก็จำเป็นต้องพลาดด้วยตัวเอง
- แม้จะอ่านหนังสือเยอะเพื่อไม่ให้ทำผิดซ้ำแบบคนอื่น แต่บางครั้งก็ต้องพลาดเอง
- ตอนขึ้นหน้าแรกของ Hacker News มีคนเข้ามา 6000 คน มีคนพยายามสมัครหลายร้อยคน แต่สมัครสำเร็จไม่ถึง 10 คน ทำให้รู้ว่ามีอะไรผิดปกติ
- ฟอร์มสมัครมีอัตราหลุด 75% พอทำ A/B testing (โดยใช้ DeployWithFlags ที่ฉันสร้างเอง) แล้วเพิ่ม OAuth provider เพิ่มเติม ก็ลดลงมาเหลือ 50%
การตั้งราคายากมากจริง ๆ
- ถ้าตั้งราคาสูงเกินไป คนจะคาดหวังว่าแอปของคุณต้องทำได้ทุกอย่างแล้วก็ผิดหวังจากไป
- ถ้าตั้งราคาต่ำเกินไป ก็จะมีลูกค้าที่จ่าย $9 แล้วอยากให้คุณเขียนแอปใหม่ทั้งตัว
- ลูกค้าที่ยากเกินไปก็คืนเงินให้ ขึ้นราคา แล้วเดินหน้าต่อ
- เตรียมตัวไว้ให้พร้อมสำหรับการทดลองเรื่องราคาอีกมาก
ไม่จำเป็นต้องโฟกัสกับ MRR (Monthly Recurring Revenue) มากเกินไป..
- MRR เป็นวิธีที่แย่มากในการวัดว่าธุรกิจกำลังไปทางไหนในช่วงเริ่มต้น
- สิ่งที่แก้ไปเมื่อหลายสัปดาห์ก่อนจะมาส่งผลกับ MRR ตอนนี้ ดังนั้นก่อนจะมีลูกค้าจำนวนมาก ก็ยากจะรู้ว่าการเปลี่ยนแปลงนั้นได้ผลจริงไหม
- DAU หรือบางตัวชี้วัดความสำเร็จของลูกค้า (เช่น การตรวจหน้าเว็บ การสร้างภาพ ฯลฯ) มีประโยชน์กว่า MRR
- ตัวเลขเหล่านี้ช่วยบอกได้ว่าผู้ใช้จริงกำลังใช้ผลิตภัณฑ์หรือไม่ และมันสร้างคุณค่าให้พวกเขาหรือเปล่า
แม้แต่ paid tier ก็ยังต้องมี free trial
- free tier เป็นวิธีที่ดีในการดึงคนเข้ามาและทำให้คนพูดถึงผลิตภัณฑ์ของคุณ
- แต่ถ้า paid tier ดีกว่า free tier มาก ก็ต้องมีวิธีให้คนได้ลอง "ของดี (Good Stuff)" ที่อยู่ในแพ็กเกจจ่ายเงิน
- กว่าจะเข้าใจเรื่องนี้ก็ใช้เวลา 11 เดือน
- แม้จะมี free tier แต่ผู้ใช้ใหม่ 95% เลือกทดลองใช้ฟรีของโปร tier
การเอา traffic เข้ามาเพิ่มเป็นเรื่องยาก แต่การเปลี่ยนสิ่งที่คนทำเมื่อเข้ามาแล้วง่ายกว่า
- การได้รับความสนใจบนอินเทอร์เน็ตเป็นเกมที่ยาวและช้า
- ถ้าทำ content marketing คุณภาพดีอย่างสม่ำเสมอหลายเดือน จำนวนผู้อ่านจะเพิ่มจากวันละ 1–2 คนเป็นหลายร้อยคน
- การเพิ่มจำนวนคนเข้าเว็บไซต์ไม่ใช่เรื่องง่ายเลย
- แต่สิ่งที่ผู้คนทำเมื่อเข้ามาในเว็บไซต์แล้ว เป็นสิ่งที่คุณมีอิทธิพลได้และเริ่มทำได้ตั้งแต่วันนี้
(เช่น การเพิ่ม OAuth login provider)
Content marketing ช่วยซื้อเวลาให้คุณ
- การลงทุนกับ content marketing ทำให้ธุรกิจเดินต่อเองได้อยู่ช่วงหนึ่ง
- ตลอดหนึ่งปี มีบทความเก่าหลายชิ้นกลายเป็นไวรัลและดึงผู้เข้าชมได้หลายหมื่นคน ทุกวันนี้ยังมีคนราว 1500 คนเข้ามาแบบ organic เพื่ออ่านบทความเหล่านั้น แม้ฉันจะไม่ได้ทำอะไรเลย
ปล่อยของชิ้นเล็ก แต่ปล่อยบ่อย
- ผู้คนอาจเสนอให้สร้างฟีเจอร์บางอย่างเพื่อปรับปรุงผลิตภัณฑ์ แต่พวกเขาอาจไม่ได้ใช้ฟีเจอร์นั้นจริง
- พวกเขาอาจแค่อยากช่วย และเคยเห็นฟีเจอร์คล้ายกันในผลิตภัณฑ์อื่น
- เพราะนี่เป็นครั้งแรกที่คุณกำลังทำ SaaS คุณจะดีใจที่มีคนมาบอกความคิดเห็น และรีบสร้างฟีเจอร์ให้พวกเขา
- ฉันจะไม่บอกว่าอย่าสร้างฟีเจอร์ (ฉันเองก็เคยได้รับคำแนะนำนั้น และสุดท้ายก็สร้างฟีเจอร์ที่ไม่มีใครใช้ขึ้นมาอยู่ดี)
- ควรถามให้ชัดว่าพวกเขาจะใช้ฟีเจอร์นั้นอย่างไร ถามลูกค้าคนอื่นว่าจัดการปัญหานั้นกันยังไง สร้างเวอร์ชันที่เล็กที่สุดของฟีเจอร์นั้น แล้วดูว่ามีผู้ใช้อื่นใช้มันหรือไม่
คุณคงไม่อยากสร้างฟีเจอร์ที่มีคนใช้แค่คนเดียวใช่ไหม? - การลบฟีเจอร์ที่ไม่มีใครต้องการซึ่งใช้เวลาทำไปแค่ไม่กี่ชั่วโมง เจ็บน้อยกว่าการลบสิ่งที่ทุ่มเวลาหลายเดือนมาก
ปล่อยใช้งานก่อน แล้วค่อยกังวลเรื่องการ scale ทีหลัง
- ในเวอร์ชันแรกของ OnlineOrNot แทบไม่ได้ปรับสถาปัตยกรรมให้เหมาะสมเลย
(แต่ละ uptime check ค้าง DB connection ไว้ ทำให้รองรับผู้ใช้จำนวนมากได้ยาก) - และฉันยังยอมให้คนงงกับ UI ที่ยังไม่สมบูรณ์ ดีกว่าสร้างสิ่งที่ไม่มีใครต้องการ
- ภายหลังจึงค่อยออกแบบสถาปัตยกรรมใหม่ จนใช้ RDS instance ขนาดเล็กเพียงตัวเดียวก็รองรับงานได้หลายล้านครั้งต่อสัปดาห์
เวลาที่ใช้แก้ปัญหาจริง ๆ มีน้อยกว่าที่คิด
- ตลอด 1 ปี เวลาที่ใช้เขียนโปรแกรม มีเพียงครึ่งเดียวที่ใช้ไปกับการแก้ปัญหาที่ฉันอยากแก้จริง ๆ
- อีกครึ่งหนึ่งใช้ไปกับการสร้าง SaaS platform
- งานฝั่งแพลตฟอร์ม SaaS มีทั้งระบบยืนยันตัวตนหลายรูปแบบ, trial, onboarding, การจัดการทีม, การจัดการ invoice, อีเมลตาม lifecycle ฯลฯ
- หลายอย่างสามารถจ้างหรือใช้บริการภายนอกได้ (ถ้าไม่มี Stripe ฉันคงขายแบบ subscription ไม่ได้)
- แต่ก็จะมีบางอย่างที่ไม่ถูกใจเสมอ และถ้าคุณอยากจัดการมันให้ต่างออกไป ก็ต้องสร้างเอง
3 ความคิดเห็น
เป็นบทความที่ดีครับ
เป็นเคล็ดลับดี ๆ สำหรับการวางแผนและดูแลบริการที่เปิดใช้งานจริงเลย!!
ถึงจะมีระดับฟรีอยู่แล้ว แต่ ก็ยังจำเป็นต้องมีช่วงทดลองใช้ฟรีสำหรับระดับแบบชำระเงิน รู้สึกว่าส่วนนี้สำคัญมากจริง ๆ ครับ