7 एमवीपी गलतियाँ जो आपके रनवे पर असर डालती हैं

42% स्टार्टअप विफल हो जाते हैं क्योंकि उन्होंने कुछ ऐसा बनाया जो बाज़ार नहीं चाहता था।इसलिए नहीं कि कोड टूट गया. इसलिए नहीं कि सर्वर क्रैश हो गए. क्योंकि संस्थापकों ने ऐसी सुविधाओं के निर्माण में महीनों का समय बिताया, जिनकी किसी ने मांग नहीं की थी, फिर उनके पास पाठ्यक्रम-सही करने से पहले ही पैसा ख़त्म हो गया।

यह आँकड़ा सीबी इनसाइट्स के 101 असफल स्टार्टअप्स के पोस्टमार्टम विश्लेषण से आया है, और यह वर्षों से स्थिर है। पैटर्न हर बार एक ही होता है: एक मजबूत दृष्टि, वास्तविक तकनीकी प्रतिभा और संस्करण एक बनाने के लिए पर्याप्त धन वाली एक संस्थापक टीम। वे इसका निर्माण करते हैं। उन्होंने इसे लॉन्च किया. किसी को परवाह नहीं। रनवे ख़त्म हो गया है.

हमने सावी में 30 से अधिक स्टार्टअप के लिए एमवीपी बनाए हैं। जो लोग सफल होते हैं उनमें एक सामान्य विशेषता होती है: वे एमवीपी को एक सीखने के उपकरण के रूप में मानते हैं, उत्पाद लॉन्च के रूप में नहीं। जो विफल होते हैं उनकी एक अलग विशेषता होती है: वे एमवीपी को उस उत्पाद के लघु संस्करण के रूप में मानते हैं जिसकी वे तीन वर्षों में कल्पना करते हैं।

यहां वे सात गलतियां हैं जो हम अक्सर देखते हैं, और उनमें से प्रत्येक से कैसे बचा जाए।

सात एमवीपी गलतियाँ

1. अपने पहले दस उपयोगकर्ताओं के बजाय अपने दृष्टिकोण का निर्माण करें

आपका तीन-वर्षीय उत्पाद रोडमैप एक अनुमान है। एक शिक्षित अनुमान, लेकिन एक अनुमान. एमवीपी उस अनुमान में सबसे जोखिम भरी धारणाओं का परीक्षण करने के लिए मौजूद है, न कि पूरी चीज़ का एक छोटा संस्करण बनाने के लिए।

एक संस्थापक हमारे पास विक्रेता ऑनबोर्डिंग, कमीशन ट्रैकिंग, भुगतान स्वचालन और एक समीक्षा प्रणाली के साथ एक बहु-विक्रेता बाज़ार की चाहत में आया था। हमने पूछा: "आज कितने विक्रेताओं ने आपके प्लेटफ़ॉर्म पर बिक्री करने की प्रतिबद्धता जताई है?" जवाब था दो. दो विक्रेताओं को स्वचालित ऑनबोर्डिंग की आवश्यकता नहीं है। उन्हें एक फ़ोन कॉल और एक साझा स्प्रेडशीट की आवश्यकता है।

हमने ~$5,000 में एक एकल-विक्रेता स्टोरफ्रंट बनाया (हमारे दायरे के समान)।फ्रूटेक्सनिर्माण)। संस्थापक ने वास्तविक लेनदेन के साथ मांग को साबित किया, आठ और विक्रेताओं पर हस्ताक्षर किए, और फिर खर्च को वापस करने के लिए राजस्व के साथ बहु-विक्रेता सुविधाओं में निवेश किया। छठे महीने में उसने जो सुविधाएँ बनाईं, वे पहले महीने में उसकी कल्पना से भिन्न थीं, क्योंकि उसके पास डेटा था।

2. सुविधा को संपूर्णता के रूप में छिपाने देना

फ़ीचर क्रीप एमवीपी ब्लोट का #1 कारण है। यह अक्षमता से नहीं आता. यह चिंता से आता है. संस्थापकों को चिंता है कि यदि उत्पाद अधूरा लगेगा तो उपयोगकर्ता इसे उछाल देंगे। इसलिए वे लॉन्च से पहले बार-बार "एक और सुविधा" जोड़ते हैं, जब तक कि एमवीपी 6 महीने देर से और बजट से 3 गुना अधिक न हो जाए।

