बनाने से पहले लगाने वाली तीन पाबंदियां

• प्रोडक्ट आइडिया में पहले constraints तय करने चाहिए, ताकि exploration space कम हो और नतीजा बहुत जटिल या पहचानहीन प्रोडक्ट बनने से बचे
• हर आइडिया को एक पेज के one pager में समेटा जाना चाहिए; अगर वह उसमें नहीं समाता, तो इसका मतलब है कि अभी और research, planning, और prototyping की जरूरत है
• प्रोडक्ट से अलग भी टिक सकने वाली core tech साथ में बनानी चाहिए, ताकि दिशा बदलने पर भी वह संचित एसेट के रूप में बढ़ती रहे
• प्रोडक्ट के केंद्र में ऐसा एक defining constraint होना चाहिए जो यूज़र को लगातार दिखाई दे, और यही पाबंदी प्रोडक्ट की feel और पहचान को स्वाभाविक रूप से तय करे
• अगर तीन में से एक भी कसौटी पार नहीं होती, तो उसे न बनाने का रवैया scope control और लंबे समय की leverage हासिल करने के लिए महत्वपूर्ण है

---

बनाने से पहले लगाने वाली तीन पाबंदियां

• प्रोडक्ट बनाने से पहले constraints तय कर देने से exploration space कम हो जाता है और प्रोडक्ट बहुत जटिल या पहचानहीन दिशा में जाने से बचता है
• 10 साल तक कई प्रोडक्ट बनाते हुए यह देखा गया कि बहुत जटिल या पहचानहीन प्रोडक्ट अक्सर असफल होते हैं, और इन्हीं कोशिशों-गलतियों के बाद बात तीन मानदंडों तक सिमटी

• एक पेज से आगे गया, तो नहीं बनाएंगे

  • हर आइडिया को one pager में व्यवस्थित करना चाहिए, और यही दस्तावेज़ north star की भूमिका निभाता है
  • one pager समझौता-रहित, सटीक, महत्वाकांक्षी और अनावश्यक बातों से मुक्त होना चाहिए
  • निवेशकों, contributors, टीम members, दोस्तों और परिवार जैसे अलग-अलग लोगों से बातचीत में भी यही एक दस्तावेज़ इस्तेमाल किया जा सकता है
  • collaboration के दौरान टकराव हो, तो one pager में जो नहीं है उस पर लड़ने की जरूरत नहीं; अगर वह सच में महत्वपूर्ण है, तो दस्तावेज़ को बदलकर उसमें शामिल करना चाहिए
  • अगर एक पेज भी नहीं भर पा रहे हैं, तो जबरन सामग्री बढ़ाने के बजाय इसे इस रूप में देखना चाहिए कि अभी बनाने की तैयारी पूरी नहीं है
  • उस स्थिति में पहले research, planning, prototyping करने के बाद one pager फिर से लिखना चाहिए
  • और अगर बात एक पेज से आगे चली जाती है, तो वह बहुत जटिल है, इसलिए उसे नहीं बनाना चाहिए

• मुख्य तकनीक प्रोडक्ट से अलग होनी चाहिए

  • प्रोडक्ट से अलग, उसे सहारा देने वाली core tech भी बनानी चाहिए
  • core tech कोई methodology, technology, tool, या अलग प्रोडक्ट हो सकती है, और उसे मौजूदा प्रोडक्ट के बिना भी टिकना चाहिए
  • यह अलगाव चीजों को एक ही प्रोडक्ट में फंसे रहने से बचाता है और pivot होने पर भी accumulation जारी रखता है
  • प्रोडक्ट अक्सर दिशा बदलते हैं, लेकिन core tech एक स्थायी और संचयी एसेट के रूप में बची रहती है
  • लंबे समय में ऐसी cumulative मेहनत non-linear लाभ दे सकती है
  • उदाहरण के तौर पर Linus Torvalds का git, HashiCorp का HCL, और Google का Kubernetes दिया गया है
  • इसके लिए बड़े enterprise जैसी resources जरूरी नहीं; codebase से अलग की गई library या लगातार निखारी जाने वाली methodology भी हो सकती है
  • core tech प्रोडक्ट की दिशा से स्वतंत्र होनी चाहिए, लेकिन व्यक्ति या कंपनी की long-term vision से मेल खानी चाहिए
  • अगर कोई आइडिया core tech बनने की संभावना ही नहीं देता, तो उसमें पर्याप्त leverage नहीं है

