खोया हुआ भरोसा (Lost confidence)

• RICE जैसे confidence-based prioritization frameworks ज़्यादातर शोर हैं, और हमें ऐसा निर्णय लेने का तरीका चाहिए जो अज्ञात भविष्य को जानने का दिखावा न करे
• confidence score आमतौर पर छोटे (small) प्रोजेक्ट्स पर ऊँचा और बड़े (large) प्रोजेक्ट्स पर नीचा दिया जाता है, इसलिए यह व्यवस्थित रूप से बड़े मूल्य वाले प्रोजेक्ट्स को पीछे धकेलकर प्राथमिकता को विकृत करता है
• confidence score की परिभाषा अस्पष्ट है, सत्यापन डेटा भी कम है, और प्रोजेक्ट लगभग हमेशा देर से पूरे होते हैं और उम्मीद से कम impact देते हैं, इसलिए यह विश्वसनीय नहीं है
• समाधान यह है कि probability नहीं बल्कि uncertainty के क्षेत्र में पूछा जाए: "किसी भी probability distribution में समझदारी भरा कदम क्या होगा?"
• confidence की जगह हमेशा सच रहने वाली बातें, customer impact, option बनाए रखना, और asymmetric bets जैसी तकनीकों से प्राथमिकता तय करना ज़्यादा महत्वपूर्ण है

---

confidence का खेल (Confidence games)

• कई prioritization frameworks अपने score में इस भरोसे को शामिल करते हैं कि अनुमानित effort से अनुमानित impact हासिल किया जा सकता है
  • समान value और समान effort वाले दो प्रोजेक्ट्स में, जिस पर execution confidence ज़्यादा हो उसे चुनना अपने-आप में तर्कसंगत है
  • लेकिन व्यवहार में इसका उपयोग अक्सर "1) scoring करो → 2) साफ विजेता को चलाओ → 3) tie हो तो ज़्यादा confidence वाला चुनो" इस तरह नहीं होता
• RICE पहले ही चरण के score calculation में confidence को सीधे गुणा कर देता है
  • RICE formula: Score = (Reach × Impact × Confidence) / Effort
  • RPS formula: Score = Reach × Potential × Solution Confidence
• यह तरीका दो अलग-अलग scenarios को एक ही स्तर पर रखकर झूठी समानता पैदा करता है
  • छोटा लेकिन निश्चित रूप से डिलीवर किया जा सकने वाला incremental feature
  • बड़ा feature जिसका impact ऊँचा है लेकिन risk भी है
• आमतौर पर छोटे प्रोजेक्ट्स में confidence ऊँचा और बड़े प्रोजेक्ट्स में कम होता है, इसलिए confidence को गुणा करने से आप अधिकतम value देने की दिशा से व्यवस्थित रूप से दूर चले जाते हैं
  • Agile movement की मूल प्रेरणाओं में से एक यही समझ थी कि "बड़े प्रोजेक्ट्स की सफलता पर confidence हमेशा कम होना चाहिए"
• confidence score पर भरोसा न करने के कारण
  • परिभाषा अस्पष्ट है: "30%" का मतलब क्या है, यह साफ नहीं। आदर्श रूप में हर प्रोजेक्ट का confidence score रिकॉर्ड करके बाद में वास्तविक नतीजों से मिलान कर accuracy मापनी चाहिए, लेकिन व्यवहार में ऐसा नहीं होता
  • अगर साल में कुछ ही बड़े features ship होते हैं, तो बाद में validate करने के लिए डेटा ही पर्याप्त नहीं होता
  • प्रोजेक्ट लगभग हमेशा देर से पूरे होते हैं, और impact उम्मीद से कम व धीमा होता है। 9 महीने और 6 टीमों वाला प्रोजेक्ट भी किसी न किसी "काफ़ी confidence" के साथ ही शुरू हुआ था