यहां एक उपयोगी परीक्षण है: अपनी सूची की प्रत्येक सुविधा के लिए, पूछें "क्या पहले 30 दिनों में इस सुविधा के कारण कोई उपयोगकर्ता हमें भुगतान करेगा या हमारी अनुशंसा करेगा?" यदि उत्तर नहीं है तो उसे काट दें। "चरण दो की ओर न बढ़ें।" इसे दस्तावेज़ से पूरी तरह काट दें. आप इसे बाद में कभी भी वापस जोड़ सकते हैं. आप उन महीनों को वापस नहीं जोड़ सकते जो आपने उन सुविधाओं के निर्माण में खर्च किए थे जिनमें सुई भी नहीं हिली थी।

अनुशासन ना कहने में है. तीन विशेषताओं वाला एक एमवीपी, जिनमें से प्रत्येक एक वास्तविक समस्या को हल करता है, बारह विशेषताओं वाले एक एमवीपी को मात देता है, जिनमें से प्रत्येक एक सैद्धांतिक समस्या को आधा हल करता है।

3. तकनीकी आधार की ओवर-इंजीनियरिंग

"हमें माइक्रोसर्विसेज की आवश्यकता है क्योंकि हम दस लाख उपयोगकर्ताओं तक पहुंचने की योजना बना रहे हैं।" नहीं आप नहीं। आपके पास शून्य उपयोगकर्ता हैं. PostgreSQL डेटाबेस वाला एक अखंड Next.js ऐप बिना किसी परेशानी के 10,000 समवर्ती उपयोगकर्ताओं को संभालता है। आप महीनों, संभवतः वर्षों तक उस संख्या तक नहीं पहुंचेंगे।

प्रत्येक सप्ताह जब आप रिफैक्टरिंग इंफ्रास्ट्रक्चर पर खर्च करते हैं तो वह शून्य बाजार सीखने का सप्ताह होता है। यह कोई अतिशयोक्ति नहीं है. आपके इंजीनियर उपयोगकर्ताओं से बात करने के बजाय Kubernetes कॉन्फ़िगरेशन लिख रहे हैं। वे एक ऐसे उत्पाद के लिए इवेंट-संचालित आर्किटेक्चर स्थापित कर रहे हैं जो प्रति दिन 12 अनुरोधों को संसाधित करता है।

जब हमने बनायाड्रॉपटैक्सी, हमने एक सीधे बहु-किरायेदार मोनोलिथ से शुरुआत की। एक तैनाती, किरायेदार स्कोपिंग वाला एक डेटाबेस, एक कोडबेस। यह अब पूरे भारत में कई टैक्सी ऑपरेटरों को सेवा प्रदान करता है। आर्किटेक्चर का विस्तार इसलिए हुआ क्योंकि हमने जल्दी ही स्मार्ट निर्णय ले लिए (उचित डेटा अलगाव, अनुक्रमित क्वेरीज़, सीडीएन-समर्थित संपत्तियां), इसलिए नहीं कि हमने पहले ही दिन एक वितरित प्रणाली बनाई।

उबाऊ तकनीक चुनें. Next.js, रिएक्ट, टाइपस्क्रिप्ट, पोस्टग्रेएसक्यूएल, टेलविंड सीएसएस। इन उपकरणों में विशाल पारिस्थितिकी तंत्र, व्यापक दस्तावेज़ीकरण और हजारों उत्पादन परिनियोजन हैं जिनसे आप सीख सकते हैं। आपके उपयोगकर्ताओं द्वारा सामने आने वाली समस्याओं के लिए इंजीनियरिंग जटिलता को बचाएं, न कि उन समस्याओं के लिए जिनकी आप कल्पना करते हैं।

4. कोड लिखने से पहले उपयोगकर्ता की बातचीत को छोड़ देना

सीखने की गति ही एकमात्र मीट्रिक है जो एमवीपी चरण में मायने रखती है। कोड की पंक्तियाँ नहीं. परिनियोजन आवृत्ति नहीं. परीक्षण कवरेज नहीं. आप कितनी तेजी से सीख रहे हैं कि आपका बाज़ार क्या चाहता है?

कोड की एक पंक्ति लिखने से पहले सबसे तेज़ सीख होती है। संभावित उपयोगकर्ताओं के साथ पांच वार्तालाप आपको पांच सप्ताह के विकास के अलावा क्या बनाना है इसके बारे में अधिक बताएंगे। उन वार्तालापों का कोई मूल्य नहीं है। विकास में वास्तविक पैसा खर्च होता है।

