ऐसे काम करो जिन्हें स्केल नहीं किया जा सकता (2013)

 (paulgraham.com)
3 पॉइंट द्वारा GN⁺ 2025-08-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Y Combinator सलाह देता है कि startup के शुरुआती चरण में 'ऐसे काम' सक्रिय रूप से करने चाहिए जिन्हें स्केल नहीं किया जा सकता
  • Stripe, Airbnb जैसे सफल startup ने शुरुआती users को जुटाने के लिए सीधे और आक्रामक तरीके अपनाए
  • ज़्यादातर startup शुरुआत में बहुत नाज़ुक होते हैं, और संस्थापक का खुद मैदान में उतरना ही growth की कुंजी होता है
  • शुरुआती users को बेहतरीन अनुभव और संतुष्टि देना लंबी अवधि की growth के लिए महत्वपूर्ण है
  • शुरुआती चरण में automation की जगह manual काम, niche market पर फोकस, और direct consulting प्रभावी हो सकते हैं

परिचय: startup growth की हक़ीक़त

  • कई aspiring founders सोचते हैं कि startup अपने-आप बढ़ता है, लेकिन वास्तव में संस्थापक को खुद आगे बढ़कर growth की चिंगारी जलानी पड़ती है
  • पुरानी कारों के स्टार्टिंग हैंडल की तरह, शुरुआत में मेहनत-प्रधान प्रक्रिया ज़रूरी होती है

users को सीधे recruit करना (Recruit)

  • अधिकांश startup को passive ढंग से users के आने का इंतज़ार नहीं करना चाहिए, बल्कि खुद उन्हें ढूँढने निकलना चाहिए
  • Stripe ने भी शुरुआती दिनों में 'Collison installation' नाम के तरीके से, beta version में रुचि रखने वालों के laptop लेकर खुद installation किया और users हासिल किए
  • संस्थापक ऐसे कामों से इसलिए बचते हैं क्योंकि उन्हें rejection का डर, शर्म, और कम user संख्या को कमतर समझने की प्रवृत्ति होती है
  • वास्तव में compound growth के असर से, अगर weekly 10% growth बनी रहे तो 2 साल बाद users की संख्या लाखों में पहुँच सकती है
  • Airbnb भी New York में hosts के पास खुद जाकर उन्हें register कराने में मदद करने जितना सक्रिय था

शुरुआती startup की नाज़ुकता (Fragile)

  • लगभग हर startup शुरुआत में बहुत अस्थिर होता है, और थोड़े समय की सीधी मेहनत से सफलता और विफलता का फ़र्क तय हो सकता है
  • बाहरी critics या investors की उदासीनता से भी ज़्यादा ख़तरनाक है खुद अपने business की value को कम आँकना
  • शुरुआत में यह नहीं पूछना चाहिए कि 'क्या यह company दुनिया बदल देगी?', बल्कि 'अगर सही कोशिश की जाए तो यह कितनी बड़ी हो सकती है?'
  • उदाहरण के तौर पर Microsoft, Airbnb के शुरुआती दिन भी ऊपर से बहुत छोटे दिखते थे, फिर भी वही सबसे सही रास्ता था
  • सही users की शुरुआत अपने जैसे लोगों से हो सकती है, या शुरुआती users में से सबसे उत्साही समूह को पहचानकर उसी पर फोकस करना चाहिए

user delight को अधिकतम करना (Delight)

  • सिर्फ users को जुटाना ही नहीं, बल्कि मौजूदा users को असाधारण संतुष्टि देने के लिए अतिरिक्त प्रयास भी ज़रूरी है
  • Wufoo ने शुरुआती भरोसा बनाने के लिए हर नए signup पर हाथ से लिखे thank-you letters भेजे
  • बड़ी कंपनियों की customer service वाली सोच में बँधने के बजाय, startup के शुरुआती दौर में ही संभव personalized experience पर ज़ोर देना चाहिए
  • अगर शुरुआती users को खुश करने का काम इतना बढ़ जाए कि संभालना मुश्किल लगे, तो यह उल्टा एक अच्छा growth signal हो सकता है
  • शुरुआती founders में customer service का अनुभव कम होना, छोटी company के competitive advantage का पूरा उपयोग न कर पाने का एक कारण है