• एक निर्णायक पाबंदी ही प्रोडक्ट को परिभाषित करे

  • प्रोडक्ट के केंद्र में ऐसा defining constraint होना चाहिए जो यूज़र को हमेशा दिखाई दे
  • यह पाबंदी ऐसी होनी चाहिए जिससे यूज़र बार-बार रूबरू हो और interaction करे, और वही प्रोडक्ट की पहचान बनाए
  • अच्छी पाबंदी प्रोडक्ट की feel बनाती है और पूरे user experience में समा जाती है
  • Minecraft सिर्फ ब्लॉक्स से बना है, और IKEA flat-pack self-assembly furniture है — यानी पहचान सीधे उस पाबंदी से सामने आती है
  • ऐसी पाबंदियां decision space कम करती हैं, scope सीमित करती हैं, और वास्तव में महत्वपूर्ण समस्याओं पर फोकस करने में मदद करती हैं
  • अगर पाबंदी चुनी ही न जाए या गलत चुनी जाए, तो प्रोडक्ट हर चीज़ करने की कोशिश में फूला हुआ बन जाता है
  • अगर पाबंदी अच्छी तरह डिज़ाइन की गई हो, तो प्रोडक्ट डिज़ाइन उसी से स्वाभाविक रूप से निकलता है
  • यह पाबंदी भी one pager के सबसे सामने रखी जानी चाहिए

समापन मानदंड

• तीन पाबंदियों में से एक भी पूरी न हो, तो उसे नहीं बनाना चाहिए

[GN⁺]

Hacker News की राय

• मैं इन्हें product primitives कहता रहा हूँ
  जैसे Notion के blocks, Telegram के messages/conversations, Figma के frames/layers, Twitter के tweets, Excel के cells/sheets, Photoshop के tools/layers, और CLI के commands

  मेरा मानना है कि अच्छा product design तब निकलता है जब ऐसे primitives की संख्या बहुत कम हो
  खराब products या तो यह नहीं जानते कि उनके primitives क्या हैं, या इतने ज़्यादा रखते हैं कि product के अंदर हर element अलग-अलग दिशा में बिखरा हुआ लगता है
  तब users को कई अलग top-level concepts सीखने पड़ते हैं, जिससे वे उलझ जाते हैं, हिचकिचाते हैं, और उन्हें सिखाना भी मुश्किल हो जाता है
  आदर्श रूप में, एक-दो-तीन core primitives काफ़ी होने चाहिए

  किसी app की जटिलता और शक्ति इस बात से आती है कि वह composable और गहराई वाले primitives चुनता है
  Notion block, Excel cell, CLI command, Minecraft block की तरह छोटे units से बहुत कुछ किया जा सके

  • यह Alexandrian Pattern Language जैसा दिखता है, लेकिन वास्तव में pattern से ज़्यादा Alexander के बाद के Centers विचार के क़रीब लगता है

    मेरी समझ में software industry ने उनके pattern ideas को बड़े पैमाने पर अपनाया, लेकिन अपने बाद के वर्षों में Alexander ने system की अंतिम बुनियादी इकाई को Center माना
    जैसे रोशन आँगन, खिड़की के पास बैठने की जगह, fireplace — ऐसी चीज़ें जो स्थानीय उपयोगिता और एकजुटता का केंद्र बनती हैं
    एक मज़बूत center स्वाभाविक रूप से composable होता है, स्थानीय तनाव हल करता है, छोटे centers से बना होता है, और बड़े centers बनाने के लिए building block की तरह काम करता है

    products अक्सर बुरे इरादे से नहीं, बल्कि इसी वजह से उलझे हुए और फूले हुए बन जाते हैं
    user requirements को अनुभव के आधार पर काफ़ी हद तक खोजा जा सकता है, लेकिन उन requirements को सुंदर ढंग से समाहित करने वाली असली केंद्रीय संरचना बहुत सूक्ष्म होती है और उसे ढूँढना कठिन होता है
    इसलिए सामने आने वाली हर ज़रूरत के लिए एक अलग, सख्त interface जोड़ देना हमेशा सबसे आसान रास्ता बन जाता है
    ऐसी ज़रूरतों को स्वाभाविक रूप से समेटने वाला core primitive ढूँढने के लिए गहरे architectural काम की ज़रूरत होती है

    शायद इसी वजह से हम बार-बार faster horses ही बनाते रहते हैं

  • पहले मैं इसे concept count कहता था
    आम तौर पर किसी product को बनाने वाले core concepts की संख्या को न्यूनतम रखना अच्छा होता है, और इसे product के nouns and verbs भी कहा जाता था

  • यह दर्शन थोड़ा ज़रूरत से ज़्यादा सरल लगता है
    Tana में primitives लगभग सिर्फ bullets और supertags ही हैं, फिर भी इतना जटिल है कि बेहद साधारण काम करने के लिए भी घंटों का tutorial देखना पड़ता है
    इसके उलट Google Maps में primitives काफ़ी ज़्यादा हैं, फिर भी 90% use cases में UX काफ़ी मज़बूत लगता है

  • programming languages को देखते समय भी मैं ऐसा ही पैमाना इस्तेमाल करता था
    कोई language आकार में बड़ी हो सकती है, लेकिन अगर वह conceptually छोटी है, तो एक बार सीखने के बाद बाकी चीज़ें अनुभव के साथ आती जाती हैं; जबकि conceptually बड़ी language में entry barrier बहुत ऊँचा लगता था
    इसका सबसे तेज़ एहसास मुझे perl में हुआ था

  • छोटा होना चाहिए, लेकिन बहुत ज़्यादा छोटा भी नहीं
    उदाहरण के लिए shell script (POSIX shell, bash) ने scripting को भी command के रूप में model किया ताकि कोई नया concept न लाना पड़े, लेकिन नतीजा, जैसा सब जानते हैं, एक गर्म, धीमा और अव्यवस्थित मिश्रण बना