• Hofstadter's Law उद्धरण: "Hofstadter's Law को ध्यान में रखने पर भी चीज़ें हमेशा उम्मीद से ज़्यादा समय लेती हैं"
• अनुभवी PM से पूछिए, "कौन-सा feature था जिसके बारे में पूरा यक़ीन था कि लोग पसंद करेंगे, लेकिन ऐसा नहीं हुआ?" — हर किसी के पास कई उदाहरण होंगे
  • ग्राहक बातचीत, स्पष्ट requests, खरीदने के वादे जैसे सबूत होने पर भी, feature बन जाने के बाद वादा करने वाले लोग भी अक्सर उसका उपयोग नहीं करते
  • prediction बेहतर करने की एक तकनीक: ग्राहक से कहिए कि वह अपने असली workflow में step-by-step बताए कि वह इसे कैसे इस्तेमाल करेगा। जैसे-जैसे वह चरणों से गुज़रेगा, अक्सर खुद समझ जाएगा: "इसे करने के लिए तो मुझे अपना code फिर से लिखना पड़ेगा, इसलिए मैं नहीं करूँगा"
• content creators के साथ भी यही होता है: बिना उम्मीद के जल्दी में प्रकाशित किया गया लेख साल का सबसे ज़्यादा पढ़ा/सराहा गया piece बन सकता है, जबकि घंटों की मेहनत वाला masterpiece अनदेखा रह जाता है
  • "confidence × outcome (पसंद किया गया/अनदेखा किया गया)" वाली 2×2 तालिका के चारों खाने उदाहरणों से भरे पड़े हैं

confidence और risk की जगह क्या उपयोग करें (What to use in place of confidence and risk)

• जवाब probability नहीं बल्कि uncertainty के क्षेत्र में है
  • probability यह मानकर चलती है कि distribution ज्ञात है। किसी निष्पक्ष सिक्के को 100 बार उछालने पर 40 से 60 बार heads आना बहुत संभावित है
  • startup की दुनिया में लगभग सब कुछ इससे अलग है। सफलता, strategy, और features या तो अभूतपूर्व होते हैं, या बहुत जटिल, या inputs इतने सटीक नहीं होते कि अर्थपूर्ण probability दी जा सके
  • अर्थशास्त्री Frank Knight की 1921 की पुस्तक से आया "Knightian Uncertainty" का विचार
  • Bayesian तरीकों को भी numerical priors और conditional probabilities चाहिए, जबकि यहाँ दोनों न तो ज्ञात हैं और न ठीक से परिभाषित किए जा सकते हैं
• uncertainty के क्षेत्र का सवाल है: "probability distribution चाहे जो हो, समझदारी भरा कदम क्या है?"

• हमेशा सच रहने वाली बातें (True always)

  • उन बातों पर ध्यान दीजिए जो हर हाल में सच रहती हैं — Bezos का long-term constants सिद्धांत
    • उपयोगकर्ता सामान्य रूप से तेज़ और responsive software पसंद करते हैं। वे background sync, instant interaction, और हर device पर काम करने वाली चीज़ों को महत्व देते हैं
    • सबसे खराब स्थिति में भी, अगर किसी को speed की परवाह कम हो, तब भी वह speed को नकारात्मक नहीं मानता। सबसे अच्छी स्थिति में Notion, Figma, Miro, Gmail, और Google Docs की तरह performance मुख्य differentiator बन जाती है
  • हर feature की universal appeal नहीं होती। बारीक numerical breakdown के बजाय उन features की पहचान करें जिन्हें लगभग सभी ग्राहक मूल्यवान मानेंगे या कम-से-कम पसंद करेंगे
    • कभी-कभी यह इसलिए निश्चित होता है क्योंकि वह अनिवार्य है। SOC 2 compliance जैसे enterprise requirements भले रोमांचक न हों, लेकिन enterprise sale के लिए निश्चित रूप से मूल्यवान होते हैं
    • इस तरह की निश्चितता differentiation की कमी की भरपाई करती है
  • लेकिन सबसे innovative और differentiating ideas शायद ही कभी "पूरी तरह निश्चित" श्रेणी में आते हैं
    • जो चीज़ निश्चित है वह मूल्यवान हो सकती है, पर रणनीतिक differentiator बनना मुश्किल है
    • एक शानदार product को विश्वसनीय सुधारों और नवाचारपूर्ण छलांगों — दोनों की ज़रूरत होती है

