स्टार्टअप के लिए डिसिजन लॉग
स्टार्टअप हर हफ्ते सैकड़ों निर्णय लेते हैं। ज़्यादातर Slack थ्रेड्स और भूली हुई मीटिंग्स में खो जाते हैं। जानें कैसे बनाएं एक डिसिजन लॉग जो सच में काम करे।
By Ellis Keane · 2026-03-16
1986 में, स्पेस शटल Challenger लॉन्च के 73 सेकंड बाद टूट गया। बाद की जाँच में पता चला कि Morton Thiokol के इंजीनियरों ने एक रात पहले O-ring सील्स को लेकर चिंता जताई थी – उनका तर्क था कि ठंड के कारण लॉन्च असुरक्षित है। मैनेजमेंट ने उन्हें नज़रअंदाज़ कर दिया। फैसला एक टेलीकॉन्फ्रेंस में हुआ, और चार्ट्स तथा गवाहियाँ मौजूद होने के बावजूद, इस फैसले के पीछे की अहम सोच प्रतिभागियों में बिखरी रही और कभी भरोसे के साथ ऊपर तक नहीं पहुँची।
मैं आपके स्टार्टअप के प्रोडक्ट निर्णयों की तुलना शटल आपदा से नहीं कर रहा (खैर, ज़्यादातर तो नहीं)। लेकिन बुनियादी फेल पैटर्न वही है जो मैं हर हफ्ते स्टार्टअप्स में देखता हूँ – बस दाँव कम होते हैं: एक निर्णय लिया जाता है, उसके पीछे की सोच किसी के दिमाग में या एक Slack थ्रेड में जीती है जो स्क्रीन से स्क्रॉल हो जाने वाली है, और तीन महीने बाद कोई नहीं बता सकता कि हमने approach A को approach B के ऊपर क्यों चुना। इसलिए नहीं कि निर्णय गलत था – कभी-कभी वह शानदार था – बल्कि इसलिए कि जो context उसे सही बनाता था वह उड़ गया।
"एक निर्णय लिया जाता है, उसके पीछे की सोच किसी के दिमाग में या एक Slack थ्रेड में जीती है जो स्क्रीन से स्क्रॉल हो जाने वाली है, और तीन महीने बाद कोई नहीं बता सकता कि हमने approach A को approach B के ऊपर क्यों चुना।" – Ellis Keane
स्टार्टअप के लिए डिसिजन लॉग कोई नौकरशाही काम नहीं है। यह फर्क है «हमने यह कोशिश की और काम नहीं किया» (उपयोगी) और «मुझे लगता है हमने एक बार इस पर बात की थी?» (बेकार) के बीच।
एक खोए हुए निर्णय की शारीरिक-रचना
मुझे एक खास निर्णय को उसके जीवनचक्र से गुज़रते हुए दिखाने दें, क्योंकि इस समस्या का सार संस्करण ठोस संस्करण जितना नहीं समझाता।
फरवरी का एक मंगलवार है। आपके Head of Engineering और PM एक Slack थ्रेड में बहस कर रहे हैं – क्या खुद का नोटिफिकेशन सिस्टम बनाएँ या किसी थर्ड-पार्टी सर्विस का उपयोग करें। थ्रेड 47 मैसेज लंबा है (मुझे पता है, लेकिन यही होता है), और मैसेज 38 तक वे थर्ड-पार्टी विकल्प पर टिक गए हैं क्योंकि खुद बनाने में तीन स्प्रिंट लगेंगे और लॉन्च डेडलाइन दो में है।
PM एक Linear issue बनाता है: «नोटिफिकेशन के लिए [Service X] इंटीग्रेट करें।» एक इंजीनियर इसे उठाता है, बनाना शुरू करता है। Slack थ्रेड तकनीकी रूप से अभी भी है, लेकिन कोई इसे बुकमार्क नहीं करता और न ही Linear issue से लिंक करता है।
मई आता है। थर्ड-पार्टी सर्विस में भरोसेमंदी की समस्या आती है। कोई पूछता है: «हमने इसे खुद क्यों नहीं बनाया?» PM को बातचीत याद है लेकिन details नहीं। Head of Engineering पैरेंटल लीव पर है। Slack थ्रेड फरवरी के #engineering चैनल में कहीं है, लेकिन किसी को सही तारीख याद नहीं, और Slack सर्च «notification» के लिए 200 नतीजे देता है – क्योंकि, ज़ाहिर है, हर टीम हर वक्त नोटिफिकेशन पर बात करती है।
टीम 45 मिनट एक मीटिंग में मूल सोच को फिर से बनाने में बिताती है। आखिरकार वे उसी निर्णय पर पहुँचते हैं – समय की बाधा अभी भी लागू थी – लेकिन 45 मिनट चले गए और संशय बना रहता है। इसे हर महीने दर्जनों निर्णयों से गुणा करें, और आपको पहले से सोच-समझकर लिए गए फैसलों को फिर से बहस में डालने में ख़र्च हुए समय का एक बड़ा हिस्सा मिलेगा।
स्टार्टअप इसमें विशेष रूप से कमज़ोर क्यों होते हैं
बड़ी कंपनियाँ (अपनी तमाम खामियों के बावजूद, जो कम नहीं हैं) प्रक्रियाओं में संस्थागत स्मृति एन्कोड करती हैं: architecture decision records, RFC, डिज़ाइन दस्तावेज़ जो औपचारिक समीक्षा चक्रों से गुज़रते हैं। निर्णय Confluence में दबे हो सकते हैं, लेकिन कम से कम कहीं न कहीं लिखे हुए हैं जहाँ खोजा जा सके।
स्टार्टअप्स के पास यह बुनियादी ढाँचा नहीं होता, और इसे बनाना बिल्कुल उसी तरह का overhead लगता है जिससे छोटे और तेज़ रहने पर बचना चाहिए। यह तर्क वाजिब है कि «हम बस याद रखेंगे» चार लोगों में काम करता है – और करता भी है –, जब तक पाँचवाँ व्यक्ति नहीं आ जाता जिसे कोई context नहीं है कि चीज़ें ऐसी क्यों हैं।
दूसरी बात जो स्टार्टअप में निर्णय ट्रैकिंग को खासतौर पर मुश्किल बनाती है वह है टूल का बिखराव। निर्णय हर जगह होते हैं: Slack थ्रेड्स, Zoom कॉल्स, Notion कमेंट्स, Linear चर्चाएँ, GitHub PR रिव्यूज़, और – बढ़ते हुए – DMs में जो कभी शेयर्ड चैनल तक नहीं पहुँचते। हर टूल निर्णय का एक हिस्सा कैप्चर करता है, लेकिन कोई भी पूरी बात नहीं पकड़ता, और उनके बीच के लिंक इंसानी याददाश्त से बने रहते हैं – जो प्यार से कहें तो – सबसे कम भरोसेमंद डेटाबेस है जिस तक हमारी पहुँच है।
डिसिजन लॉग को वास्तव में क्या चाहिए
इसे ज़रूरत से ज़्यादा जटिल बनाने की ललक होती है। मैंने टीमों को Notion में प्रति एंट्री 15 properties के साथ विस्तृत डेटाबेस बनाते देखा है – निर्णय का प्रकार, प्रभाव स्तर, रिव्यू स्टेटस, stakeholders, संबंधित OKRs – और फिर कभी इस्तेमाल नहीं करते क्योंकि हर निर्णय के लिए इन सभी फ़ील्ड्स को भरने का बोझ माने जाने वाले मूल्य से ज़्यादा है।
स्टार्टअप के लिए डिसिजन लॉग इतना हल्का होना चाहिए कि लोग इसे वास्तव में इस्तेमाल करें। यह ज़रूरी है:
निर्णय खुद। एक वाक्य। «हम खुद बनाने की जगह नोटिफिकेशन के लिए Service X का उपयोग करेंगे।» कोई पैराग्राफ नहीं – एक वाक्य।
किसने लिया और कब। नाम और तारीख। यह स्पष्ट लगता है, लेकिन यही हिस्सा सबसे ज़्यादा मायने रखता है जब कोई छह महीने बाद निर्णय पर सवाल उठाता है। यह दोष की बात नहीं है (खैर, ज़्यादातर नहीं) – यह जानना है कि मूल सोच के लिए किससे पूछें।
कौन-कौन से विकल्प सोचे गए। दो या तीन बुलेट पॉइंट। «खुद बनाने पर विचार किया (3-स्प्रिंट अनुमान, डेडलाइन बहुत तंग)» और «Service Y पर विचार किया (कीमत 10,000 यूज़र्स से आगे scale नहीं होती)।» यह हिस्सा बार-बार होने वाली बहस को रोकता है – अगर विकल्प और उनके trade-offs दर्ज हैं, तो टीम को उन्हें फिर से खोजने की ज़रूरत नहीं।
चर्चा कहाँ हुई। Slack थ्रेड, Linear issue, Notion कमेंट – जहाँ भी असली बहस हुई उसका लिंक। यह सबसे कम आँका जाने वाला फ़ील्ड है। इसके बिना, लॉग एंट्री बिना सबूत के दावा है। इसके साथ, जो कोई पूरा context चाहता है वह मूल बातचीत पढ़ सकता है।
क्या निर्णय बदल देगा। यह वैकल्पिक है लेकिन उन स्टार्टअप्स के लिए अविश्वसनीय रूप से उपयोगी है जहाँ context तेज़ी से बदलता है। «हम इसे दोबारा देखेंगे अगर लॉन्च डेडलाइन 4 हफ्ते से ज़्यादा खिसकती है» या «यह मानता है कि हम महीने में 10,000 नोटिफिकेशन के नीचे रहते हैं।» यह एक स्थिर रिकॉर्ड को जीवंत बनाता है।
स्टार्टअप के लिए सबसे अच्छा डिसिजन लॉग वह है जिसे आपकी टीम वास्तव में भरती है। पाँच फ़ील्ड्स, हर एक में एक वाक्य। अगर एक निर्णय लॉग करने में 90 सेकंड से ज़्यादा लगे, तो सिस्टम एक महीने के अंदर दम तोड़ देगा।
इसे कहाँ रखें?
मैंने टीमों को तीन तरीके आज़माते देखा है, और सभी में समझौते हैं।
एक Notion डेटाबेस। यह सबसे आम है और काफी अच्छा काम करता है। ऊपर दिए पाँच फ़ील्ड्स के साथ एक डेटाबेस बनाएँ, एक टेम्पलेट जोड़ें ताकि भरना जल्दी हो, और हर एंट्री को संबंधित प्रोजेक्ट पेज से लिंक करें। नुकसान: Notion वह जगह है जहाँ specs रहती हैं, निर्णय नहीं होते – इसलिए आप इस पर निर्भर हैं कि कोई निर्णय के बाद Notion पर जाएगा जो कहीं और लिया गया था। वह «बाद का» कदम ही वह जगह है जहाँ उपयोग गिरता है।
सीधे Slack में। कुछ टीमें एक dedicated #decisions चैनल रखती हैं और हर निर्णय के लिए एक फॉर्मेटेड मैसेज पोस्ट करती हैं। यह कम झंझट है (निर्णय वैसे भी Slack में हुआ होगा), लेकिन Slack की सर्च से प्रोजेक्ट या तारीख-सीमा के अनुसार निर्णय खोजना मुश्किल होता है, और structured फ़ील्ड्स की कमी का मतलब है कि समय के साथ consistency कम होती है।
सीधे Linear में। अगर निर्णय किसी विशेष वर्कफ़्लो से जुड़ा है, तो इसे संबंधित Linear issue पर कमेंट के रूप में लॉग करने से निर्णय उस काम के करीब रहता है जो उसे प्रभावित करता है। नुकसान यह है कि कई issues या प्रोजेक्ट्स में फैले निर्णयों का कोई स्वाभाविक घर नहीं है।
इनमें से कोई भी बढ़िया नहीं है, अगर मैं ईमानदार हूँ। बुनियादी समस्या यह है कि निर्णय कई टूल्स में होते हैं, लेकिन लॉग एक टूल में रहते हैं – इसलिए हमेशा एक मैन्युअल कदम होता है खाई पाटने के लिए। यह मैन्युअल कदम ही हर डिसिजन लॉग में एकमात्र failure point है।
Sugarbug में हम क्या बना रहे हैं
Sugarbug के साथ हम जो तरीका अपना रहे हैं वह है – टूल्स में होते ही निर्णयों को पहचानना, न कि किसी से मैन्युअल रूप से लॉग करवाना।
जब कोई Slack थ्रेड किसी नतीजे पर पहुँचता है («ठीक है, Service X से जाते हैं»), जब कोई Linear issue की चर्चा सुलझती है, जब कोई GitHub PR review अप्रूवल के साथ खत्म होता है – ये सभी सिग्नल हैं कि एक निर्णय लिया गया। Sugarbug इन सिग्नलों को लेता है, उन्हें वर्गीकृत करता है और नॉलेज ग्राफ़ में संबंधित कामों और लोगों से जोड़ता है। «डिसिजन लॉग» कोई अलग डेटाबेस नहीं है जिसे किसी को बनाए रखना हो – यह आपके मौजूदा टूल्स में पहले से मौजूद निर्णयों का एक दृश्य है।
हम अभी भी classification accuracy पर काम कर रहे हैं («एक निर्णय» और «बस एक बातचीत» के बीच का फर्क निकालना उतना आसान नहीं जितना लगता है), लेकिन दिशात्मक दाँव यह है कि स्रोत पर निर्णयों को कैप्चर करना – जहाँ वे वास्तव में होते हैं – इंसानों से उन्हें किसी अलग सिस्टम में दोहराने को कहने से ज़्यादा भरोसेमंद है।
अगर आपको यह दिलचस्प लगता है, तो sugarbug.ai पर अधिक जानकारी है। लेकिन ऊपर बताया गया मैन्युअल सिस्टम अधिकांश स्टार्टअप्स के लिए तब तक अच्छा काम करेगा जब तक टीम इतनी बड़ी न हो कि मैन्युअल लॉगिंग की dropout rate एक वास्तविक समस्या बन जाए – हमारे अनुभव में, आमतौर पर 8–12 लोगों के आसपास।
Slack scroll में निर्णय खोना बंद करें। Sugarbug उन्हें उन टूल्स से अपने आप कैप्चर करता है जहाँ वे वास्तव में होते हैं।
Q: स्टार्टअप के डिसिजन लॉग में क्या होना चाहिए? A: कम से कम: निर्णय खुद (एक वाक्य), किसने लिया, कब, कौन-कौन से विकल्प सोचे गए और चर्चा कहाँ हुई। आखिरी फ़ील्ड सबसे ज़रूरी है – मूल बातचीत के लिंक के बिना, लॉग एंट्री बिना सबूत के दावा बन जाती है, और जब कोई छह महीने बाद सवाल उठाता है तो आप फिर से याददाश्त से जोड़-तोड़ में लग जाते हैं।
Q: क्या Sugarbug मौजूदा टूल्स से अपने आप डिसिजन लॉग बनाता है? A: यही वह दिशा है जिसमें हम जा रहे हैं। Sugarbug Slack, Linear, GitHub, Notion और अन्य टूल्स से सिग्नल लेता है और उन्हें नॉलेज ग्राफ़ में वर्गीकृत करता है। जब वह एक निर्णय पहचानता है – एक अप्रूव्ड PR, एक सुलझी हुई Linear चर्चा, एक Slack थ्रेड जो स्पष्ट अगले कदम के साथ खत्म होता है – वह उस निर्णय को संबंधित काम और लोगों से अपने आप जोड़ देता है। हम अभी भी classification को बेहतर कर रहे हैं («निर्णय» और «बातचीत» में फर्क करना सच में मुश्किल है), लेकिन सिग्नल की इनजेस्शन और लिंकिंग काम कर रही है।
Q: स्टार्टअप को अपना डिसिजन लॉग कितनी बार अपडेट करना चाहिए? A: आदर्श रूप से, निर्णय लेते ही उन्हें लॉग करें – साप्ताहिक रूप से एक साथ नहीं। शुक्रवार तक मंगलवार के निर्णय की सोच पहले से धुंधली हो जाती है, और किसी के «सोचे गए विकल्प» फ़ील्ड को सही से भरने की संभावना तेज़ी से गिरती है। अगर मैन्युअल लॉगिंग कर रहे हैं, तो इसे निर्णय के तुरंत बाद 90 सेकंड की आदत बनाएँ। Sugarbug जैसे टूल का उपयोग करते समय, लक्ष्य है उन टूल्स से रियल-टाइम कैप्चर जहाँ निर्णय वास्तव में होते हैं।
Q: क्या Sugarbug Slack, Linear और GitHub में निर्णयों को ट्रैक कर सकता है? A: Sugarbug तीनों से (और Notion और Figma से) जुड़ता है और बातचीत, कामों और कोड बदलावों के बीच संबंधों का नॉलेज ग्राफ़ बनाए रखता है। जब कोई निर्णय Slack थ्रेड में उभरता है, Linear issue की ओर जाता है और GitHub PR को जन्म देता है, Sugarbug पूरी चेन को जोड़ देता है – ताकि आप निर्णय को उत्पत्ति से implementation तक बिना किसी के मैन्युअल लिंक बनाए ट्रैक कर सकें।
Q: डिसिजन लॉग और Architecture Decision Record (ADR) में क्या फर्क है? A: ADR आमतौर पर महत्वपूर्ण तकनीकी विकल्पों के लिए औपचारिक दस्तावेज़ होते हैं – «हम MongoDB की जगह PostgreSQL इस्तेमाल करेंगे» – context, decision और परिणामों के लिए structured sections के साथ। स्टार्टअप के लिए डिसिजन लॉग अधिक व्यापक और हल्का है: यह दैनिक परिचालन निर्णयों को कैप्चर करता है (कौन सा vendor, कौन सी deadline, कौन सा feature कटे) जिन्हें ADR बहुत छोटा समझकर दस्तावेज़ नहीं करते। दोनों मूल्यवान हैं; डिसिजन लॉग उन 95% निर्णयों को कवर करता है जो औपचारिक ADR का औचित्य नहीं रखते लेकिन फिर भी ट्रैक करने योग्य होने चाहिए।