मिनिमम वायबल प्रोडक्ट (MVP): कम बनाएँ, तेज़ी से सीखें

FabricLoop टीम द्वारा · मई 2026 · 9 मिनट में पढ़ें

"MVP" शब्द का इतना ज़्यादा और इतने ढीले ढंग से इस्तेमाल हुआ है कि उसका अर्थ लगभग खो गया है। संस्थापक इसे पॉलिश किए हुए v1 लॉन्च, कच्चे प्रोटोटाइप, लैंडिंग पेज और इनके बीच की हर चीज़ के लिए इस्तेमाल करते हैं। कुछ लोग इसे कुछ टूटा-फूटा शिप करने के बहाने के तौर पर इस्तेमाल करते हैं। कुछ इसे हमेशा बनाते रहने की वजह बना लेते हैं ("यह अभी वायबल नहीं है")।

मूल परिभाषा — एरिक राइस की Lean Startup से — सटीक है: MVP किसी प्रोडक्ट का वह संस्करण है जिससे कम से कम मेहनत में ग्राहकों के बारे में अधिकतम प्रमाणित सीख (validated learning) जुटाई जा सके। यह सीखने का औज़ार है, प्रोडक्ट लॉन्च नहीं।

सबसे अहम शब्द: वायबल

"मिनिमम" मुश्किल हिस्सा नहीं है। संस्थापक स्वाभाविक रूप से फ़ीचर घटाने की ओर झुकते हैं। मुश्किल हिस्सा "वायबल" है। एक वायबल प्रोडक्ट इतना मूल्य देता है कि कोई सचमुच उसका इस्तेमाल करे और आपको ईमानदार फ़ीडबैक दे — या आदर्श रूप से, उसके लिए भुगतान करे।

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

MVP एक परिकल्पना की जाँच है

MVP के बारे में सोचने का सबसे अच्छा तरीका इसे स्पष्ट रूप से कही गई परिकल्पना वाले प्रयोग की तरह देखना है। कुछ भी बनाने से पहले लिख लें:

अगर आप गलत साबित होने की स्पष्ट शर्त नहीं बता सकते, तो आप परिकल्पना नहीं परख रहे — आप प्रोडक्ट बना रहे हैं। MVP तभी काम करता है जब आप पहले से तय कर लें कि "ना" कैसा दिखता है।

MVP का स्पेक्ट्रम: नकली से लेकर कार्यात्मक तक

MVP पूरी तरह मैनुअल से लेकर पूरी तरह स्वचालित तक एक स्पेक्ट्रम पर होते हैं। आपको इस स्पेक्ट्रम पर कहाँ होना चाहिए, यह इस पर निर्भर करता है कि आप क्या सीखना चाहते हैं और परीक्षण में कितना निवेश करने को तैयार हैं।

कई संस्थापक सीधे "फ़ंक्शनल MVP" पर कूद जाते हैं क्योंकि वह सबसे वैध लगता है। लेकिन कंसीयर्ज MVP — 10 ग्राहकों को हाथ से सेवा देना — अक्सर छह महीने के निर्माण से ज़्यादा दो हफ़्तों में सिखा देता है। लक्ष्य सीखना है, प्रोडक्ट नहीं।

MVP में क्या शामिल हो और क्या नहीं

स्कोप का फ़ैसला वह जगह है जहाँ ज़्यादातर MVP गड़बड़ा जाते हैं। क्या शामिल करें, इसके लिए एक ढाँचा:

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

MVP और बीटा का अंतर

ये एक ही चीज़ नहीं हैं और इन्हें मिलाने से समस्याएँ पैदा होती हैं। MVP एक प्रयोग है जो परिकल्पना को परखने के लिए बना है। बीटा आपके इच्छित प्रोडक्ट का शुरुआती संस्करण है जिसे आम उपलब्धता से पहले परीक्षण के लिए जारी किया जाता है।

MVP को प्रयोग के बाद पूरी तरह फेंका जा सकता है। बीटा आमतौर पर उस चीज़ की बुनियाद होता है जो आप शिप करेंगे। MVP प्रति इकाई मेहनत अधिकतम सीख के लिए बनता है। बीटा लगभग पूरे प्रोडक्ट में बग ढूँढने के लिए बनता है।

आपके पास कोड की एक लाइन लिखे बिना भी MVP हो सकता है। काफ़ी हद तक बन चुके प्रोडक्ट के बिना बीटा नहीं हो सकता।

कैसे जानें कि आपका MVP सफल रहा

अपनी परिकल्पना पर लौटें। MVP "सफल" तब नहीं जब लोगों ने अच्छी बातें कहीं, बल्कि तब जब उन्होंने वही विशिष्ट व्यवहार किया जिसका आपने अनुमान लगाया था। तारीफ़ें वैलिडेशन नहीं हैं। प्रतिबद्धताएँ — समय, पैसा, बार-बार इस्तेमाल — वैलिडेशन हैं।

तीन संकेत कि आपके MVP ने परिकल्पना सही साबित की:

• उपयोगकर्ता बिना याद दिलाए लौटे
• कम से कम एक व्यक्ति ने बिना दबाव के भुगतान किया (या भुगतान की प्रतिबद्धता जताई)
• कोई फ़ीचर न होने पर उपयोगकर्ता उलझे या निराश हुए — यानी उन्होंने उस पर निर्भर रहने की योजना बनाई थी

तीन संकेत कि ऐसा नहीं हुआ:

• उपयोगकर्ताओं ने कहा कि उन्हें पसंद आया पर दोबारा इस्तेमाल नहीं किया
• सकारात्मक फ़ीडबैक ज़्यादातर दोस्तों और परिवार से आया
• उनके समझ पाने से पहले आपको विस्तार से समझाना पड़ा कि यह उपयोगी क्यों है