user experience के प्रति जुनून (Experience)

  • Steve Jobs के 'Insanely great' वाले विचार की तरह, शुरुआत में user experience को लेकर जुनूनी होना ज़रूरी है
  • शुरुआती product के पूरी तरह polished होने से ज़्यादा, अधूरा होने पर भी users के साथ interaction के ज़रिए उसे बेहतर बनाना महत्वपूर्ण है
  • users से सीधे जुड़कर मिलने वाला feedback growth पर सबसे बड़ा असर डालता है

छोटे बाज़ार से शुरुआत करना (Fire)

  • Facebook और Airbnb की तरह, जानबूझकर बहुत छोटे market (जैसे Harvard students) से शुरुआत करके, उसी समूह के भीतर critical mass हासिल करने की रणनीति उपयोगी है
  • सबसे तेज़ प्रतिक्रिया देने वाले early adopters को ढूँढना शुरुआती चरण में अधिक प्रभावी होता है
  • YC जैसे accelerator programs, दूसरे startup को customer मानकर market में प्रवेश करने के लिए भी फ़ायदेमंद हो सकते हैं

hardware startup के लिए विशेष रणनीति (Meraki)

  • hardware startup में शुरुआती mass production cost ज़्यादा होती है, इसलिए Meraki, Pebble की तरह founders खुद product assemble करते हैं
  • सीधे बनाते हुए design optimization, components sourcing जैसे विषयों पर व्यावहारिक सीख मिलती है

consulting शैली में users तक पहुँचना (Consult)

  • B2B product में किसी एक खास customer के लिए consulting की तरह customized solution बनाकर, बाद में पास के market में विस्तार किया जा सकता है
  • customer को वास्तव में किस समस्या का समाधान चाहिए, उसके अनुसार पूरी तरह ढलने की प्रक्रिया से growth का रास्ता निकलता है
  • शुरुआत में customer की जगह software खुद चलाकर देना, या ज़रूरी features तुरंत जोड़ना भी एक तरीका हो सकता है

पूरी तरह manual strategy (Manual)

  • जब users कम हों, तो काम manual तरीके से किया जा सकता है, और बाद में धीरे-धीरे automation की ओर जाया जा सकता है
  • Stripe ने शुरुआत में 'instant account setup' को manual प्रक्रिया के ज़रिए पूरा किया ताकि user experience बेहतर रहे
  • शुरू से automation पर अटकने के बजाय, manual काम करके product और customer की असली समस्या समझना प्राथमिकता होनी चाहिए

'big launch' की अक्षमता (Big)

  • एक ही बार में बड़े पैमाने पर launch करना, या बड़ी companies के साथ partnership पर growth छोड़ देना, आम तौर पर विफल रहता है
  • शुरुआत में कम users पर ध्यान देना चाहिए, और तीव्र प्रयास तथा सीधे तरीके ज़्यादा महत्वपूर्ण होते हैं
  • users का ध्यान धीरे-धीरे बढ़ता है, सीधे प्रबंधन और संतुष्टि देने के ज़रिए growth आती है

startup idea को दो-आयामी तरीके से देखना (Vector)

  • सफल startup को product (क्या बनाना है) + non-scalable strategy (शुरुआत में कौन-से काम खुद करने हैं) के vector की तरह सोचना चाहिए
  • इस तरह शुरुआती सीधे कदम product के DNA पर सकारात्मक असर छोड़ते हैं
  • शुरुआती direct effort समय के साथ product और organizational culture में बदलकर लंबी अवधि की growth का इंजन बन जाता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-08-17
