बनाने से पहले सोचने योग्य 3 constraints
(jordanlord.co.uk)- प्रोडक्ट आइडिया पर पहले constraints लगाने से exploration space कम होता है और चीज़ें बहुत जटिल या पहचानहीन नतीजों की ओर बहने से बचती हैं
- हर आइडिया को एक पेज के one pager में समेटा जाना चाहिए; अगर वह उसमें नहीं समाता, तो इसका मतलब है कि अभी और research, planning, और prototype की ज़रूरत है
- प्रोडक्ट से अलग भी टिक सकने वाली core tech साथ में बननी चाहिए, ताकि दिशा बदलने पर भी वह संचित asset के रूप में जमा होती रहे
- प्रोडक्ट के केंद्र में एक ऐसा defining constraint होना चाहिए जो यूज़र को लगातार दिखाई दे; यही constraint प्रोडक्ट की feel और पहचान को स्वाभाविक रूप से तय करता है
- अगर तीनों में से एक भी मानदंड पार न हो, तो उसे न बनाने का रवैया scope control और लंबी अवधि के leverage के लिए महत्वपूर्ण है
बनाने से पहले लगाए जाने वाले तीन constraints
- प्रोडक्ट बनाने से पहले constraints तय कर देने से exploration space कम हो जाता है और नतीजा बहुत जटिल या पहचानहीन होने से बचता है
- 10 साल तक कई प्रोडक्ट बनाते हुए यह देखा गया कि बहुत जटिल या पहचानहीन प्रोडक्ट असफलता की ओर ले जाते हैं, और इन्हीं trial and error के बाद बात तीन मानदंडों तक सिमटी
-
एक पेज से आगे गया तो नहीं बनाना
- हर आइडिया को एक one pager में व्यवस्थित होना चाहिए, और यही दस्तावेज़ north star की भूमिका निभाता है
- one pager समझौता-रहित, सटीक, महत्वाकांक्षी, और साथ ही अनावश्यक बातों से मुक्त होना चाहिए
- investor, contributor, team member, दोस्त, परिवार जैसे अलग-अलग लोगों के साथ संवाद में वही एक दस्तावेज़ इस्तेमाल किया जा सकता है
- सहयोग के दौरान टकराव हो तो one pager में जो नहीं है, उस पर लड़ने की ज़रूरत नहीं; अगर वह सच में महत्वपूर्ण है, तो दस्तावेज़ में संशोधन कर उसे शामिल करना चाहिए
- अगर एक पेज भी नहीं भर पा रहे, तो जबरन सामग्री बढ़ाने की जगह इसे इस रूप में देखना चाहिए कि अभी बनाने की तैयारी नहीं हुई है
- ऐसे में पहले research, planning, prototype से गुजरना चाहिए और फिर one pager दोबारा लिखना चाहिए
- और अगर बात एक पेज से आगे निकल जाती है, तो वह बहुत जटिल है, इसलिए उसे नहीं बनाना चाहिए
-
मुख्य तकनीक प्रोडक्ट से अलग होनी चाहिए
- प्रोडक्ट से अलग, उसे सहारा देने वाली core tech बनानी चाहिए
- core tech कोई methodology, technology, tool, या अलग प्रोडक्ट हो सकती है, और मौजूदा प्रोडक्ट के बिना भी टिकनी चाहिए
- यह अलगाव आपको सिर्फ एक प्रोडक्ट में कैद नहीं होने देता और pivot होने पर भी संचय जारी रखता है
- प्रोडक्ट अक्सर दिशा बदलते हैं, लेकिन core tech एक निरंतर और संचयी asset के रूप में बनी रहती है
- लंबी अवधि में ऐसा संचयी प्रयास non-linear लाभ दे सकता है
- उदाहरण के तौर पर Linus Torvalds का git, HashiCorp का HCL, और Google का Kubernetes दिए गए हैं
- इसके लिए बड़े enterprise जैसे resources ज़रूरी नहीं; codebase से अलग की गई library या लगातार निखारी जाने वाली methodology भी चल सकती है
- core tech प्रोडक्ट की दिशा से स्वतंत्र होनी चाहिए, लेकिन व्यक्ति या कंपनी के long-term vision के साथ मेल खाना चाहिए
- अगर कोई आइडिया core tech बनने की संभावना ही नहीं देता, तो उसमें पर्याप्त leverage नहीं है
-
एक निर्णायक constraint प्रोडक्ट को परिभाषित करना चाहिए
- प्रोडक्ट के केंद्र में ऐसा defining constraint होना चाहिए जो यूज़र को हमेशा दिखाई दे
- यह constraint ऐसा तत्व होना चाहिए जिससे यूज़र बार-बार रूबरू हो और interact करे; यही प्रोडक्ट की पहचान बनाता है
- अच्छा constraint प्रोडक्ट की feel बनाता है और पूरे user experience में घुल जाता है
- Minecraft में सब कुछ blocks से बना है, और IKEA की पहचान flat-pack self-assembly furniture है—यानी पहचान constraint से सीधे प्रकट होती है
- ऐसे constraint निर्णय-क्षेत्र को घटाते हैं, scope सीमित करते हैं, और वास्तव में महत्वपूर्ण समस्याओं पर ध्यान केंद्रित करने में मदद करते हैं
- अगर constraint चुना ही नहीं गया, या गलत चुना गया, तो प्रोडक्ट हर चीज़ करने की कोशिश करने वाले फूले हुए सिस्टम में बदल जाता है
- अच्छी तरह डिज़ाइन किया गया constraint हो तो प्रोडक्ट डिज़ाइन उसी से स्वाभाविक रूप से निकलकर आता है
- यह constraint भी one pager के सबसे सामने होना चाहिए
समापन मानदंड
- तीनों constraints में से एक भी पार न हो, तो उसे नहीं बनाना चाहिए
2 टिप्पणियां
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 ऐसे होते हैं जो ख़ुद झेलने पर ही भीतर बैठते हैं
one-pager का idea वाक़ई बहुत अच्छा है
अगर आप constraints को सिर्फ़ एक page में भी साफ़-साफ़ लिखने का समय नहीं निकाल पाते, तो आगे बढ़ते हुए भाग-दौड़ में आप उन constraints को बहुत देर से खोजेंगे
और तब वह bug नहीं रहेगा, बल्कि सीधे हम गलत चीज़ बना रहे थे जैसी स्तर की खामी होगी
मैं इसे data से साबित नहीं कर सकता, लेकिन मेरे अनुभव में वे projects कहीं ज़्यादा सफल होते हैं जिनमें सब लोग अवधारणात्मक रूप से एक ही page पर हों
भले ही वह सिर्फ़ एक high-level single-page document हो, अगर उससे यह साफ़ हो जाए कि हम क्या कर रहे हैं और क्या नहीं कर रहे, तो उसका असर बड़ा होता है
इसके उलट, impulsive तरीक़े से धकेले गए projects में अंततः वे लोग भी निराश हो जाते हैं जिन्होंने अपनी सोच कभी साफ़ शब्दों में कही ही नहीं थी
काश लेखक ऐसा कोई पूरा example दिखाता जहाँ constraints सचमुच काम कर रहे हों
खासकर तीसरा point व्यवहार में कैसा दिखता है, इसका ठीक अंदाज़ा नहीं बनता
आख़िरकार लगता है कि ख़ुद ही कुछ सोचकर निकालना पड़ेगा
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 करने लगा
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 में भी काफ़ी उपयोगी हो सकते हैं
मैं भी इसे तुरंत आज़माने वाला हूँ
शायद यह बहुत ज़्यादा सरल हो, लेकिन space और flow के नज़रिए से देखो तो यह और दिलचस्प हो जाता है
लोगों का flow, रोशनी का flow, खाने का flow, transitions जैसी चीज़ों के बारे में सोचा जा सकता है, और यह काफ़ी मज़ेदार है
शायद यह मेरी वैल्यूज़ और पसंद से मेल खाता है, इसलिए कंटेंट अच्छा लग रहा है.
(असल में सिर्फ़ नज़र बनाए रखने के लिए)