• मुझे तीनों constraints पसंद हैं, लेकिन 1-page document project की complexity के अनुसार बदलना चाहिए
  छोटे से मध्यम आकार के project के लिए एक page काफ़ी होगा, लेकिन Mars flight-control software के लिए implementation शुरू करने से पहले शायद ऐसा one-pager चाहिए होगा जो कई sub-specs से hyperlink किया गया हो

  technology और product को अलग रखना सचमुच समझदारी है
  उदाहरण के लिए Skype में backend का P2P communication technology हिस्सा था और frontend का calling application हिस्सा, और समझदार founders ने इन दोनों को अलग-अलग companies में रखा था
  इसलिए frontend app Skype के Microsoft को बिक जाने के बाद भी, core IP और P2P backend technology वाली company को अलग से अपने पास रखा जा सका

  एक ही constraint को केंद्र में रखना समझ में आता है, लेकिन मुझे कभी-कभी कई constraints या priorities की list रखना बेहतर लगता है
  अगर top-level principle को monetize करना मुश्किल हो, तो उसे अटल सिद्धांत की तरह पकड़ लेना business को दिवालियेपन की ओर धकेल सकता है
  अगर team के भीतर किसी ऐसे direction में बड़ा pivot करने का idea हो जिसे बेचना कहीं आसान हो, तो वह मूल योजना से काफ़ी अलग होते हुए भी जीवित रहने का रास्ता खोल सकता है
  Twitter भी मूल रूप से कुछ और करने निकला था, और public status update एक side project से निकला था

• इस लेख ने उस तरीके को बहुत अच्छी तरह समेटा है जिसमें मैं पहले अपने research mentor के साथ business बनाता था

  हम पहले पीछे की दो चीज़ें तय करते थे, यानी core technology और constraints
  core technology एक ऐसा sampler था जो sparse data के लिए arbitrary hierarchical Bayesian graph model को संभव बनाता था, और constraint यह था कि computation CPU-bound स्थिति में संभव होनी चाहिए
  सबसे ज़्यादा समय यह समझने में लगा कि अंतिम product को underlying technology से अलग होना चाहिए

  शुरू करने से पहले भी कई लोगों से ऐसा ही advice सुना था, लेकिन कुछ lessons ऐसे होते हैं जो ख़ुद झेलने पर ही भीतर बैठते हैं

  • tenants नहीं, tenets सही शब्द है

