आपके एमवीपी रोडमैप में 47 विशेषताएं हैं। आप आश्वस्त हैं कि हर एक आवश्यक है। और वह दृढ़ विश्वास संभवतः आपकी हत्या कर देगास्टार्टअप.
यहां वह है जो आपको किसी ने नहीं बताया: सैकड़ों सॉफ्टवेयर कंपनियों के उपयोग डेटा के पेंडो विश्लेषण के अनुसार, औसत उत्पाद में 80% सुविधाएं शायद ही कभी या कभी भी उपयोग नहीं की जाती हैं। स्टैंडिश ग्रुप ने इसी तरह के परिणाम पाए, यह देखते हुए कि केवल 20% सॉफ़्टवेयर सुविधाओं का अक्सर उपयोग किया जाता है, जबकि 50% को शायद ही कभी छुआ जाता है।
आप वास्तव में अपने उपयोगकर्ताओं की अपेक्षा से पांच गुना अधिक निर्माण करने की योजना बना रहे हैं। वह महत्वाकांक्षा न��ीं है. इससे पहले कि आप कुछ भी उपयोगी सीख सकें, यह आपके रनवे पर जलने का एक नुस्खा है।
"एक उपयोगकर्ता, एक समस्या" विधि इस स्क्रिप्ट को फ़्लिप करती है। यह पूछने के बजाय कि "हमें कौन सी सुविधाएँ बनानी चाहिए?" आप एक अलग प्रश्न से शुरू करते हैं: "वह कौन व्यक्ति है जिसके लिए मैं एक समस्या का समाधान कर रहा हूं, और वह कौन सी ���बसे दर्दनाक चीज है जिसे मैं उनके लिए ठीक कर सकता हूं?"
इस दृष्टिकोण ने उन संस्थापकों की मदद की है जिनके साथ मैंने काम किया है, उनके शुरुआती दायरे को 60% या उससे अधिक कम कर दिया है, महीनों के बजाय हफ्तों में शिप किया है, और ब्लैक में रहते हुए भी उत्पाद-बाज़ार में फिट होने तक पहुंच गया है।
अधिकांश एमवीपी लॉ���्च होने से पहले विफल क्यों हो जाते हैं
सीबी इनसाइट्स ने 2023 से बंद हुए 431 वीसी-समर्थित स्टार्टअप का विश्लेषण किया। निष्कर्षों से हर संस्थापक को रुकना चाहिए। जबकि 70% ने मृत्यु का कारण "नकदी की कमी" बताया, यह लक्षण है, बीमारी नहीं। असली हत्यारे? ख़राब उत्पाद-बाज़ार फिट (43%), ख़राब समय (29%), और अस्थिर इकाई अर्थशास्त्र (19%)।
कुछ दिलचस्प बात पर ध्यान दें: इन कंपनियों ने असफल होने से पहले संयुक्त रूप से $17.5 बिलियन जुटाए। इस डेटासेट में औसत स्टार्टअप ने $11 मिलियन जुटाए। पैसा समस्या नहीं थी. फोकस था.
जो कंपनियाँ ख़त्म हो गईं वे इसलिए विफल नहीं हुईं क्योंकि उ���्होंने बहुत कम निर्माण किया था। वे असफल रहे क्योंकि उन्होंने बहुत लंबे समय तक गलत चीजें बनाईं।
अधिकांश संस्थापक अपने एमवीपी को अपनी पूर्ण दृष्टि के लघु संस्करण की तरह मानते हैं। वे अपने 50-फीचर रोडमैप को देखते हैं और 25 फीचर्स को "न्यूनतम" उत्पाद में निचोड़ने का प्रयास करते हैं। यह न्यूनतम नहीं है. यह अभी भी बहुत ज्यादा है.
उद्योग के आंकड़ों के अनुसार, औसत एमवीपी को बनने में तीन से चार महीने लगते हैं। वाई कॉम्बिनेटर और टेकस्टार्स ने पाया है कि सफल स्टार्टअप आम तौर पर विचार के दो से तीन महीने के भीतर अपना पहला एमवीपी लॉन्च करते हैं। आपके द्वारा जोड़ी गई प्रत्येक अतिरि��्त सुविधा आपको उस विंडो से और दूर ले जाती है।
और यहाँ क्रूर सत्य है: उत्पाद-बाज़ार में दो-तिहाई विफलताएँ शुरुआती चरण की कंपनियों में होती हैं जिन्हें कभी अपना बाज़ार नहीं मिला। जब वे किसी ऐसे व्यक्ति की तलाश कर रहे थे जो वास्तव में वह चाहता था जो वे बना रहे थे, तब भी उनका समय और पैसा ख़त्म हो गया।
रूपरेखा: एक उपयोगकर्ता, एक समस्या
एक उपयोगकर्ता, एक समस्या विधि आपको कोड की एक पंक्ति लिखने से पहले दो प्रश्नों का उत्तर देकर अत्यधिक सरलता प्रदान करती है।
प्रश्न 1: एक व्यक्ति कौन है?
"सहस्त्राब्दी पीढ़ी जो स्थिरता की परवाह करती है" नहीं। "छोटेव्यवसायमालिक" नहीं। एक विशिष्ट, वास्तविक इंसान जिससे आप वास्तव में बात कर सकते हैं।
यह डेनवर में एक एकल एकाउंटेंट सारा हो सकती है, जो ग्राहक दस्तावेजों का पीछा करने में सप्ताह में 12 घंटे बिताती है। या ऑस्टिन में एक खाद्य ट्रक मालिक मार्कस, जिसे हर महीने 400 डॉलर का नुकसान होता है क्योंकि वह सामग्री की मांग का अनुमान नहीं लगा सकता है। जितना अधिक विशिष्ट, उतना बेहतर.
जब आपके साथ काम कर रहे हों अनुकूलित एमवीपी विकास सेवाएँ, यह उपयोगकर्ता विशिष्टता आपका उत्तर सितारा बन जाती है। प्रत्येक फीचर निर्णय को एक साधारण परीक्षण के माध्यम से फ़िल्टर किया जाता है: क्या इससे सारा की दस्तावेज़-पीछा करने की ��मस्या हल हो जाती है? यदि नहीं, तो यह v1 में नहीं है।
प्रश्न 2: एक समस्या क्या है?
तीन समस्याएं नहीं. संबंधित दर्द बिंदुओं का समूह नहीं. एक चीज़ जो आपके उपयोगकर्ताओं के जीवन को काफी हद तक बदतर बना देती है, और वह यह कि वे अभी सक्रिय रूप से ���माधान करने का प्रयास कर रहे हैं।
सर्वोत्तम समस्याओं में तीन विशेषताएँ होती हैं:
- आवृत्ति: समस्या अक्सर इतनी घटित होती है कि बात बन जाती है। कोई व्यक्ति वर्ष में एक बार जिस दर्द बिंदु का अनुभव करता है, उसे दूर करने के लिए पर्याप्त अत्यावश्यक नहीं है।
- तीव्रता: जब ऐसा होता है, तो यह वास्तव में दुखदायी होता है। वे समय, पैसा, प्रतिष्ठा या नींद खो देते हैं।
- वर्तमान प्रयास: वे' आप पहले से ही इसे स्प्रेडशीट, मैन्युअल प्रक्रियाओं या डक्ट-टेप्ड वर्कअराउंड के साथ हल करने का प्रयास कर रहे हैं।
यदि आप तीनों को पार कर सकते हैं, तो आपको निर्माण योग्य कुछ मिल गया है।
वास्तव में अपने रोडमैप का 60% कैसे काटें
एक बार जब आप अपने एक उपयोगकर्ता और एक समस्या की पहचान कर लेते हैं, तो यह आपकी फीचर सूची का ऑडिट करने का समय है। यहीं पर अधिकांश संस्थापक चिड़चिड़े हो जाते हैं। हर चीज़ महत्वपूर्ण लगती है. कुछ भी काटने योग्य नहीं लगता.
यहां वह प्रक्रिया है जो काम करती है:
चरण 1: आपके द्वार�� नियोजित प्रत्येक सुविधा को लिखें।
उन सबको बाहर निकालो. एकीकरण, डैशबोर्ड, अधिसूचना प्रणाली, व्यवस्थापक पैनल और रिपोर्टिंग उपकरण। सब कुछ।
चरण 2: प्रत्येक सुविधा के लिए, पूछें: "क्या यह सीधे मेरे एक उपयोगकर्ता के लिए मेरी एक समस्या का समाधान करता है?"
नहीं "क्या यह किसी दिन उपयोगी हो सकता है?" नहीं "क्या यह डेमो में प्रभावशाली लगेगा?" क्या यह आपके द्वारा पहचाने गए मुख्य दर्द बिंदु को सीधे संबोधित करता है? हां या नहीं।
चरण 3: तीन बाल्टियों में क्रमबद्ध करें।
- कोर (सीधे एक समस्या का समाधान क���ता है)
- समर्थन करना (कोर कार्य को बेहतर बनाता है)
- (बाकी सब कुछ) पाकर अच्छा लगा
ईमानदार हो। अधिकांश संस्थापकों को पता चला कि उनकी नियोजित सुविधाओं का 70-80% भाग तीन में आते हैं।
चरण 4: केवल मुख्य सुविधाओं को v1 में शिप करें।
आपके पहले संस्करण में नाइस-टू-हैव बकेट से कुछ भी शामिल नहीं होना चाहिए और सपोर्टिंग से न्यूनतम आइटम शामिल होने चाहिए। यदि आप एक वाक्य में यह नहीं बता सकते कि कोई सुविधा आपके एक उपयोगकर्ता की एक समस्या को कैसे हल करती है, तो यह शिप नहीं होती है।
यह व्यवहार में ऐसा दिखता है। व्यक्तिगत प्रशिक्षकों के लिए शेड्यूलिंग ऐप बनाने वाला ��क संस्थापक इस प्रारंभिक फीचर सूची के साथ मेरे पास आया:
- Google, Apple और Outlook के साथ कैलेंडर समन्वयन
- ग्राहक प्रबंधन डैशबोर्ड
- एसएमएस और ईमेल के माध्यम से स्वचालित अनुस्मारक
- भुगतान प्रसंस्करण
- ग्राहकों के लिए प्रगति ट्रैकिंग
- वर्कआउट प्लान बिल्डर
- पोषण लॉगिंग
- इन-ऐप मैसेजिंग
- वीडियो कॉल एकीकरण
- एनालिटिक्स डैशबोर्ड
एक उपयोगकर्ता, एक समस्या फ़िल्टर लागू करने के बाद (एक उपयोगकर्ता: जेक नाम का स्वतंत्र व्यक्तिगत प्रशिक्षक जो ग्राहकों को खो देता है क्योंकि वे नियुक्तियाँ भूल जाते हैं; एक समस्या: शेड्यूलिंग भ्रम के कारण छूटे हुए सत्र), v1 बन गया:
- सत्र बुकिंग के साथ सरल कैलेंडर
- 24 घंटे पहले स्वचालित एसएमएस अनुस्मारक
इतना ही। दो विशेषताएं. एमवीपी छह सप्ताह में भेज दिया गया। जेक ने अपने वास्तविक ग्राहकों के साथ इसका परीक्षण किया। छूटे हुए सत्रों में 40% की गिरावट आई। इसके बाद ही संस्थापक ने अनुमानों के बजाय वास्तविक उपयोग डेटा द्वारा निर्देशित सुविधाओं को जोड़ना शुरू किया।
मनोविज्ञान का जाल: क्यों संस्थापक अति-निर्माण करते हैं
यह समझने से कि हम अति-स्कोप क्यों करते हैं, इसे रोकने में मदद मिलती है। तीन मनोवैज्ञानिक ताकतें संस्थापकों के खिलाफ काम करती हैं:
प्रतिस्पर्धात्मकता का भ्रम. आप प्रतिस्पर्धियों को सुविधा-संपन्न उत्पादों के साथ देखते हैं और मानते हैं कि आपको उनसे मुकाबला करने की आवश्यकता है। लेकिन उन सुविधाओं का निर्माण वर्षों में किया गया था, जो उस राजस्व से वित्त पोषित थे जो आपके पास अभी तक नहीं है। एमवीपी चरण में सुविधाओं पर प्रतिस्पर्धा करना एक हाई स्कूल के छात्र की तरह है जो एक पेशेवर एथलीट से आगे निकलने की कोशिश कर रहा है। अलग वजन वर्ग, अलग खेल।
निवेशकपिचविरूपण। आपने निवेशकों को अपने भव्य दृष्टिकोण के बारे में बताया है। अब ऐसा महसूस होता है कि आपको अपने प्रति उनके विश्वास को मान्य करने के लिए सब कुछ बनाने की आवश्यकता है। लेकिन अच्छे निवेशक विज़न और v1 के बीच अंतर जानते हैं। वे आपकी सीखने और अनुकूलन करने की क्षमता पर दांव लगा रहे हैं, न कि पहले दिन पूरा उत्पाद भेजने की आपकी क्षमता पर।
छोटेपन का डर. दो-फ़ीचर वाला एमवीपी शर्मनाक लगता है। इसे गंभीरता से लेना बहुत आसान लगता है। लेकिन ड्रॉपबॉक्स ने कुछ भी बनाने से पहले एक वीडियो के साथ अपनी पूरी अवधारणा को मान्य किया। बफ़र को एक लैंडिंग पृष्ठ और एक मूल्य निर्धारण तालिका के साथ लॉन्च किया गया। ज़ैप्पोस ने दुकानों से मैन्युअल रूप से जूते खरीदने और उन्हें ग्राहकों तक पहुंचाने से शुरुआत की। छोटे प्रथम संस्करण एक विशेषता हैं, बग नहीं।
वैलिडेशन लूप: आपके शिप करने के बाद क्या होता है
अपना दायरा कम करना अंत नहीं है। यह एक सीखने के चक्र की शुरुआत है जो वास्तव में काम करता है।
एक केंद्रित एमवीपी के साथ, आप छह महीने के बजाय आठ से बारह सप्ताह में लॉन्च कर सकते हैं। वह गति लाभ यौगिक। आप वास्तविक उपयोगकर्ता डेटा एकत्र करना शुरू करते हैं जबकि प्रतिस्पर्धी अभी भी इस बात पर बहस कर रहे हैं कि उनके विशिष्ट दस्तावेज़ में कौन सी सुविधाएँ शामिल की जाएं।
सत्यापन लूप इस तरह दिखता है:
- अपनी मुख्य सुविधाओं को उन उपयोगकर्ताओं के एक छोटे समूह को भेजें जो आपके एक उपयोगकर्ता प्रोफ़ाइल से मेल खाते हों।
- देखो वे वास्तव में क्या करते हैं। वह नहीं जो वे कहते हैं कि वे करेंगे। वे वास्तव में क्या करते हैं.
- समस्या मीट्रिक को मापें. यदि आप "छूटी हुई अपॉइंटमेंट" का समाधान कर रहे हैं, तो छूटी हुई अपॉइंटमेंट दर को ट्रैक करें। यदि आप "मैन्युअल डेटा प्रविष्टि पर बर्बाद समय" का समाधान कर रहे हैं, तो बचाए गए घंटों को मापें।
- व्यवहार के आधार पर पुनरावृति करें। सुविधाएँ केवल तभी जोड़ें जब उपयोगकर्ता प्रदर्शित करें कि आपने जो पहले ही बनाया है उसका मूल्य उन्होंने अधिकतम कर लिया है।
यह दृष्टिकोण स्टार्टअप निर्माण में सबसे महंगी गलती को रोकता है: उन सुविधाओं में महीनों का निवेश करना जिनका कोई उपयोग नहीं करता है।
वास्तविक संख्याएँ: काटने का दायरा वास्तव में क्या बचाता है
आइए गणित के बारे में ठोस जानकारी प्राप्त करें।
15-20 सुविधाओं वाले एक सामान्य एमवीपी में चार से छह महीने लगते हैं और टीम ���ंरचना और स्थान के आधार पर इसकी लागत $50,000-$150,000 होती है। तीन से पांच मुख्य विशेषताओं वाले एक केंद्रित एमवीपी में छह से बारह सप्ताह लगते हैं और इसकी लागत $15,000-$40,000 होती है।
यह सिर्फ लागत बचत नहीं है। यह एक टाइमलाइन बचत है जो आपको पुनरावृत्ति के लिए तीन से चार अतिरिक्त महीनों का रनवे देती है,विपणन, और उत्पाद-बाज़ार के लिए उपयुक्त खोजना।
अवसर लागत पर विचार करें. यदि आप यह जानने से पहले छह महीने बिताते हैं कि कोई आपका उत्पाद चाहता है या नहीं, और उत्तर "नहीं" निकलता है, तो आप आधा साल और अपनी अधिकांश प्रारंभिक पूंजी खो चुके हैं। यदि आप निर्माण में आठ सप्ताह बित���ते हैं और वही सबक सीखते हैं, तो आपके पास अभी भी काम करने के लिए समय और पैसा है।
जो स्टार्टअप जीवित रहते हैं वे वे होते हैं जो नकदी खत्म होने से पहले कई सीखने के चक्र चला सकते हैं। दायरे में कटौती का मतलब कम निर्माण करना नहीं है। यह तेजी से सीखने के बारे में है।
संकेत कि आपने बहुत ज़्यादा बाल काटे हैं (और इसे कैसे ठीक करें)
अनुशासित फोकस और किसी बेकार चीज़ को भेजने के बीच अंतर है। यहां बताया गया है कि कैसे बताएं कि आप बहुत दूर चले गए हैं:
आपका एमवीपी संपूर्ण अनुभव प्रदान नहीं करता है। उपयोगकर्ताओं को आपके उत्पाद को छोड़े बिना "मुझे यह समस्या है" से "यह समस्या हल हो गई है" तक जाने में सक्षम होना चाहिए। यदि आपका शेड्यूलिंग ऐप लोगों को अपॉइंटमेंट बुक करने की सुविधा देता है, लेकिन पुष्टिकरण प्राप्त नहीं करता है, तो आपने बहुत बड़ी गलती कर दी है। लक्ष्य एक पूर्ण लूप है, चाहे वह कितना भी छोटा क्यों न हो। उपयोगकर्ता को ऐसा महसूस होना चाहिए जैसे उन्होंने कुछ वास्तविक हासिल किया है।
उपयोगकर्ता यह नहीं समझ सकते कि आप क्या पेशकश कर रहे हैं। यदि आपकी एक समस्या के समाधान के लिए 10 मिनट के स्पष्टीकरण की आवश्यकता है, तो आपने या तो उस सहायक संदर्भ को काट दिया है जो वास्तव में आवश्यक था, या आपकी एक समस्या पर पर्याप्त ध्यान केंद्रित नहीं किया गया था। सर्वश्रेष्ठ एमवीपी स्व-व्याख्यात्मक हैं। एक नए उपयोगकर्ता को 30 सेकंड के भीतर समझ जाना चाहिए कि उन्���ें क्या मिल रहा है।
आप कुछ भी नहीं सीख रहे हैं. छोटी शिपिंग का उद्देश्य डेटा एकत्र करना है। यदि आपका एमवीपी इतना सीमित है कि उपयोगकर्ता आपको उपयोगी सिग्नल देने से पहले ही बाउंस हो जाते हैं, तो आपको उन्हें जोड़े रखने के लिए बस पर्याप्त जोड़ने की आवश्यकता है। याद रखें: एक एमवीपी जिसका उपयोग ��ोई नहीं करता वह आपको कुछ नहीं सिखाता। सार्थक व्यवहार उत्पन्न करने के लिए आपको पर्याप्त कार्यक्षमता की आवश्यकता है।
आपका "समाधान" नई समस्याएं पैदा करता है। कभी-कभी, फीचर ट्रांसफर में कटौती करने से उपयोगकर्ता को निराशा होती है। यदि आपकी सुव्यवस्थित चेकआउट प्रक्रिया के लिए ग्राहकों को शिपिंग लागतों की मैन्युअल रूप से गणना करने की आवश्यकता होती है, तो आपने अपनी जटिलता को उनके सिरदर्द के रूप में बदल दिया है। यह अतिसूक्ष्मवाद नहीं है; यह आलस्य है.
तीनों मामलों में समाधान एक ही है: अनुभव को पूरा करने के लिए आवश्यक न्यूनतम सुविधाएं वापस जोड़ें, फिर रुकें। अपनी संपूर्ण इच्छा सूची क��� पुनर्स्थापित करने के लिए इन मुद्दों को एक बहाने के रूप में उपयोग न करें।
समापन से पहले, यदि आपको कभी भी किसी को तुरंत ऑनलाइन खोजने की आवश्यकता हो, तो यहतेज़ लोग खोजक गाइड सार्वजनिक जानकारी को सुरक्षित रूप से ढूंढने के सबसे विश्वसनीय तरीके बताता है।
आरंभ ��रना: आपकी 24 घंटे की कार्य योजना
यदि आपने इसे अब तक पढ़ा है, तो संभवतः आप फीचर सूची पर बैठे हैं जो बहुत लंबी है। यहां बताया गया है कि अगले 24 घंटों में क्या करना है:
- अपने एक उपयोगकर्ता को पहचानें. एक विशिष्ट नाम (वास्तविक या आविष्कृत), उनका काम, उनकी दैनिक निराशाएँ और उनके लिए सफलता कैसी दिखती है, लिखें।
- अपनी एक समस्या को परिभाषित करें. इस वाक्य को पूरा करें: "हर हफ्ते, [एक उपयोगकर्ता] [समय/धन/अवसर] खो देता है क्योंकि [विशिष्ट समस्या]।" यदि आप नुकसान की मात्रा निर्धारित नहीं कर सकते हैं, तो आपको इतनी दर्दनाक समस्या नहीं मिली है।
- अपनी सुविधाओं का ऑडिट करें. ऊपर दिए गए फ़िल्टर प्रश्नों का उपयोग करके प्रत्येक नियोजित सुविधा को मूल, सहायक या उपयोगी के रूप में टैग करें।
- एक समय सीमा निर्धारित करें. ऐसी लॉन्च तिथि चुनें जो आठ से बारह सप्ताह बाद की हो। वास्तव में क्या प्राप्त करने योग्य है यह निर्धारित करने के लिए वहां से पीछे की ओर काम करें।
- ऐसे पांच लोगों से बात करें जो आपके एक उपयोगकर्ता से मेल खाते हों। कुछ और बनाने से पहले, पुष्टि करें कि आपकी एक समस्या वास्तविक है और आपकी मुख्य विशेषताएं इसे हल कर देंगी।
सर्वोत्तम एमवीपी बड़े उत्पादों के छोटे संस्करण नहीं हैं। वे विशिष्ट समस्याओं का संपूर्ण समाधान हैं। जब आप उस फोकस को हासिल कर लेते हैं, तो बाकी सब कुछ स्पष्ट हो जाता है: आगे क्या बनाना है, इसकी मार्केटिंग कैसे करनी है, किसे काम पर रखना है, कौन से मेट्रिक्स मायने रखते हैं।
अपने रोडमैप का 60% काटना कष्टदायक लगता है। लेकिन अपने स्टार्टअप को ख़त्म होते हुए देखना क्योंकि आपने ऐसी सुविधाएँ बनाईं जिनका उपयोग किसी ने नहीं किया? यही असली दर्द है जिससे आप बचने की कोशिश कर रहे हैं।
छोटा शुरू करो। केंद्रित रहो। ऐसी कोई चीज़ भेजें जो बाज़ार में मौजूद किसी भी अन्य चीज़ की तुलना में एक व्यक्ति की समस्या को बेहतर ढंग से हल ���र दे।
इस तरह आप बाकी सब कुछ बनाने के लिए पर्याप्त समय तक जीवित रहते हैं।