एक ठोस दृष्टिकोण: किसी इंजीनियर को जानकारी देने से पहले, अपने लक्षित बाज़ार में दस लोगों का साक्षात्कार लें। उनसे पूछें कि जिस समस्या को आप लक्षित कर रहे हैं उसे हल करने के लिए वे आज क्या करते हैं। पूछें कि उनके वर्तमान समाधान के बारे में उन्हें क्या परेशान करता है। पूछें कि झुंझलाहट गायब करने के लिए वे क्या भुगतान करेंगे। उत्तरों को शब्दशः रिकार्ड करें। आप पाँच या छह वार्तालापों में पैटर्न देखेंगे। उन पैटर्न के लिए निर्माण करें, अपनी धारणाओं के लिए नहीं।

5. मांग को मान्य करने से पहले डिजाइन पर बहुत अधिक खर्च करना

कस्टम चित्रण, एनिमेटेड ट्रांज़िशन, आठ ब्रेकप्वाइंट पर पिक्सेल-परफेक्ट रिस्पॉन्सिव लेआउट। इनकी कीमत $5,000-$15,000 है। एक एमवीपी के लिए जो चौथे सप्ताह में बदल सकता है, यह एक बुरा निवेश है।

आपके ब्रांड रंगों के साथ shadcn/ui जैसी घटक लाइब्रेरी पर निर्मित एक साफ़ UI की कीमत $1,000-$2,000 है। उपयोगकर्ता "बदसूरत" और "स्वच्छ लेकिन सरल" के बीच अंतर बता सकते हैं। जब वे मूल्यांकन कर रहे होते हैं कि आपका उत्पाद उनकी समस्या का समाधान करता है या नहीं, तो वे "स्वच्छ लेकिन सरल" और "$15,000 कस्टम डिज़ाइन" के बीच अंतर नहीं बता सकते हैं।

आपके पास 50 से अधिक भुगतान करने वाले उपयोगकर्ता होने के बाद डिज़ाइन में निवेश करें। उस बिंदु पर, आप जानते हैं कि कौन सी स्क्रीन मायने रखती है, कौन से प्रवाह से सबसे अधिक ट्रैफ़िक मिलता है, और उपयोगकर्ता कहाँ छूटते हैं। आप यह अनुमान लगाने के बजाय कि कौन से पृष्ठ महत्वपूर्ण होंगे, अपना डिज़ाइन बजट राजस्व बढ़ाने वाली स्क्रीन पर खर्च कर सकते हैं।

6. गलत विकास भागीदार चुनना

यहां तीन सामान्य जाल हैं। पहला: एक बड़ी एजेंसी को नियुक्त करना जो आपके $15,000 एमवीपी के लिए एक प्रोजेक्ट मैनेजर, एक डिजाइनर, दो फ्रंटएंड डेवलपर्स, एक बैकएंड डेवलपर और एक क्यूए इंजीनियर नियुक्त करती है। आपका आधा बजट समन्वय पर खर्च हो जाता है। प्रोजेक्ट मैनेजर आपका फीडबैक डिजाइनर को भेजता है, जो इसे डेवलपर को भेजता है, जो इसकी गलत व्याख्या करता है और गलत चीज बनाता है। दो सप्ताह बर्बाद हो गये.

दूसरा: अपवर्क पर सबसे सस्ते फ्रीलांसर को काम पर रखना। $15/घंटा डेवलपर कोड वितरित करता है जो डेमो में काम करता है और उत्पादन में बाधा डालता है। आप प्रारंभिक निर्माण पर $8,000 खर्च करते हैं और इसे किसी और के साथ ठीक कराने पर $12,000 खर्च करते हैं। कुल लागत: $20,000, और आपने चार महीने देर से लॉन्च किया।

तीसरा: घर में बहुत जल्दी निर्माण करना। 120,000 डॉलर प्रति वर्ष पर दो पूर्णकालिक इंजीनियरों को नियुक्त करने का मतलब है कि आप एक भी उपयोगकर्ता होने से पहले 20,000 डॉलर प्रति माह खर्च कर रहे हैं। 6 सप्ताह लगने वाले एमवीपी के लिए, आपने वेतन, लाभ, उपकरण और प्रबंधन समय के रूप में $30,000 का भुगतान किया है।

एमवीपी के लिए सही भागीदार वरिष्ठ इंजीनियरों (एक या दो लोगों) की एक छोटी टीम है जो पूर्ण स्टैक का मालिक है। आप कोड लिखने वाले व्यक्ति से सीधे बात करें। कोई हैंडऑफ़ नहीं. कोई टेलीफोन गेम नहीं. सावी में, हमारे एमवीपी ग्राहक उस इंजीनियर से बात करते हैं जो पहली कॉल पर उनका उत्पाद तैयार करेगा, बिक्री प्रतिनिधि से नहीं।