• one-pager का idea वाक़ई बहुत अच्छा है
  अगर आप constraints को सिर्फ़ एक page में भी साफ़-साफ़ लिखने का समय नहीं निकाल पाते, तो आगे बढ़ते हुए भाग-दौड़ में आप उन constraints को बहुत देर से खोजेंगे
  और तब वह bug नहीं रहेगा, बल्कि सीधे हम गलत चीज़ बना रहे थे जैसी स्तर की खामी होगी

  मैं इसे data से साबित नहीं कर सकता, लेकिन मेरे अनुभव में वे projects कहीं ज़्यादा सफल होते हैं जिनमें सब लोग अवधारणात्मक रूप से एक ही page पर हों
  भले ही वह सिर्फ़ एक high-level single-page document हो, अगर उससे यह साफ़ हो जाए कि हम क्या कर रहे हैं और क्या नहीं कर रहे, तो उसका असर बड़ा होता है
  इसके उलट, impulsive तरीक़े से धकेले गए projects में अंततः वे लोग भी निराश हो जाते हैं जिन्होंने अपनी सोच कभी साफ़ शब्दों में कही ही नहीं थी

• काश लेखक ऐसा कोई पूरा example दिखाता जहाँ constraints सचमुच काम कर रहे हों
  खासकर तीसरा point व्यवहार में कैसा दिखता है, इसका ठीक अंदाज़ा नहीं बनता

  • थोड़ा गढ़े हुए hook जैसा भी लगता है
    आख़िरकार लगता है कि ख़ुद ही कुछ सोचकर निकालना पड़ेगा
    Linux का everything's a file जैसा idea मुझे अच्छा लगता है
    ऐसे एक मज़बूत concept के सहारे भी काफ़ी दूर तक जाया जा सकता है

• constraints को कम आँका जाता है

  सबसे elegant solutions आम तौर पर अनंत freedom से नहीं, बल्कि स्पष्ट constraints के भीतर बनाने से निकलते हैं
  और यह point 1 से भी जुड़ता है
  one-pager लिखने की प्रक्रिया ख़ुद उन constraints को परिभाषित करने में मदद करती है

• Google के पास Kubernetes होना, सबसे बढ़कर, शायद competitors को निष्क्रिय करने के मक़सद से था

• अगर solo SaaS हो, तो मैं एक और constraint जोड़ूँगा: क्या इस हफ़्ते एक beta user मिल सकता है
  time, scope, और technology one-pager पर ठीक दिखें, फिर भी अगर कोई आ ही न रहा हो तो project वैसे ही मर जाता है
  इसलिए शुरू से distribution constraint जोड़ देने पर मैं features में गहराई तक जाने से पहले demand side validate करने लगा

  • सख़्ती से कहें तो वह constraint से ज़्यादा goal या metric जैसा लगता है

• core technology को product से अलग किया जा सके — यह बात कहीं बहुत जल्दी abstraction करने और design patterns का ज़रूरत से ज़्यादा इस्तेमाल करने की ओर न ले जाए

  बेशक concerns की separation, business domain layer को persistence/network/UI जैसी चीज़ों से साफ़-साफ़ अलग रखना सही है
  फिर भी domain layer आख़िरकार product से बहुत मज़बूती से बँधी रहेगी
  मुझे नहीं लगता कि इससे बचने का कोई तरीका है

  • शायद मतलब यह है कि खरीदारों को आकर्षित करने वाला एक ऊपरी चेहरा होता है, और जो चीज़ अंदर असल में चल रही है वह खरीदार की दिलचस्पी का विषय नहीं होती

    इन दो layers के बीच interface का काम करने वाले कुछ concepts हो सकते हैं, लेकिन भीतर की चीज़ें कैसे evolve करती हैं, यह बाहर की product layer से अलग रहना चाहिए — शायद बात यह है

• मैं अभी kitchen remodeling का design कर रहा हूँ, और मुझे लग रहा है कि ये तीन constraints software से आगे, ज़्यादा सामान्य design work में भी काफ़ी उपयोगी हो सकते हैं

  मैं भी इसे तुरंत आज़माने वाला हूँ

  • लोगों की जगह, storage की जगह, work की जगह — कुछ everything's a space जैसा सोचा जा सकता है
    शायद यह बहुत ज़्यादा सरल हो, लेकिन space और flow के नज़रिए से देखो तो यह और दिलचस्प हो जाता है
    लोगों का flow, रोशनी का flow, खाने का flow, transitions जैसी चीज़ों के बारे में सोचा जा सकता है, और यह काफ़ी मज़ेदार है