• तेज़ खोज, तेज़ रिकवरी (Quick discovery, quick recovery)

  • build करने से पहले संभावित ग्राहकों का व्यवस्थित interview लेकर ideas validate करने की वकालत लंबे समय से की जाती रही है, लेकिन यह भी "confidence trap" में फँस सकता है
    • बनाए बिना आप कभी पक्के तौर पर नहीं जान सकते
    • फिर भी, build से पहले invalidate करना संभव है, और इससे महीनों या वर्षों की बर्बादी रोकी जा सकती है, इसलिए यह अब भी सही शुरुआत है
  • सामान्य समाधान है SLC बनाना, जो MVP का उन्नत रूप है — इतना simple लेकिन complete product कि उससे वास्तविक feedback मिले, prediction नहीं बल्कि अनुभव
    • एक मौजूदा product को पक्की जीत और innovative bets के बीच संतुलित portfolio बनाए रखना चाहिए, और दोनों के लिए अलग validation methods लगाने चाहिए
  • dummy features का उदाहरण: ऐसा बटन जिसे क्लिक करने पर संदेश आए, "यह feature अभी उपलब्ध नहीं है। बताइए आप इसे कैसे इस्तेमाल करेंगे"
    • यह रुचि रखने वाले उपयोगकर्ताओं की संख्या और संभावित interview candidates का व्यवहार-आधारित वास्तविक signal देता है
    • survey की तुलना में 100 गुना बेहतर signal। survey में लोग आसानी से "हाँ" कह देते हैं, लेकिन बटन क्लिक जैसा व्यवहार वास्तविक रुचि माँगता है। देखा गया व्यवहार, कही गई मंशा से अधिक महत्वपूर्ण है

• confidence की जगह customer impact पर ध्यान दें (Focus instead on customer impact)

  • confidence को impact से बदलें। impact को दो तरीकों से परिभाषित किया गया है
    • Majority rule: जिन features का उपयोग अधिकांश user नियमित रूप से करते हैं, वे साफ तौर पर महत्वपूर्ण हैं और adoption व retention के मुख्य कारण होने की संभावना रखते हैं
    • Passionate advocates: ऐसे features जो थोड़े लोगों के बीच गहरी दीवानगी पैदा करते हैं। वे लोग जो कहते हैं, "मैंने सिर्फ इसी वजह से खरीदा।" भले यह universal न हो, लेकिन किसी खास segment में गहरी loyalty बनाता है — magnificent delighters
  • जब उपयोगकर्ता product के किसी खास हिस्से से सचमुच प्यार करते हैं, तो वे बाकी कमियों को सह लेते हैं
    • iPod के आकर्षण की वजह से अरबों लोगों ने iTunes जैसे बेहद खराब software को झेला
    • खूबसूरती से डिज़ाइन किया गया software features की कमी या platform limitations के बावजूद केवल design experience के दम पर अपनाया जा सकता है
  • high-impact features की मात्रात्मक परिभाषा
    • (1) ग्राहकों के कम-से-कम 51% नियमित रूप से उसका उपयोग करें, या
    • (2) ग्राहकों के कम-से-कम 15% उसे अपने चुनने या बने रहने के शीर्ष 3 कारणों में गिनें
    • यह ऊँची कसौटी है, लेकिन innovative और risky features के लिए कसौटी ऊँची होनी ही चाहिए; reward इतना बड़ा होना चाहिए कि risk जायज़ लगे

