CB Insights स्टार्टअप विफल होने के कारण का एक वार्षिक विश्लेषण प्रकाशित करता है। वर्षों से, पहला कारण समान रहा है: "कोई बाजार की जरूरत नहीं।" खराब निष्पादन नहीं। पैसा खत्म नहीं होना। बुरी टीम नहीं। उत्पाद ने बस उस समस्या को हल नहीं किया जो लोगों को अपना व्यवहार बदलने के लिए पर्याप्त कारण था।
यह आंकड़ा आश्चर्यजनक है जब आप विचार करते हैं कि उत्पाद बनाने में कितना प्रयास जाता है। टीमें महीनों — कभी-कभी वर्षों — डिजाइनिंग सिस्टम, कोड लिखने, आर्किटेक्चर के बारे में बहस करने और प्रवाह को परिपूर्ण करने में व्यतीत करती हैं। और सबसे आम कारण वे विफल हो जाते हैं यह है कि किसी ने पूछा नहीं कि क्या कोई इसे हल कर रहा है वास्तविक समस्या।
लोग वास्तव में चाहते हैं उत्पाद बनाना एक प्रतिभा नहीं है। यह एक अनुशासन है। इसकी एक विधि है, और वह विधि सीखी जा सकती है।
सबसे आम उत्पाद गलती समस्या को गहराई से समझने से पहले एक समाधान से प्यार करना है। यह लगभग सार्वभौमिक है पहली बार संस्थापकों में और अनुभवी लोगों में काफी सामान्य है। पैटर्न हमेशा समान है: किसी के पास एक विचार है, वे इसे सम्मोहक पाते हैं, और वे निर्माण शुरू करते हैं। ग्राहक एक विचार है — किसी को समझा जाए, समझा नहीं।
दुष्प्रभाव जटिल नहीं है लेकिन इसमें अनुशासन की आवश्यकता है: समस्या पर अधिक समय व्यतीत करें जितना आप सोचते हैं कि वारंट है, इससे पहले कि आप सभी समाधान पर विचार करें। उन लोगों से बात करें जिनकी समस्या है। उन्हें काम करते देखें। उन वर्कअराउंड को समझें जो वे आज उपयोग करते हैं और वे अपूर्ण क्यों हैं। केवल तभी आपके पास पर्याप्त संदर्भ है कि कुछ डिजाइन करने के लिए जो वास्तव में फिट बैठता है।
अच्छा उत्पाद विकास एक सीधी रेखा नहीं है — यह एक पाश है। पाश के चारों ओर प्रत्येक पुनरावृत्ति मान्यताओं को साक्ष्य के साथ बदलने का एक अवसर है। ऐसी टीमें जो लोग चाहते हैं उत्पाद बनाती हैं वे हैं जो इस पाश को जल्दी और अक्सर पूरा करते हैं।
पाश एक औपचारिकता नहीं है। प्रत्येक चरण का एक विशिष्ट आउटपुट होता है जो अगले के लिए इनपुट बनता है। चरणों को छोड़ना — सबसे आम है समस्या से सीधे निर्माण के लिए छोड़ना — ऐसे उत्पाद का उत्पादन करता है जो चिह्न को मिस करते हैं।
सभी समस्याएं हल करने के लायक नहीं हैं। एक अच्छी उत्पाद समस्या के तीन गुण हैं: यह बार-बार होती है (लोगों को अक्सर प्रभावित करती है, शायद ही कभी नहीं), यह गहन है (लोग इसे पर्याप्त महसूस करते हैं कि वे राहत चाहते हैं), और मौजूदा समाधान वास्तव में अपर्याप्त हैं (न केवल थोड़ा आप जो बनाएंगे उससे अलग)।
गलती पहली गुणवत्ता को अनुकूलित करना और अन्य दो को अनदेखा करना है। "लोग बैठकों में समय बर्बाद करते हैं" बार-बार होता है। लेकिन अगर दर्द कम है — अगर लोगों को अच्छा-पर्याप्त वर्कअराउंड मिल गए हैं — तो समस्या व्यावसायिक रूप से हल करने के लायक नहीं हो सकती। और अगर पहले से ही बारह उपकरण हैं जो आप करना चाहते हैं, तो आपको एक बहुत विशिष्ट कारण चाहिए कि क्यों आप चुने जाएंगे।
अनुसंधान का उत्पाद सर्कलों में एक बुरा प्रतिष्ठा है — यह धीमी परामर्श फर्मों, मोटी रिपोर्ट और निष्कर्षों के साथ जुड़ा है जो कोई नहीं पढ़ता है। यह कार्यान्वयन की विफलता है, व्यवहार की नहीं। अच्छे उत्पाद अनुसंधान तेजी, विशिष्ट, और क्या आप निर्माण परिवर्तन।
अनुसंधान का लक्ष्य यह नहीं है कि समस्या वास्तविक है। आप भारी अनुसंधान में निवेश करने से पहले पहले से ही विश्वास करना चाहिए। लक्ष्य समस्या को पर्याप्त गहराई से समझना है ताकि आप जानें कि एक अच्छा समाधान कैसा दिखता है: विशेष रूप से किसी के पास समस्या है, किस संदर्भ में, वे पहले से ही क्या कोशिश कर चुके हैं, वे क्या शब्दों का उपयोग करते हैं इसका वर्णन करने के लिए, और क्या "हल" उनके लिए दिखेगा।
एक अनुमान एक विशिष्ट, गलत प्रमाणित भविष्यद्वाणी है कि आप क्या मानते हैं यह सच है। यह स्पष्टता को मजबूर करता है। यदि आप एक स्पष्ट अनुमान नहीं लिख सकते हैं, तो आप अभी तक समस्या को पर्याप्त रूप से समझ नहीं पाए हैं ताकि एक समाधान का निर्माण कर सकें।
एक उपयोगी उत्पाद अनुमान के तीन भाग हैं:
संकेत सबसे महत्वपूर्ण भाग है — और सबसे आम तौर पर छोड़ा गया। एक पूर्व-प्रतिबद्ध संकेत के बिना, हर प्रयोग "तरह का काम किया।" टीमें अस्पष्ट डेटा को अनुकूल रूप से व्याख्या करने के तरीके खोजती हैं। एक अनुमान एक गलत प्रमाणन शर्त के बिना बस एक इच्छा है।
निर्माण चरण वह है जहां अधिकांश टीमें बहुत अधिक समय व्यतीत करती हैं। लक्ष्य उत्पाद निर्माण नहीं है — यह न्यूनतम चीज़ बनाने के लिए है जो आपके अनुमान पर संकेत देगी। ये अलग-अलग उद्देश्य हैं और वे बहुत अलग-अलग आउटपुट उत्पन्न करते हैं।
अधिकांश प्रारंभिक चरण अनुमानों के लिए, न्यूनतम टीमें क्या सोचते हैं उससे कहीं अधिक कम है। क्या आप मैन्युअल रूप से यह कर सकते हैं कि सॉफ्टवेयर क्या करेगा, दस लोगों के लिए, यह परीक्षण करने के लिए कि क्या वे परिणाम को महत्व देते हैं? क्या आप मौजूदा उपकरणों को एक साथ सिलाई कर सकते हैं और नई अवसंरचना को बनाने से पहले वर्कफ़्लो का परीक्षण कर सकते हैं? क्या आप एक प्रोटोटाइप स्केच कर सकते हैं और इसे पांच उपयोगकर्ताओं के साथ चलाने से पहले किसी भी कोड लिख सकते हैं?
यहाँ अनुशासन है कि कुछ भी बनाने से पहले पूछना: "मैं क्या सीखने की कोशिश कर रहा हूँ?" और "न्यूनतम चीज़ क्या है जो मुझे इसे सीखने देगी?" उत्तर लगभग हमेशा टीम जो बनाना चाहती है उससे छोटा होता है।
लॉन्च के बाद — चाहे वह प्रोटोटाइप, मैनुअल पायलट, या तैनात सुविधा हो — माप चरण वह है जहां टीमें खुद को सबसे आम तौर पर मूर्ख बनाती हैं। वे उपयोगकर्ताओं से पूछते हैं कि क्या उन्हें यह पसंद था। उपयोगकर्ता हाँ कहते हैं। टीम प्रयोग को सत्यापित के रूप में चिह्नित करती है।
भावना संकेत नहीं है। एकमात्र विश्वसनीय संकेत व्यवहार है: क्या लोगों ने चीज़ की? क्या वे वापस आए? क्या उन्होंने भुगतान किया? क्या उन्होंने किसी और को बताया?
मात्रात्मक माप के लिए, लॉन्च से पहले की जांच करें। जानें कि आप कौन से विशिष्ट कार्यों को ट्रैक कर रहे हैं। एक दहलीज सेट करें अग्रिम — "हम इसे सत्यापित मानेंगे यदि X% उपयोगकर्ता Z दिनों के भीतर Y पूरा करते हैं।" गुणात्मक माप के लिए, संरचित अनुवर्ती साक्षात्कार संचालित करें, खुली-समाप्त संतुष्टि सर्वेक्षण नहीं।
सीखने का चरण आपके उपयोगकर्ता और समस्या की मानसिक मॉडल को अपडेट करने के बारे में है, न कि केवल निर्णय लें कि अगले क्या बनाना है। ऐसी टीमें जो इस चरण को छोड़ देती हैं डेटा एकत्र करती हैं लेकिन समझ जमा नहीं करती हैं। वे जल्दी निष्पादन करते हैं लेकिन समय के साथ अपनी पूर्वाभास में सुधार नहीं करते।
एक अच्छा सीखने सत्र पूछता है: हमने क्या भविष्यद्वाणी की? वास्तव में क्या हुआ? अंतर हमारी मान्यताओं के बारे में हमें क्या बताता है? सबसे महत्वपूर्ण चीज़ क्या है जो हम अभी नहीं जानते हैं?
सीखने का चरण एक तीक्ष्ण समस्या परिभाषा, एक संशोधित अनुमान, या — यदि प्रयोग स्पष्ट रूप से विफल हुआ है — पूरी तरह से एक अलग दिशा को आगे बढ़ाने का एक निर्णय है। ये सभी परिणाम मूल्यवान हैं। सबसे खराब परिणाम अस्पष्टता है: "हमने कुछ सीखा लेकिन यह सुनिश्चित नहीं है कि अगले क्या करना है।" यह एक संकेत है कि प्रयोग काफी विशिष्ट नहीं था।
उत्पाद विकास कभी भी उस चरण तक नहीं पहुंचता है जहां आप इस पाश को चलाना बंद कर देते हैं। सवाल बदलते हैं — जल्दी पर आप सत्यापन कर रहे हैं कि समस्या वास्तविक है; बाद में आप सत्यापन कर रहे हैं कि क्या एक विशिष्ट समाधान तत्व काम कर रहा है — लेकिन संरचना हमेशा समान है। अवलोकन करें, परिकल्पना करें, परीक्षण करें, सीखें।
ऐसी टीमें जो लोग चाहते हैं उत्पाद बनाती हैं वे सबसे चतुर प्रारंभिक अंतर्दृष्टि वाले नहीं हैं। वे सबसे तेजी से और सबसे ईमानदारी से पाश पूरा करते हैं। सीखने की गति, शिपिंग की गति नहीं, प्रतिस्पर्धात्मक लाभ है।