पिछले अध्याय में हमने देखा कि पर्सनल डेवलपमेंट "तय करना → तैयारी → बनाना → पब्लिश → बढ़ाना" के 5 फेज़ में आगे बढ़ता है, और सुनहरा नियम है "एक फ़ीचर पर सिमटकर MVP पब्लिश करना"। यह अध्याय 2 उसी पहले फेज़ "तय करना" को लेता है। क्या और किसके लिए बनाना है, इसे छोटा करके तय करें, और उसे स्पेक (spec) के रूप में उतारें — यहाँ तक हम साथ मिलकर बढ़ेंगे।

इस अध्याय का लक्ष्य

"जो बनाना है" उसे AI को सौंपने लायक रूप तक पक्का करना

एक आइडिया तय हो जाए
AI से मंथन करके बनाने लायक एक चीज़ ठोस रूप में चुन पाएँ।
एक लाइन में कह सकें
"किसकी, कौन-सी परेशानी को, कैसे हल करता है" — इसे एक लाइन में भाषा दे सकें।
स्पेक तक लिख सकें
स्क्रीन, डेटा और ऑपरेशन का न्यूनतम स्पेक लिखकर, AI को सौंपने की तैयारी हो जाए।

पहले "तय करना" क्यों ज़रूरी है

जल्दी कोड लिखना शुरू करने की चाह समझ में आती है। पर पर्सनल डेवलपमेंट में सबसे आम नाकामी है "बनाते-बनाते यह समझ न आना कि आखिर बना क्या रहे हैं"। लक्ष्य धुंधला रहते हुए हाथ चलाएँ, तो बीच में "अरे यह फ़ीचर भी" कहकर दिशा डगमगाती है, और चीज़ कभी पूरी नहीं होती।

इसीलिए कोडिंग को बाद के लिए टाल दें। पहले "क्या, किसके लिए, कहाँ तक बनाना है" यह साफ़ करें। बिना नक्शे और बिना मंज़िल तय किए चल पड़ें तो भटकना तय है, उलटे अगर मंज़िल तय हो, तो AI नाम का साथी सबसे छोटे रास्ते तक पहुँचा देता है।

😵 बिना तय किए बनाना शुरू करें तो

फ़ीचर लगातार बढ़कर जटिल हो जाते हैं। AI को हर बार दिया निर्देश भी डगमगाता है। पूरा होना दूर होता जाता है, जोश खत्म होकर चीज़ छूट जाती है।

🎯 पहले तय करके बनाएँ तो

लक्ष्य एक पर टिक जाता है। AI को सटीक निर्देश दे पाते हैं, आउटपुट भी नहीं डगमगाता। सबसे छोटे रास्ते से "चलती हुई चीज़" तक पहुँचते हैं।

💡 "तय करना" कोई सोच में डूबने का समय नहीं है। परफ़ेक्ट प्रपोज़ल की ज़रूरत नहीं। इस अध्याय में हम बस इतना करते हैं जितना एक पन्ने (या एक मेमो स्क्रीन) में समा जाए — एक छोटा फ़ैसला। सोच में रुके रहने से बेहतर है, कच्चा ही सही, तय करके आगे बढ़ना — मंज़िल तक कहीं जल्दी पहुँचेंगे।

आइडिया कैसे खोजें — AI से मंथन

"कुछ खास बनाने का मन नहीं है" — कोई बात नहीं। आइडिया शून्य से गढ़ने की चीज़ नहीं, बल्कि अपने आसपास की परेशानियों से उठाई जाने वाली चीज़ है। और यही खोज-काम AI का सबसे मज़बूत पक्ष है। अकेले सिर खपाने की ज़रूरत नहीं। AI को मंथन का साथी बना लें, तो आइडिया धड़ाधड़ निकलते हैं।

😤 अपनी "झंझट" से

रोज़ जो थोड़ा झंझट भरा लगता है। हाथ से बार-बार वही काम, रिकॉर्ड रखने की मेहनत, ढूँढने में लगता समय। जिससे आप परेशान हैं, उससे कोई और भी परेशान है।

🙋 जो खुद चाहिए उससे

