उत्पाद डेवलपमेंट

वो बदसूरत ऐप जिसे किसानों ने प्यार किया

प्रिया का पहला रियल ऐप बदसूरत था। कलर्स ग़लत थे। फ़ॉन्ट्स इनलगातार थे। "ऐड प्रोड्यूस" बटन कभी-कभी पुराने फ़ोन्स पर ग़ायब हो जाता था। हिंदी में टाइप करो तो सर्च काम नहीं करता। एक स्क्रीन पर टाइपो था — "ऑर्डर" की जगह "ओडर" लिखा था।

लेकिन हुआ ये: तीन हफ़्तों में, 47 किसान रोज़ इस्तेमाल कर रहे थे। इसलिए नहीं कि ख़ूबसूरत था। इसलिए कि जब द्वाराहाट के हरीश अंकल ने सुबह 8 बजे अपनी 500 kg राजमा ऐप पर लिस्ट की, तो 10 बजे तक तीन बायर्स मुक़ाबला कर रहे थे। उन्होंने ₹95/kg पर बेची — मंडी ट्रेडर ₹65/kg दे रहा था।

किसी ने टाइपो की शिकायत नहीं की। किसी ने कलर्स की बात नहीं की। सबको बस इससे मतलब था कि ऐप उनकी समस्या हल कर रहा है।

"प्रिया बेटी, ये फ़ोन वाली चीज़ बहुत काम की है," हरीश अंकल ने बोला। "हिंदी टाइपिंग वाली दिक्कत ठीक कर देना बस।"

उत्पाद डेवलपमेंट का सबसे ज़रूरी लेसन यही है: पहले असली समस्या हल करो, पॉलिश बाद में। बहुत सारे फ़ाउंडर्स महीनों लगाते हैं एक ऐसा उत्पाद बिल्कुल सही करने में जो कोई चाहता ही नहीं। प्रिया ने तीन हफ़्तों में कुछ बदसूरत बनाया जो लोग असलीी इस्तेमाल कर रहे थे।

एक भी लाइन ऑफ़ कोड लिखने से पहले: इस्तेमालर्स से बात करो

प्रिया ने ऐप वो नहीं बनाया जो उसे लगता था कि किसानों को चाहिए। उसने 50 किसानों से बात की — डेवलपर के एक भी लाइन ऑफ़ कोड लिखने से पहले।

सर्वेज़ नहीं। Google Forms नहीं। आमने-सामने बात, बग़ीचों में चारपाई पर बैठकर, मंडी के गेट पर सुबह 5 बजे।

क्या पूछा:

• "बताइए, फ़सल तैयार होने से लेकर पैसे मिलने तक क्या-क्या होता है?"
• "बेचने में सबसे तकलीफ़ वाली बात क्या है?"
• "अगर एक चीज़ बदल सकें बेचने के तरीक़े में, तो क्या बदलेंगे?"
• "स्मार्टफ़ोन इस्तेमाल करते हैं? WhatsApp? कभी ऑनलाइन कुछ ख़रीदा या बेचा?"
• "अगर एक ऐप हो जो आज के अलग-अलग बायर्स के रेट्स दिखाए, तो इस्तेमाल करेंगे?"

क्या सीखा (जो गेस नहीं कर पाती):

1. ज़्यादातर किसानों को सबसे अच्छा दाम नहीं चाहिए था। उन्हें सही दाम भरोसे से चाहिए था। रिलायबिलिटी ऑप्टिमाइज़ेशन से ज़्यादा मायने रखती थी।
2. पेमेंट कब मिलेगा ये उतना ही ज़रूरी था जितना कि कितना मिलेगा। एक बायर जो 3 दिन में पे करे, वो बेहतर था उससे जो 20% ज़्यादा दे लेकिन 3 हफ़्ते लगाए।
3. बहुत सारे किसान इंग्लिश में लिटरेट नहीं थे। पूरा ऐप हिंदी में और वॉइस नोट्स के साथ काम करना ज़रूरी था।
4. ट्रस्ट सब कुछ था। किसान किसी एनॉनिमस बायर से डील नहीं करेंगे। बायर का नाम, फ़ोटो, और पास्ट ट्रांज़ैक्शन्स देखना चाहते थे।
5. स्मार्टफ़ोन इस्तेमाल ज़्यादा था, लेकिन डेटा महँगा। ऐप को स्लो 2G कनेक्शन पर काम करना था और कम डेटा ख़र्च करना था।

