ऐप बनाने से पहले ऐप के विचार को कैसे परखें
किसी ऐप के विचार को परखने का मतलब है यह जानना कि क्या लोगों के एक खास समूह को यह समस्या है, क्या वे पहले से इसे हल करने की कोशिश कर रहे हैं, और क्या वे आपके समाधान के लिए कुछ असली चीज़ दे देंगे, जैसे समय, एक ईमेल या पैसा। बातचीत से शुरू करें, फिर landing page या waitlist पर जाएं, और pre-sale या लौटकर आने वाले user को सबसे मज़बूत सबूत मानें। हर कदम थोड़ा ज़्यादा लागत लेता है, और थोड़ा ज़्यादा बताता है।
परखना यह साबित नहीं करता कि विचार सफल होगा। यह उस संभावना को कम करता है कि आप ऐसी चीज़ पर महीनों लगा दें जिसे कोई न चाहे।
आप असल में क्या परख रहे हैं
“क्या यह अच्छा विचार है?” परखने के लिए बहुत धुंधला सवाल है। इसे ऐसे सवालों में तोड़ें जिनका जवाब आप दे सकें:
| सवाल | “हां” कैसा दिखता है |
|---|---|
| क्या समस्या मौजूद है? | लोग बिना पूछे अपने शब्दों में उसका वर्णन करते हैं |
| क्या यह काफ़ी दर्दनाक है? | उन्होंने workarounds, spreadsheets या दूसरे tools आज़माए हैं |
| यह किसे सबसे ज़्यादा है? | एक ही समूह बार-बार आता है: एक भूमिका, उद्योग या स्थिति |
| क्या वे पैसे देंगे? | वे पहले से उस पर पैसा या समय खर्च करते हैं, या pre-order करते हैं |
| क्या आप उन तक पहुंच सकते हैं? | आप जानते हैं वे कहां इकट्ठा होते हैं: एक forum, व्यापार समूह या newsletter |
आख़िरी सवाल अक्सर छूट जाता है। जो समस्या असली है पर जिन लोगों को वह है उन तक आप पहुंच नहीं सकते, वह फिर भी एक कठिन कारोबार है।
चरण 1: अपनी सबसे जोखिम वाली धारणा लिखें
किसी भी शोध से पहले, विचार को एक वाक्य में लिखें: “[कौन] [समस्या] से जूझता है और [समाधान] इस्तेमाल करेगा क्योंकि [कारण]।” फिर लिखें कि उसके काम करने के लिए क्या सच होना चाहिए, और उस बात पर गोला लगाएं जिसके बारे में आप सबसे कम निश्चित हैं। पहले वही परखें।
उदाहरण के लिए, कुत्तों के ग्रूमर्स के लिए एक scheduling ऐप की सबसे जोखिम भरी धारणा शायद यह न हो कि “ग्रूमर्स को scheduling चाहिए” — उन्हें स्पष्ट रूप से चाहिए — बल्कि यह हो कि “ग्रूमर्स अपने मौजूदा tool से इतने नाखुश हैं कि बदल दें।”
चरण 2: समस्या पर interviews
Interviews सबसे सस्ता, सबसे ज़्यादा संकेत देने वाला तरीका है, और इसे बुरी तरह करना भी सबसे आसान है। लक्ष्य व्यक्ति के मौजूदा व्यवहार के बारे में जानना है, न कि उसे अपना विचार बेचना।
किससे बात करें
ऐसे लोग जो आपके एक-वाक्य के विवरण से मेल खाते हों। दोस्त और परिवार अभ्यास के लिए ठीक हैं, पर वे ईमानदार के बजाय विनम्र होंगे। असली संभावित ग्राहक वहीं खोजें जहां वे पहले से हैं: उद्योग समूह, subreddits, स्थानीय व्यापार संघ, LinkedIn पर अपना नेटवर्क।
क्या पूछें
भविष्य की काल्पनिक बातों के बजाय अतीत के बारे में पूछें:
- “[समस्या] से आपका पिछली बार सामना कब हुआ था, बताइए।”
- “आपने उसके लिए क्या किया? कौन से tools इस्तेमाल किए?”
- “उसमें सबसे ज़्यादा परेशान करने वाली बात क्या थी?”
- “क्या आपने उसे ठीक करने के लिए कभी पैसे दिए हैं? क्यों या क्यों नहीं?”
- “ऐसा होने पर और कौन शामिल होता है?”
क्या न करें
- “क्या आप ऐसी ऐप इस्तेमाल करेंगे जो…?” लगभग हर कोई शिष्टाचार में हां कहेगा।
- अपना समाधान बहुत जल्दी दिखाना। एक बार वे उसे देख लें, तो वे अपनी समस्या बताने के बजाय उस पर प्रतिक्रिया देने लगते हैं।
- तारीफ़ें गिनना। “यह बहुत अच्छा विचार है” सबूत नहीं है। “जब यह तैयार हो तो क्या मैं इसे आज़मा सकता हूँ?” थोड़ा सबूत है। “यह मेरा कार्ड है” बहुत है।
नोट्स लें, और बाद में वे तीन बातें लिखें जो आपने सीखीं। जब कई लोग एक ही दर्द को मिलते-जुलते शब्दों में बताएं, तो वे शब्द लिख लें; वही आपके landing page की headline बनेंगे।
चरण 3: देखें कि पहले से क्या मौजूद है
अपने समाधान नहीं, समस्या को खोजें। मौजूदा उत्पाद, उनके pricing पेज और सार्वजनिक reviews देखें। प्रतिस्पर्धा आमतौर पर अच्छा संकेत है: इसका मतलब है कि लोग समस्या हल करने के लिए पैसे देते हैं। आप जिस चीज़ की तलाश में हैं वह एक अंतर (gap) है: एक समूह जिसे मौजूदा tools ठीक से नहीं सेवा देते, एक price point जिसे कोई नहीं छूता, या एक workflow जो अब भी spreadsheets में होता है।
अगर कुछ भी मौजूद नहीं है, तो पता लगाएं क्यों। कभी यह अवसर होता है; अक्सर इसका मतलब होता है कि समस्या पैसे देने लायक दर्दनाक नहीं है।
चरण 4: landing page से smoke test
Smoke test एक ऐसा पेज है जो उत्पाद का वर्णन ऐसे करता है जैसे वह मौजूद हो, साथ में एक साफ़ कार्रवाई: waitlist में जुड़ें, access मांगें, या pre-order करें। फिर आप सही लोगों को उस पर भेजते हैं और मापते हैं कि कितने लोग कार्रवाई करते हैं।
पेज को क्या चाहिए:
- एक headline जो समस्या को आपके interviewees के शब्दों में बताए।
- तीन या चार ठोस लाभ, यानी user के लिए क्या बदलता है।
- एक call to action।
- एक ईमानदार नोट कि उत्पाद विकास में है, ताकि किसी के साथ धोखा न लगे।
फिर ट्रैफ़िक वहां से लाएं जहां आपके audience हैं। किसी संकीर्ण audience पर छोटा paid ad test काम कर सकता है; समुदायों में पोस्ट करना भी, बशर्ते आप उनके नियम मानें। कनवर्ट करने वाला landing page कैसे बनाएं में संरचना और copy के बारे में बताया गया है।
नतीजे कैसे पढ़ें
कोई सार्वभौमिक “अच्छा” conversion rate नहीं होता, इसलिए खुद से तुलना करें: दो headlines या दो audiences आज़माएं और देखें कौन बेहतर करता है। सबसे उपयोगी नतीजा प्रतिशत नहीं, साइन अप करने वाले लोगों की सूची है। उन्हें ईमेल करें और कॉल मांगें।
चरण 5: waitlist बनाएं, और उसका इस्तेमाल करें
Waitlist लॉन्च से पहले इच्छुक लोगों के ईमेल इकट्ठा करती है। यह दो कारणों से उपयोगी है: इससे interview के लिए लोग मिलते हैं, और लॉन्च के दिन एक audience मिलता है।
इसकी कमज़ोरी यह है कि साइन अप करना लगभग मुफ़्त है। सूची को ज़्यादा काम करवाएं:
- साइन अप पर एक सवाल पूछें, जैसे “इसके लिए आप आज क्या इस्तेमाल करते हैं?”
- शुरुआती साइन-अप वालों को व्यक्तिगत जवाब दें और 15 मिनट मांगें।
- हर कुछ हफ़्तों में एक छोटा अपडेट भेजें, ताकि सूची ठंडी न पड़े।
waitlist पेज कैसे बनाएं में निर्माण के बारे में बताया गया है, जिसमें यह भी है कि ईमेल कहां स्टोर होते हैं।
चरण 6: पहले से बेचें या deposit लें
शुरुआती संकेत में सबसे मज़बूत पैसा है। शुरुआती पहुंच छूट पर, एक founding-member कीमत पर, या वापसी योग्य deposit पर पेशकश करें, और देखें कौन भुगतान करता है। इसके लिए आपके payment provider का payment link काफ़ी है; आपको तैयार उत्पाद की ज़रूरत नहीं।
सीधे रहें: बताएं कि आप कब तक देने की उम्मीद करते हैं, और जो कोई वापसी मांगे उसे पैसे लौटाएं। जो pre-sale कोई नहीं लेता, वह भी एक नतीजा है: हो सकता है कीमत गलत हो, audience गलत हो, या दर्द उतना तीखा न हो जितना interviews में लगा था।
चरण 7: Concierge और Wizard-of-Oz tests
कभी-कभी सबसे तेज़ “उत्पाद” आप खुद होते हैं।
- Concierge test: परिणाम हाथ से दें। अगर ऐप हर हफ़्ते रिपोर्ट बनाएगी, तो उन्हें खुद spreadsheet में बनाकर ईमेल करें। स्वचालित करने से पहले आप ठीक-ठीक जान लेते हैं कि users किस चीज़ को महत्व देते हैं।
- Wizard-of-Oz test: users एक सरल interface देखते हैं, पर उसके पीछे काम आप हाथ से करते हैं। User उत्पाद का अनुभव करता है; आप सीखते हैं कि वह लौटता है या नहीं।
दोनों को बढ़ाना धीमा है, और यही मकसद है। आप सिर्फ़ वही स्वचालित करते हैं जो करने लायक साबित हो चुका हो।
चरण 8: एक छोटा MVP बनाएं और व्यवहार देखें
Minimum viable product वह सबसे छोटा संस्करण है जो एक मुख्य काम करता है। AI app builders के साथ, database और login वाला एक काम करने वाला MVP महीनों के बजाय दिनों में बन सकता है, इसलिए उसे परखने का हिस्सा बनाना अब उचित है, देखें MVP क्या है।
मुख्य मीट्रिक साइन अप नहीं, लौटकर उपयोग है। क्या लोग बिना आपके उकसाए दूसरी और तीसरी बार वापस आते हैं? क्या वे किसी सहकर्मी को बुलाते हैं? क्या जब कुछ टूटता है तो वे शिकायत करते हैं? ये संकेत हैं कि ऐप उनके लिए मायने रखती है।
परखने के तरीकों की तुलना
| तरीका | लागत | समय | क्या साबित करता है | कहां भ्रमित करता है |
|---|---|---|---|---|
| समस्या पर interviews | मुफ़्त | दिन | समस्या असली है और लोग उसे कैसे बताते हैं | शिष्टाचार; गलत लोगों से बात करना |
| प्रतिस्पर्धा का शोध | मुफ़्त | घंटे | लोग पहले से उसे हल करने के लिए पैसे देते हैं | बिना जांचे मान लेना कि अंतर मौजूद है |
| Landing page smoke test | कम | दिन | संदेश क्लिक खींचता है | क्लिक प्रतिबद्धता नहीं है |
| Waitlist | कम | हफ़्ते | लगातार दिलचस्पी; लॉन्च का audience | ईमेल देना सस्ता है |
| Pre-sale / deposit | कम | दिन से हफ़्ते | पैसे देने की इच्छा | शुरुआती अपनाने वाले मुख्य धारा से अलग हो सकते हैं |
| Concierge test | आपका समय | हफ़्ते | परिणाम को महत्व मिलता है | आपको उत्पाद से अलग करना कठिन है |
| MVP | कम से मध्यम | दिन से हफ़्ते | असली उपयोग और बने रहना | कम उपयोग उत्पाद की समस्या हो सकता है, विचार की नहीं |
कब रुकें, बदलें या जारी रखें
शुरू करने से पहले अपनी सीमा तय करें, जैसे “दस interviews, तीन लोग कहें कि वे पैसे देंगे, एक pre-sale”। फिर ईमानदार रहें:
- जारी रखें अगर लोग उसी दर्द का वर्णन करते रहें और कुछ लोग समय या पैसा देने को तैयार हों।
- बदलें अगर दर्द असली है, पर किसी दूसरे समूह के लिए, या आपकी सोची हुई से अलग कीमत पर। यह आम है और उपयोगी भी।
- रुकें अगर किसी ने समस्या हल करने की कोशिश नहीं की, कोई पैसे नहीं देगा, और आप उन लोगों तक पहुंच नहीं सकते जिन्हें यह है।
जल्दी रुकना एक अच्छा नतीजा है। यह आपको अगला विचार परखने के लिए मुक्त करता है।
Mythex के साथ परखना
Mythex इस प्रक्रिया के बाद के चरणों में फ़िट होता है। आप एक waitlist फ़ॉर्म वाले landing page का वर्णन कर सकते हैं और उसी दिन वह एक सार्वजनिक URL पर लाइव हो सकता है, साइन-अप एक database में सेव होते हैं, और जब संकेत अच्छे हों तो वही प्रोजेक्ट एक छोटे MVP में बदला जा सकता है। शुरू करना मुफ़्त है, और docs में waitlist walkthrough चरण दिखाता है। अगर बजट पर विचार कर रहे हैं, तो ऐप बनाने में कितना खर्च आता है विकल्पों की तुलना करता है।
सवाल
ऐप के विचार को परखने का सबसे तेज़ तरीका क्या है?
उन पांच से दस लोगों से बात करें जिन्हें यह समस्या है, और उनसे पूछें कि वे आज क्या करते हैं, न कि अपना विचार बेचें। अगर वे समस्या को साफ़ बताते हैं, उसे हल करने की कोशिश कर चुके हैं और उस पर समय या पैसा खर्च कर रहे हैं, तो आपके पास एक ऐसा संकेत है जिसे landing page या pre-sale से आगे परखना चाहिए।
क्या waitlist विचार को परखने के लिए काफ़ी है?
अकेले नहीं। ईमेल से साइन अप करना लोगों के लिए लगभग मुफ़्त है, इसलिए waitlist दिलचस्पी दिखाती है, पैसे देने की इच्छा नहीं। इसे उन लोगों की सूची मानें जिनसे बात करनी है और जिन्हें बेचना है, और pre-orders या deposits जैसे मज़बूत संकेत खोजें।
मुझे कितने customer interviews चाहिए?
कोई जादुई संख्या नहीं है। तब तक जारी रखें जब तक जवाब आपको चौंकाना बंद न कर दें; एक संकीर्ण audience के लिए यह कुछ ही बातचीतों के बाद हो सकता है। अगर हर interview अलग कहानी बताए, तो आपका audience शायद बहुत व्यापक है।
क्या विचार को परखने के लिए MVP बनाना चाहिए, या बनाने से पहले परखें?
पहले सस्ती जांचें करें: interviews और landing page में दिन लगते हैं, हफ़्ते नहीं। AI app builders के साथ एक छोटा MVP भी अब सस्ता है, इसलिए उसे बनाना भी परखने का हिस्सा हो सकता है, बशर्ते आप उसे जल्दी असली users के सामने रखें और मापें कि वे वापस आते हैं या नहीं।