"ऐसा ऐप हो तो इस्तेमाल करूँ" — जो आपने सोचा हो। पहला यूज़र खुद आप। जो खुद सच में चाहते हैं, उसे बनाने की प्रेरणा बनी रहती है।

💬 AI से बातचीत से

धुंधली-सी दिलचस्पी AI को बताएँ और उससे सवाल वापस लें। बातचीत में ही आकार उभरने लगता है। मन में आए ख़्याल बोलकर निकालने के लिए यह सबसे बढ़िया साथी है।

मंथन की कुंजी है, ठोस विषय देना। "कोई अच्छा ऐप बताओ?" से अच्छा जवाब नहीं मिलता। नीचे की तरह, नज़रिया साफ़ करके पूछें।

🗣️ सीधे इस्तेमाल किए जा सकने वाले मंथन-सवाल
  • "घर-खर्च संभालने की झंझट हल करने वाले 10 ऐप-आइडिया, एक-एक लाइन में दो।"
  • "इनमें से सबसे छोटा जो बनाया जा सके वह कौन-सा है? वजह भी बताओ।"
  • "यह आइडिया, क्या सच में कोई इस्तेमाल करेगा? मान लो कौन यूज़र और किस मौके पर, बताओ।"
  • "क्या मिलती-जुलती सर्विस पहले से है? अगर है, तो एक व्यक्ति किस फ़र्क पर दाँव लगा सके?"
  • "इस आइडिया को सिर्फ़ एक फ़ीचर तक काटना हो, तो कौन-सा फ़ीचर रखना चाहिए?"

10 निकलवाकर 1 चुनना — यह तरीका असरदार है। AI ढेरों विकल्प पल भर में सामने रख देता है, इसलिए आपका काम बस "चुनने" पर टिका रहता है। जो दिल को छू जाए, उसे और गहराई से खंगालते जाएँ।

एक फ़ीचर पर सिमटें — पर्सनल डेवलपमेंट का नियम

आइडिया दिखने लगे, तो अगली अहम बात है "ज़रूरत से ज़्यादा न भरना"। पिछले अध्याय का नियम याद है? एक फ़ीचर पर सिमटकर MVP पब्लिश करना — यह पर्सनल डेवलपमेंट में सबसे ज़्यादा तोड़ा जाने वाला, और सबसे ज़्यादा निभाने लायक नियम है।

"बना ही रहे हैं तो वह फ़ीचर भी, यह भी" — जिस पल आप लालच में पड़े, पूरा होना दूर हो गया। दो फ़ीचर हो जाएँ तो काम दुगना नहीं, उनके मेल की वजह से तिगुना-चौगुना फूल जाता है। एक व्यक्ति के समय और हौसले की सीमा होती है। शुरुआत में, बस एक "यह हो जाए तो वैल्यू है" पर पूरी तरह सिमट जाएँ।

❌ ज़्यादा भरना (Before)
रीडिंग-लॉग ऐप का उदाहरण

किताब दर्ज करना, राय-नोट, स्टार रेटिंग, पढ़ने के समय का ग्राफ़, दोस्तों से शेयर, AI से किताब की सिफ़ारिश, बारकोड स्कैन… सब कुछ भरना चाहते हैं, और चीज़ कभी पूरी नहीं होती।

✅ एक फ़ीचर पर सिमटें (After)
रीडिंग-लॉग ऐप का उदाहरण

बस "पढ़ी हुई किताब को एक लाइन की राय के साथ दर्ज करना"। लिस्ट में पलटकर देख पाना काफ़ी है। पहले पब्लिश करें, इस्तेमाल हो तो अगला जोड़ें।

✅ काटने की कसौटी है "इसके बिना बात बनती है या नहीं"। जिस फ़ीचर पर दुविधा हो, उसे पहले "बाद के लिए" वाले डिब्बे में डालें। फेंकना नहीं — पब्लिश के बाद सच में ज़रूरी हो तो जोड़ लें। पहला एक फ़ीचर चलकर किसी के काम आ जाए, तब आगे क्या जोड़ना है यह यूज़र की प्रतिक्रिया बता देती है।