• leverage में निवेश करें (Invest in leverage)

  • कुछ ऐसे क्षेत्र होते हैं जहाँ छोटा incremental change बहुत बड़ा परिणाम दे सकता है
  • गणितीय और संरचनात्मक रूप से लगभग हमेशा सही ठहरने वाले leverage areas मौजूद हैं
    • (संबंधित पुस्तक-प्रचार वाला भाग विज्ञापन होने के कारण छोड़ा गया है)

• optionality को अधिकतम करें (Maximize optionality)

  • अगर भविष्य ज्ञात नहीं है, तो ऐसे विकल्प चुनिए जो जब आप वहाँ पहुँचें तब आपके पास उपलब्ध विकल्पों की संख्या को अधिकतम करें
    • यह सिर्फ flexibility या lock-in से बचने की बात नहीं, बल्कि इस तरह design करने की बात है कि भविष्य में जो भी आए, आप उससे निपट सकें
  • उदाहरण
    • कम लागत बनाए रखना → profitability सुरक्षित रखते हुए pricing, packaging, और future resilience के कई experiments की गुंजाइश
    • अच्छी तरह validated और सक्रिय रूप से विकसित हो रही cross-platform UI libraries/frameworks चुनना → platforms और devices के विकास के साथ तालमेल
    • plugin architecture → आप और community ऐसी चीज़ें बना सकें जिनकी आज कल्पना भी नहीं है
    • API-first architecture → team isolation, frontend/backend separation, और customer integrations को सक्षम करना
    • vendor service wrappers → अस्थिर, महँगे, या पीछे रह गए vendors को बदलने की क्षमता
  • future options बनाए रखना आज अतिरिक्त काम माँगता है
    • vendor-wrapping API आज के दिन तुरंत value नहीं जोड़ती
    • यह स्थिरता और predictability को महत्व देने वाली mature companies के लिए समझदारी हो सकती है, लेकिन शुरुआती चरण में जहाँ incumbent को speed से हराना हो, वहाँ यह गलत चुनाव हो सकता है
  • पूरी company की optionality अधिकतम करने का सबसे अच्छा तरीका है एक बेहतरीन company बनाना
    • स्वस्थ और टिकाऊ growth, बड़ा और बढ़ता gross margin, customers का प्यार जो retention, upgrades, और word of mouth से साबित हो, और employees का प्यार जो long tenure और career growth से दिखे
    • एक बेहतरीन company के पास acquisition, independence, fundraising, IPO, succession जैसे कई विकल्प होते हैं

• bets का portfolio (Portfolio of bets)

  • portfolio volatility कम करता है, लेकिन maximum upside भी कम कर देता है
    • इसमें पूरी तरह हार जाने की संभावना कम होती है, इसलिए downside बहुत बुरा नहीं दिखता, लेकिन क्योंकि जीत को हार की भरपाई करनी होती है, कभी-कभार की बड़ी सफलता भी single bet जितनी बड़ी नहीं बनती
    • उदाहरण: अगर IPO के समय Amazon खरीदकर हमेशा पकड़े रहते, तो शानदार होता; लेकिन उसी साल किसी और IPO पर यही रणनीति लगाते तो शायद $0 हो जाता। portfolio आपको शून्य तक नहीं ले जाता, पर अधिकतम growth सबसे अच्छे single stock से बहुत कम होती है
  • गणितीय साइडबार: portfolio distribution से स्वतंत्र रूप से काम क्यों करता है — क्योंकि Central Limit Theorem
    • अगर एक स्थिर लेकिन अज्ञात distribution वाली population से N samples बार-बार लिए जाएँ और sample means का histogram बनाया जाए, तो वह distribution Gaussian (normal distribution) की ओर अभिसरित होती है; mean population mean के पास और variance population variance के 1/n के अनुसार होता है
    • Lindeberg–Lévy CLT दिखाती है कि sample अलग-अलग distributions से आए हों तब भी यह लागू हो सकता है, बशर्ते independence, finite variance, और किसी एक variable का प्रभुत्व न हो
    • लेकिन startup environments में आम distributions के लिए ये शर्तें टूट सकती हैं, जैसे कुछ Power Law distributions में variance infinite होता है
  • portfolio तब काम करता है जब आप पूर्वानुमेय लेकिन औसत परिणाम चाहते हैं, और तब नहीं जब आप outliers चाहते हैं
    • venture/angel portfolios का उदाहरण: 65% में नुकसान होता है, और केवल लगभग 10% ही ऐसा return देते हैं जो risk और illiquidity को justify कर सके
    • अगर लक्ष्य outlier है, तो portfolio नहीं बल्कि all-in investment की ज़रूरत होती है, क्योंकि startup returns का distribution Lindeberg की शर्तों को तोड़ने वाला Power Law होता है
  • निष्कर्ष: अगर प्राथमिकता का उद्देश्य market differentiation और growth engine खोजना है, तो portfolio गलत tool है। यह छोटे, भरोसेमंद, incremental results के लिए ठीक है, और उस स्थिति में confidence पर बहस करने की ज़रूरत ही नहीं होती

