एमवीपी और उत्पाद विकास: सबसे छोटा सत्यापन योग्य उत्पाद

लाभ:

• एमवीपी (न्यूनतम व्यवहार्य उत्पाद) की अवधारणा और 'सबसे छोटी शिक्षण इकाई' के तर्क को समझने और कृत्रिम बुद्धिमत्ता के साथ दायरा निर्धारित करने की क्षमता
• सुविधा प्राथमिकता (MoSCoW, प्रभाव-प्रयास) और कृत्रिम बुद्धिमत्ता-समर्थित तीव्र प्रोटोटाइप/लैंडिंग पृष्ठ उत्पादन को लागू करने की क्षमता
• यह समझना कि एमवीपी का उद्देश्य सीखना है, बेचना नहीं, और अति-इंजीनियरिंग स्टार्टअप की सबसे महंगी गलती है।

संस्थापकों द्वारा की जाने वाली सबसे महंगी गलती एक ऐसे उत्पाद को बेहतर बनाने में महीनों खर्च करना है जिसके बारे में उन्हें यकीन नहीं है कि कोई भी इसे चाहता है। जब वे बाज़ार जाते हैं, तो उन्हें पता चलता है कि या तो समस्या ग़लत थी या समाधान। इस आपदा से बचने का तरीका एमवीपी है: न्यूनतम व्यवहार्य उत्पाद - सबसे छोटा उत्पाद संस्करण जो कम से कम प्रयास में सबसे अधिक सीख प्रदान करेगा। इस इकाई में, हम एमवीपी के दायरे को निर्धारित करने, सुविधाओं को प्राथमिकता देने और तेजी से प्रोटोटाइप/टीज़र तैयार करने के लिए एआई (कृत्रिम बुद्धिमत्ता) का उपयोग करेंगे। सबसे महत्वपूर्ण वाक्य: एमवीपी का उद्देश्य सीखना है, बेचना नहीं; सबसे महँगी गलती अपुष्ट धारणाओं को अति-इंजीनियरिंग करना है।

एमवीपी क्या है और क्या नहीं?

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

एमवीपी का विपरीत ओवर-इंजीनियरिंग है - सुविधाओं, पैमाने और पूर्णता पर खर्च किया गया प्रयास जिनकी अभी तक आवश्यकता नहीं है - और सोना चढ़ाना - पॉलिशिंग विवरण कोई भी नहीं चाहता है। ये स्टार्टअप के सबसे घातक पैसे और समय के हत्यारे हैं; क्योंकि उन्हें लगता है कि वे "काम" कर रहे हैं लेकिन सीखने में देरी करते हैं।

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

सुविधा प्राथमिकता

चूंकि कोई असीमित समय और पैसा नहीं है, इसलिए यह तय करना आवश्यक है कि कौन सी सुविधा पहले बनाई जाएगी। दो व्यावहारिक तरीके:

MoSCoW: सुविधाओं को चार भागों में विभाजित करता है - अवश्य, चाहिए, हो सकता है, नहीं। एमवीपी बस एक "आवश्यक" सेट है।

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

चरण दर चरण: एआई के साथ एमवीपी डिजाइन

1. सीखने का प्रश्न लिखें. "यह एमवीपी किस एकल धारणा का परीक्षण करेगा?"
2. उम्मीदवार की विशेषताएं सूचीबद्ध करें. अपने मन की सारी बातें उड़ेल दो।
3. एआई को प्राथमिकता दें। MoSCoW या प्रभाव-प्रयास के साथ निकालें; "अवश्य" क्लस्टर ढूंढें।
4. सबसे हल्का रूप चुनें. क्या किसी कोड की आवश्यकता है या लैंडिंग पृष्ठ/वीडियो/मैन्युअल सेवा पर्याप्त है?
5. प्रोटोटाइप/पेज तैयार करें। श्वेतपत्र पाठ, प्रवाह, या छद्म कोड ड्राफ्ट के लिए AI से पूछें।
6. अपनी सफलता के मानदंड पहले से परिभाषित करें। "अगर मैं यह परिणाम देखता हूं, तो धारणा की पुष्टि हो जाती है।"
7. प्रकाशित करें और जानें. वास्तविक व्यवहार को मापें; संस्थापक निर्णय लेता है.

तीन मिनी मामले

