अप्रैल में, मैंने लिखा कि Prova को असली किस चीज़ ने बनाया: sprint engine, billing, evaluations, वो boring operational work जो एक demo को product से अलग करता है।
वो पोस्ट सही थी जब मैंने पब्लिश की। जो sprint-first architecture मैंने describe की — authored sprints, rubric reviews, adaptive routing, Operator और Builder paths — genuinely काम कर रही थी। Engine सही था।
जो मैं अभी तक नहीं जानता था वो ये कि उसके ऊपर layered curriculum अभी भी गलत था।
ऐसा गलत नहीं जो आप एक demo में पकड़ लें। ऐसा गलत जो तभी surface करता है जब आपने हर rubric लिख लिया हो, हर user path trace कर लिया हो, और वो सवाल पूछा हो जो mid-May तक किसी ने मुझसे पूछने को force नहीं किया: ऐसा क्या है जो एक free chatbot के लिए इसे replicate करना मुश्किल बनाता है?
Mid-May से late June के बीच, curriculum दो बार rebuild हुआ। हर बार, मैंने कुछ ऐसा replace किया जिस पर मुझे पहले confidence था। ये है कि हर rewrite असल में किस बारे में था।
3-lane architecture (26 मई – 1 जून)
May के आखिर तक, product में एक problem थी। 33 sprints थे, और तीन बिल्कुल अलग audiences — workflow redesign कर रहे operators, पहला useful slice ship करने की कोशिश कर रहे builders, और teams transform करने की कोशिश कर रहे leaders — 9 में से 7 sprints share कर रहे थे और बाकी दो को "track" कह रहे थे। वो एक menu था, spine नहीं।
चौड़ाई खाई नहीं होती।
तो मैंने वो बनाया जो rigorous answer लगता था: एक layered architecture जिसमें shared Layer 0 foundation, फिर तीन audience lanes (Operator, Builder, Leader) अपने dedicated sprints के साथ, सब course के 16 templates और published corpus से sourced। 38 units across 5 unit types। Concept, exercise, sprint, project, checkpoint — हर एक की अपनी completion semantics।
Paper पर, ये एक real curriculum जैसा लगता था।
जो टूटा वो कोई individual sprint नहीं था। वो था पूरी चीज़ के नीचे का structural assumption: कि ज़्यादा lanes और ज़्यादा sprints product को ज़्यादा defensible बनाते हैं।
नहीं बनाते।
Hamilton Helmer का 7 Powers framework ये explicitly name करता है। Power, barriers से आती है — ऐसे structural advantages जो competitors सिर्फ decide करके replicate नहीं कर सकते। Path में sprints जोड़ना barrier नहीं है। वो operational surface area है। एक generic chatbot बिना किसी friction के instantly breadth match कर लेता है।
3-lane model ने coverage जोड़ा। Depth नहीं जोड़ा। मैंने गलत चीज़ बनाई थी, और मुझे तब तक दिखा नहीं जब तक architecture deploy हो चुका था और हर sprint लिखा जा चुका था।
मैंने 3-lane model के लिए 24 नए sprints author किए थे, course के templates और published corpus से sourced। Architecture paper पर rigorous लगती थी। मुझे उस पर pride था।
Lane system उसी हफ्ते decommission कर दिया गया जिस हफ्ते वो ship हुआ था।
एक rule (2 जून – 22 जून)
दूसरी rewrite, sprints से शुरू नहीं हुई। एक strategy question से शुरू हुई।
मैं बैठा और पूछा: अगर Prova की एकमात्र defensible edge कुछ ऐसा है जो एक horizontal AI tool structurally adopt नहीं कर सकता, तो वो edge क्या होगी?
जवाब तीन reinforcing layers में settle हुआ:
Vertical depth (wedge). एक marketer जो brief-documented campaign workflow को real measurement और decision gate के साथ, advertising-grade standard पर ship करता है। ये वो नहीं है जो एक chatbot prompt से produce कर सके।
Scaffolding (activation). ज़्यादातर marketers को नहीं पता कि क्या पूछना है। Product को उन्हें "मुझे लगता है AI इसमें help कर सकता है लेकिन मुझे नहीं पता कहाँ से शुरू करूँ" पर meet करना है और scoping, sequencing, और standard-setting का काम करना है।
Verified, shipped work to a standard (proof). हर sprint एक submission के साथ खत्म होता है जो एक real rubric के खिलाफ review होती है। "अच्छा दिखता है" नहीं। "grammatically clean है" नहीं। बल्कि: क्या ये artifact उस चीज़ के सामने टिकता है जो एक agency operator या media buyer actually use करेगा?
उन तीन layers से, architecture dramatically simplify हुई।
3-lane structure को एक loop grammar ने replace किया: reality-check → brief → plan → run/build → decision-gate → capstone।
तीनों paths के लिए same grammar। हर path के लिए अलग artifacts। Operator एक campaign workflow pilot run करता है। Builder एक working product slice ship करता है। Leader एक stakeholder business case और operating model blueprint build करता है।
Depth सिर्फ capstone के बाद add की गई: agency extensions, product-depth extensions, org-change extensions। अगर कोई user ज़्यादा चाहता था, तो उसने पहले spine से गुज़रकर earn किया।
Breadth, गायब नहीं हुई। Evidence-triggered detour modules में demote कर दी गई — short, assigned sprints जो सिर्फ तब appear होते हैं जब कोई reviewer एक ऐसा gap detect करता है जो authored spine currently address नहीं कर सकती। Data-infrastructure-audit। Vendor-stack-decisions। Table-stakes diagnostic। वो अब भी exist करते हैं। बस वो route नहीं हैं जो आप लेते हैं, unless product के पास evidence हो कि आपको उनकी ज़रूरत है।
इसे formalize करने वाला single commit 11 जून को feat!: replace dual curriculum routing with unified path sequences था। ! एक breaking change को denote करता है। primary_path (operator, builder, leader) ने learning_track को single routing axis के तौर पर replace किया। एक feature flag — DISABLE_BRIEF_DRIVEN_RESET_PATH — ने transition को isolate किया जब तक QA gate pass नहीं हुआ। Seven legacy sprints को sequencing से retire कर दिया गया लेकिन history के तौर पर viewable रखा गया।
Capstone, structural बन गया, feature नहीं। यही switching-cost mechanism है। एक horizontal tool एक decent sprint packet generate कर सकता है। वो verified, shipped artifacts का portfolio नहीं generate कर सकता जो advertising-grade standards के खिलाफ एक persistent reviewer history के साथ review किए गए हों।
कोई भी नया sprint या path author करने से पहले, पूछो: ये 7 Powers में से किसको strengthen करता है, और इसकी barrier क्या है? अगर honest answer "ये coverage जोड़ता है" है और कोई barrier नहीं, तो ये operational surface area है जिसे chatbot पहले ही cover करता है — इसे मत बनाओ।
— 5 जून, 2026, Prova curriculum strategy doc
उस rule ने 3-lane architecture को खत्म किया। उसने उन sprints को खत्म किया जो अच्छे लिखे थे लेकिन structurally redundant थे। उसने capstone को एक feature से जिसे मैं defer कर रहा था, एक structural requirement में बदल दिया। और ये वो सवाल है जो मुझे मार्च से पूछना चाहिए था।
अप्रैल और जून के बीच का फ़र्क
अप्रैल में लॉन्च किया गया प्रोडक्ट इंजन के हिसाब से सही था। जून में फाइनल किया गया प्रोडक्ट स्पाइन के हिसाब से सही था।
Engine — authored sprints, rubric reviews, adaptive routing, composed sprint lifecycle — ज़रूरी था। बिना काम करते sprint engine के curriculum architecture सिर्फ एक syllabus है।
लेकिन बिना defensible spine के sprint engine सिर्फ एक feature list है जिसे free tools पहले से match कर रहे हैं।
दोनों products के बीच का फ़र्क ज़्यादा code नहीं था। एक बेहतर सवाल था। "ये किस Power को strengthen करता है?" ने मुझे उन चीज़ों को kill करने पर मजबूर किया जिन पर मुझे pride था, और उन चीज़ों को elevate करने पर जिन्हें मैं optional treat कर रहा था।
मैं ये claim नहीं कर रहा कि June architecture finished है। Products rarely होते हैं। लेकिन अगर आप अभी एक learning product बना रहे हैं, तो अगला sprint लिखने से पहले ये सवाल पूछने लायक है। क्योंकि breadth जोड़ना सबसे आसान चीज़ है, और पहली चीज़ जिसे एक generic AI commoditize करेगा।
Additional context: Prova, marketers और advertising professionals के लिए मेरा coaching product है, जिसमें Operator path (workflow redesign) और Builder path (पहला useful slice ship करना) है। ये prova.chandlernguyen.com पर है। 7 Powers framework, Hamilton Helmer की किताब 7 Powers: The Foundations of Business Strategy से आता है — ये पोस्ट framework को reference करती है, सिखाती नहीं; किताब source है।
अक्सर पूछे जाने वाले सवाल
क्या 7 Powers framework product strategy के बाहर भी applicable है?
हाँ, लेकिन ये सबसे sharp तब होता है जब आप कुछ ऐसा build कर रहे हों जो general-purpose tools से compete करता है। सवाल "ये किस Power को strengthen करता है?" आपको force करता है ज़्यादा चीज़ें करने (operational surface area) और कुछ ऐसा बनाने (एक barrier) जो एक chatbot structurally adopt नहीं कर सकता, के बीच फ़र्क करने पर। ये distinction curriculum design, consulting frameworks, editorial voice — किसी भी चीज़ पर apply होता है जहाँ default competitive response "add more stuff" हो।
आपको कैसे पता चलता है कि कब किसी चीज़ को decommission करना है बनाम restructure करना है?
7 Powers test ही litmus है। अगर कोई sprint या lane सवाल पर fail हो जाए — "ये किस Power को strengthen करता है?" — और honest answer हो "कोई नहीं, ये सिर्फ coverage जोड़ता है," तो decommission करो। अगर honest answer हो "ये switching costs या cornered resources को strengthen कर सकता है, लेकिन मैंने इसे उस तरह build नहीं किया है," तो पहले restructure करो, फिर दोबारा test करो। 3-lane model पहले test में outright fail हुआ। Capstone ने दूसरा pass किया — ये हमेशा एक ऐसा feature था जिसे मैं defer कर रहा था, लेकिन सवाल पूछने से reveal हुआ कि इसे शुरू से structural होना चाहिए था।
क्या एक single "loop grammar" हर path को एक जैसा feel नहीं कराता?
Paper पर ऐसा लगता है। Practice में, grammar एक shared spine है, shared experience नहीं। एक campaign workflow pilot run करने वाला operator, एक working product slice ship करने वाला builder, और एक stakeholder business case build करने वाला leader — सब एक ही loop से बिल्कुल अलग artifacts तक पहुँचते हैं। Loop, depth और decision gates को enforce करता है। Differentiation, user जो लाता है उससे आता है — उनका domain, उनकी problems, उनका data — और वो क्या build करते हैं। Grammar वो constraint है जो depth को possible बनाता है, वो limit नहीं जो सब कुछ uniform बना दे।
अगर आप fast-moving AI layer के ऊपर structured product बना रहे हैं, तो मुझे genuinely curious है: आपकी architecture में वो एक चीज़ क्या है जो एक free tool सिर्फ prompts जोड़कर replicate नहीं कर सकता?
फिलहाल इतना ही।
चीयर्स, Chandler