इन पाँच इनसाइट्स ने हर उत्पाद फ़ैसला शेप किया। इनमें से कोई भी को-वर्किंग स्पेस के व्हाइटबोर्ड से नहीं आई। ये आईं किसानों के साथ बैठकर।

नियम ऑफ़ थम्ब: कुछ भी बनाने से पहले 30-50 पोटेंशियल इस्तेमालर्स से बात करो। ऐसे लोगों से नहीं जो पोलाइटली हाँ बोल दें। उन लोगों से जिनकी असलीी वो समस्या है जो तुम हल करना चाहते हो। अगर 50 लोग समस्या वाले नहीं मिल रहे, तो शायद समस्या इतनी बड़ी नहीं है।

MVP थिंकिंग: मिनिमम क्या है जो कोर समस्या हल करे?

MVP पिछले चैप्टर में इंट्रोड्यूस किया था। अब गहरे जाते हैं।

"मिनिमम" वर्ड सबसे मुश्किल है। हर फ़ाउंडर एक और फ़ीचर ऐड करना चाहता है। "अगर ये भी ऐड कर दें तो..." — ये उत्पाद डेवलपमेंट का सबसे ख़तरनाक सेंटेंस है।

प्रिया की कोर समस्या: किसान बायर्स नहीं ढूँढ पाते और करंट दामेस नहीं जानते।

उसके MVP में एग्ज़ैक्टली तीन चीज़ें चाहिए थीं:

1. किसान लिस्ट करे क्या है उसके पास (क्रॉप टाइप, क्वांटिटी, जगह, अपेक्षित दाम)
2. बायर ब्राउज़ करे लिस्टिंग्स और इंटरेस्ट दिखाए
3. दोनों को नोटिफ़िकेशन मिले जब मैच हो

बस। कोई पेमेंट प्रक्रियािंग नहीं। कोई लॉजिस्टिक्स कोऑर्डिनेशन नहीं। कोई गुणवत्ता ग्रेडिंग नहीं। कोई समीक्षा सिस्टम नहीं। कोई चैट नहीं। कोई एनालिटिक्स डैशबोर्ड नहीं।

ये सब फ़ीचर्स उपयोगी हैं। लेकिन कोर असंप्शन टेस्ट करने के लिए कोई ज़रूरी नहीं: क्या किसान और बायर्स सच में एक डिजिटल प्लेटफ़ॉर्म के थ्रू ट्रांज़ैक्ट करेंगे?

MVP में क्या डालना है कैसे तय करें:

ख़ुद से पूछो: "अगर उत्पाद सिर्फ़ एक काम कर सके, तो वो एक काम क्या हो?"

वो बनाओ। शिप करो। देखो क्या होता है।

फिर इस्तेमालर्स से पूछो: "एक चीज़ बताओ जो ये कर पाए और अभी नहीं कर पा रहा?"

वो अगला बनाओ।

ऐसे ही तुम ऐसे फ़ीचर्स बनाने से बचते हो जो किसी ने माँगे ही नहीं।

बिल्ड, टेस्ट, इटरेट

उत्पाद डेवलपमेंट सीधी लाइन नहीं है। ये लूप है।

छोटी चीज़ बनाओ
    → इस्तेमालर्स के हाथ में दो
        → देखो वो क्या करते हैं (न कि क्या बोलते हैं)
            → जो टूटा है ठीक करो
                → जो मिसिंग है ऐड करो
                    → दोबारा

प्रिया का इटरेशन साइकल कुछ ऐसा था:

वीक 1-3: फ़्रीलांस डेवलपर के साथ MVP बनाया। तीन स्क्रीन्स, बुनियादी फ़ंक्शनैलिटी।

वीक 4: WhatsApp ग्रुप वाले 23 किसानों को दिया। 5 किसानों के साथ बैठकर देखा कि वो कैसे इस्तेमाल करते हैं। कहाँ कन्फ़्इस्तेमाल होते हैं, पहले कहाँ टैप करते हैं, कहाँ छोड़ देते हैं।

वीक 5-6: टॉप 3 पेन पॉइंट्स फ़िक्स किए:

• हिंदी इनपुट काम नहीं कर रहा था → फ़िक्स किया
• प्रोड्यूस लिस्ट करने में 8 टैप्स लग रहे थे → 4 पर कम किया
• बायर जेन्यूइन है या नहीं, कोई तरीक़ा नहीं → बायर वेरिफ़िकेशन बैज ऐड किया

वीक 7-8: 60 किसानों तक एक्सपैंड किया। नई समस्याएँ आईं:

• रिमोट इलाक़ाज़ में कनेक्टिविटी ख़राब → ऑफ़लाइन मोड ऐड किया जो कनेक्ट होने पर सिंक करे
• बायर्स जगह से फ़िल्टर करना चाहते थे → जगह फ़िल्टर ऐड किया

वीक 9-12: 150 किसानों तक एक्सपैंड किया। ऐप स्टेबल हुआ। ट्रांज़ैक्शन्स प्रिया की मैन्युअल मदद के बिना होने लगे।

ध्यान दो उसने क्या नहीं किया: 6 महीने अकेले बैठकर बिल्कुल सही उत्पाद नहीं बनाया। 3 हफ़्तों में रफ़ चीज़ शिप कर दी और रियल यूसेज से सुधार किया।

उत्पाद डेवलपमेंट का 80/20 नियम: 80% इस्तेमालर्स 20% फ़ीचर्स इस्तेमाल करेंगे। वो 20% ढूँढो और एक्सीलेंट बनाओ। बाक़ी सब बाद में।

उत्पाद-मार्केट फ़िट: कैसे पता चलेगा?

उत्पाद-मार्केट फ़िट (PMF) वो मोमेंट है जब तुम्हारा उत्पाद साफ़ तौर पर एक स्ट्रॉन्ग मार्केट माँग सैटिस्फ़ाई कर रहा है। ये किसी भी स्टार्टअप का सबसे ज़रूरी माइलस्टोन है।

कैसे पता चलेगा कि PMF है?

सबसे सिंपल टेस्ट (Rahul Vohra, Superhuman): इस्तेमालर्स से पूछो, "अगर ये उत्पाद अब अवेलेबल न हो तो कैसा फ़ील होगा?"

• अगर 40%+ बोलें "बहुत डिसअपॉइंटेड" → शायद PMF है
• अगर 40% से कम → अभी नहीं

PMF के और साइन्स:

• इस्तेमालर्स बिना याद दिलाए वापस आते हैं (ऑर्गेनिक रिटेंशन)
• इस्तेमालर्स दूसरों को बताते हैं (ऑर्गेनिक बढ़त)
• इस्तेमालर्स ढूँढने में नहीं, माँग सँभालने में संघर्ष हो रहा है
• यूसेज मापदंड हर हफ़्ते ऊपर जा रहे हैं
• ऐसे बायर्स/साझेदार कॉन्टैक्ट कर रहे हैं जिनसे तुमने बात नहीं की

PMF नहीं है अगर:

• हर इस्तेमालर को पर्सनली कन्विंस करना पड़ता है
• इस्तेमालर्स साइन अप करते हैं लेकिन वापस नहीं आते
• लोग "नाइस आइडिया" बोलते हैं लेकिन इस्तेमाल नहीं करते
• बेस्ट बढ़त चैनल पेड ऐड्स है (हर इस्तेमालर के लिए पे करना पड़ रहा है)
• फ़ीचर्स ऐड कर रहे हो उम्मीद में कि कुछ काम कर जाए

प्रिया को पता चला कि अर्ली PMF आ गई जब किसान कॉल करके कम्प्लेन करने लगे कि ऐप डाउन है। अगर उत्पाद की केयर नहीं होती, तो कम्प्लेन क्यों करते? एंग्री इस्तेमालर्स जो चाहते हैं कि उत्पाद काम करे — ये पोलाइट इस्तेमालर्स से बेहतर साइन है जिन्हें फ़र्क़ ही नहीं पड़ता।

इस्तेमालर राय: गैदर और प्रायोरिटाइज़ कैसे करें

जब उत्पाद इस्तेमालर्स के हाथ में है, राय आएगा — कभी-कभी बहुत ज़्यादा। चुनौती ये है कि किस पर एक्शन लेना है।

राय कैसे गैदर करें:

1. इस्तेमालर्स को देखो, सिर्फ़ पूछो मत। लोग एक बात बोलते हैं, करते कुछ और हैं। प्रिया ने 5 मिनट किसान को ऐप इस्तेमाल करते देखकर ज़्यादा सीखा — बजाय पूछने के कि कौन सा फ़ीचर चाहिए।