केस 1 - बिना कोड लिखे एमवीपी। एक संस्थापक एक ऐसे ऐप के बारे में सोच रहा था जो घर का बना खाना बेचने वाले पड़ोसियों को ग्राहकों से जोड़े। कोड लिखने में महीनों बिताने के बजाय, उन्होंने एक डेमो पेज और एक व्हाट्सएप लाइन से शुरुआत की; मैन्युअल रूप से मिलान किए गए ऑर्डर ("विज़ार्ड पीछे" विधि)। उन्हें दो सप्ताह में 40 वास्तविक ऑर्डर प्राप्त हुए और पता चला कि असली बाधा डिलीवरी लॉजिस्टिक्स थी। यदि उसने कोड लिखा होता, तो उसे यह महीनों बाद पता चलता। एमवीपी ने सीखने को आगे बढ़ाया।

केस 2 - अति-इंजीनियरिंग जाल। एक टीम ने एक ऐसा बुनियादी ढांचा तैयार करने में 4 महीने का समय बिताया, जो "लाखों उपयोगकर्ताओं तक पहुंच सके" जबकि उसके पास अभी तक एक भी ग्राहक नहीं था। जब उत्पाद सामने आया, तो कोई भी इसे नहीं चाहता था; समस्या ग़लत थी. खर्च किया गया लगभग सारा प्रयास बर्बाद हो गया। पाठ: कर्षण समस्या को हल करने के बाद स्केल समस्या एक विलासिता है; पहले साबित करो कि कोई क्या चाहता है.

केस 3 - प्राथमिकता देने की शक्ति। एक संस्थापक के पास 30 विशेषताओं की एक सूची थी। उन्होंने एआई से एक प्रभाव-प्रयास मैट्रिक्स बनाया और वास्तविक ग्राहक वार्तालापों से संकेत के साथ "प्रभाव" कॉलम को सही किया। 30 सुविधाओं में से केवल 4 ही "आवश्यक" साबित हुईं। 6 महीने के बजाय 3 सप्ताह में एमवीपी जारी किया गया; ग्राहक ने दिखाया कि शेष 26 सुविधाओं में से अधिकांश की बिल्कुल भी आवश्यकता नहीं थी।

चार प्रतिलिपि योग्य टेम्पलेट

1) सीखने का प्रश्न + एमवीपी दायरा:

आपकी भूमिका: लीन उत्पाद कोच। मैं जिस धारणा का परीक्षण करना चाहता हूं वह है:[उदा. "व्यापारी संग्रह के लिए मासिक भुगतान करते हैं"]। (1) इस धारणा को सत्यापित करने के लिए आवश्यक सबसे छोटे उत्पाद का वर्णन करें, (2) दिखाएं कि क्या इसका कोई ऐसा संस्करण संभव है जिसके लिए किसी कोड (लैंडिंग पृष्ठ, वीडियो, मैन्युअल सेवा) की आवश्यकता नहीं है, (3) "आकर्षक लेकिन अनावश्यक" सुविधाओं के बारे में चेतावनी दें जिन्हें इसे एमवीपी में शामिल नहीं किया जाना चाहिए।

2) MoSCoW प्राथमिकता:

सुविधाओं की निम्नलिखित सूची को MoSCoW में विभाजित करें: अवश्य / चाहिए / हो सकता है / नहीं होगा। केवल वे जो "उस धारणा के लिए आवश्यक हैं जिसका मैं परीक्षण करना चाहता हूं" को शामिल किया जाना चाहिए। एक वाक्य में लिखें कि प्रत्येक सुविधा उस क्लस्टर में क्यों है। सूची: [विशेषताएं]।

3) प्रभाव-प्रयास मैट्रिक्स:

निम्नलिखित विशेषताओं को "ग्राहकों पर प्रभाव (1-5)" और "करने का प्रयास (1-5)" अक्षों पर स्कोर करें और उन्हें 4 चतुर्थांशों में रखें। उच्च प्रभाव-कम प्रयास वाले को "पहले करें" के रूप में चिह्नित करें, और कम प्रभाव-उच्च प्रयास वाले को "नहीं करें" के रूप में चिह्नित करें। मुझे याद दिलाएं कि प्रभाव स्कोर को मेरे वास्तविक ग्राहक जुड़ाव के विरुद्ध मान्य किया जाना चाहिए। सूची: [विशेषताएं]।

4) लैंडिंग पेज टेक्स्ट:

मेरे एमवीपी के लिए एक स्प्लैश पेज टेक्स्ट लिखें। अनुभाग: (1) ग्राहक भाषा में शीर्षक (मूल्य प्रस्ताव), (2) समस्या-समाधान कथा, (3) 3 लाभ बिंदु, (4) एक स्पष्ट कॉल (पूर्व-पंजीकरण / प्रतीक्षा सूची)। अतिशयोक्तिपूर्ण वादों का प्रयोग करना; केवल यह दावा करता हूं कि मैं सत्यापित कर सकता हूं। तुर्की, सरल, ईमानदार.

कमजोर संकेत/मजबूत संकेत

कमजोर संकेत:

मेरे उत्पाद की सभी सुविधाओं की सूची बनाएं.

यह संकेत एमवीपी तर्क के विरुद्ध जाता है; यह एक लंबी इच्छा सूची तैयार करता है जो सीखने में देरी करता है और अति-इंजीनियरिंग को आमंत्रित करता है।

शक्तिशाली संकेत:

एकमात्र धारणा जिसका मैं परीक्षण करना चाहता हूं वह है: [x]। सबसे छोटे एमवीपी का वर्णन करें जो इस धारणा को सत्यापित करेगा, एक ऐसे संस्करण का प्रस्ताव करेगा जिसके लिए किसी कोड की आवश्यकता नहीं है, सुविधाओं को MoSCoW के साथ अलग करें और केवल अवश्य सेट छोड़ दें। मेरी सफलता मानदंड (जो परिणाम धारणा को मान्य करता है) पहले से न लिखने में मेरी सहायता करें।

दृष्टिकोण

सीखने की दर

लागत

जोखिम

शुरुआत से संपूर्ण उत्पाद बनाना

बहुत धीमा

उच्च

ग़लत चीज़ में पैसा न लगाएं

अत्यधिक इंजीनियरिंग/सोना चढ़ाना

धीमा

बहुत ऊँचा

सबसे महंगी गलती

केवल अनिवार्य रूप से प्रदर्शित एमवीपी

तेज़

कम

प्रबंधनीय

नो-कोड एमवीपी (लैंडिंग/एले)

सबसे तेज़

सबसे कम

प्रारंभिक शिक्षा

सामान्य गलतियाँ

• एमवीपी को संपूर्ण उत्पाद समझने की भूल। एमवीपी सीखने की सबसे छोटी इकाई है, परिष्कृत समापन नहीं।
• अति-इंजीनियरिंग. जब आसपास कोई ग्राहक न हो तो पैमाने/पूर्णता पर महीनों बिताना; सबसे महंगी गलती.
• सीखने के प्रश्न को परिभाषित नहीं करना. एक एमवीपी जो यह नहीं जानता कि वह क्या परीक्षण कर रहा है वह दिशाहीन बर्बादी है।
• सफलता के मापदंड बाद में तय करना. यदि मानदंड पहले से नहीं लिखे गए हैं, तो प्रत्येक परिणाम को "सफलता" के रूप में समझा जाएगा।
• नो-कोड विकल्पों को दरकिनार करना। लैंडिंग पृष्ठ/वीडियो/लेखन कोड जब आप सेवा के साथ मैन्युअल रूप से इसका परीक्षण कर सकते हैं।

सावधानी: एआई एक प्रोटोटाइप या कोड ड्राफ्ट तैयार कर सकता है, लेकिन उत्पादित कोड की सुरक्षा, सटीकता और कानूनी अनुपालन के लिए आप जिम्मेदार हैं। विशेष रूप से भुगतान, व्यक्तिगत डेटा या सुरक्षा से जुड़े एमवीपी में, एआई आउटपुट एक प्रारंभिक स्केच है; यह आवश्यक है कि लाइव होने से पहले एक सक्षम डेवलपर/विशेषज्ञ इसकी समीक्षा करे।

सारांश

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

आवेदन कार्य

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

जांच सूची

• [ ] क्या मैंने अपने एमवीपी परीक्षणों में सीखने वाला एक प्रश्न स्पष्ट रूप से लिखा है?
• [ ] क्या मैंने नो-कोड एमवीपी संस्करण का मूल्यांकन किया है?
• [ ] क्या मैंने सुविधाओं को प्राथमिकता दी और केवल "अवश्य" क्लस्टर छोड़ दिया?
• [ ] क्या मैंने प्रकाशन से पहले सफलता मानदंड परिभाषित किया है?
• [ ] क्या मैंने तकनीकी/कानूनी-महत्वपूर्ण आउटपुट को विशेषज्ञ समीक्षा के लिए छोड़ दिया है?