7. लगातार लॉन्च करने के बजाय एक बार लॉन्च करना

"बड़ा खुलासा" लॉन्च हार्डवेयर कंपनियों की ओर से एक होल्डओवर है। सॉफ़्टवेयर उस तरह से काम नहीं करता. यदि आप निर्माण में चार महीने मौन रहकर बिताते हैं और फिर एक प्रेस विज्ञप्ति के साथ लॉन्च करते हैं, तो आपको एक डेटा बिंदु मिलता है: पहले दिन कितने लोगों ने साइन अप किया। निर्णय लेने के लिए यह पर्याप्त डेटा नहीं है.

एक बेहतर तरीका: दूसरे सप्ताह में पांच उपयोगकर्ताओं के लिए एक कार्यशील संस्करण तैनात करना। प्रतिक्रिया प्राप्त करें. तीसरे सप्ताह में अपडेट भेजें। अधिक प्रतिक्रिया प्राप्त करें. जब आप छठे सप्ताह में अपना "सार्वजनिक लॉन्च" करते हैं, तब तक आप वास्तविक उपयोग के आधार पर पहले ही तीन संस्करणों को दोहरा चुके होते हैं। आपका उत्पाद अधिक सख्त है. आपका संदेश अधिक तीव्र है. आपका ऑनबोर्डिंग प्रवाह यह दर्शाता है कि लोग उत्पाद का उपयोग कैसे करते हैं, न कि यह कि आपने उनकी कल्पना कैसे की थी।

फ्रूटेक्स स्टोरफ्रंट दूसरे सप्ताह में अपने पहले डिलीवरी ज़ोन के साथ लाइव हो गया। संस्थापक ने 15 ग्राहकों के साथ इसका परीक्षण किया, पाया कि चेकआउट प्रवाह के लिए एक पिनकोड सत्यापन चरण की आवश्यकता थी जिसकी उसने अपेक्षा नहीं की थी, और हमने इसे दो दिनों में जोड़ दिया। "लॉन्च दिवस" ​​तक उस बग को ठीक कर दिया गया था और तीन और ज़ोन लाइव थे। सीख इसलिए हुई क्योंकि उत्पाद जल्दी ही उपयोगकर्ताओं के हाथ में था।

एमवीपी मानसिकता जो काम करती है

सावी में हमारे द्वारा भेजे गए प्रत्येक सफल एमवीपी ने एक सरल ढांचे का पालन किया है:

• एक उपयोगकर्ता प्रकार.दूसरों को जोड़ने से पहले एक व्यक्तित्व की अच्छी तरह सेवा करें।
• एक कोर प्रवाह.प्राथमिक उपयोगकर्ता यात्रा को सफल बनाएं। बाकी सब कुछ ध्यान भटकाने वाला है।
• बोरिंग टेक स्टैक.Next.js, टाइपस्क्रिप्ट, PostgreSQL। सिद्ध उपकरण जो आपके इंजीनियर को आपकी व्यावसायिक समस्या पर ध्यान केंद्रित करने देते हैं।
• 3-6 सप्ताह की समयरेखा.कुछ वास्तविक बनाने के लिए पर्याप्त लंबा। दायरे के बारे में ईमानदार रहने के लिए पर्याप्त छोटा।
• लॉन्च से पहले उपयोगकर्ता.दूसरे सप्ताह तक उत्पाद को वास्तविक हाथों में पहुंचाएं। वहां से पुनरावृति करें.

लक्ष्य आपके सपनों के उत्पाद का लघु संस्करण भेजना नहीं है। लक्ष्य यह जानना है कि क्या आपकी मूल धारणा सही है। क्या बाज़ार वह चाहता है जो आप बना रहे हैं? क्या लोग इसके लिए भुगतान करेंगे? उपयोगकर्ता यात्रा कहाँ रुकती है?

आप चार सप्ताह में $5,000 एमवीपी के साथ उन प्रश्नों का उत्तर दे सकते हैं। या आप $50,000 और छह महीने खर्च करके एक पूर्ण उत्पाद तैयार कर सकते हैं जो इनमें से किसी का भी जवाब नहीं देता। 42% स्टार्टअप जो गलत चीज़ का निर्माण करके विफल हो जाते हैं, उन्होंने दूसरा रास्ता चुना। आपको नहीं करना है।

अक्सर पूछे जाने वाले प्रश्नों