आइडिया को एक लाइन में भाषा दें

जिस एक फ़ीचर पर सिमटे, अब उसे एक लाइन के शब्दों में ढालें। यही इस अध्याय का दिल है। दिमाग में तैरती धुंधली-सी छवि को "किसकी, कौन-सी परेशानी को, कैसे हल करता है" के साँचे में बैठा दें, तो आइडिया एकदम ठोस हो जाता है।

📝 एक-लाइन टेम्पलेट
【किसके】 लिए, 【कौन-सी परेशानी】 को, 【कैसे हल】 करने वाला ऐप।
उदाहरण:
"किताबें खूब पढ़ने वालों के लिए, पढ़ी किताब जल्दी भूल जाने की परेशानी को, एक लाइन की राय के साथ फटाफट दर्ज करके लिस्ट में पलटकर देखने लायक बनाने वाला ऐप।"

यह एक लाइन लिख पाएँ, तो आपका पर्सनल डेवलपमेंट आधा सफल हुआ जैसा है। आगे का सब कुछ — टेक्नोलॉजी चुनना, AI को निर्देश, पब्लिश के वक्त का परिचय-टेक्स्ट — इस एक लाइन को ही न डगमगाने वाली धुरी बना लेगा। जब अच्छे से न लिख पाएँ, तब यह भी AI से करवा लें। "इस फ़ीचर को, किसकी-कौन-सी परेशानी को-कैसे हल करता है, इस एक लाइन में बना दो" — ऐसा कहें, तो वह कई विकल्प निकाल देगा।

स्पेक में उतारें — AI डेवलपमेंट की बुनियाद

एक लाइन पक्की हो जाए, तो आखिर में उसे स्पेक (spec) बनाएँ। स्पेक यानी "क्या बनाना है, इसका डिज़ाइन-मेमो"। ज़्यादा मुश्किल न सोचें, बस स्क्रीन, डेटा और ऑपरेशन — इन तीन बातों को न्यूनतम रूप में लिख डालना काफ़ी है।

स्पेक क्यों अहम है? AI कोडिंग में, स्पेक ही सीधे बुनियाद बन जाता है। "ऐसा ऐप बना दो" कहकर सब कुछ फेंक देने से बेहतर है, स्क्रीन-डेटा-ऑपरेशन लिखा स्पेक सौंपना — तब AI कई गुना ज़्यादा सटीक कोड लौटाता है। इसी सोच को गहराई तक ले जाने वाला तरीका है स्पेक-ड्रिवन डेवलपमेंट (Spec-Driven Development), और पर्सनल डेवलपमेंट में भी यही सिद्धांत काम करता है।

🖼️ स्क्रीन

कौन-सी स्क्रीन चाहिए।
उदा.: रिकॉर्ड लिस्ट, रिकॉर्ड जोड़ना। ज़्यादातर 2–3 स्क्रीन में काम चल जाता है।

🗂️ डेटा

क्या सेव करना है।
उदा.: किताब का टाइटल, राय, दर्ज-तारीख़। बस फ़ील्ड्स की सूची बना दें।

👆 ऑपरेशन

यूज़र क्या कर सकता है।
उदा.: रिकॉर्ड जोड़ना, लिस्ट में देखना। जो कर सकते हैं उन्हें क्रिया के रूप में गिनाएँ।

इन तीनों को लिख डालना ही आपका पहला स्पेक है। मसलन रीडिंग-लॉग ऐप के लिए, कुछ ऐसा मेमो बनेगा।

📄 न्यूनतम स्पेक-मेमो का उदाहरण
स्क्रीन: ①रिकॉर्ड लिस्ट ②रिकॉर्ड जोड़ने का फ़ॉर्म
डेटा: किताब का टाइटल (टेक्स्ट) / राय (एक लाइन का टेक्स्ट) / दर्ज-तारीख़ (डेट)
ऑपरेशन: रिकॉर्ड जोड़ना, लिस्ट में नए से पुराने क्रम में देखना, रिकॉर्ड मिटाना