• asymmetric bets (Asymmetric bets)

  • यह portfolio का स्वाभाविक उल्टा है। अगर portfolio reliability के लिए है, तो asymmetric bets outliers के लिए हैं
    • यहाँ लक्ष्य bet की सफलता/विफलता की भविष्यवाणी करना नहीं, बल्कि ऐसे bets लेना है जिनका downside सीमित और मापने योग्य हो और upside बड़ा हो
  • अगर सबसे खराब स्थिति "2 महीने का नुकसान" है और सबसे अच्छी स्थिति "पूर्ण differentiation" है, तो probability लगभग अर्थहीन हो जाती है
    • इतना काफ़ी है कि downside survivable हो, और upside इतना बड़ा कि एक जीत दस हार की भरपाई कर सके
    • सटीक probabilities भले न पता हों, लेकिन हर bet का shape समझा जा सकता है
  • strategy-level asymmetric bets का shape अक्सर पहले से तय होता है, जैसे नया market जहाँ compounding recommendations जमा होते जाते हैं, या ऐसा moat जो हर sale के साथ गहरा होता जाता है
    • feature level पर asymmetry को खुद बनाना पड़ता है, क्योंकि software projects का default shape अक्सर "2 हफ्ते → 2 महीने → इतना समय लग गया कि अब खत्म करना ही पड़ेगा" में बह जाता है
    • इसका mechanism है शुरू करने से पहले बजट लिख देना: "2 engineers, 3 weeks, उसके बाद रुककर समीक्षा।" timebox ही सीमित downside है
  • confidence को "यह bet कितना asymmetric है" से बदलना भी एक तरीका है
    • RICE आपसे ऐसी probabilities का अनुमान लगाने को कहता है जिनके बारे में वह खुद मानता है कि वे ज्ञात नहीं हैं
    • asymmetry आपसे दो ऐसी चीज़ें पूछती है जिनका अनुमान वास्तव में लगाया जा सकता है: समय/लागत के हिसाब से worst case और customer value के हिसाब से best case। दोनों ठोस हैं, और अगर सभी numbers को 10 की घातों तक सीमित रखा जाए, तो बैठक में उन पर सहमति बन सकती है

निष्कर्ष

• यह दिखावा करना बंद करें कि confidence को quantifiably नापा या परिभाषित किया जा सकता है
• इसकी जगह ऐसी तकनीकें इस्तेमाल करें जो भविष्य के अप्रत्याशित होने पर भी काम करती हैं — क्योंकि भविष्य हमेशा अप्रत्याशित होता है

[hmmhmmhm]

"इसके बजाय ऐसी तकनीक का इस्तेमाल करें जो हर बार काम करे जब भविष्य का अनुमान लगाना असंभव हो, क्योंकि भविष्य हमेशा ही अप्रत्याशित होता है" — बढ़िया है

[spilist2]

बहुत शानदार लेख है।