2. बिहेवियर डेटा ट्रैक करो। इस्तेमालर्स कहाँ ड्रॉप ऑफ़ करते हैं? कौन सा फ़ीचर सबसे ज़्यादा इस्तेमाल होता है? कौन सी स्क्रीन छोड़ते हैं? सिंपल एनालिटिक्स टूल्स (Google Analytics भी) बता देते हैं क्या असलीी हो रहा है।

3. चर्न्ड इस्तेमालर्स से बात करो। जो लोग उत्पाद इस्तेमाल करना बंद कर चुके हैं, वो एक्टिव इस्तेमालर्स से ज़्यादा वैल्यूएबल हैं समस्याएँ समझने के लिए। "क्यों बंद किया?" — ये सबसे ज़रूरी सवाल है।

4. पावर इस्तेमालर्स से बात करो। तुम्हारे टॉप 10% इस्तेमालर्स उत्पाद के बारे में तुमसे ज़्यादा जानते हैं। उन्होंने वर्कअराउंड्स ढूँढे हैं, एज केसेस मिले हैं, ऐसे इस्तेमाल केसेस खोजे हैं जो तुमने सोचे नहीं।

5. उन लोगों के फ़ीचर रिक्वेस्ट्स इग्नोर करो जो उत्पाद इस्तेमाल ही नहीं करते। सबकी राय है। सिर्फ़ असली इस्तेमालर्स की राय मायने रखती है।

राय प्रायोरिटाइज़ कैसे करें:

प्रिया ने एक सिंपल Google Sheet बनाई: एक कॉलम राय के लिए, एक कितने इस्तेमालर्स ने मेंशन किया, एक सिवेरिटी (कोर इस्तेमाल ब्लॉक / एनॉयिंग / नाइस-टू-हैव)। हर हफ़्ते, वो और डेवलपर टॉप 3 आइटम्स पिक करके फ़िक्स करते। सिंपल सिस्टम, लेकिन काम कर गया।

नॉन-टेक्निकल फ़ाउंडर्स के लिए टेक फ़ैसले

प्रिया ने कॉलेज में कंप्यूटर साइंस पढ़ा था, तो टेक्निकल साइड समझती थी। लेकिन बहुत सारे फ़ाउंडर्स टेक्निकल नहीं हैं — और ये बिल्कुल ठीक है। कोडिंग आना ज़रूरी नहीं। टेक्नोलॉजी के बारे में अच्छे फ़ैसले लेना ज़रूरी है।

हर नॉन-टेक्निकल फ़ाउंडर को ये सवाल आंसर कर पाने चाहिए:

1. कौन सा प्लेटफ़ॉर्म? मोबाइल ऐप (Android, iOS, या दोनों)? वेब ऐप? WhatsApp बॉट? आंसर इस्तेमालर्स पर निर्भर करता है। प्रिया के किसान मोस्टली Android इस्तेमालर्स थे, लो-एंड फ़ोन्स — तो Android-फ़र्स्ट सही था।

2. नेटिव ऐप या क्रॉस-प्लेटफ़ॉर्म? नेटिव (Android और iOS के लिए अलग-अलग कोड) बेहतर प्रदर्शन देता है। क्रॉस-प्लेटफ़ॉर्म (React Native, Flutter) जल्दी और सस्ता बनता है। ज़्यादातर अर्ली-चरण स्टार्टअप्स के लिए क्रॉस-प्लेटफ़ॉर्म सही कॉल है।

3. डेटा कहाँ रहेगा? क्लाउड (AWS, Google Cloud, Azure) स्टार्टअप्स के लिए स्टैंडर्ड है। अपने सर्वर्स मत बनाओ। क्लाउड की लागत सर्वर डाउन होने की लागत के सामने बहुत कम है।

4. पेमेंट्स कैसे सँभालोगे? एग्ज़िस्टिंग पेमेंट गेटवेज़ इस्तेमाल करो (Razorpay, Cashfree, PhonePe for Business)। अपना पेमेंट सिस्टम कभी मत बनाओ।

कोड समझना ज़रूरी नहीं। ट्रेड-ऑफ़्स समझना ज़रूरी है।

डेवलपर्स हायर करें, आउटसोर्स करें, या नो-कोड?