💡 स्पेक परफ़ेक्ट न भी हो, चलेगा। शुरू से ही सब कुछ लिख डालने की ज़रूरत नहीं। बनाते हुए "अरे, यह भी चाहिए" महसूस हो, तो जोड़ लें। अहम है "पहले बुनियाद वाला एक पन्ना अपने पास होना"। कोरे से शुरू करने के बजाय, एक ड्राफ़्ट हो तो AI और इंसान — दोनों कई गुना तेज़ बढ़ते हैं।

बिगिनर रूट / प्रैक्टिकल रूट कैसे बढ़ाएँ

यहाँ तक का "तय करना" काम, दोनों रूट में एक जैसा है। फ़र्क बस इतना है कि स्पेक को कितना औपचारिक रूप से लिखना है, और उसे किसे सौंपना है। अपने रूट के हिसाब से आगे बढ़ें।

🌱 बिगिनर रूट
नोट और AI चैट काफ़ी हैं

स्पेक को नोटपैड या कॉपी पर हाथ से लिखें, चलेगा। सजा-सँवरा दस्तावेज़ ज़रूरी नहीं। "स्क्रीन, डेटा, ऑपरेशन" को बुलेट में लिखकर, वही AI चैट में पेस्ट करके मंथन करें। "इस स्पेक में कोई कमी या विरोधाभास है?" पूछें, तो AI छेद भर देगा।

इस अध्याय का लक्ष्य: एक-लाइन की भाषा और तीन-बिंदु मेमो लिख पाना — बस इतना काफ़ी।

🔧 प्रैक्टिकल रूट
Markdown में स्पेक लिखें

स्पेक को Markdown फ़ाइल (उदा.: spec.md) में समेटकर, Claude Code या Cursor को सौंपें। AI एडिटर स्पेक पढ़कर इंप्लीमेंटेशन की बुनियाद बनाता है, इसलिए यहाँ जितना ध्यान दें, आगे उतना तेज़। लिखने का तरीका स्पेक-ड्रिवन डेवलपमेंट से समझें।

इस अध्याय का लक्ष्य: AI एडिटर को सौंपने लायक एक spec.md बन जाए — बस इतना काफ़ी।

दोनों में से किसी भी रूट में, इस अध्याय के अंत तक "एक-लाइन की भाषा" और "स्क्रीन-डेटा-ऑपरेशन का न्यूनतम स्पेक" आपके हाथ में हो — यही लक्ष्य है। यहाँ तक आ गए, तो बस बनाने की बुनियाद तैयार करना बाकी है। अगले फेज़ में बढ़ने की तैयारी हो गई।

सार और अगला अध्याय

इस अध्याय का सार
  • कोडिंग बाद में। पहले "क्या, किसके लिए बनाना है" तय करें, तो भटकते नहीं।
  • आइडिया अपने आसपास की परेशानी और अपनी चाहत से। AI से मंथन करके 10 निकालें, 1 चुनें।
  • पर्सनल डेवलपमेंट का नियम है "एक फ़ीचर पर सिमटना"। दुविधा वाला फ़ीचर "बाद के लिए" वाले डिब्बे में।
  • आइडिया को "किसकी, कौन-सी परेशानी को, कैसे हल करता है" की एक लाइन में भाषा दें।
  • स्पेक यानी स्क्रीन, डेटा, ऑपरेशन — न्यूनतम तीन बिंदु। AI कोडिंग में स्पेक ही बुनियाद बनता है।
  • बिगिनर के लिए नोट और AI चैट, प्रैक्टिकल के लिए Markdown का spec.md

"तय करना" फेज़ यहीं तक। आइडिया एक लाइन बन गया, न्यूनतम स्पेक हाथ में हो, तो अब बनाना शुरू करने से बस एक कदम पीछे हैं। अगला — उसे असल में किस टेक्नोलॉजी और टूल से बनाना है, यह तय करने वाला फेज़। पिछले अध्याय 1 "पूरी तस्वीर और रास्ता चुनना" पर लौटकर नक्शा दोबारा देख सकते हैं, या सीधे अध्याय 3 "टेक्नोलॉजी और टूल की तैयारी" की ओर बढ़ें। आपकी उस एक लाइन को रूप देने वाली बुनियाद बनने लगी है।