एक AI-native media team के लिए 90-day rollout campaign lifecycle का एक stage है जो शुरू से आख़िर तक redesign किया गया, पाँच stages शुरू किए गए नहीं। दिन 1–30 constraint ठीक करते हैं और एक brief machine-readable बनाते हैं; दिन 31–60 उस stage को चलाते हैं जिसमें model पहला pass produce करता है और review standard बनाते हैं; दिन 61–90 मापते हैं और evidence के साथ decide करते हैं कि विस्तार करना है या नहीं।
मैंने teams को एक quarter में AI-native बनने की कोशिश tools ख़रीदकर और workshops चलाकर करते देखा है, और मैंने teams को चुपचाप एक workflow दोबारा बनाकर और result को अगले के लिए तर्क देने देकर करते देखा है। दूसरा group छोटा है और आगे जाता है। यह उन 90 दिनों का shape है, उस तरह लिखा जैसे मैं इसे एक असली team के लिए, एक असली client load के साथ sequence करता।
90 दिन और एक stage क्यों
Timeline मनमाना नहीं है और scope डरपोक नहीं है। यह सबसे छोटी unit है जो भरोसेमंद evidence produce कर सकती है।
नब्बे दिन इतने लंबे हैं कि एक stage को कई असली cycles से गुज़ारें — कई weekly reports, कई campaigns, कई briefs — ताकि result एक अच्छे हफ़्ते की demo न हो। यह इतने छोटे हैं कि यह transformation programme के बजाय एक project रहे, जो मायने रखता है क्योंकि transformation programmes कुछ produce करने से पहले funding खो देते हैं।
एक stage unit इसलिए है क्योंकि parade problem partial redesign को दंड देता है। एक stage ठीक करें और पड़ोसियों को छोड़ दें, और gain बग़ल से रिस जाता है। लेकिन एक stage को पूरी तरह redesign करना method साबित करता है और आपको अगले stage के लिए internal case देता है, जो पाँच आधे-अधूरे pilots से ज़्यादा क़ीमती है।
दिन 1–30: constraint चुनें, brief ठीक करें
पहला महीना diagnosis और design है, tooling नहीं।
वह stage चुनें जिसका campaign अंत में इंतज़ार कर रही है — आमतौर पर reporting, research या brief। फिर लिखें कि उस stage के लिए "अच्छा" कैसा दिखता है और input को machine-readable बनाएँ। अगर यह brief है, तो इसका मतलब है direction, audience, brand rules और success metric एक ऐसी shape में जिसे एक व्यक्ति और एक workflow दोनों इस्तेमाल कर सकें। अगर यह reporting है, तो इसका मतलब है data sources, join और anomaly threshold पहले से तय।
महीने एक का output एक चलता हुआ system नहीं है। यह एक page का design है: stage, owner, machine-readable input, standard, और वह measure जिससे आप success जज करेंगे। अगर आप इसे एक page पर नहीं लिख सकते, तो stage बहुत बड़ा है — इसे बाँटें।
दिन 31–60: चलाएँ, और standard बनाएँ
दूसरा महीना वह जगह है जहाँ workflow असल में चलता है, और जहाँ review standard मुश्किल तरीक़े से बनता है।
Stage को चलाएँ जिसमें model पहला pass produce करे: यह report narrative, research synthesis या plan options generate करता है, और एक व्यक्ति standard के सामने review करता है। पहले दो हफ़्तों में कच्चापन उम्मीद करें — brief आपकी सोच से ज़्यादा vague होगा, और review वे चीज़ें पकड़ेगा जिनका standard ने अनुमान नहीं लगाया। यही असली काम पर चलाने का बिंदु है, test campaign पर नहीं।
महीने दो का deliverable एक working standard है: क्या automatically check होता है, एक human को क्या देखना ज़रूरी है, और exceptions का क्या होता है। इसे लिखें, क्योंकि एक व्यक्ति के दिमाग़ में रहने वाला review standard एक standard नहीं है, यह एक bottleneck है। यह वह महीना भी है जिसमें आप सीखते हैं कि stage को असल में कितनी review capacity चाहिए — लगभग हमेशा पहले plan की मान्यता से ज़्यादा।
दिन 61–90: मापें, फिर decide करें
तीसरा महीना measurement और एक फ़ैसला है, और यह वह हिस्सा है जिसे बेसब्री वाली teams छोड़ देती हैं।
Stage की दो चीज़ों पर तुलना करें: cycle time और quality। काम सचमुच जल्दी ख़त्म हुआ, और error या rework rate बढ़ा? एक तेज़ stage जिसमें ज़्यादा errors हैं, जीत नहीं है; यह वह risk है जिसका आपने अब तक भुगतान नहीं किया। एक तेज़ stage जिसमें quality स्थिर या बेहतर है, वह evidence है जो आपको विस्तार के लिए चाहिए।
फिर ईमानदारी से तीन में से एक call लें। अगर numbers अच्छे हैं, अगला stage लें — लेकिन एक बार में एक, वही design इस्तेमाल करते हुए। अगर numbers मिले-जुले हैं, विस्तार से पहले standard या brief ठीक करें, क्योंकि method ठोस है और execution नहीं। अगर numbers ख़राब हैं और आप कारण नहीं बता सकते, रुकें और लिखें कि क्या सीखा; यह एक टूटी workflow को scale करने से सस्ता है।
तीन phases एक नज़र में
| Phase | लक्ष्य | मुख्य output | Success signal |
|---|---|---|---|
| दिन 1–30 | Diagnose और design | एक page का design: stage, owner, input, standard | आप stage और उसका measure एक page पर बता सकते हैं |
| दिन 31–60 | चलाओ और standardise करो | एक working, लिखा review standard | Stage असली काम पर बिना heroics चलता है |
| दिन 61–90 | मापो और decide करो | Cycle time और quality पर evidence | विस्तार, ठीक या रोकने का defensible फ़ैसला |
Signal वाला column वह हिस्सा है जिस पर ख़ुद को परखना है। हर phase में एक सवाल है जो बताता है कि आगे बढ़ें या नहीं, और इनमें से कोई भी "क्या यह progress लगा" नहीं है।
वे traps जो rollouts मार देती हैं
समुद्र उबालना। Team तीन stages एक साथ redesign करती है क्योंकि सब दर्द देते हैं। Parade problem गारंटी देता है कि constraints यथावत रहेंगी और मेहनत इतनी फैलेगी कि कुछ साबित न हो। एक stage।
Tool-first। Rollout एक procurement list से शुरू होता है, workflow diagnosis से नहीं। आप एक AI-assisted team और एक बड़े software bill पर पहुँचते हैं, जो वह failure है जिसे AI-native vs AI-assisted का फ़र्क़ बताता है। Tools design के downstream हैं।
कोई नामित owner नहीं। जिस rollout का owner "team" हो उसका owner कोई नहीं। एक व्यक्ति stage, standard और evidence का owner होता है, और उस व्यक्ति के पास stage कैसे चलता है यह बदलने का अधिकार होता है।
Standard छोड़ना। Team output automate कर देती है और review अनौपचारिक रखती है। यह तब तक काम करता है जब तक पहली error किसी client तक न पहुँचे, और फिर rollout अपना sponsor खो देता है। Volume बढ़ाने से पहले standard define करें।
इसे किसे चलाना चाहिए
आपको एक senior sponsor और एक team चाहिए जो pilot बनने को तैयार हो। Sponsor 90 दिनों को दूसरे काम के लिए लूटे जाने से बचाता है; pilot team असली campaigns पर redesign करती है। आपको शुरू करने से पहले org-wide alignment नहीं चाहिए — उसका इंतज़ार करना एक साल slides पर बिताने का आम तरीक़ा है — और आपको एक engineering team नहीं चाहिए जब तक एक असली integration ख़ुद का ख़र्च न निकाले।
Pilot team में वह operator होना चाहिए जो काम का owner हो, एक व्यक्ति जो data को गंभीरता से ले, और एक reviewer जो ईमानदारी से बताए जब output अच्छा न हो। वह आख़िरी role भूलना आसान है और वही rollout को ईमानदार रखता है।
90 दिनों पर success कैसा दिखता है
Quarter के अंत में, success जान-बूझकर मामूली और असामान्य रूप से ठोस है: एक stage असली काम पर AI-native चलता है, एक लिखे standard और एक नामित owner के साथ; आप वह cycle time दिखा सकते हैं जो उसने बचाया और वह quality जो उसने बनाए रखी; और आपके पास अगला stage लेने का एक defensible कारण है।
यह एक transformation नहीं है। यह एक का चलता हुआ prototype है, और यह एक roadmap से ज़्यादा क़ीमती है, क्योंकि यह intent के बजाय evidence है। Execution guide वह पूरा map है जिसके अंदर यह rollout बैठता है, और for-team-leads track पहले के बाद के stages sequence करती है।
FAQ
90 दिन क्यों, 30 या 180 नहीं?
तीस दिन बहुत छोटे हैं कि एक stage कई असली cycles से गुज़रे, इसलिए result एक demo है, evidence नहीं। एक सौ अस्सी दिन काम को एक programme बना देते हैं जो गति और funding खो देता है। नब्बे दिन सबसे छोटी unit हैं जो भरोसेमंद सबूत produce करती है।
क्या सबसे मुश्किल stage पहले चुनना है?
नहीं — constraint चुनें, जो वह stage है जिसका campaign अंत में इंतज़ार करती है। यह आमतौर पर reporting, research या brief होता है, कोई glamorous चीज़ नहीं। Constraint वह जगह है जहाँ cycle time रहता है, और उसे ठीक करना ही बाक़ी के लिए case बनाता है।
अगर pilot fail हो जाए?
एक fail हुआ pilot जो एक ईमानदार कारण produce करता है, उस scaled workflow से सस्ता है जिसे आप समझा नहीं सकते। लिखें कि stage, brief या standard ने क्या ग़लत किया, ठीक करें, और उसी stage पर 90 दिन दोबारा चलाएँ। Method ठोस है; ज़्यादातर failures execution हैं, concept नहीं।
Rollout का owner कौन होता है?
एक senior sponsor और stage के लिए एक नामित owner। Sponsor समय बचाता है; owner standard और evidence का owner है। जिस rollout का owner "team" हो उसका owner कोई नहीं और वह एक महीने के अंदर दूसरे काम के लिए लूट लिया जाएगा।
Short version
एक 90-day AI-native rollout एक stage है जो शुरू से आख़िर तक redesign किया गया: दिन 1–30 में brief diagnose और design करें, दिन 31–60 में इसे चलाएँ और review standard बनाएँ, दिन 61–90 में मापें और decide करें। एक stage, एक owner, विस्तार से पहले evidence। Traps हैं समुद्र उबालना, tools से शुरू करना, owner न होना, और standard छोड़ना। Execution guide व्यापक map है।
मैंने ऐसे rollouts चलाए हैं जिन्होंने बहुत ज़्यादा करने की कोशिश की और ऐसे जो बहुत कम करते थे, और जो काम करते थे वे हमेशा वे थे जिन्होंने अगले को छूने से पहले एक चीज़ ठीक से साबित की।
अगर आपकी team एक rollout plan कर रही है, तो मैं सुनना चाहूँगा कि आपने कौन-सा stage चुना और क्यों — वह चुनाव आमतौर पर बताता है कि वह टिकेगा या नहीं।
शुभकामनाओं सहित, Chandler
यह लेख हिंदी में उपलब्ध है, लेकिन कोर्स सामग्री (वीडियो, टेम्पलेट्स और सपोर्टिंग गाइड्स) अंग्रेज़ी और जापानी में उपलब्ध है। यह साइट 13 भाषाओं में उपलब्ध है।