नॉन-टेक्निकल फ़ाउंडर के लिए सबसे बड़ा फ़ैसला।

विकल्प 1: फ़ुल-टाइम डेवलपर हायर करो (या टेक्निकल को-फ़ाउंडर ढूँढो)

बेस्ट फ़ॉर: उत्पाद जहाँ टेक्नोलॉजी ही कोर बिज़नेस है (ज़्यादातर टेक स्टार्टअप्स)।

प्रोज़: उत्पाद डीपली समझते हैं। जल्दी इटरेट कर सकते हैं। कमिटेड हैं।

कॉन्स: महँगा (डीसेंट डेवलपर ₹6-15 लाख/ईयर)। ढूँढना, इवैल्यूएट करना, सँभालना — सब तुम्हारे ऊपर।

विकल्प 2: डेवलपमेंट एजेंसी या फ़्रीलांसर्स को आउटसोर्स करो

बेस्ट फ़ॉर: हायर करने से पहले कॉन्सेप्ट टेस्ट करने के लिए v1 बनाना।

प्रोज़: अपफ़्रंट सस्ता। तनख़्वाह कमिट किए बिना फ़िनिश्ड उत्पाद मिलता है।

कॉन्स: इस्तेमालर्स को तुम्हारी तरह नहीं समझते। कम्यूनिकेशन ओवरहेड। गुणवत्ता बहुत वेरी करती है। प्रोजेक्ट ख़त्म होने पर चले जाते हैं — और तुम ऐसा कोड बनाए रख करते हो जो समझ में नहीं आता।

प्रिया ने v1 के लिए यही किया — ₹2 लाख में फ़्रीलांस डेवलपर। टेस्टिंग के लिए काम चल गया। v2 बनाने के लिए फ़ुल-टाइम डेवलपर हायर किया।

विकल्प 3: नो-कोड / लो-कोड टूल्स

बेस्ट फ़ॉर: नॉन-टेक बिज़नेसेस जिन्हें सिंपल डिजिटल प्रेज़ेंस या वर्कफ़्लो चाहिए।

Bubble, Glide, Adalo, या Google Sheets + Zapier जैसे टूल्स बिना कोड लिखे सरप्राइज़िंगली फ़ंक्शनल उत्पाद बना सकते हैं।

प्रोज़: फ़ास्ट, सस्ता, डेवलपर नहीं चाहिए।

कॉन्स: लिमिटेड कस्टमाइज़ेशन। जेनेरिक फ़ील। स्केल करना मुश्किल। कॉम्प्लेक्स, डेटा-हेवी उत्पाद के लिए सूटेबल नहीं।

अंकिता का तरीक़ा: अंकिता टेक पर्सन नहीं है। उसका D2C पहाड़ी फ़ूड ब्रांड Shopify पर चलता है (नो-कोड ई-कॉमर्स), WhatsApp Business ग्राहक कम्यूनिकेशन के लिए, और Google Sheet भंडार ट्रैकिंग के लिए। कुल "टेक" लागत: ₹2,000/मंथ Shopify। डेवलपर की ज़रूरत ही नहीं। उसका उत्पाद खाना है, वेबसाइट नहीं।

डिज़ाइन मायने्स — लेकिन फ़ंक्शनैलिटी पहले

एक ख़ूबसूरत उत्पाद जो काम न करे — बेकार है। एक बदसूरत उत्पाद जो रियल समस्या हल करे — इस्तेमाल होगा।

लेकिन डिज़ाइन सिर्फ़ ख़ूबसूरती नहीं है। अच्छे डिज़ाइन का मतलब:

• इस्तेमालर्स बिना इंस्ट्रक्शन्स के समझ जाएँ क्या करना है। अगर ट्यूटोरियल चाहिए, तो डिज़ाइन नाकाम है।
• सबसे ज़रूरी एक्शन सबसे प्रॉमिनेंट हो। प्रिया के ऐप में "लिस्ट प्रोड्यूस" बटन फ़ार्मर की होम स्क्रीन पर सबसे बड़ा एलिमेंट है।
• इस्तेमालर्स के सबसे ख़राब डिवाइस पर काम करे। प्रिया ने ₹5,000 के Redmi फ़ोन पर 2G कनेक्शन पर टेस्ट किया। वहाँ काम किया तो हर जगह काम करेगा।
• निरंतरता। सेम कलर्स, सेम बटन स्टाइल्स, सेम पैटर्न्स हर जगह। इस्तेमालर्स एक बार सीखें और इंस्टिंक्ट से नेविगेट करें।

