drbook เป็น product แรกของไอแอมดีอาร์ที่เราตั้งใจทำเป็น commercial ครับ (iamdr.net นั้นงานเพื่อสังคม) เป็น product ที่เราทำกันอยู่สองปี ล้มลุกคลุกคลานมาเยอะ ในที่สุดเราก็ตัดสินใจที่จะปิดตัวลงในอีกไม่กี่วันข้างหน้านี้ ผมเลยอยากแชร์ lessons learned เรื่องนี้ให้หลายๆ คนที่กำลังจะทำ startup ได้ลองอ่านดูนะครับ (เผื่อจะไม่พลาดแบบพวกผม 55)
ผมจะมีคำแนะนำที่เป็นความคิดผมนะครับ ซึ่งในอนาคตมันอาจจะเปลี่ยนก็ได้ เพราะ ณ ปัจจุบันชีวิตผมเองก็ไม่ได้ถึงไหน อ่านดูก็อย่าเชื่อมากนะครับ 555
Highlights
- Vision สำคัญที่สุด ต้องแน่ใจว่าเรากำลังแก้ problem worth solving
- แต่ถึงเริ่มไม่ดี คุยกับ stakeholder เยอะๆ เปิดใจให้กว้าง อย่าหลอกตัวเอง ตบๆ ไอเดียให้เข้ารูปเข้ารอย
- อย่าไปเสียดายที่ทำมาตั้งนาน ถ้าไม่สามารถ pivot หาสิ่งที่เวิร์คได้ก็ทิ้งไปเลยดีกว่า การทำธุรกิจเป็นการลงทุน ถ้าแนวโน้มจะขาดทุนยาวต้อง cut loss ให้เร็ว
- ทีมสำคัญมาก hustler, hipster, hacker ควรมีให้ครบ
จุดเริ่มต้น
ราวต้นปี 2014 ตอนนั้นเราเพิ่งเสร็จจาก iamdr.net มา ประสบการณ์การทำ startup มีน้อย (ผมเองเพิ่ง fail มาจาก startup ส่วนตัวของตัวเองก่อนหน้านี้) แต่อ่านมาเยอะนะ Lean startup, Running lean อะไรอ่านมาหมดแล้ว event ต่างๆ ก็เข้าเยอะ AIS the startup ก็เคยแข่ง เรียกว่าทฤษฎีแน่นก็พอได้ 555 เราเลยอยากลองหา project เล็กๆ ซักอย่างหนึ่ง เป็นปัญหาใกล้ๆ ตัวที่เจอในชีวิตการเป็นหมอ
สุดท้ายก็มาจบที่ไอเดียว่า เวลาที่เราไปตรวจเนี่ย ถ้าไม่ต้องพกหนังสือไปด้วยก็ดีนะ เป็น reference ง่ายๆ เร็วๆ จริงๆ แอพแบบนี้ก็มีมานานแล้วแต่เป็นภาษาอังกฤษ ซึ่งบริบทหลายๆ อย่างมันก็ไม่เข้ากับการรักษาในเมืองไทย เช่น Medscape, Skyscape ฯลฯ แล้วไหนๆ จะทำแล้วก็ทำเป็น platform เลยสิ ให้ใครก็ได้เอาหนังสือตัวเองมา publish
ตอนนั้นในไทยก็มี ookbee อยู่แล้ว แต่เราเข้าไปดูก็เห็นส่วนใหญ่เป็น PDF ซึ่งมันไม่เหมาะจะใช้ในมือถือ ถ้าเราทำให้เป็น reference ที่เปิดง่ายๆ ใช้ง่ายๆ ใส่ฟังก์ชั่นเกี่ยวกับการแพทย์เข้าไปหน่อย พวกคำนวณโดสยา คำนวณนู่นนี่นั่น ให้เป็นสิ่งที่แพทย์ทุกคนต้องมีติดเครื่องไว้ มันก็น่าจะพอมีตลาดนะ อย่างน้อยเราก็น่าจะกินตลาดหมอได้ จ่ายคนละ 500 ซัก 3,000 คนก็กำไรเห็นๆ แล้ว break-even, scale ไป southeast Asia ต่อด้วยไป industry อื่น เป็นเจ้าพ่อแห่ง academic e-book !!
โอเค ได้ไอเดียแล้ว ดูทำไม่ยาก ตลาดมีชัดเจน จัดกันเลย !
2016 Rath’s advice:
- อย่าแก้ปัญหาเล็กๆ มันมักไม่ใช่ problem worth solving ถ้าจะเล่นปัญหาเล็กต้องมั่นใจว่าฐานลูกค้าจะเยอะมากๆ (ผมหมายถึงระดับหลายล้านคน) แพทย์ทั้งประเทศมีอยู่ไม่กี่หมื่น
- ถ้าเราจะแก้ปัญหาเล็ก มันจะยากในทุกกระบวนการ ตั้งแต่การหาคนร่วมทีม (พอหาไม่ได้ก็ต้องจ้างทำ ใช้ sweat equity ไม่ได้) หาผู้ลงทุน ไปจนถึงการขาย อย่างไอเดีย drbook ที่เรารู้สึกว่ามันเป็น pain ที่หนักพอตัวสำหรับเรานะ พอทำจริงๆ คนส่วนใหญ่ก็ไม่ได้รู้สึกว่ามันเป็นปัญหา
- ถ้าเราจะเล่นตลาดที่เล็ก ต้องมั่นใจว่าคนจำนวนน้อยนั้นยินดีจะจ่ายแพง เก็บเงิน 100,000 จาก 30,000 คนนี่มันก็โอเคนะ แต่สำหรับ startup ทั้งปีเก็บ 200 จาก 3,000 นี่ไม่โอเคครับ จะเก็บ 200 ต้องเก็บจากคนเป็นล้าน ก็กลับมาเรื่องปัญหาตั้งต้นอีก พอปัญหามันเล็ก ก็ไม่มีใครยอมจ่ายแพงครับ
- มีหลายคนอยากทำ product มาขายหมอ ขายคลินิก อันนี้คิดเรื่อง financial projection ให้ดีๆ นะครับ pricing เท่าไหร่ที่ทำให้ธุรกิจอยู่ได้ CAC, CLV เท่าไหร่ ยิ่งสาย B2B ช่วงแรกๆ มันต้องไล่ขายทีละคลินิก วันหนึ่งๆ จะวิ่งขายได้กี่คลินิก จะผ่านช่วงนี้ไปต้องมีงบเท่าไหร่ กี่ปีคืนทุน
สาเหตุของความ fail ของ drbook
ผมแยกสาเหตุความ fail ออกเป็น 3 ประเด็น
- การ validate ไอเดียตั้งต้น
- การขาด technical competency
- การขาด business man
การ validate ไอเดียตั้งต้น
โอเค ถึงแม้ไอเดียตั้งต้นเราจะไม่เวิร์คขนาดไหน กระบวนการ validate ที่ดีจะทำให้ product มัน pivot ไปๆ มาๆ จนมาเข้ารูปเข้ารอยได้ ตามคอนเซปท์พวก Build-measure-learn หรือ fail fast, fail often, fail forward ฯลฯ
อันนี้เป็นปัญหาสำคัญมากของ founder ที่ทำ startup ใหม่ๆ ครับ มักคิดว่า product ของตัวเองกำลังแก้ problem worth solving อยู่ ทั้งๆ ที่จริงๆ มันไม่ใช่ ! ขีดเส้นใต้สามรอบ พวกผมเป็นหมอ มั่นใจแน่ๆ ว่าส่ิงที่แก้เป็นปัญหาที่เราเจอมาจริงๆ เราอยากได้ solution แบบนี้แหละ ความเชื่อผิดๆ นี้ทำเราเจ็บหนักมาสามรอบ (drbook, drjob, readclinic)
ตอนนั้นเรา validate ด้วยการถามเพื่อนๆ ที่เป็นหมอ มีนัดสัมภาษณ์หมอคนอื่นๆ เป็นเรื่องเป็นราวด้วยนะ (อ่าน Running lean มา มี script การสัมภาษณ์พร้อม ทำตามหนังสือเป๊ะ 55) แต่ skill การเก็บ insight ตอนนั้นยังอ่อนด้อยนัก เราไม่สามารถแยกได้เลยว่าอะไรเป็น must-have หรือ nice-to-have ใน product ของเรา เราคิดไปเองว่าทุกอย่างเป็น must-have ดังนั้น MVP ของเราจะต้องมี function เหล่านี้ทั้งหมด เพราะสิ่งเหล่านี้มันคือ must-have !
ซึ่งการทำบางฟังก์ชั่นก่อให้เกิดปัญหาให้เราในเวลาต่อมา ดังจะกล่าวในหัวข้อถัดไป
2016 Rath’s advice:
- Skill การแยก must-have กับ nice-to-have คือสิ่งสำคัญมาก ตัด nice-to-have ทั้งหมดทิ้งแล้วโฟกัสแต่สิ่งที่สำคัญ
- การจะได้ insight จาก potential customer สิ่งสำคัญไม่ใช่ script แต่เป็น mindset คือ การเปิดใจให้กว้าง ถามสิ่งที่เราอยากรู้อย่างจริงใจ และรับความคิดเห็นจริงๆ ของเขา (อย่าหลอกตัวเอง 55) เวลาคนเราพูดถึงสิ่งที่เขากำลังอิน มันจะมีพลังงานบางอย่าง เขาจะมีอารมณ์ร่วมตอนพูดถึงมัน เราจะสัมผัสได้ว่าเรื่องนี้เป็นปัญหาสำหรับเขาจริงๆ และเราจะหาทางแก้ให้เขา ซึ่งเราก็ยังไม่รู้ว่ามันคืออะไร แค่คิดว่ามันน่าจะเป็นแบบนี้ แต่มันอาจไม่ใช่
- แต่ถึงเราจะ validate must-have problem มาได้ก็จริง อย่าลืมประเมินขนาดตลาดให้ถูก มันอาจเป็น pain ที่หนักมากของคนไม่กี่คน แบบนี้ก็ไม่ใช่ problem worth solving (ยกเว้นคนนั้นจะจ่ายหนักมาก 55)
- ไม่ใช่แค่ potential customer แต่ควรคุยกับ stakeholder ทั้งหมดในธุรกิจเราให้ครบ อย่าไปมองใครเป็นคู่แข่งตั้งแต่ต้น ทำไมเขาไม่ทำเรื่องนี้ เขาอาจไม่ได้คิดไม่ออก แต่มันทำไม่ได้เพราะปัญหาอะไรหรือเปล่า อย่าไปกลัวใครขโมยไอเดีย (ถ้ากำลังทำสิ่งที่แค่ฟังไอเดียก็ขโมยไปทำได้เลย ผมว่าอย่าทำต่อเลยครับ)
ตัวอย่าง UI ของ drbook iPad
ตัวอย่าง UI ของ drbook iPhone
การขาด technical competency
ชอบมีคนพูดว่า “ตอนนี้เราไม่รู้จะทำมันได้อย่างไร แต่เราจะทำมันให้ได้ภายใน xx วัน” อันนี้ถ้าทำได้มันก็เท่ แต่ถ้าทำไม่ได้นี่มันสร้างความเสียหายมากๆ นะครับ = =
ตอนนั้นผมไม่ได้มี technical skill เท่าไหร่ ทำเป็นแค่ basic HTML, CSS (ผมไม่รู้แม้กระทั่งภาพรวมแบบที่เขียนในบทความนี้) สิ่งที่เราต้อง deliver ใน MVP (ที่อุดมไปด้วย must-have feature อันสุดยอดของเรา) ประกอบด้วย 3 อย่าง
- iPhone และ iPad app
- Back-end web และ web admin สำหรับการจัดการต่างๆ
- หนังสือสำหรับขึ้นบน platform
2 ข้อแรก เราใช้การ outsource ให้ software house ทำให้ ด้วยแนวคิดตอนนั้นว่าเราแค่อยากปล่อย MVP ของเราออกมาดูตลาดเร็วๆ ครั้งเดียว ถ้าเวิร์คก็จะได้ raise fund สร้างทีม dev ขึ้นมาทำต่อ ส่วนข้อหลังผมรับมาทำเอง
ทั้งสามข้อเข้ากับประโยคข้างต้นทั้งหมด “ตอนนี้เราไม่รู้จะทำมันได้อย่างไร แต่เราจะทำมันให้ได้ภายใน xx วัน”
ฝั่ง Software House
ช่วงแรกทุกอย่างดูเป็นไปด้วยดี ทีมโฟกัสกับการสร้าง product ให้เรา ปัญหามันมาเกิดเมื่อถึงคราวต้อง deliver function ที่เขาไม่รู้ว่าจะสร้างมันอย่างไร (ที่พีคคือฟังก์ชั่นที่ว่าสรุปเป็น nice-to-have) สิ่งที่เกิดขึ้นคือ
- บริษัทต้องใช้เวลาอย่างมากในการ R&D หา solution มันเป็นความรู้สึกว่าใกล้จะได้แล้ว แต่สุดท้ายก็ไม่ได้อยู่ตลอดเวลา (แต่ผมไม่ได้ blame อะไรเขานะครับ ทีมเป็น dev ที่เก่งจริง และผมสัมผัสได้ว่าเขาก็ทำเต็มที่แล้ว แต่มันยากจริงๆ)
- สิ่งที่เกิดตามมาคือการขอเลื่อนการ deliver ฟังก์ชั่นเหล่านี้ไปเรื่อยๆ ขอเวลาอีกนิดใกล้ได้แล้ว อันนี้ก็ไม่ blame อะไรนะครับ ผมก็เห็นอยู่ว่ามันใกล้ได้จริงๆ (แค่สุดท้ายเราและเขาถึงรู้ว่าจริงๆ ยังไม่ได้ใกล้)
- ทำให้ slot เวลาที่ทางบริษัทตั้งใจว่าจะทำโปรเจคท์นี้ไม่เสร็จตามที่ตั้งใจ
- สิ่งที่เกิดต่อมาคือ บริษัทก็มีงานอื่นๆ แทรกเข้ามาเรื่อยๆ งานเก่างานใหม่ปนกันไปหมด ทุกงานก็ด่วนทั้งหมด ทำให้เขาไม่สามารถโฟกัสกับการทำ project นี้ต่อไปได้
- หลังจากเขา deliver งานมาส่วนหนึ่ง (ตามหลัก agile) เรานำงานนั้นมาดูแล้วเราก็อยากปรับอีก ไปๆ มาๆ ก็เกิดการตัดออกเพิ่มเข้าของฟังก์ชั่นเข้าไปเรื่อยๆ
- สุดท้าย โปรเจคท์ที่แพลนจะเสร็จใน 3 เดือน ใช้เวลาเกือบ 1 ปีครึ่งจึงจะเสร็จได้
ถามว่าเราไม่ได้ทำสัญญาหรือ ? คือพอทำงานด้วยกันมา ฝั่งผมเองก็ผิดที่เพิ่มอะไรเข้าไป (เอาจริงๆ ความ agile มันล้มเหลวไปนานแล้วใน project นี้) มันก็เป็นเพื่อนกันแล้ว เราก็ไม่อยากไปปรับอะไรเขาน่ะครับ และเราก็ผิดอยู่ส่วนหนึ่งที่ไปงอกงานให้เขา ก็ไม่กล้าปรับแหละครับ
เราใช้เวลาส่วนใหญ่ทำฟังก์ชั่นที่ไม่ได้สำคัญอะไรกับโปรเจคท์ (แต่เราคิดไปเองว่าสำคัญ) เป็นความล้มเหลวในการบริหารโครงการอย่างขั้นสุด
ฝั่งเราเอง
เนื่องจากเราไม่ต้องการเป็น PDF ผมก็ research ดูว่าควรจะทำอย่างไรดี อ่านๆ ดูก็เห็นเขาว่าจะทำ eBook ก็ต้อง ePub นี่แหละ ก็เลยศึกษาวิธีแปลงต้นฉบับ PDF มาเป็น ePub (เวอร์ชั่น 3 ด้วย ชอบของใหม่ เผื่ออนาคต) เราใช้ ePub ซึ่งเป็น format ที่เป็นมาตรฐาน “เผื่อ” ว่าซักวันหนึ่งเราจะสเกลไป industry อื่นได้ เราจะได้เป็น ePub platform สำคัญของภูมิภาค!
สุดท้ายผมสามารถสร้าง ePub ได้จริง แต่มันต้องใช้ effort สูงมากต่อหนึ่งเล่ม (ประมาณ 100 หน้าใช้เวลาราว 4 วัน) ปัญหาของการแปลง PDF เป็น ePub ในหนังสือภาษาไทย (ย้ำว่าภาษาไทย เพราะภาษาอังกฤษไม่มีปัญหาเหล่านี้) มีดังนี้ครับ
- PDF หลายไฟล์ไม่สามารถ copy & paste ได้ มันกลายเป็นตัวอักษรประหลาด พวกนี้ผมลองมาหลายอย่าง สรุปว่าที่เวิร์คสุดคือใช้ OCR software แปลง
- PDF ที่สามารถ copy & paste ได้ก็ตาม มันก็มีจุดที่ผิดอยู่ดี เอาแค่การเว้นวรรคก็ผิดแล้ว PDF พอสุดบรรทัดมันไม่ได้ตัดคำ มันเป็นการขึ้นบรรทัดใหม่ เช่น “การแพทย์” ถ้าอยู่ปลายบรรทัด เวลาก็อปมามันจะเป็น “การ แพทย์”
- สิ่งที่เราทำสำหรับทั้งสองกรณีคือ นำ PDF ที่อยู่ในรูป Word แล้ว มาให้คนแก้คำผิดและ proof ต่ออีกรอบหนึ่ง ตอนแรกผมทำเองทั้งหมด สุดท้ายไม่ไหว จ้างทำ cost ก็บานสิครับ
- ความยากอีกอย่างคือหนังสือวิชาการ มันมีการจัด format เยอะ เดี๋ยวตาราง เดี๋ยว bullet เดี๋ยวอักขระพิเศษ มันไม่เหมือนหนังสือนิยายที่ตัวหนังสือต่อกันไปเรื่อยๆ
- เรื่องนี้สุดท้ายเรานำไปปรึกษาพี่หมู ookbee (เพราะ ookbee ก็มี ePub) ไม่แน่ใจว่าพี่หมูให้เปิดเผยได้หรือเปล่าเลยไม่เปิดวิธีของ ookbee ละกันครับ แต่สุดท้ายก็รู้ว่าวิธีข้างต้นมันก็ไม่ได้แย่หรอก
ทำไมผมถึงบอกว่านี่เป็นปัญหา technical competency เพราะกระบวนการทั้งหมดข้างต้น ถ้าเรามี dev ที่เก่งพอ มันสามารถ automate ได้ทั้งหมด แต่แน่นอนว่า cost ในการสร้าง software นี้มันไม่ราคาถูกแน่ๆ
2016 Rath’s advice:
- ย้ำอีกครั้งว่า validate ดีๆ ว่าอะไรคือ must-have
- ควร in-house development เพราะ startup product มันมีความเปลี่ยนแปลงที่เยอะตลอดทาง ถ้าหาไม่ได้จริงๆ ทำเป็น part-time ก็ยังดี (เรื่องการหา dev ร่วมทีมนี่เขียนได้เป็นอีก blog) แต่เขาต้องมีความเป็นเจ้าของ product นั้น
- การประเมินความเป็นไปได้ของโปรเจคท์ก่อนเริ่มก็สำคัญ แต่ผมว่าสิ่งที่สำคัญกว่าคือการ detect ให้เร็วว่ามันเป็นไปไม่ได้ในเวลาที่กำหนด และควรจะรีบตัดจบให้ไว ไปทำอย่างอื่นที่สำคัญกว่า launch ไปแบบไม่สมบูรณ์ยังดีกว่าไม่ได้ launch (แต่ประโยคนี้ไม่จริงใน product บางอย่างนะ)
- อย่าไปเสียเวลาทำงาน non-skill เพราะเวลาของเรามีค่า ควรเอาไปทำสิ่งที่มีประโยชน์จริงๆ ผมใช้เวลาของชีวิตไปราวๆ 6 เดือนกับการทำเรื่องเหล่านี้ วันๆ นั่ง copy & paste ตรวจทานคำผิด สุดท้ายหนังสือเหล่านั้นเราไม่ได้เอาขึ้น store ของเราด้วยซ้ำ (ด้วยเหตุผลหลายๆ อย่าง ข้ามละกันครับ เดี๋ยวยาว)
- งาน non-skill เหล่านี้ควรส่งต่อไปให้คนที่เขารับทำ ถ้าเราจะบอกว่าเราไม่มีเงินมาจ้างคนทำ ควรพิจารณาธุรกิจตัวเองว่าทำไมมันไม่มีเงินมาจ้างแค่งาน non-skill พวกนี้
- ย้ำอีกทีว่าทำแต่ส่ิงที่ must-have อย่างกรณีผม เราอยากเปิดตัวแล้วมีหนังสือเยอะๆ เลยเอาหนังสือที่คงไม่มีใครอ่านมาแปลงซะเยอะ จริงๆ แปลงแค่ไม่กี่เล่มแต่มีแต่เล่มโดนๆ ยังได้ผลกว่า
ตัวอย่าง bug ที่เกิด เวลาเปิดหน้าไปเรื่อยๆ จะเกิดเป็นสี่เหลี่ยมสีเทาแล้วค้างไป
การขาด business man
ใน startup ใดๆ ก็ตามเลยนะครับ dev ให้เสร็จเป็นแค่ส่วนนึงเท่านั้น แต่มันมีอีกหลาย aspect มากๆ ในการทำธุรกิจที่ใช้พลังยิ่งกว่าการ dev ซะอีก อันนี้เป็นสิ่งที่คนทำ startup ใหม่ๆ ไม่ค่อยเข้าใจนะครับ ถ้าเราทำให้เสร็จ user ก็จะเข้ามาใช้ ไม่นะครับ ไม่มีใครมาครับถ้า business skill คุณไม่แข็งพอ ยกเว้นว่า product เราจะเมพมากๆ ซึ่งส่วนใหญ่มันไม่ขนาดนั้น (แต่เราจะคิดไปเองว่ามันเมพ)
ตอนนั้นพี่ตั้ม (CEO iamdr) ยังไม่ได้มา full-time ที่บริษัท ปัญหาที่เกิดขึ้นคือ เราไม่มีคนไปขายไอเดียเชิญชวนหมอหรืออาจารย์แพทย์นำหนังสือมาอยู่บน platform (ไม่ใช่ทุกอย่างจะทำผ่าน online แล้วเวิร์คน่ะครับ) ตอน product เสร็จแล้ว ถ้าจะให้เกิดจริงๆ มันก็ต้องทำ offline-marketing กันหนัก ไม่ใช่แค่ online (ยกเว้นจะมี creativity คิดแคมเปญเมพๆ ได้)
สิ่งสำคัญที่สุดคือ เราเช็คกันไม่เป็นว่าสิ่งที่เราทำอยู่มันเป็น problem worth solving หรือเปล่า โอเคเริ่มไม่สวย, validate มาไม่ดี แต่ทำไปควรจะ detect ให้เร็ว ถ้าไม่เวิร์คควรจบโดยเร็ว แล้วเอาเวลาไปทำอะไรที่น่าจะเวิร์ค
2016 Rath’s advice:
- คนอื่นอาจจะพอ part-time ได้ แต่ CEO ควร Full-time ถ้ามีงานประจำอยู่ เก็บเงินซักก้อนแล้วลาออกมาลุยให้เต็มที่ครับ เตรียมรันเวย์ไว้ให้รันได้ซักระยะ ทำงานอย่างอื่น part-time ไปด้วยก็ได้ แต่งานหลักควรเป็นงานบริษัท
- แต่ก่อนจะลาออกมันก็ควรมีสัญญาณหลายๆ อย่างที่บอกว่าออกมาทำมันน่าจะเวิร์คได้นะ หลายคนใช้สัญญาณว่าธุรกิจสร้างรายได้มากกว่างานประจำ แต่ผมว่าไม่จำเป็นต้องรอขนาดนั้นครับ มันแตกต่างกันไปในแต่ละเคส
- อย่าไปเสียดายถ้าลงแรงลงเงินไปเยอะแล้ว ขอทำต่ออีกหน่อยน่า ถ้ามันจะไม่เวิร์คทำต่อไปมันก็ zombie business ครับ ไม่ตายแต่ไม่โต จะทำต่อต้อง pivot ไปเลย ถ้าจะไม่ pivot ก็เลิกไปเลยดีกว่า
ถ้าให้ทำอีกครั้ง จะทำแบบไหน
จะไม่ทำครับ 555 แต่สมมติว่ากำหนดโจทย์มาเลยว่าให้ทำ ผมจะทำแบบนี้
- ติดต่อหมอเอาหนังสือให้ได้แค่เล่มเดียวเท่านั้น แต่เป็นเล่มที่โดนหน่อย
- ลองเอาหนังสือมาแปลงจาก PDF ดู ควรประเมินต้นทุนได้ว่ามันเท่าไหร่ ควรขายราคาไหน
- เอาหนังสือที่แปลงแล้วมาเข้า ionic ทำเป็น web view app ง่ายๆ มีฟังก์ชั่นแค่เปิดสารบัญแล้วไปหน้าที่ต้องการ ไม่ต้องมีขีดไฮไลท์ ไม่ต้องแทรกโน้ต ไม่ต้องมีเครื่องคิดเลข ไม่ต้องเป็น platform มีระบบ store เอาง่ายๆ แค่นี้ก่อนแล้ว แล้วเก็บ feedback ดูว่า user คิดอย่างไร
- ถึงขั้นนี้จริงๆ ควรรู้ได้แล้วว่ากำลังทำ nice-to-have product ที่มีขนาดตลาดเล็กอีกต่างหาก รวม cost ทั้งหมดไม่เกิน 30,000 เอ่า เวลาอย่างมากก็เดือนเดียว
- แต่สมมติยังไม่รู้ตัวจริงๆ อยากขอลองต่ออีกนิด สร้างเป็น eBook store ให้ load หนังสือได้ ไม่ต้องหวังไกลว่าจะเป็น platform ePub ชั้นนำของภูมิภาค ใช้ HTML5 + CSS ธรรมดาทำไปเลยครับ จะลดความปวดหัวและ limitation ของ ePub ไปได้เยอะ จะแปลงค่อยมาแปลงทีหลังสมมติมันเวิร์ค
สิ่งสำคัญที่สุดก็คือ มโนให้น้อย คุยกับ user/customer เยอะๆ
สรุปจากทั้งหมด
- แก้ปัญหาเล็กปัญหาใหญ่ ยังไงก็เหนื่อย เราคิดว่าเราจะทำอะไรเล็กๆ แป๊ปๆ success ถึงกำไรไม่เยอะแต่ก็น่าจะเลี้ยงตัวเองได้ ส่วนใหญ่มันไม่ถึงจุดนั้นง่ายๆ นะครับ จะทำโปรเจคท์ใดก็ตาม ผมว่าตัวเลขอย่างน้อยคือ 2 ปี ถึงจะพอพามันไปถึงจุดที่ stable ได้ ลองถามตนเองดีๆ ว่าเราพร้อมจะอยู่กับมันไปสองปีหรือเปล่า แต่จะให้ดีที่สุดคือเราน่าจะทำอะไรที่เราอยากอยู่กับมันไปตลอดชีวิตมากกว่า
- จะเห็นว่าหลายๆ Rath’s advice ผมจะมีวงเล็บข้อยกเว้นไว้ จริงๆ จะบอกว่ามันใส่ได้แทบจะทุกข้อเลยครับ เพราะโลกนี้มันไม่มีสูตรสำเร็จ เราไม่สามารถอ่านเรื่องราวความสำเร็จของใครแล้ว reproduce มาเป็นของเราได้ เราต้องสร้าง story ของเราขึ้นมาเอง
- และเนื่องจากผมก็ยังไม่ได้ success อะไร อันนี้คือมาแชร์ความล้มเหลว 555 ดังนั้นอย่าเชื่อผมมากครับ
ก็หวังว่าจะเป็นประโยชน์สำหรับผู้ต้องการเริ่มทำ startup ทุกท่านนะครับ ^.^ มีอะไรแชร์กันได้ครับ
ขอบคุณมากครับสำหรับประสบการณ์ที่มีประโยชน์
เยี่ยมมากขอบคุณครับ
ขอบคุณมากครับ รู้สึกผ่านมาคล้ายๆกันครับ
ขอบคุณมากครับ
ผมว่าการเรียนรู้ จากความล้มเหลวมันแตกประเด็นความคิดได้มากกว่า การเรียนรู้จากความสำเร็จ เพราะ คนส่วนใหญ่มักจะมุ่งไปทางเดียวกันเยอะ จนเฝือไปหมด เอ๊ะ..หรือผมเป็นพวกเสพติดความลำบากหว่า