Hacker News की राय

  • मैंने हाल में एक पॉडकास्ट में कही गई एक बात सुनी थी जिससे मैं सच में बहुत जुड़ा: startup की सबसे बड़ी समस्या inertia होती है। दुनिया हमें खास पसंद नहीं करती, न ही उसे लगता है कि उसे हमारी ज़रूरत है... हमें इसे उलटना पड़ता है। हमें बिल्कुल शुरुआत से momentum बनाना पड़ता है, और founder का सच में सबसे महत्वपूर्ण काम इसी inertia को उलटने वाले काम करना है। यह भौतिक अर्थ में भी सच है। दुनिया रुकी हुई है, और हमें खुद शुरुआत का धक्का देकर momentum बनाना पड़ता है। इस नज़रिए से देखें तो शुरुआत में non-scalable काम करना अजीब नहीं लगता। आप किसी पहले से चलती मशीन को optimize नहीं कर रहे, बल्कि उस stage में हैं जहाँ आपको engine को ठीक से चालू कराने के लिए एक-एक चीज़ हाथ से घुमानी पड़ती है। Paul Graham की बात यह है कि scalable growth या automation उसके बाद की समस्या है। users से एक-एक करके मिलना ही सिखाता है कि सच में क्या काम करता है। यह इस बात के सबूत जमा करने की प्रक्रिया है कि user आपको ज़रूरी मानता है, और यह साबित करने की कि किस चीज़ को scale करना वाकई सार्थक है

    • मेरे हिसाब से manual काम की असली value यह है कि उससे सीधा सीखने को मिलता है। मेरे एक ग्राहक हर हफ्ते महत्वपूर्ण finance और securities news को खुद चुनकर curated list के रूप में देते थे। वह एक छोटे niche के अंदर का और भी छोटा niche था, लेकिन users उसे सच में पसंद करते थे। फिर एक समय आया जब सब कुछ automate करने की कोशिश हुई, और content बिना चयन के बहुत बढ़ गया, spam जैसी जानकारी भी बढ़ने लगी, value खत्म हो गई, और आखिरकार product भी उसी राह पर चला गया। खबरें ज़्यादा थीं, लेकिन क्योंकि अब उन्हें हाथ से चुनकर edit नहीं किया जा रहा था, signal-to-noise ratio और खराब हो गया। वास्तव में manual काम, भले scope में सीमित था, कहीं ज़्यादा मूल्यवान था। बहुत-सी कंपनियाँ यह नहीं समझतीं और बहुत जल्दी automation पर अटक जाती हैं। एक और उदाहरण में, एक client था जो competitor pricing हाथ से check करता था। automation चाहिए था, तो Excel-आधारित एक simple scraper बना दिया गया। शुरुआत में वह खुश था, लेकिन बाद में समझ आया कि competitor sites को खुद देखते हुए जो नई products, catalog trends वगैरह सीखने को मिलता था, वह मौका छूट रहा है। आखिर में उसने फिर से manual exploration शुरू किया, और scraper को सिर्फ साधारण price analysis के लिए इस्तेमाल किया। लेकिन मेरे ज़्यादातर दूसरे ग्राहक product और problem की मूल प्रकृति से ज़्यादा automation की ही चिंता करते हैं, और इस कारण बार-बार महत्वपूर्ण learning के मौके खो देते हैं

    • इसलिए “लोग जो चाहते हैं वही बनाओ” startup दुनिया का मशहूर कथन है

    • “inertia को उलटना” वाली अभिव्यक्ति मुझे बहुत पसंद आई, लेकिन यह approach हर startup पर लागू नहीं होती। Sequoia के Arc framework के अनुसार तीन तरीके होते हैं: Hair on Fire (तुरंत दर्द, जहाँ momentum महत्वपूर्ण है), Hard Fact (दर्द है, लेकिन आदत बदलनी पड़ती है), Future Vision (लोग अभी मानते ही नहीं कि यह संभव है, इसलिए पहले trust बनाना पड़ता है)। non-scalable काम खुद करके परिणाम लाना Hair on Fire तरह की समस्या में अनिवार्य है, लेकिन बाकी मामलों में आपको वास्तविकता की समझ को बदलना पड़ता है या पहले credibility बनानी होती है

  • मेरा सिद्धांत है कि इसे तीन चरणों में बाँटा जा सकता है: Not Scaling (scale से पहले), Scaling (scale), और Antiscaling (अप्रिय होने का चरण)। Not Scaling वह stage है जहाँ आप market में अपना moat बनाते हैं। Scaling वह समय है जब product इतना लोकप्रिय हो जाता है कि customer नए customer लेकर आते हैं, और बस servers या DB sharding के जरिए बढ़ती demand संभालनी होती है। Antiscaling वह phase है जब आप आधुनिक web की समस्याओं जैसे किसी enterprise में बदलने लगते हैं। intelligence agencies आपसे इस वजह से संपर्क करती हैं कि आपकी service का इस्तेमाल terrorist कर रहे हैं, और city administration या सरकारें आपको target करके licensing या regulation laws बनाती हैं। founder इतना मशहूर हो जाता है कि memes बनने लगते हैं और location tracking तक होने लगती है। दुनिया पर राज करने की ज़रूरत नहीं है, पैसे कमाना काफी है। जो लोग दुनिया बदलने की बात करते हैं, उनमें से बहुत कम लोग सच में अच्छे नतीजे लाते हैं, इसलिए बस कुछ उपयोगी बनाना ज़्यादा महत्वपूर्ण है

    • “बस पैसे कमाने हैं” वाली बात Goodhart’s Law की याद दिलाती है: जब कोई metric (जैसे revenue) खुद लक्ष्य बन जाता है, तो वह अच्छा measurement नहीं रह जाता

    • यह नज़रिया मुझे बहुत biased लगता है। जब आपने ऐसी चीज़ बनाई हो जिसे कोई नहीं चाहता, तब जो चरम उदासीनता मिलती है, उसका यहाँ ज़िक्र नहीं है। और सच कहें तो उससे भी अधिक सामान्य मामला वह है जहाँ चीज़ बस हल्की-सी सफल होती है। कोई उससे नफरत नहीं करता, लेकिन कोई उसे पागलों की तरह प्यार भी नहीं करता। थोड़ा-बहुत positive response मिलता है, लेकिन hype या monopoly जैसी edge के बिना, किसी को सच में बहुत फर्क नहीं पड़ता। ऐसा case सबसे आम है

  • और उदाहरण जुटाने के लिए नीचे links छोड़ रहा हूँ

  • मैं यह बात हर शुरुआती founder और शुरुआती stage में जुड़ने वाले कर्मचारियों को सुझाना चाहूँगा। हम 15 से अधिक लोगों की टीम बन चुके हैं, लेकिन आज भी हर नए signup पर खुद फोन करते हैं। वजहें हैं 1) वे हमारे बारे में कैसे जान पाए 2) क्या उन्हें शुरुआत में इस्तेमाल करने में मदद चाहिए 3) (अप्रत्यक्ष रूप से) यह बताना कि हमारी team सच में व्यक्तिगत रूप से ध्यान देती है। हमारी service B2B platform है, इसलिए शायद यह और भी बेहतर काम करता है, और target audience developers होने के बावजूद, जब एक बार यह स्पष्ट हो जाता है कि “नहीं, हम sales call नहीं कर रहे”, तब लोग सच में बहुत ईमानदार और अच्छी बातें बताते हैं

  • Paul Graham की आलोचना करने वाली आवाज़ें बहुत हैं, लेकिन इस लेख का सार बस इतना है कि premature optimization मत करो। यानी, बड़ी कंपनी की तरह behave मत करो। अगर founder खुद काम करेगा, तो भले वह inefficient हो, उसे real-world experience और feedback मिलेगा, और शुरुआत से scalable solution जल्दी न लाकर भी तेज़ feedback मिल सकता है। यह अपनी अलग पहचान बनाने में भी मददगार है। “Do Things That Don’t Scale” को शायद सचमुच शब्दशः याद रखना चाहिए

    • बहुत बार लोग इस डर से कि कहीं service ज़्यादा demand के कारण टूट न जाए, उस stage पर भी ज़रूरत से ज़्यादा scalable systems बना देते हैं जहाँ उसकी बिल्कुल ज़रूरत नहीं होती। लेकिन मुझे लगता है कि vertical scaling (सिर्फ resources बढ़ाने वाला तरीका) को बहुत कम आंका जाता है। मौजूदा monolithic backend में सिर्फ resources जोड़कर भी आप service को समझने के लिए समय खरीद सकते हैं। सबसे बढ़कर, इससे आप फिर से सोचते हैं कि users को आपके product की कौन-सी ‘core value’ सच में पसंद है। और अगर users सच में आपके product से प्यार करते हैं, तो शुरुआत में थोड़ी performance की कमी को वे समझ भी लेते हैं। Twitter के शुरुआती दिनों में “fail whale” अक्सर दिखता था, लेकिन क्योंकि मनचाही functionality काम करती थी, वह विस्फोटक रूप से बढ़ा। शुरुआती stage में सबसे महत्वपूर्ण हैं तेज़ feedback, iteration, और customer satisfaction। scaling से पहले experiment, user communication, और observation आते हैं। जब सही समय महसूस हो, तभी scaling पर सोचें, और वह समय पहले से predict नहीं किया जा सकता। technology सिर्फ एक tool है; आपके पास बेहतरीन violin हो, तब भी पहले ‘अच्छा संगीत’ बनाना ज़रूरी है

    • यह भी याद रखना चाहिए कि हर सफल business के करोड़ों या अरबों users नहीं होते। मैं internal tools पर काम करता हूँ, और हमारे environment का scale पहले से तय है, performance के प्रति खास sensitivity नहीं है, और traffic भी irregular नहीं है। फिर भी हमारी team में एक व्यक्ति था जो सिर्फ कुछ milliseconds बचाने के लिए पूरे codebase को ऐसी language में rewrite करने पर अड़ा हुआ था जिसे वही अकेला जानता था। किसी को परवाह नहीं थी, और उसने जो बनाया उससे सिर्फ maintenance risk बढ़ा। उसके जाने के बाद manager के निर्णय से सब हटा दिया गया; अगर design ज़्यादा simple और धीमा होता, तो बाकी लोगों के लिए handover लेना कहीं आसान होता

    • “premature optimization” और “Do Things That Don’t Scale” में हल्का फर्क है। पहला मानकर चलता है कि scalable version ही ‘optimal’ है, जबकि दूसरा संकेत देता है कि non-scalable तरीका ही शायद सबसे बेहतर हो सकता है। उदाहरण के लिए, CEO का खुद संपर्क संभालना shared inbox से कहीं बेहतर हो सकता है। scalable तरीका (contact form) शुरुआत से optimal नहीं था; वास्तव में वह process quality को कम करता है। scaling अपने आप में बुरी चीज़ नहीं है, लेकिन उसके साथ आने वाली complexity और customer से दूरी बड़ी होती है। यह समझना ज़रूरी है कि context के अनुसार process खराब भी हो सकता है। मेरे हिसाब से यह संदेश “premature process degradation को रोकना” के अधिक करीब है

    • आखिरकार इसे “जो समस्या अभी है ही नहीं, उसे पहले से हल करने की कोशिश मत करो” के रूप में समेटा जा सकता है

    • “बड़ी कंपनी की तरह व्यवहार मत करो” वाली सलाह ईमानदारी से हर आकार की organization पर लागू होती है। consultant के रूप में, मैं startup और छोटे businesses को सिर्फ इसलिए बड़ी organizations के rules और policies अपनाने से रोकने में बहुत समय लगाता हूँ क्योंकि वे एक corporation हैं। ऐसी policies सैकड़ों लोगों वाली scale पर तो ज़रूरी होती हैं, लेकिन छोटी organizations में उल्टा रुकावट बनती हैं। जैसे k8s, nosql, ज़रूरत से ज़्यादा सख्त security policies वगैरह। Netflix का internal culture guide इसे अच्छे से दिखाता है। अगर organization छोटी है, और आपने सही hiring की है, तो असली delegation होना चाहिए ताकि team members खुद निर्णय ले सकें। जब तक problem या risk सच में बड़ा न हो जाए, हर चीज़ को नियमों में बाँधने की ज़रूरत नहीं होती

  • Stripe YC portfolio की सबसे सफल कंपनियों में से एक है, और Stripe ने जिस समस्या को हल किया वह सच में बहुत urgent और pressing थी। जहाँ बहुत-से लोग शायद users के खुद आने का इंतज़ार करते, Stripe aggressive user acquisition के लिए मशहूर था। वह 12 साल पहले की बात थी, और तब किसी ने नहीं सोचा था कि वह इतना बड़ा बन जाएगा। काश तब उसमें निवेश कर पाता

  • बेशक इसमें survivor bias है। लेकिन खुद काम करने और तुरंत automate न करने वाला दौर महत्वपूर्ण है, इस बात से मैं पूरी तरह सहमत हूँ। ऐसा करने से पूरी process या system की अधिक सटीक mental model बनती है, जो सिर्फ slides या documents से संभव नहीं। आजकल की भाषा में कहें तो यह ‘taste’ विकसित करने की प्रक्रिया है। क्या अच्छा है, क्यों अच्छा है, इसका सीधा बोध बनता है, और आप उन decision points पर भी स्पष्ट नज़रिया बना लेते हैं जिन पर बाकी लोग सोचते तक नहीं। आज AI के कारण बहुत-सी जगहें बहुत जल्दी automation की ओर कूदना चाहती हैं, लेकिन www.socratify.com पर भी content अब तक हाथ से बनाया जा रहा है। सब कहते हैं कि AI से बनाना चाहिए, लेकिन हमारा मुख्य उद्देश्य context और quality को ठीक से curate करना है। verification process को बाद में कुछ हद तक automate किया जा सकता है, लेकिन human brain और insight को पूरी तरह replace करना मुश्किल है—यह बात हमने व्यवहार में कई अप्रत्यक्ष तरीकों से महसूस की है

  • YC ने seed funding को बहुत आसान बनाया, और इससे खेल बदल गया। मुझे पूरा भरोसा है कि Paul Graham, Jessica Livingston, और YC team ने पुराने system की समस्या को सही पहचाना और उसे सुधारा। YC के आने से पहले seed funding लगभग असंभव थी। वह असमान थी, और ऐसा लगता था जैसे किसी पुराने bank office में गुस्से में बैठे 8 partners के सामने pitch कर रहे हों। जहाँ श्रेय बनता है, वहाँ देना चाहिए—इस market को उन्होंने ही सुधारा

    • मुझे लगता है यह हिस्सा विवादास्पद है। मान लें कि funding ज़्यादा लोगों के लिए खुल गई, फिर भी YC से पहले हो या बाद में, seeding अब भी कठिन है। फर्क बस यह है कि YC जैसे बड़े players आने से bootstrapping founders की स्थिति और कमजोर हुई है। एक समय के बाद हालात ऐसे हो जाते हैं कि founder वह नहीं बनाता जो वह सच में चाहता है, बल्कि वही topics पकड़ने लगता है जिन्हें YC चुनता है। founders के पास अपनी skill खुद गढ़ने वाली चीज़ें करने के मौके कम हो गए हैं

  • काश OpenAI जैसी बड़ी कंपनियाँ “Do Things That Don’t Scale” को गंभीरता से पढ़तीं और वास्तव में उससे सीखतीं। उनके पास इतना capital था कि वे ज़रूरी data licenses वैध तरीके से खरीद सकती थीं। लेकिन उन्होंने सिर्फ scalable तरीका चुना (scraping, stealing), मानो बड़ी मात्रा में उठा लेने पर या तो किसी को पता नहीं चलेगा, या फिर बहुत देर से आपत्ति आएगी। यानी उन्होंने यह उम्मीद की कि आज के content creators को AI training data के रूप में इस्तेमाल किए जाने का कोई भुगतान न मिले और बात यूँ ही निकल जाए

    • यह scaling का मसला कम और capitalism में स्वाभाविक रूप से मौजूद ‘पैसा बचाने की लालच’ का मसला ज़्यादा लगता है

  • यह लेख वही था जो मैंने पहली बार Hacker News पर देखा था। जब भी यह कभी-कभी फिर सामने आता है, पुरानी यादें ताज़ा हो जाती हैं