डिज़ाइन में निवेश कब करें:

• उत्पाद-मार्केट फ़िट के बाद। PMF से पहले फ़ंक्शनैलिटी ज़्यादा मायने रखती है।
• जब इस्तेमालर्स इंटरफ़ेस से कन्फ़्इस्तेमाल हो रहे हों (उन्हें संघर्ष करते देखो → डिज़ाइन फ़िक्स करो)
• जब कॉम्पिटीशन है और इस्तेमालर्स के पास अल्टरनेटिव्स हैं (बेटर डिज़ाइन = ट्रस्ट = कन्वर्शन्स)

अंकिता की उत्पाद डेवलपमेंट जर्नी

सारी उत्पाद डेवलपमेंट ऐप्स के बारे में नहीं होती। अंकिता के पहाड़ी फ़ूड ब्रांड ने भी अपना उत्पाद डेवलपमेंट साइकल किया:

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

फ़ेज़ 2: रियल ग्राहकों से टेस्टिंग 50 जार्स बनाकर हल्द्वानी के मार्केट स्टॉल पर बेचे। कुछ सोल्ड आउट हुए। कुछ नहीं बिके। क्या सीखा:

• भाँग की चटनी बेस्टसेलर थी (यूनीक, कहीं और नहीं मिलती)
• 500g जार बहुत बड़ा था — लोग पहले छोटी क्वांटिटी ट्राई करना चाहते थे
• लेबल हैंडमेड लग रहा था (क्योंकि था) — ज़्यादा दाम पॉइंट पर पेशेवर पैकेजिंग चाहिए

फ़ेज़ 3: स्टैंडर्डाइज़्ड रेसिपी फ़ूड उत्पाद डेवलपमेंट का सबसे मुश्किल हिस्सा: हर बार बिल्कुल वही टेस्ट आए। 10 जार्स बनाओ तो लगातार। 100 बनाओ तो वेरी कर जाता। दो महीने लगे एग्ज़ैक्ट मेज़रमेंट्स, टेम्परेचर्स, और प्रक्रियाेस डॉक्यूमेंट करने में।

फ़ेज़ 4: शेल्फ़ स्टेबिलिटी फ़्रेश चटनी 2 हफ़्ते चलती है। ई-कॉमर्स के लिए 6 महीने की शेल्फ़ लाइफ़ चाहिए। इसका मतलब:

• फ़ूड टेक्नोलॉजिस्ट के साथ काम (FSSAI कॉन्टैक्ट्स से मिला)
• प्रिज़र्वेटिव विकल्प टेस्ट करना (नैचुरल प्रिज़र्वेटिव्स चुने ताकि "पहाड़ी" पोज़ीशनिंग बनी रहे)
• सही वैक्यूम-सील्ड पैकेजिंग में निवेश करना

फ़ेज़ 5: D2C लॉन्च ये सब होने के बाद ही Shopify वेबसाइट पर लॉन्च किया। उत्पाद 8 महीने तक टेस्ट, स्टैंडर्डाइज़, और वैलिडेट हो चुका था रियल ग्राहकों से।

लेसन: चाहे उत्पाद ऐप हो या चटनी, प्रक्रिया सेम है। बिल्ड → टेस्ट → सुधार → रिपीट। उत्पाद सही होने तक स्केल मत करो।

फ़ीचर्स ऐड करना vs "नो" बोलना

उत्पाद डेवलपमेंट में सबसे मुश्किल वर्ड "नो" है।

हर इस्तेमालर का सजेशन है। हर निवेशक की ओपिनियन है। टीम के आइडियाज़ हैं। सब कुछ बनाने का टेम्प्टेशन है।

"यस" बोलने की लागत:

हर नया फ़ीचर:

• बनाने में टाइम लगता है (मतलब और चीज़ें नहीं बनतीं)
• बनाए रख करने में टाइम लगता है (हमेशा)
• उत्पाद सभी इस्तेमालर्स के लिए ज़्यादा कॉम्प्लेक्स हो जाता है
• टूटने वाली चीज़ें बढ़ जाती हैं
• ध्यान डाइल्यूट होता है

कैसे तय करें:

1. क्या ये कोर इस्तेमाल केस में मदद करता है? प्रिया का कोर इस्तेमाल केस: किसानों का प्रोड्यूस बायर्स को बेचना। वेदर फ़ोरकास्ट कूल है लेकिन कोर इस्तेमाल केस में मदद नहीं करता। बेटर दाम कम्पेरिज़न टूल करता है।

2. क्या मल्टीपल इस्तेमालर्स ने माँगा है? एक इस्तेमालर की रिक्वेस्ट एनेक्डोट है। 50 इस्तेमालर्स की रिक्वेस्ट डेटा है।

3. क्या करंट प्रायोरिटीज़ डिरेल किए बिना बना सकते हो? अगर टॉप प्रायोरिटी पेमेंट फ़्लो फ़िक्स करना है, तो "फ़ार्मर प्रोफ़ाइल" फ़ीचर बाद में।

4. क्या ग्रो करने में मदद करेगा? कुछ फ़ीचर्स एग्ज़िस्टिंग इस्तेमालर्स को ख़ुश नहीं करते लेकिन नए इस्तेमालर्स आकर्षित करते हैं। रेफ़रल, शेयरिंग, इंटीग्रेशन्स — ये बढ़त ड्राइव कर सकते हैं।

प्रिया की "नो" लिस्ट:

• फ़ार्मर्स के बीच चैट (कोर इस्तेमाल केस नहीं — WhatsApp इस्तेमाल करो)
• वेदर फ़ोरकास्ट्स (उपयोगी लेकिन दूसरे ऐप्स पहले से करते हैं)
• फ़ार्मर लोन्स (इम्पॉर्टेंट समस्या लेकिन बिल्कुल अलग बिज़नेस)
• इंग्लिश लैंग्वेज सपोर्ट (इस्तेमालर्स को ज़रूरत नहीं)

प्रिया की "यस" लिस्ट:

• हिंदी वॉइस इनपुट प्रोड्यूस लिस्टिंग्स के लिए (इस्तेमालर्स टाइपिंग में संघर्ष करते हैं)
• फ़ोटो अपलोड प्रोड्यूस के लिए (बायर्स देखना चाहते हैं क्या ख़रीद रहे हैं)
• पेमेंट ट्रैकिंग (बायर ने कब पे किया? कितना पेंडिंग है?)
• रिपीट ऑर्डर फ़ंक्शनैलिटी (बायर्स हर हफ़्ते सेम चीज़ ऑर्डर करते हैं)

की टेकअवेज़

1. ऐसा उत्पाद बनाओ जो रियल समस्या हल करे। पॉलिश बाद में।
2. कुछ भी बनाने से पहले 30-50 इस्तेमालर्स से बात करो। उन्हें देखो, सिर्फ़ पूछो मत।
3. MVP एक चीज़ अच्छे से करे, दस चीज़ें बुरे तरीक़े से नहीं।
4. बिल्ड → टेस्ट → इटरेट। जल्दी शिप करो, जल्दी सीखो।
5. उत्पाद-मार्केट फ़िट का मतलब — इस्तेमालर्स बिना पूछे वापस आएँ। "अगर ये ग़ायब हो जाए तो?" — यही टेस्ट है।
6. नॉन-टेक्निकल फ़ाउंडर्स: कोडिंग आना ज़रूरी नहीं, अच्छे टेक फ़ैसले लेना ज़रूरी है।
7. डिज़ाइन मायने रखता है, लेकिन फ़ंक्शनैलिटी के बाद।
8. फ़िज़िकल उत्पाद (अंकिता की चटनी) भी सेम लूप पालन करते हैं जो डिजिटल उत्पाद।
9. ज़्यादातर फ़ीचर रिक्वेस्ट्स को "नो" बोलो। कॉम्प्लेक्सिटी की लागत रियल है।

प्रिया के ऐप पर अब 500 किसान और 40 इंस्टीट्यूशनल बायर्स हैं। ट्रांज़ैक्शन्स बढ़ रहे हैं। लेकिन एक निवेशक पूछता है: "तुम्हारे मापदंड क्या हैं?" प्रिया के पास डाउनलोड्स हैं। लेकिन DAU? रिटेंशन? कोहॉर्ट एनालिसिस? कोई आइडिया नहीं। अगले चैप्टर में सीखेंगे वो नंबर्स जो सच में मायने रखते हैं।