- Max Rozen द्वारा शुरू किया गया OnlineOrNot ऐसे बाज़ार में शुरू हुआ जहाँ पहले से ही 200 से अधिक प्रतिस्पर्धी उत्पाद मौजूद थे
- शुरुआत में कई उत्पाद इस्तेमाल करने में असुविधाजनक थे, और बाद में अनगिनत प्रतिस्पर्धी उत्पाद आए और जल्दी गायब भी हो गए
- कुछ प्रतिस्पर्धी उत्पादों ने VC फंडिंग ली, बड़ी कंपनियों द्वारा अधिग्रहित हुए, और आगे चलकर उनका user experience लगातार खराब होता गया
- OnlineOrNot का लक्ष्य self-funded, लंबे समय तक टिकाऊ बिज़नेस बनाना था
- लेखक आज भी अपनी full-time नौकरी बनाए रखते हुए लगातार SaaS विकसित कर रहे हैं
- वे हर साल एक retrospective लिखते हैं, और समय के साथ यह भी पता चला कि पहले सीखे गए कुछ सबक गलत थे
जो सिद्धांत नहीं बदले
कई वर्षों तक बिज़नेस चलाते हुए बहुत कुछ सीखा, लेकिन कुछ मुख्य सिद्धांत ऐसे हैं जो आज भी नहीं बदले
हर working day 2 घंटे निवेश करना
- OnlineOrNot शुरू करने से पहले से ही वे हर सुबह काम पर जाने से पहले 2 घंटे अपने personal projects पर लगाते थे
- इसी समय का उपयोग करके उन्होंने सैकड़ों लेख, एक किताब, और कई software projects पूरे किए
- दिन में कितना समय लगाते हैं, उससे ज़्यादा महत्वपूर्ण है हर दिन लगातार प्रयास करना
- यह समय निकालने के लिए वे 2 घंटे पहले उठते थे और अपनी दिनचर्या को उसी हिसाब से बदलते थे
दूसरे side projects नहीं करना
- जैसे कहा जाता है, "एक साथ दो खरगोशों का पीछा करोगे तो एक भी नहीं पकड़ोगे", इसलिए वे एक चीज़ पर फोकस करते हैं
- कुछ असाधारण लोग कई projects सफल बना लेते हैं, लेकिन वे मानते हैं कि वे ऐसे नहीं हैं
- $0 से $500 MRR तक पहुँचना सबसे मुश्किल चरण है, और इसे बार-बार दोहराने की ज़रूरत नहीं
- जो मॉडल पहले से काम कर रहा है, उसी पर ध्यान देना चाहिए, और marketing का तरीका भी उसी नज़रिए से चुनना चाहिए
ग्राहकों की तकलीफ़ हल करना सबसे पहले
- जब कोई user sign up करता है, तो automated email के ज़रिए उससे पूछा जाता है, "आपने sign up क्यों किया?"
- वे सभी emails पढ़ते हैं और खुद जवाब देते हैं, और यही product improvement के लिए सबसे अहम insight बनता है
- यह समझना कि users को कहाँ दिक्कत हो रही है, और सच में उसे हल करना, यही प्राथमिकता है
लगातार दोहराना और सुधारना
- अगर कोई काम 2 घंटे के भीतर deploy नहीं हो सकता, तो उसका scope घटाकर पहले deploy करते हैं
- आदर्श रूप से हर चीज़ ठीक 2 घंटे में पूरी नहीं होती, लेकिन वे जल्दी initial version shipping करके बाद में features बढ़ाने का तरीका पसंद करते हैं
- अगर सब कुछ बनाकर ही deploy करने की कोशिश करें, तो motivation कम हो जाती है और focus टूट जाता है
- feature flags के पीछे धीरे-धीरे features पूरा करने का तरीका कहीं ज़्यादा असरदार है
सीखे गए सबक
कुछ किताबें पढ़ो, फिर तुरंत बनाना शुरू करो
- शुरुआत में गलतियाँ कम करने के लिए उन्होंने दर्जनों business books पढ़ीं
- लेकिन अंत में यह समझ आया कि खुद गलतियाँ करके सीखना सबसे असरदार है
- उदाहरण: Hacker News के मुख्य पेज पर आने के बाद 6000 लोग आए, लेकिन असली app तक पहुँचने वाले users की संख्या एक अंक में ही रही
- सिर्फ sign-up form पर ही 75% users छूट गए → एक OAuth login option जोड़ने से drop-off 50% तक सुधर गया
- अगर वे फिर से शुरू करते, तो सिर्फ ये किताबें पढ़कर तुरंत शुरू कर देते:
- The Mom Test (Rob Fitzpatrick)
- Deploy Empathy (Michele Hansen)
- Badass: Making Users Awesome (Kathy Sierra)
- और अगर SaaS चलाने की practical details चाहिए हों, तो The SaaS Playbook (Rob Walling) भी
subscription बेचने से पहले समस्या हल करना ज़रूरी है
- SaaS का उद्देश्य subscription बेचना नहीं, बल्कि ग्राहकों की तकलीफ़ हल करना है
- "अगर features बनाते रहेंगे तो कभी न कभी लोग इस्तेमाल करेंगे" → इस सोच को बदलकर "users के काम में आने वाली झुंझलाहट भरी समस्या हल करें" करना होगा
- SaaS समस्या हल करने का सिर्फ एक तरीका है; इसके अलावा screencast, docs, writing, books, workshops, code samples जैसे कई तरीके हो सकते हैं
छोटा बनाओ, बार-बार deploy करो
- users feature ideas देते हैं, लेकिन असल में अक्सर उनका इस्तेमाल नहीं करते
- जो लोग पहली बार SaaS शुरू करते हैं, वे सिर्फ किसी से बात हो जाने भर से उत्साहित होकर सीधे feature बना देने की गलती कर सकते हैं
- यह पूछना चाहिए कि वे उस feature का इस्तेमाल कैसे करेंगे, और दूसरे users इस समस्या को कैसे हल कर रहे हैं, फिर
- सबसे कम संभव feature के साथ पहले implement करके प्रतिक्रिया देखनी चाहिए
- सिर्फ एक व्यक्ति के लिए 'snowflake feature' बनाने से बेहतर है, ऐसे features के लिए रणनीतिक रूप से काम करना जिन्हें कई लोग इस्तेमाल करें
- कुछ घंटों की मेहनत से बना feature हटाना दुख देता है, लेकिन कुछ महीनों की मेहनत से बना feature हटाना उससे कहीं ज़्यादा दर्दनाक होता है
पहले ship करो, scale बाद में सोचो
- OnlineOrNot का शुरुआती version architecture optimization के बिना जल्दी launch किया गया
- वास्तव में system में ऐसा bug था जो लगभग 100 checks तक ही सीमित कर देता था,
- और समस्या होने पर user को सिर्फ "Error!" दिखाने वाला UI था, यानी वह बहुत अधूरा था
- फिर भी लेखक ने बेकार features बनाने की बजाय अधूरे UI के लिए आलोचना झेलना चुना
- शुरुआत से ही हज़ारों users आ जाएँगे, इसकी कोई गारंटी नहीं थी, इसलिए जल्दी validate करना ज़्यादा महत्वपूर्ण था
- अस्थायी रूप से database को higher plan पर upgrade करके checks की capacity बढ़ाई गई
- फिर कुछ ही घंटों में इसे refactor करके लाखों checks संभालने लायक बनाया गया, और error screen भी बेहतर की गई
early access program चलाना
- product development के शुरुआती चरण में ज़्यादातर users अधूरे features के प्रति कुछ हद तक सहनशील होते हैं
- समय के साथ users की उम्मीदें बढ़ती हैं और वे अधिक mature product चाहते हैं
- इसे संभालने के लिए हर user account में "early access program में शामिल हों" checkbox जोड़ा गया
- इसमें शामिल users अधूरे नए features पहले इस्तेमाल करके feedback देते हैं
- यह testing और feedback के बीच संतुलन बनाने का अच्छा तरीका साबित हुआ
free trial जितनी जल्दी हो सके शुरू करो
- आजकल यह सलाह आम है कि "free plan को सही तरह balance करना बहुत मुश्किल है, इसलिए इसे मत करो"
- लेकिन शुरुआती दौर में free plan word-of-mouth और user acquisition के लिए असरदार था
- इसकी कमी यह थी कि अगर free plan और paid features में बड़ा अंतर हो, तो अच्छे features आज़माने का कोई रास्ता होना चाहिए
- शुरुआत के 11 महीने बाद onboarding के दौरान "क्या आप free trial शुरू करना चाहेंगे?" यह सवाल जोड़ा गया
- इसका असली मतलब कुछ ऐसा था:
> “क्या आप 14 दिनों तक अच्छे features आज़माकर निर्णय लेना चाहेंगे, या फिर कुछ महीनों तक सीमित features इस्तेमाल करके अंत में निराश होना चाहेंगे?”
- इसका असली मतलब कुछ ऐसा था:
- बाद में प्रयोग के तौर पर सभी users को default रूप से free trial देना शुरू किया गया,
- और सिर्फ इस एक प्रयोग से monthly growth rate 2x से भी अधिक बढ़ गई
- निष्कर्ष:
- "यह एक paid service है. अच्छे features इस्तेमाल करते रहना है तो payment details चाहिए"
- यह संदेश, "यह free service है. ज़्यादा इस्तेमाल करेंगे तो शायद paid हो" से बिज़नेस के हिसाब से कहीं अधिक असरदार है
documentation भी product का हिस्सा है
- पहले यह कहा जाता था कि "developers docs नहीं पढ़ते", लेकिन यह पूरी तरह गलत है
- आदर्श customers में से कुछ ने OnlineOrNot की documentation की तारीफ़ की, और इसी के बाद उन्होंने docs में गंभीर निवेश किया
- API docs भी खुद बनाए गए ताकि user experience पर पूरा control रखा जा सके
- product analytics tools से देखने पर दो बातें साफ हुईं:
- user UI में समस्या झेलता है, docs देखकर feature खोज लेता है, तो product इस्तेमाल जारी रखता है
- अगर उसे वांछित जानकारी नहीं मिलती, तो वह check बनाए बिना छोड़कर चला जाता है
- documentation की quality सीधे user retention से जुड़ी है
product को mobile के हिसाब से design करो
- आम धारणा के विपरीत, B2B SaaS users भी smartphone से काम शुरू करते हैं
- वास्तव में कुल users में लगभग 50% mobile पर product इस्तेमाल करना शुरू करते हैं
- account बनाते हैं, कुछ pages register करते हैं, फिर PC पर वापस आकर दोबारा देखते हैं
- पहले 6 महीनों तक mobile environment का ध्यान नहीं रखा गया, और mobile sign-ups में से अधिकांश छूट गए
- बाद में responsive UI लागू करने पर mobile user retention साफ़ तौर पर बढ़ा
users से सीधे पूछो कि वे कहाँ से आए
- पहले साल के बीच में किया गया सबसे मूल्यवान code change यह था कि
- sign-up के समय "आपको OnlineOrNot के बारे में कहाँ से पता चला?" यह सवाल जोड़ा गया
- user acquisition channels समझना marketing efficiency बढ़ाने के लिए बेहद महत्वपूर्ण है
- marketing channels दर्जनों हो सकते हैं, लेकिन ध्यान देने के लिए resources सीमित होते हैं
- जब कोई channel अच्छा काम करता दिखे, तो उसी में फोकस्ड निवेश करना चाहिए, और जब तक उसकी प्रतिक्रिया कम न हो जाए तब तक जारी रखना चाहिए
intrusive analytics tools का इस्तेमाल न करना
- शुरुआत में आम SaaS products की तरह session tracking और funnel analytics tools लगाए गए, लेकिन वे बहुत उपयोगी नहीं निकले
- बड़े teams के लिए वे काम आ सकते हैं, लेकिन छोटे services में random results को गलत तरीके से समझ लेने का जोखिम ज़्यादा होता है
- एक solo founder के रूप में, जब हर सुबह सिर्फ 2 घंटे ही मिलते थे,
- तब बड़े data sets खंगालने की बजाय विश्वसनीय users के inner-circle से सीधे राय लेना ज़्यादा असरदार था
- features और समस्याओं पर intuitive feedback लेकर, भावना-आधारित निर्णय से product सुधारा गया
feature न हो तब भी संभावित ग्राहक से बात करो
- एक दिन एक CTO ने पूछा कि क्या कोई खास feature supported है
- पहले उनका इरादा सिर्फ "माफ़ कीजिए, अभी नहीं है" कहकर बात खत्म करने का था, लेकिन
- जिज्ञासा से उन्होंने पूछा कि वे किस समस्या का सामना कर रहे हैं और क्या हासिल करना चाहते हैं
- inner-circle users से भी पूछा कि क्या उन्हें यही समस्या है
- और feature को कैसे design किया जा सकता है, इस पर ideas साझा किए
- नतीजा यह हुआ कि वह CTO अगले ही दिन paid subscriber बन गया, और आज तक customer है
- वह feature दूसरे users के लिए भी उपयोगी साबित हुआ
समस्या हल करने से ज़्यादा समय platform बनाने में जाता है
- पिछले 4 वर्षों के development time का आधा से अधिक हिस्सा SaaS platform बनाने में लगा
- असली लक्ष्य, यानी “website down है या नहीं, यह जाँचना और alert भेजना”, उसका सिर्फ एक हिस्सा था
- वास्तव में जिन features की ज़रूरत पड़ी, वे थे:
- कई authentication methods और user management
- trial, onboarding
- बार-बार होने वाले DB tasks, team management, invoice handling
- lifecycle emails आदि
- कुछ काम Stripe जैसी services को outsource किए गए, लेकिन
- कई हिस्से ऐसे थे जिन्हें खुद संभालना या customize करना ज़रूरी था, इसलिए अंततः खुद बनाना पड़ा
pricing वास्तव में बहुत कठिन है
- कीमत बहुत ज़्यादा हो तो expectations बढ़ जाती हैं या लोग sign up ही नहीं करते
- कीमत बहुत कम हो तो $9 देने वाला user भी पूरे app को अपनी ज़रूरत के हिसाब से बदलने की मांग कर सकता है
- समाधान:
- मुश्किल customers को refund देकर विदा कर दो
- price बढ़ाओ, और आगे बढ़ो
- खासकर शुरुआती चरण में features बढ़ाते समय लगातार pricing experiments ज़रूरी हैं
सिर्फ MRR पर अटके मत रहो
- MRR(Monthly Recurring Revenue) बिज़नेस performance मापने के लिए हमेशा सही metric नहीं होता
- कई हफ्ते या महीनों पहले किए गए काम आज के MRR को प्रभावित करते हैं, इसलिए real-time प्रभाव मापना मुश्किल होता है
- कुछ SaaS products में user sign up के बाद असल payment तक पहुँचने में 60 दिन से अधिक लग सकते हैं
- इसलिए यह समझने के लिए दूसरे metrics भी चाहिए कि लोग वास्तव में use कर रहे हैं या नहीं और value मिल रही है या नहीं
- उदाहरण: बनाई गई images की संख्या, submit किए गए forms की संख्या जैसे behavior-based success metrics
“unlimited” कभी मत दो
- हमेशा ऐसे whale customers होंगे जो "unlimited" का पूरा फायदा उठा लेंगे
- उदाहरण: $250/महीना देकर बहुत भारी resources इस्तेमाल करने वाला customer
- अगर unlimited जिस unit पर दिया जा रहा है वह cost पैदा करने वाली चीज़ है, तो यह निश्चित रूप से घाटे का सौदा है
- यही सलाह lifetime deals पर भी लागू होती है
- अगर आप $100 में lifetime usage दे देते हैं, तो आने वाले कई सालों तक feature requests झेलनी पड़ सकती हैं
- और अगर किसी third-party marketplace का इस्तेमाल किया हो, तो संभव है कि इसमें से सिर्फ 30% revenue ही आपके पास आए
- अंततः आप असली customers नहीं, बल्कि छोटे समय के फायदे के बदले लंबे समय तक बंधे रहने वाले users को बुला रहे होते हैं
paid resources पर rate limit ज़रूर लगाओ
- AI, SMS, email sending जैसी paid APIs इस्तेमाल करते समय usage limits अनिवार्य हैं
- "वह paid customer है, तो क्या unlimited इस्तेमाल नहीं कर सकता?" → कुछ अपवाद हो सकते हैं, लेकिन
- ज़्यादातर मामलों में अचानक भारी लागत या vendor द्वारा spam label किए जाने का जोखिम होता है
- वास्तविक उदाहरण:
- सैकड़ों WordPress sites host करने वाले server में RAM कम होने से errors आने लगे
- और उसके कारण हज़ारों SMS alerts अपने-आप भेज दिए गए, जिससे बड़ा खर्च हुआ
- जिन customers को सचमुच बड़े पैमाने पर usage चाहिए होगा, वे खुद आपसे संपर्क करेंगे
एक ही पेज पर सब कुछ समझाने की कोशिश मत करो
> "अगर आप हर किसी से सब कुछ कहने की कोशिश करेंगे, तो अंत में किसी से कुछ भी नहीं कह पाएँगे"
- यह बात landing page copywriting पर खास तौर पर लागू होती है
- OnlineOrNot में हर नया feature जुड़ने पर अगर main landing page में उसका विवरण जोड़ते रहें, तो
- message बिखरा हुआ हो जाता है और users की समझ भी कम हो जाती है
- उदाहरण: Slack notifications दूसरा feature था जो बनाया गया, लेकिन कई लोगों को यह पता ही नहीं चला कि यह feature मौजूद है
- समाधान: हर feature के लिए अलग landing page बनाओ
- मुख्य: https://onlineornot.com/
- uptime monitoring: https://onlineornot.com/website-monitoring
- API monitoring: https://onlineornot.com/api-monitoring
- status pages: https://onlineornot.com/status-pages
- cron job monitoring: https://onlineornot.com/cron-job-monitoring
- हर page पर पर्याप्त जगह के साथ feature को साफ़ और स्पष्ट तरीके से समझाया जा सकता है
traffic बढ़ाना मुश्किल है, conversion सुधारना अभी संभव है
- इंटरनेट पर ध्यान पाना लंबी लड़ाई है और बहुत धीमा काम
- लगातार अच्छी content marketing करने पर भी, 1-2 visitors से सैकड़ों visitors तक बढ़ने में महीनों या सालों लग सकते हैं
- traffic बढ़ाना अपने-आप में आसान नहीं है
- इसके उलट, जो users पहले से आ चुके हैं, उनके behavior को तुरंत बदला जा सकता है
- उदाहरण: sign-up form में OAuth login option जोड़ना जैसे सुधार आज ही conversion rate बढ़ा सकते हैं
competitors इतने महत्वपूर्ण नहीं होते
- इस पूरे लेख में competitors की बात लगभग नहीं के बराबर है, क्योंकि असल में उनका प्रभाव इतना बड़ा नहीं होता
- बुनियादी features होना ज़रूरी है ताकि customers आपको विकल्प के रूप में consider करें, लेकिन
- असली competitor यह है कि users को आपके product के अस्तित्व के बारे में पता ही न हो
- features से भी ज़्यादा महत्वपूर्ण है awareness और accessibility
4 टिप्पणियां
सेवा चलाने वाले के नज़रिए से बहुत-सी बातें दिल को छूती हैं.
मैंने भी नींद कम करके डेवलपमेंट किया था, और मेरी सेहत खराब हो गई थी..
जिन लोगों का ऐसा ही अनुभव रहा है, उनसे मेरी जिज्ञासा है कि क्या इस तरह का समय निवेश बच्चों की परवरिश के साथ संभव है।
आने-जाने का समय, कंपनी में बिताया समय, और घर पर बच्चों के साथ बिताया समय—ये सब मिलकर दिन का लगभग ज़्यादातर हिस्सा ले लेते हैं, इसलिए ऐसी सेवा बनाने और चलाने के लिए कुछ और छोड़ना पड़ता है. बस उम्मीद है कि वह परिवार या सेहत न हो..
यह वाकई बहुत कुछ सिखाने वाला लेख है। सुबह के 2 घंटे का उपयोग करके लिखना और कई प्रोजेक्ट पूरे करना...!
यह सीखने लायक बहुत अच्छा लेख है। आखिरकार, हमें यह नहीं भूलना चाहिए कि SaaS भी एक ऐसा प्रोडक्ट है जिसे ग्राहक अपनी समस्या हल करने के लिए अपनाते हैं।
अकेले 1 साल तक SaaS चलाकर मैंने क्या सीखा
देखते ही देखते 3 साल बीत गए, हा! बदली हुई बातों की तुलना करते हुए पढ़िए!